Long Sound Filenames

[boblishman]

OK... having established that we can use Cyan's .ogg files in the sfx folder as sound effects ... another problem has occurred ...

Blender´s Audio Plugin has a maximum file name length... so, when you import the (converted) .wav file it truncates the filename.

However, the filename needs to be the complete filename in the Alcscript ... so, when you try and export the Age, the Blender Console complains that it can't find the .wav file (because the name is truncated in Blender ... )

Is there a way for the plugin to "ignore" the .wav files in Blender (there is no real need for them to be in Blender anyway is there?) and simply take the filename from the Alcscript when exporting?
That way it would be possible to use the pre-existing sound effects with long filenames ...

[Aloys]

I have noticed that too. That's exactly the kind of inconsistency that annoys me about blender..
I have taken an habit to make file names as short as possible. (not only for sound files, but all assets) That's annoying, but that's just safer in the end.

[Chacal]

There are two solutions right now and both are unsavory.
1- PrpExplorer. If v0.7 has been fixed and doesn't shred the prp files anymore.
2- If not, it gets ugly: manual edit using a hex editor.

I've done both when modifying the Cyan city files.

When writing and testing your Age, you should do this:
- copy the ogg file to a short-name one
- use the short-name one until your final version is ready
- use the above tricks to switch to the regular ogg file.

[boblishman]

what I don't understand is the need to import the wav file into Blender in the first place ... The plugin doesn't encode or re-write the sound file ... so why does it need it? ... surely we would actually be better off if the plugin just used the Alcscript file ( and then add the .ogg extention) ... ? ? ?

[Paradox]

what I don't understand is the need to import the wav file into Blender in the first place ... The plugin doesn't encode or re-write the sound file ... so why does it need it? ... surely we would actually be better off if the plugin just used the Alcscript file ( and then add the .ogg extention) ... ? ? ?

PyPRP needs to read the .wav header information because of the way that Cyan handles plSoundBuffers. The plSoundBuffer contains detailed header information from the .wav file including byte-sizes and encoding.