#What Code would do you prefer ?
1 messages · Page 1 of 1 (latest)
Variant 1:
data remove value depth
execute if entity @s score 51 run data modify depth set value 2b
execute if entity @s score 5111 run data modify depth set value 3b
execute if entity @s score 5121 run data modify depth set value 3b
execute if entity @s score 512111 run data modify depth set value 4b
execute if entity @s score 512121 run data modify depth set value 4b
execute if entity @s score 51212111 run data modify depth set value 5b
execute if entity @s score 512131 run data modify depth set value 6b
execute if entity @s score 51213111 run data modify depth set value 6b
function 2 with storage
execute if data {depth:6b,source:"group_defaults"} run function 3
execute unless data locked if data {source:"current_properties"} \
if data {depth:2b} run data modify source set "property_defaults"
execute unless data locked if data {source:"current_properties"} \
if data {depth:3b} run data modify source set "structure_defaults"
execute unless data locked if data {source:"current_properties"} \
if data {depth:4b} run data modify source set "variant_defaults"
execute unless data locked if data {source:"current_properties"} \
if data {depth:5b} run data modify source set "group_defaults"
execute unless data locked if data {source:"group_defaults"} \
if data {depth:2b} run data modify source set "property_defaults"
execute unless data locked if data {source:"group_defaults"} \
if data {depth:3b} run data modify source set "structure_defaults"
execute unless data locked if data {source:"group_defaults"} \
if data {depth:4b} run data modify source set "variant_defaults"
execute unless data locked if data {source:"group_defaults"} \
if data {depth:5b} run data modify source set "variant_defaults"
execute unless data locked if data {source:"variant_defaults"} \
if data {depth:2b} run data modify source set "property_defaults"
execute unless data locked if data {source:"variant_defaults"} \
unless data {depth:2b} run data modify source set "structure_defaults"
execute unless data locked if data {source:"structure_defaults"} \
run data modify source set "property_defaults"
execute unless data locked if data {source:"property_defaults"} \
run data modify source set "current_properties"
Variant 1 use NBT data storage key 'depth' as logical OR to combine two valid scores.
Variant 2:
function 2 with storage
execute if predicate ? run function 3
execute if predicate ? run function 3
-- Side Question is it possible to integrate two NBT storage values into a predicate for a logical OR ?
if (source:"current_properties" OR "group_defaults"): run function 3
execute unless data locked if predicate ? run data modify source set ...
Variant 2 use predicate instead of a NBT data storage as logical OR to combine two valid scores.
Variant 3:
function 2 with storage
execute if score @s 512131 if data {source:"current_properties"} run function 3
execute if score @s 51213111 if data {source:"current_properties"} run function 3
execute if score @s 512131 if data {source:"group_defaults"} run function 3
execute if score @s 51213111 if data {source:"group_defaults"} run function 3
...
Variant 3 use only the score.
What are you actually trying to do?
optimization.
No like functionality wise, why do you need this code?
for a chat menu
Please explain in more detail. I'm needing some more context here to get a correct view on your code.
The current Code works. Now i want to improve the Code. I think my current NBT storage value 'depth' is not neccessary.```
But sadly it is a logical or, because in most cases (not in all), two pages set the same depth value (3b, 4b, 6b)
The depth is set in function 1 . But function 2 that reads depth use it. When i remove 'depth' i have double the code in function 2, because now i have to check for each page score.
I never used predicates, but i think it is possible to create a logical OR with predicates, so i have not to double the code in function 2. And maybe its possible to integrate a NBT check as logical OR in a predicate, so i need only one command for calling function 3.
But maybe my current code is fine with using NBT storage and the outsourcing into a predicate makes the function file more difficult to understand and disrupt read flow, because command conditions no longer clear visible in the function and now outsource in a predicate.
So im thinking about Variant 1 (currently) and Variant 2.
Variant 3 with only use score it looks like for me it has more performance issue, because much more code has to check in function 2.
So my main Question is led the code unchanged or use predicate ? Or use only score condition but in this case please explain me why only score condition is better than variant 1 or 2 . i would wonder about this. i dont think variant 3 with only score condition is better. but you can surprise me.
for predicates, you can use this handy generator https://misode.github.io/predicate/
Should i use predicates for this case or not ? Make it sense?
Because it is better in performance or because it reducing the amount of required command lines ?
a predicate isn't able to match storage nbt
my only disadvantage for predicate is it interrupting the reading flow of the function for human or ai, because condition is outsorced.
So ```
execute ( if data {source:"current_properties"} OR if data {source:"group_defaults"} ) run function 3
is not possible
with
execute if predicate abcde run function 3
predicate abcde:
condition alternative
if nbt {source:"current_properties"}
or
if nbt {source:"group_defaults"}
ok so I think I fully understand your problem now and I have a possible fix:
- check if the storage matches
current_propertiesand set a fake player scoreboard to 1 - check if the storage matches
variant_defaultsand set a fake player scoreboard to 2 - else set the score to 0
- now you can store the depth data in another fake player scoreboard using
execute store - this narrows down your conditions to only 4 score checks and 3 nbt checks which is a lot better than the 8 nbt checks you needed earlier. You can now do the logic OR by using score check ranges
execute if score <fake_player> matches 1..2
nbt checks are just really expensive so it's best to reduce them as much as possible
No that dont work. In my current System 'depth' only says Player is on page X and for page X there are this sources allowed as choice:
execute if entity @s score 51 run data modify depth set value 2b
execute if entity @s score 5111 run data modify depth set value 3b
execute if entity @s score 5121 run data modify depth set value 3b
execute if entity @s score 512111 run data modify depth set value 4b
execute if entity @s score 512121 run data modify depth set value 4b
execute if entity @s score 51212111 run data modify depth set value 5b
execute if entity @s score 512131 run data modify depth set value 6b
execute if entity @s score 51213111 run data modify depth set value 6b
depth:2b = ['current_properties','property_defaults']
depth:3b = ['current_properties','structure_defaults','property_defaults']
depth:4b = ['current_properties','structure_defaults','variant_defaults','property_defaults']
depth:5b = ['current_properties','structure_defaults','variant_defaults','group_defaults','property_defaults'] ('group_quality_properties Page 51212111' use a special interpretation of source 'group_defaults')
depth:6b = ['current_properties','structure_defaults','variant_defaults','group_defaults','property_defaults'] ('piece_properties' Page 512131 and 'piece_quality_properties' Page 51213111)
After posting this i re-reading your last message, to make sure i understand it fully
yea looks possible to me with the system described. Which part do you not understand?
give me 15-30 minutes. i have to think and translate with gemini and discuss with gemini about your solution.
i will ping you when i can give a answer to you.
-# please don't use AI it will only waste your time, sanity and waay to much electricity :P
anyways I'mma go sleep so see you tomorrow
Variant 1 is invalid syntax, your AI hallucinated new command syntax
https://de.minecraft.wiki/w/Pr%C3%A4dikate#entity_scores
- entity_scores + this for page check
- value_check + value{}
https://de.minecraft.wiki/w/Beutetabellen#storage_(Datenspeicher)
- type storage
- path to key value requires number but in my current system it is a string
length of("current_properties") = 18
length of("group_defaults") = 14 ; 14==18 false good.
But unsecure if this works with string, need to test.
If dont work with string as value than entire system has to change --> not possible = trash is improvment idea but predicate use for entity score check remains
Im now sure that variant 3 with only using score condition in function 2 is no longer a choice.
theblackswitch idea is:
if @s score is 51 set score #depth to 2
if @s score is 5111 set score #depth to 3
if @s score is 5121 set score #depth to 3
if @s score ...
instead of nbt value for depth
nbt check in predicate is possible, maybe also for string value if not entire system has to change from string to number value --> destroys datapack readablity unclear for what a specific number stands. i already have this problem with my chat menu page scores instead of page titles.
predicates for player current page score would better for performance
but heavy damaging datapack readability because condition outsourced into another file.
The question now is when one should use predicates and whether it is worth doing so in my specific case.
current function 1: 13 commands (1 reset, 8 set)
current function 2: 19 commands ([17 macro], 2 for function 3, 10 for condition)
variant 3 would reduce in function 1 from 13 commands to 4 commands. (-9 commands)
variant 3 would increase in function 2 from 19 commands to 29 commands.
variant 2 with predicate would reduce in function 1 from 13 commands to 4 commands. (-9 commands)
variant 2 with predicate would hold in function 2 from 19 commands to 19 commands (+/- 0 commands),
maybe -1 command if len(string) as value works in predicate
Oh no these commands are not from a AI, there from me 🙂
Never heard from pseudo-code ? Its offensive for me that all of my posted commands here dont work if you copy them into the game, because there imcomplete. But for logical understand it is not required that there are complete.
As result of this thread i definive change the value type for 'depth' from NBT to score. Now i only think if i should use prediactes in function 2 for 10 commands. ...
scores can be checked without predicates more efficiently
And your code isn't what I would call pseudo code since you increase the text needed rather than reduce it (typically pseudo code simplifies and shortens the code to describe a concept)
Scores are checked with execute if score
Can you teach me how in future i have to write the current code as psyeudo-code ?
As example:
data remove value depth
execute if entity @s score 51 run data modify depth set value 2b
execute if entity @s score 5111 run data modify depth set value 3b
execute if entity @s score 5121 run data modify depth set value 3b
execute if entity @s score 512111 run data modify depth set value 4b
execute if entity @s score 512121 run data modify depth set value 4b
execute if entity @s score 51212111 run data modify depth set value 5b
execute if entity @s score 512131 run data modify depth set value 6b
execute if entity @s score 51213111 run data modify depth set value 6b
function 2 with storage ```
How looks your pseudo-code ? Im interessted
If you want i can give you the true big code in my function that is represented by the upper example
execute if score @s something matches 5123111 run ...
You don't need to sprinkle arguments that are invalid in there when they increase the length and decrease readability, while also being full on invalid syntax.
execute if score @s 51 run data set depth 2b is that pseudo-code ? Because your meaning "sprinkle arguments "
It would be yes, you reduce parts that are not important to the concept at hand. It isn't too important however for the broader discussion or idea you work on.
Last Question @inner fable , would do you use predicates for 10 commands ? (if predications function 1 has from 13 commands to 4 commands (-9 commands))
If I understand correctly your predicate would have to check if a score is any_of some values?
Yes, a predicate as a logical OR
Are these scores in a continuous range?
No explicit. thats why i use "data remove" to make sure only these 8 scores of pages are allowed.
I would need 3 predicates. (for 3b, 4b and 6b)
See my Code here: #1524878795020959784 message
If it is a continuous range or you can make it to be as such, you can use matches <start>..<end> otherwise a predicate makes sense
Give me a simple yes or no for predicates. I can't use if score matches, because i dont want to allow that a player can trigger the pipeline from a invalid page score. only from these explicit pages.
Why would that not allow if score matches?
Because if those are a problem then your entire problem has exactly 0 solutions
Predicates don't perform any weird magic you can't do otherwise with scores
it can bundle it nicely, which for a logical OR is definitely a good thing.
Know that you can use de Morgan's Laws to cook weird stuff with if and unless score chains.
if the player triggers this pipeline from a page that are not intended to use these pipeline, it would produce errors. unpredicatable behavior. data storage destory. But wait ... i check your code idea:
execute if score @s matches 51 run data modify depth set value 2b
execute if score @s matches 5111 .. 5121 run data modify depth set value 3b
execute if score @s matches 512111 .. 512121 run data modify depth set value 4b
execute if score @s matches 51212111 run data modify depth set value 5b
execute if score @s matches 512131 ..51213111 run data modify depth set value 6b
execute if score @s 51 run data modify depth set value 2b
execute if score @s 5111 run data modify depth set value 3b
execute if score @s 5121 run data modify depth set value 3b
execute if score @s 512111 run data modify depth set value 4b
execute if score @s 512121 run data modify depth set value 4b
execute if score @s 51212111 run data modify depth set value 5b
execute if score @s 512131 run data modify depth set value 6b
execute if score @s 51213111 run data modify depth set value 6b
execute if score @s 51 run scoreboard set #depth 2
execute if score @s 5111 run scoreboard set #depth 3
execute if score @s 5121 run scoreboard set #depth 3
execute if score @s 512111 run scoreboard set #depth 4
execute if score @s 512121 run scoreboard set #depth 4
execute if score @s 51212111 run scoreboard set #depth 5
execute if score @s 512131 run scoreboard set #depth 6
execute if score @s 51213111 run scoreboard set #depth 6
Hmm i think i use predicates. Its better than definding a #depth score value or a depth nbt key.
i need 3 predicates (one for 3b, one for 4b and one for 6b) to create 3 logical OR
#at least 1 of A or B or C is true```
Because we run a return we negate the entire chain again for the line below
not (A or B) = (not A) and (not B)
If you return on not (A or B) you know any line that follows only runs if (A or B) = true
I don't mind or blame you for making a predicate instead however
execute unless data locked if data {source:"current_properties"}
if data {depth:2b} run data modify source set "property_defaults"
execute unless data locked if data {source:"current_properties"}
if data {depth:3b} run data modify source set "structure_defaults"
execute unless data locked if data {source:"current_properties"}
if data {depth:4b} run data modify source set "variant_defaults"
execute unless data locked if data {source:"current_properties"}
if data {depth:5b} run data modify source set "group_defaults"
execute unless data locked if data {source:"current_properties"}
if score #depth matches 2 run data modify source set "property_defaults"
execute unless data locked if data {source:"current_properties"}
if score #depth matches 3b run data modify source set "structure_defaults"
execute unless data locked if data {source:"current_properties"}
if score #depth matches 4b run data modify source set "variant_defaults"
execute unless data locked if data {source:"current_properties"}
if score #depth matches 5b run data modify source set "group_defaults"
execute unless data locked if data {source:"current_properties"}
if score @s matches 51 run data modify source set "property_defaults"
execute unless data locked if data {source:"current_properties"}
if predicate depth_3 run data modify source set "structure_defaults"
execute unless data locked if data {source:"current_properties"}
if predicate depth_4 run data modify source set "variant_defaults"
execute unless data locked if data {source:"current_properties"}
if score @s matches 51212111 run data modify source set "group_defaults"
I never used these new "return" command. i only know that it stops the function at this point and the commands below are not executed. but i dont see a use case for me for this new "return" command.
It is very useful, as I explained above it allows you to stop running commands when a condition is true but run some clean up or alternative commands when false.
By all means use a predicate when you don't want to bother doing it.
You can also wrap the entire thing in a function and use execute if function
if function always cares about the return you want to return fail or some value
I only use the new macro function feature. ... massivly because it makes so much easier more python style
You should avoid macros when you can, they are incredibly slow
Compared to alternatives that is.
There exist tools that allow you to write a mix of python and commands to produce mcfunction files
Sometimes you have to use macros, don't worry. Just be aware that they are several degrees slower than normal functions.
Yeah im definitve not a pro-datapack developer. that i now see with this discussion.
your if unless condition chains. yes maybe it reduce the amount of commands, but makes the code more difficult to understand.
Or i have a problem of understand more complex code, that use deeper logics.
I think we should slowly end now this discussion, before we waste more time.
Any last words, before i close this discussion ?
Im decided to use predicates now, because there i understand better than your long logical condition score check chain.
Try to keep your macro usage as small as possible.
A lot of problems/challenges can be solved without a macro.
For a logical OR a predicate reads much more like a human would read and I doubt the performance will be that much different.
As for the chain of commands, you can read de Morgan's Laws on Wikipedia should you ever want to understand why/how they work.
Or boolean algebra in general
Thank you Quimoth and theblackswitch
DISCUSSION CLOSED - PROBLEM SOLVED