@wysohn @gerzytet
I often find myself wanting to have a better organized var.yml because otherwise things get added into it in a somewhat haphazard way, no? As my server project continues to grow, var.yml is starting to get unruly making it hard to do quick checks and assessments of various variables scattered throughout the file.

Here's an idea, if it might be plausible:

Ideally, one would be able to define a category header that would hold all variables that reference that category.

So instead of this ungrouped, unorganized:

PawPawDude:
playeruuid: 7d5f4943-030d-430c-865a-4ca1c3ea270c
arena-badlands-in-world-player1: '-'
CrashTestDummyX:
playeruuid: fd34bd02-a225-4877-8670-8422d9c2fc5d
arena-badlands-in-world-player2: '-'
arena-badlands-in-world-player3: '-'
arena-badlands-in-world-player4: '-'

... you could get this instead, grouped, organized:

Category: PlayerUUIDs
PawPawDude:
playeruuid: 7d5f4943-030d-430c-865a-4ca1c3ea270c
CrashTestDummyX:
playeruuid: fd34bd02-a225-4877-8670-8422d9c2fc5d
Category: ArenaBadlandsPlayersIndex
arena-badlands-in-world-player1: '-'
arena-badlands-in-world-player2: '-'
arena-badlands-in-world-player3: '-'
arena-badlands-in-world-player4: '-'

Two details about that approach:

1. A syntax would be needed to place a variable into the desired category. Perhaps something like this option for defining/referencing a global variable:
   {category:"myVarsCategoryName", "myGlobalVariableName"}

2. The onus would be on TR to insert new variables under the correct category (if one was specified), and if it's not present, create the category header in var.yml

In the end, var.yml could (should?) have a much more serviceable formatting for anyone that chooses to use the category syntax.

I suppose that "light" users of TR wouldn't need this, but heavy users like myself that really put TR through the paces definitely could use the help since referring to var.yml is a frequent activity when setting up new game functions and debugging.

Kindly consider and comment. Thanks.

PawPawDude

Sorry for make this matter hanging for long time

It's sometimes hard to keep track of everything. I'm glad that you brought this back to our attention.

The {,} syntax indeed seems amazing, but making category in a single file would be a difficult work since the snakeyaml, which is used for var.yml, doesn't support such thing.

Though, I think we can make a new file called PlayerUUIDs.yml as needed if category is provided.

For example,

{"var.iable"} = 3 would save 3 into var.yml, yet

{"PlayerUUIDs", "var.iable"} = 3 would save 3 into PlayerUUIDs.yml.

Let me know what you think about this slightly changed design.

@gmalone
Let us know what you think about the new design.

I will add to the track as soon as you approve it

Thank you for your thoughtful reply, @wysohn

It seems it would be a workable solution to generate a unique file for designated variable categories. Interesting.

I'm wondering, since it could/would lead to a slight proliferation of new files in the TR root folder, could these types of files have a common prefix, such as "var_" or similar? That way they would group and sort together in the file system.

Alternatively, could all the special category-var files be put in a subfolder named "vars"?

I'm just thinking ahead to the minor logistics of handling the files.

In any case, I do like the idea, and for all other TR users it would remain an option, not a requirement to use the feature. I personally think it will be popular with those that do elaborate workings with TR.

Thank you.

@gmalone
Sounds good!

I was actually thinking about how would I deal with the bunch of yml files being created.

vars folder would be the best solution by far.

It will be implemented in 3.1.x, so stay tuned!

@gmalone
No problem!

Unfortunately, snakeyaml doesn't have such option to begin with.

Also, because Bukkit API has their own implementation to provide shortcut to use snakeyaml, it's very limited what we can do about it.

Or, it will require us to use snakeyaml (or use different format like json) directly in order to try to implement sorting, yet I'm not sure if it would work.

In fact, if you want to use prefix to organize your global variables, why not use dot(.) notation?

{"my.variable.name"} would be

my:
    variable:
        name: "something"

in var.yml

So you can organize the variables hierarchically.

I do use dot (.) hierarchy extensively. It's a great technique. Hey no problem about sorting. I understand that there's no sorting baked into the snakeyml and Bukkit methods. No problem at all.

Just fyi, I haven't yet merged my project into TR v3.0, but intend to asap. Gotta get to a stopping point so can do so carefully.

Thanks @wysohn

Super exciting! Thanks @wysohn

One followup question:
When you fill a var file with its data, do you have the option to alpha sort the variables before writing them to file? If so, then all like-variables -- i.e. variables w/ same/similar prefixes -- would group together inside the file.

Be well. And thanks again.