You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a similar idea as the recommendation on how to name storage locations for transient storages, just applied to scoreboard players.
I generally like having only one temporary objective, since objective names are far more limited in size than scoreboard player names (16 vs 40).
Because of that, I often run into annoyances where I accidentally re-use a player name from an outer function.
Because of that, I came up with the idea to use a path/to-pattern for player names in globally used temporary objectives.
I don't think it's a good solution to use more scoreboard objectives instead, since you'd probably end up with a scoreboard per "area"/sub-dir or whatever. The problem I am describing however happens most commonly between functions that call each other of the same sub-dir.
So I simply define a namespace.temp objective and the player names within that are called either entirely accurately like the path of the function, or uses short forms to still fit within the character limit.
Furthermore, for variables that are meant to be "global" within a subdir, I only use the path/to/subdir naming.
I separate the actual name of the player name using a dot (.).
It is not necessary to namespace player names, since they are located within an already namespaced scoreboard objective.
Does that make sense and should it perhaps be included in this repository's recommendations?
The text was updated successfully, but these errors were encountered:
This is exactly what I used to do, until I hit the 40 character fakeplayer limit. I started using arbitrary abbreviations and in some cases a single word when the scores were only ever being used within the same scope. It became arbitrary and I realized that in general it's up to me to decide how to namespace fakeplayers within my own objective.
That being said, many of the points/strategies you brought up are still useful, and entirely valid with sane function names so it might be worth adding them to the recommendations somewhere.
(The recommendations are somewhat outdated and even my own patterns have changed since then. I'm not sure when I'll next update this, as I'm in the process of rewriting a fairly complex pack that I've historically used to prototype everything IMP.)
This is a similar idea as the recommendation on how to name storage locations for transient storages, just applied to scoreboard players.
I generally like having only one temporary objective, since objective names are far more limited in size than scoreboard player names (16 vs 40).
Because of that, I often run into annoyances where I accidentally re-use a player name from an outer function.
Because of that, I came up with the idea to use a path/to-pattern for player names in globally used temporary objectives.
I don't think it's a good solution to use more scoreboard objectives instead, since you'd probably end up with a scoreboard per "area"/sub-dir or whatever. The problem I am describing however happens most commonly between functions that call each other of the same sub-dir.
So I simply define a
namespace.temp
objective and the player names within that are called either entirely accurately like the path of the function, or uses short forms to still fit within the character limit.Furthermore, for variables that are meant to be "global" within a subdir, I only use the path/to/subdir naming.
I separate the actual name of the player name using a dot (
.
).It is not necessary to namespace player names, since they are located within an already namespaced scoreboard objective.
Does that make sense and should it perhaps be included in this repository's recommendations?
The text was updated successfully, but these errors were encountered: