Sound file naming scheme

[Tels]

Okay, so I am writing a script which collects all files used by a map and creates a manifest from it. And now the sound files do my head in

 

Here is a partial list (that was created manually some time ago):

 

./sound/sfx/world/doors/door_locked_01.ogg
./sound/sfx/world/doors/door_locked_02.ogg
./sound/sfx/world/doors/door_locked_03.ogg
./sound/sfx/world/doors/door_locked_04.ogg
./sound/sfx/world/doors/door_open_1.ogg
./sound/sfx/world/doors/door_open_2.ogg
./sound/sfx/world/doors/door_open_3.ogg
./sound/sfx/world/doors/door_open_4.ogg
./sound/sfx/world/doors/door_open_5.ogg
./sound/sfx/world/doors/door_open_6.ogg
./sound/sfx/world/doors/door_open_7.ogg
./sound/sfx/world/doors/door_open_8.ogg
./sound/sfx/world/doors/door_shut_1.ogg
./sound/sfx/world/doors/door_shut_2.ogg
./sound/sfx/world/doors/door_shut_3.ogg
./sound/sfx/world/doors/door_shut_4.ogg
./sound/sfx/world/doors/door_shut_5.ogg
./sound/sfx/world/doors/door_shut_6.ogg
./sound/sfx/world/doors/wood_creak1.ogg
./sound/sfx/world/doors/wood_creak_small1.ogg
./sound/sfx/world/levers
./sound/sfx/world/levers/frob_frobber_button01.ogg
./sound/sfx/world/levers/frob_frobber_button02.ogg

 

etc.

 

Notice the four naming schemes:

 

* soundname_XX.ogg

* soundnameXX.ogg

* soundname_X.ogg

* soundnameX.ogg

 

How is my script supposed to make sense of this? And what exactly does doom support e.g. load when a definition mentions "soundname"? Does it load any file that starts with "soundname" and ends in ".ogg", regardless of what is in between? Or can there only be digits and "_" in between, regardless on how they are arranged?

 

Plus, shouldn't we keep to one naming scheme to make it consistent?

[greebo]

And what exactly does doom support e.g. load when a definition mentions "soundname"? Does it load any file that starts with "soundname" and ends in ".ogg", regardless of what is in between? Or can there only be digits and "_" in between, regardless on how they are arranged?

There are no restrictions of the filename with regard to number postfixes or underscores. You can (obviously) use anything you like.

 

The extension is ignored by the way.

 

Plus, shouldn't we keep to one naming scheme to make it consistent?

Yes, we should. But I'd be wary to open up yet another hole right now - let's close the other holes first.

 

How is my script supposed to make sense of this?

Just read in the sound filenames from the shader as they are?

[Tels]

There are no restrictions of the filename with regard to number postfixes or underscores. You can (obviously) use anything you like.

 

Ok.

 

The extension is ignored by the way.

 

Ok.

 

Yes, we should. But I'd be wary to open up yet another hole right now - let's close the other holes first.

 

agreed.

 

Just read in the sound filenames from the shader as they are?

 

I am unsure how this works.

 

For instance:

 

door_open_01
{
	no_dups

	sound/sfx/world/doors/door_open_1.ogg
}

 

and then we have:

 

def/tdm_mover_doors.def:		"snd_open"					  "door_open_01"

 

Does that mean that apart from door_open_1.ogg, any other door_open_X.ogg is essentially not used at all? Because this is the only reference I can find to this sound!? *confused*

 

I now coded into my script to read in the files based on the base name, a counter and the extension, but if the files always must be listed completely in the sound shader, this means I did this in vain?

 

For example, in thiefs_den we shipped all the door_open sounds, but if we only ever use the first one, what's the point? *confused*

[greebo]

No, all files mentioned in the shader could get played. Don't let yourself confuse about sound shader names and the filenames (which seems to be the case here as the shader has a similar name as the OGG file).

 

The numbers/indices in the shadernames or filenames are irrelevant.

 

It's working almost the same as the textures:

 

The DEF file points to the sound shader. The sound shader points to one or more sound files.

 

The code proceeds like this:

- Call idEntity::StartSound("snd_XXX");

- Code looks into "snd_XXX" spawnarg and retrieves the shader name

- The shader name is passed to the sound system.

- The sound system opens the shader and looks which sound files are available.

- Depending on what the shader definition says, one of the referenced sound files are actually played.

 

So, to cut it short, your script needs to record all of the .ogg/.wav files mentioned in the shader, as all of them are potential playback candidates.

[Tels]

No, all files mentioned in the shader could get played. Don't let yourself confuse about sound shader names and the filenames (which seems to be the case here as the shader has a similar name as the OGG file).

 

The numbers/indices in the shadernames or filenames are irrelevant.

 

It's working almost the same as the textures:

 

The DEF file points to the sound shader. The sound shader points to one or more sound files.

 

The code proceeds like this:

- Call idEntity::StartSound("snd_XXX");

- Code looks into "snd_XXX" spawnarg and retrieves the shader name

