Lua replacement for sound.tdf


[21:20:55] <[S44]FLOZi> made small addition to unitdefs_post to luafy soundcategory
[21:20:58] <[S44]FLOZi>
[21:21:33] <[S44]FLOZi> compare to yuri’s quick fix: … 2165a1c062
[21:21:44] <[S44]FLOZi> however this can replace gamedata/sound.tdf altogether
[21:21:59] <[S44]FLOZi> but requires some slight monkeying of unitdefs
[21:22:11] <[S44]FLOZi> e.g. USTank -> US_Tank
[21:22:34] <[S44]FLOZi> we might also decide it is neater to put sounds in subdirs? and code will need to be adjusted slightly for that depending on decided structure
[21:23:06] <[S44]FLOZi> pro: it automatically adds any sound with relevant filename to relevant section of a unitdef sounds table
[21:23:17] <[S44]FLOZi> con: ??? yuri said he didn’t want to mess with _post for some reason
[21:24:49] <[S44]FLOZi> and yes i should use a regex hurr hurr
[21:28:00] <[S44]FLOZi> i mean we could monkey filenames instead or use dirs e.g. sounds/ustank/select1.wav
[21:28:28] <[S44]FLOZi> or just have a crappy lookup = {ustank = “us_tank”, …}
[21:28:35] <[S44]FLOZi> but may as well do it cleanly
[21:29:04] <[S44]FLOZi> i quite like dirs but then i quite dislike having multiple files with same name in different dirs
[21:29:45] <[S44]FLOZi> so probably something like sounds/US/Tank/US_Tank_Select1.wav ??
[21:30:00] <[S44]FLOZi> well whatever. Get back to me! <3


[17:44:16] <[S44]yuritch> that looks good
[17:44:32] <[S44]yuritch> …but might lead to some massive file renaming
[17:44:49] <[S44]FLOZi> some organising of the files is requires yes
[17:45:10] <[S44]FLOZi> and some monkeying of defs
[17:45:45] <[S44]FLOZi> but hopefully easier to maintain and build upon in future
[17:45:58] <[S44]yuritch> Why I don’t like adding too much to *_post: it gets quite hard to track down just where property ‘foo’ gets set to ‘bar’. It might be in .fbi/.lua defs, it might be in one of the *_post (and there are several of those!)
[17:46:17] <[S44]FLOZi> Yes
[17:46:25] <[S44]FLOZi> this is true
[17:47:02] <[S44]FLOZi> if we expect to make more per-unit sounds then sounds in defs is sensible
[17:47:18] <[S44]FLOZi> although even then, _post can automate it based on filename
[17:47:32] <[S44]FLOZi> and there’s no point having that filename detection in each def
[17:48:18] <[S44]FLOZi> we could implement a defs_post.lua loike zwzsg did
[17:48:26] <[S44]FLOZi> so at least there is only one to check
[17:48:45] <[S44]FLOZi> and with OO unitdefs some stuff can be moved into the unit class defs
[17:48:58] <[S44]FLOZi> still it has the issue of thigns being spread across many locations
[17:49:07] <[S44]FLOZi> (well, hopefully no more than 3)
[17:51:06] <[S44]FLOZi> we could enhance my proposal with some OO features btw
[17:51:07] <[S44]FLOZi> like
[17:51:21] <[S44]FLOZi> have US/Tank/Generic_Tank_Sound.wav
[17:51:37] <[S44]FLOZi> and then US/Tank/M4A3Sherman/Override_Tank_Sound.wav
[17:51:55] <[S44]FLOZi> and def would have soundCategory = “US/Tank/M4A3Sherman”
[17:52:02] <[S44]FLOZi> and it would recursively look up one
[17:52:11] <[S44]FLOZi> until it found a sound
[17:52:17] <[S44]yuritch> That actually sounds cool. Until you get a new soundset with fewer sounds than the base :slight_smile:
[17:52:50] <[S44]yuritch> (but we don’t get much new soundsets anyway, so that’s not important)
[17:53:16] <[S44]FLOZi> idea is that e.g. most sounds can be shared but then have individual overrides on a per-unit basis
[17:53:25] <[S44]FLOZi> just a thought
[17:54:32] <[S44]yuritch> I mean the case like: base tank has 3 ‘selected’ sounds, but unit-specific set only has 2 (whomever recorded it got lazy) and so the third of the ‘generic’ gets played sometime
[17:54:36] <[S44]FLOZi> I think soundcategory as path to the folder is good idea, so long as we don’t have to escape / in the strings
[17:54:45] <[S44]FLOZi> hmm
[17:54:56] <[S44]FLOZi> that can be avoidwed
[17:55:15] <[S44]yuritch> it can
[17:55:22] <[S44]FLOZi> i.e. if unit-specific has ANY of sounds related to key x, only use unit-specific for x
[17:55:50] <[S44]FLOZi> much choice over how we do it (<3 lua)