Towards moddable audio

[ajhalme]

• Replicate TextureLoader pattern for audio
• Lua config for reference based audio file targeting
• audio.lua files for initial Lua-based modding/override
• General audio refactor

-> C7-Game/Assets#15

[ajhalme]

Basic lua-moddable audio ready for review. Keeping it very simple to start with.

[WildWeazel]

I'm confused, this will end up returning the last such table entry, correct? We would iterate backwards and return the first match in that case. But why would multiple substrings be found in the table anyway?

[ajhalme]

This is identical to TextureLoader. Inlined it here because it's a compact static helper.

I'm not sure I follow your interpretation. This function resolves the value from a nested Lua structure:

audio.menu = {
  main_menu_1 = "/my/path/file.mp3"
}

Parts:       "menu.main_menu_1" --> ["menu", "main_menu_1"]
init:        current := audio
1st pass:    current["menu"] --> current := {  main_menu_1 = "/my/path/file.mp3" }
2nd pass:    current["main_menu_1"] --> current := "/my/path/file.mp3"
return:      "/my/path/file.mp3"

The modding Lua code makes a second lookup to see if there's a direct key-based override for the structured key, using it as a flat key-value lookup. That is, there is no structure to parse in the modded code. We could make the moddable stuff structured as well, but there's no need for now.

The reason to have structured Lua data in the first place is to enable not just simple values but full objects with properties to be retrieved by a single key.

[WildWeazel]

Got it, I missed that this is recursing into the table structure