- The shader name is passed to the sound system.

- The sound system opens the shader and looks which sound files are available.

- Depending on what the shader definition says, one of the referenced sound files are actually played.

 

So, to cut it short, your script needs to record all of the .ogg/.wav files mentioned in the shader, as all of them are potential playback candidates.

 

Thanx for the explanation, but that was what I had already guessed. But the question is actually a bit different:

 

* if I find a reference to shader foobar

* and shader foobar mentions "file_1.ogg"

 

then I need _only_ file_1.ogg, right? The other files (like "file_2.ogg" or "file_3.ogg") will only be used if:

 

* the are named in the same sound shader

* or are named in a different sound shader

 

? It is not that if you mention "file_1.ogg" in a sound shader, that doom would also load "file_2.ogg" just because it is there on the file system?

 

(Sorry if I am a bit dense today

 

I am asking because according to my script and the def files, we do have multiple sounds for opening doors, but with the current SL map, only one is ever referenced, and thus, only one is ever used?

[Crispy]

Thanx for the explanation, but that was what I had already guessed. But the question is actually a bit different:

 

* if I find a reference to shader foobar

* and shader foobar mentions "file_1.ogg"

 

then I need _only_ file_1.ogg, right?

Right. Only sound files mentioned in sound shaders are ever used, AFAIK.

 

I am asking because according to my script and the def files, we do have multiple sounds for opening doors, but with the current SL map, only one is ever referenced, and thus, only one is ever used?

Apparently so.

[Tels]

Right. Only sound files mentioned in sound shaders are ever used, AFAIK.

Apparently so.

 

Ok, modifyed the script to only include what was used.

 

For practical purposes, we will also have to include some files that were released with Thiefs_Den so that any maps made with Thiefs_den will still work. However, this is a separate issue

[greebo]

I wouldn't even bother with Thief's Den resources. Let's keep in mind that this is an alpha demo, not a public toolset release with any guarantees whatsoever.

[Tels]

I wouldn't even bother with Thief's Den resources. Let's keep in mind that this is an alpha demo, not a public toolset release with any guarantees whatsoever.

 

Yeah, except people already build maps with TD, and I'd hate to break these maps just because we left out one file or another. The script takes care already of most of it, what else is left can be done with a simple diff between the manifest of TD as we released it and the manifest as we are about to release.

 

Compared to everything else I have done now, this is small fish

[greebo]

If it's a marginal amount of work, I don't have a problem with it. (And of course, if the release package isn't, say, doubled in size because of that).

 

But beware, that even if we include all the assets of TD, it is not a guarantee that the maps will work because of DEF and code changes made in the meantime.

 

Generally, we cannot give any guarantee that maps built with an alpha demo are compatible with future TDM releases, nor do we want to give such a promise. We always said that disclaimer to our Beta mappers as well and people have to live with that. Hell, even our own team test maps are broken on a regular basis, and in fact we need to be able to break them, because otherwise we are permanently constrained when changing anything because it may break an alpha map out there.

[Tels]

If it's a marginal amount of work, I don't have a problem with it. (And of course, if the release package isn't, say, doubled in size because of that).

 

It won't because most resources overlap. Plus, the current autogenerated manifest contains the resource from TD alredy, anyway. (because I am including it already

 

But beware, that even if we include all the assets of TD, it is not a guarantee that the maps will work because of DEF and code changes made in the meantime.

 

Generally, we cannot give any guarantee that maps built with an alpha demo are compatible with future TDM releases, nor do we want to give such a promise. We always said that disclaimer to our Beta mappers as well and people have to live with that. Hell, even our own team test maps are broken on a regular basis, and in fact we need to be able to break them, because otherwise we are permanently constrained when changing anything because it may break an alpha map out there.

 

I know. I am the one whos always saying that, remember?

 

However, we can at least look if it still works, and take the 5minutes to fix the obvious stuff. You know, mainly because it was decided that we release both maps, anway. And it would be lame to ship a broken map

 

Wether we release a script so that people who have created a map with TD can fix their map or we let them do it manually, I dunno yet. First thing would be to determine what resources exactly we changed, anyway. (Its a shame we don't even have this insight

[greebo]

You know, mainly because it was decided that we release both maps, anway.

Really, was it? Must have missed that.

 

I would have disagreed, but I'm fine with any decision made by the team.

[Tels]

Really, was it? Must have missed that.

 

I would have disagreed, but I'm fine with any decision made by the team.

 

Can't find where we discussed this, but the reasoning was along the lines:

 

* people new to the mod may want to play TD, too, but would have to download/install two things

* people who played TD already might want to replay it, but might no longer have it installed

 

Given the fact that it is easy to include TD, I'd say we do it. It won't increase the size of the release much (SL is muchmuch bigger and uses tons more resources) and the package script doesn't care if it eats one or two map files.

 

If the time is really tight, we can always leave it off shortly before release.

[Crispy]

Wasn't it pointed out that the TD map may have been broken by other changes? If we re-release then we really should re-test, and IMO we have enough on our plate with SL already...