[Iss Mneur]

Oh I see. Indeed you are right about that, so we were just talking past each other then.

I have updated the entry on the wiki to reflect the current requirements of the sound.tbl.

[mjn.mixael]

I think the better solution would be to allow the .tbl or .tbm to have a -1 as the id and have the parser just defer assigning them the actual id number until after all sounds have been parsed.  It could then go through the deferred list and append them all to the end of the sound.tbl this way no problems with accidentally stomping on someone else.  Remember tbms do not guarantee ordering.

An alternative, that would be more work, but less trouble all around, would be to take a page out of ships.tbl and weapons.tbl and just don't use numbers at all and refer to sounds by filename or allow a soundname to be specified in the sounds.tbl/.tbm.  This way the numbers are completely hidden from the tabler and much less likely to cause problems with .tbms.  The existing sound indexes would be assumed to be named their number just like CommanderDJ did with the mainhalls.

Those seem like better options than my idea.

[z64555]

Code: [Select]

+Randomize Pitch: 0.3      ;; Pitch Randomization percentage ( between +/- 30%)
+Randomize Volume: +0.1    ;; Volume Randomization percentage ( up to +10%)
Why cap it? Or at least... why at 30%? I figure as long as it doesn't break the game, might as well give modders as big a range to play with as possible.

This is so that modders can define a pitch range to their liking for that particular sound within that particular set. In case you did not know, it is usually much easier to maintain hi fidelity when lowering the pitch, but not when raising the pitch (read: awesome bass vs. ear-splitting garble).

I already thought about extending the syntax of a sound definition to have a cleaner syntax which could include a name option and using the current signature numbers as the default name will make it much easier to manage the sound entries .

This is basically what they did for DF:BHD, their version of the sound table assigned a name for each .wav that would be used elsewhere. For the most part, I couldn't figure out any advantage to doing this other than being able to re-use a single .wav but with different volumes. Case in point: a majority of the names assigned to each wave had the same exact name as the wav (except without the .wav file extension).

[m!m]

Here is a patch which implements the proposed name mechanism and a new syntax for the sound definition.
The new syntax looks like the following sample entry:

Code: [Select]

$Name: <name>
    [+nocreate](optional)
    +Filename: <sound filename>
    +Preload: Yes|No
    +Volume: <float>
    [+3D Sound:
        +Attenuation start: <start distance>
        +Attenuation end: <end distance>](optional)
If the +Filename option is not present after the name of +nocreate then the entry will be parsed using the default syntax to remain backwards compatible.

[attachment deleted by a ninja]

[mjn.mixael]

How does that syntax work with the retail table? I'm just confused because the retail entry layout is vastly different from your (much preferred) +entries.

This...

Code: [Select]

$Name: 6 breakup.wav, 0, 0.60, 1, 100, 800

Could be this...

Code: [Select]

$Name: 6
    +Filename: breakup
    +Preload: no
    +Volume: 0.60
    +3D Sound: 1
        +Attenuation start: 100
        +Attenuation end: 800

Right?

[m!m]

Yes that's how it works with the exception that you still need the .wav extension on the +Filename option.

[z64555]

How does that syntax work with the retail table? I'm just confused because the retail entry layout is vastly different from your (much preferred) +entries.

If I'm reading the .patch right, it looks like he made it so that the parser will detect which style of entry is used and jump to the appropriate stuffer...

[mjn.mixael]

Right, so if +filename is present, you can refer to the sound as that and it really doesn't matter what $name is set to? (will it overwrite files with the same $name in that case?)

[m!m]

No, the value you give to $Name is the name you use to refer to this sound in the other tables.

[mjn.mixael]

I'll be testing the modular sounds patch tonight... anyone else tested it yet?

[Kobrar44]

Can such thing be done to particles/explosions as well?

[mjn.mixael]

Can such thing be done to particles/explosions as well?

