Metadata and Resource handling.

[Zly-u]

Here's a new and much better in use pack's resource handling and how code loads it:

How OH should handle loading and the use of recourses in Lua:

Everything is a rough example, don't take it as an absolute idea of execution, it just provides the general idea.

• Load each pack in their separate handlers named after their folder names, which are the unique IDs

• For a currently made handler for a pack Recursively go through its files and add everything to its handler's storage. So in C++ it would look like something like this maybe: resourceManager[loaded_pack][folder_name][file_name_to_use]

• In pack1 in Lua when you use for example u_playSound("sound1.ogg") it just simply picks from the SFX array that selected sound of the pack. In an array it could look like something like this:

void playSound(string sound){
    sf::PlaySound(resourceManager.[mHexagonGame.loaded_pack]["SFX"][sound])
}

Or something close to that, and it works the same to every other resource of the pack, so there is no need of making external "identifications" or asset.json so the game can understand how to handle it when I reality we just simply could use pack's structure for that.

Some other ideas:

• exclude priority variable that has no use whatsoever, just load packs in whatever order really.
• segments in Music's metadata is redundant if we just could do that through lua in onLoad anyway like this:

local segments = {10, 60, 120, math.pi}
u_setMusicSeconds(musicId, segments[math.random(#segments)])

I already work on it, but just to keep a track of ideas here.

• Replace the execScript with just Lua's build in require, just set the pack's directory for script search in package.path on load. It will simplify the process of making module alike scripts that's very useful in scripting in general and execScript doesn't allow us to do so and in general, the function is just completely redundant.

[Morxemplum]

Load each pack in their separate handlers named after their folder names, which are the unique IDs

Ideally this is how we could've resolved issue #182, but Vee decided to go with adding a disambiguator to try and lower the odds. It can still be accomplished if someone were to intentionally try and sabotage someone's pack.

We could have Level related scripts exactly in the Level folder, and if we would need some extra functions we just could do execScript() which takes a script from Scripts folder [for further info check p.2 in Some other ideas below].

It's a good idea to have some organization, but we definitely shouldn't force how people should organize their scripts. That makes the structure not very flexible and it could make future updates much harder to implement.

exclude priority variable that has no use whatsoever, just load packs in whatever order really.

I was also thinking about getting rid of the priority variable as well. It's very arbitrary and can be easily abused by pack developers. I don't think we should make it random though. We need to probably sort the things alphabetically so there is at least some order to it.

segments in Music's metadata is redundant if we just could do that through lua in onLoad anyway like this:

I really do like this. Not only that, but it also makes music playback replay safe, so it will play on the same segment that the player started their attempt on. The only problem is how will we still display the music information on the menu.

Replace the execScript with just Lua's build in require, just set the pack's directory for script search in package.path on load. It will simplify the process of making module alike scripts that's very useful in scripting in general and execScript doesn't allow us to do so and in general, the function is just completely redundant.

Really great to see this. This also means we can deprecate u_execScript completely if this can be set up properly.

Good stuff

[Zly-u]

It's a good idea to have some organization, but we definitely shouldn't force how people should organize their scripts. That makes the structure not very flexible and it could make future updates much harder to implement.

It will not be any kind of "force" or issue since you can go back from that folder by doing require("../Sounds").
.. operator in the path means "go back in prev folder".

[Zly-u]

Oh wait nvm, I misread what you meant by the possible issues, well, I also just rechecked how exactly level.json get the main script and it's something like this: Scripts/Levels/apeirogon.lua which is actually great,I had to check that before writing the idea.
So yeah, people can do whatever for that at this point with this way of declaring main scripts.

Will edit.