Tested the modular sounds and it works great. It loads the retail data just fine. I added sounds to both sections (#Game, #Interface, NOT #Flyby) and they all worked. I modified sounds in those sections which also worked.

One thing I found odd though. Retail sounds.tbl expects a 'type' to be specified for 3D sounds. Your TBM (under the new syntax) does not want a type integer there. I suppose that's because under the current code sounds will either be 3D or not.. so those integers are unnecessary. Makes sense, just took some testing to figure that out due to the lack of instructions with this patch...

EDIT: How does the modular stuff work for the #Flyby section?

EDIT2: Trying to override an entry with a tbm results in duplicate sound warning. Warning persists when using +nocreate.

In fact...

Code: [Select]

$Name: 66
   +nocreate
   +Filename: emptymsg.wav
   +Preload: No
   +Volume: 0.50
Caused it to look for a float value (old parsing method) in the playse of +filename: emptymsg.wav.

[z64555]

As far as I can tell from the patch, the #FlyBy section would work like this:

Code: [Select]

#Flyby Sounds Start

$Terran: 0                                         ; * Terran ship1 flyby player sound (3d sound)
    +Filename: T_flyby1.wav
    +Preload:   No
    +Volume:    0.75
    +3D Soud:   1
    +Attenuation start: 200
    +Attenuation end:   400

$Terran: 1                                               ; * Terran ship2 flyby player sound (3d sound)
    +Filename: T_flyby2.wav
    +Preload:   No
    +Volume:    0.75
    +3D Soud:   1
    +Attenuation start: 200
    +Attenuation end:   400


$Vasudan: 0                                         ; * Vasudan ship1 flyby player sound (3d sound)
    +Filename: V_flyby1.wav
    +Preload:   No
    +Volume:    0.85
    +3D Soud:   1
    +Attenuation start: 200
    +Attenuation end:   400

$Vasudan: 1                                         ; * Vasudan ship1 flyby player sound (3d sound)
    +Filename: V_flyby2.wav
    +Preload:   No
    +Volume:    0.85
    +3D Soud:   1
    +Attenuation start: 200
    +Attenuation end:   400


$Shivan: 0                                        ; * SHIVAN ship1 flyby player sound (3d sound)
    +Filename: S_flyby1.wav
    +Preload:   No
    +Volume:    0.75
    +3D Soud:   1
    +Attenuation start: 200
    +Attenuation end:   400

$Shivan: 1                                        ; * SHIVAN ship1 flyby player sound (3d sound)
    +Filename: S_flyby2.wav
    +Preload:   No
    +Volume:    0.75
    +3D Soud:   1
    +Attenuation start: 200
    +Attenuation end:   400

#Flyby Sounds End
... and the value right after the $Species can apparently be anything at the moment... so long as the first entry is for the Fighters and the second is for the Bombers.

[m!m]

Can such thing be done to particles/explosions as well?

Sure, you just have to find someone who has the time to do it...

z64555 is right about the #Flyby section. It uses the same syntax but doesn't support the +nocreate tag. Sadly if you want to change the flyby sound you will have to duplicate all entries for it to work, I need to fix that later...

EDIT2: Trying to override an entry with a tbm results in duplicate sound warning. Warning persists when using +nocreate.

In fact...

Code: [Select]

$Name: 66
   +nocreate
   +Filename: emptymsg.wav
   +Preload: No
   +Volume: 0.50
Caused it to look for a float value (old parsing method) in the playse of +filename: emptymsg.wav.

I said that wrong. +nocreate has to be located right before the name itself to work. I also forgot to say that you may not use spaces inside the name as that will trigger the old parsing method...

[mjn.mixael]

So what's the next step before we can haz modular sounds in trunk?

[m!m]

Well I couldn't find any issues with the current patch so a code review would be the next step.

A thread split may also be appropriate as this thread is not about the modular sounds table but about a feature request...

[Goober5000]

I reviewed m!m's patch, making some very minor edits (mostly with const-correctness and the like).  It's committed in r9062.

[z64555]

I reviewed m!m's patch, making some very minor edits (mostly with const-correctness and the like).  It's committed in r9062.

TO THE WIKI!

Edit: Oh? Somebody made the adjustments before I did! YAAAAY! 

Edit2: TY MJN (and m|m , and Goober too)

[m!m]

Thanks mjn.mixael and Goober. I just did two minor edits to the wiki to document behavior that isn't obvious and may result in strange errors.

[mjn.mixael]

Indeed. This was a much desired feature of mine... Now that that's done.. we can take a further look at the other features requested in this thread.