Best way to replace ingame soundfiles?

[Grim Squeaker]

Okay, here's the situation. I want to replace Bioware soundfiles with new ones. In theory this should be easy with WeiDU, just copy across the wavs and WeiDU will backup the old ones. However, there needs to be some ogg-to-wav conversion and that can only happen in a bacth file once WeiDU has finished its jazz, so the automatic backup's not gonna happen. The only way I can think of doing it is:

 

1) Copy across dummy files in the tp2 e.g. COPY ~readme.txt~ ~override/foo.wav~

2) Copy across the oggs into the override e.g. COPY ~foo.ogg~ ~override/foo.ogg~

3) In the batch file, convert the files e.g. oggdec override/foo.ogg (then delete the oggs)*

 

Then hopefully in the uninstall, WeiDU's replacing of the backuped files will copy over my replacement ones and the override will be how it started before my mod. My one potential flaw is the line marked *. If I oggdec will the resulting output replace any existing files?

 

This seems to me like the only way of doing it. Can anyone think of a better way?

[the bigg]

Use an alternative override directory (http://iesdp.gibberlings3.net/misc/override.htm if you don't know what is that).

[Grim Squeaker]

Use an alternative override directory (http://iesdp.gibberlings3.net/misc/override.htm if you don't know what is that).

<{POST_SNAPBACK}>

 

I suppose that'd work, but I can see potential incompatibility issues if I start using a different override folder, as no-one else uses this trick. It'd mean future copying to the override would be automatically overridden (overrode? overrided? overrorororod?) by my files. To summarise, I don't want to use an alternative override as it could mess up future mods being installed on top of mine.

[Andyr]

Overororororororod is, I believe, the correct term.

[SConrad]

If I oggdec will the resulting output replace any existing files?

What if you delete the dummy files with the batch files before converting the oggs to wavs?

 

Alternatively, you can always patch the .dlg (or whatever) to use GS#sound.wav instead of sound.wav. That can be very tricky to do if there are a lot of soundfiles, however...

[CamDawg]

What about invoking the ogg > wav conversion before going to WeiDU? You could add it to the extraction script, or require the user to run a conversion script before using the files.

 

With Windows, the process could be invoked at extraction (tack it on to the .bat file that runs when the extraction is complete); with OS X it can be added to the .command file. The tp2 would then simply look for wavs and not bother with the ogg > wav conversion.

 

Drawback is that Win users who manually extract the package or users on other platforms such as *nix would need to manually run the script.

[the bigg]

What about invoking the ogg > wav conversion before going to WeiDU? You could add it to the extraction script, or require the user to run a conversion script before using the files.

 

With Windows, the process could be invoked at extraction (tack it on to the .bat file that runs when the extraction is complete); with OS X it can be added to the .command file. The tp2 would then simply look for wavs and not bother with the ogg > wav conversion.

 

Drawback is that Win users who manually extract the package or users on other platforms such as *nix would need to manually run the script.

<{POST_SNAPBACK}>

on *nix you need to have Wine to run bg2, so that isn't a problem

 

However, I can always try to code an alternative version of AT_*_EXIT that is run when met, rather than at the end of the installation [and in a bottom-up order relative to when they are listed in the tp2].

[CamDawg]

on *nix you need to have Wine to run bg2, so that isn't a problem 

 

However, I can always try to code an alternative version of AT_*_EXIT that is run when met, rather than at the end of the installation [and in a bottom-up order relative to when they are listed in the tp2].

 

It'd be more useful to have the ogg > wav decode function in WeiDU itself, assuming that the source is available and free to use.

 

Failing that, I still think performing the ogg > wav conversion prior to WeiDU is the best solution, so that the wav files get automatically included in WeiDU's onion layer approach. Perhaps a RUN_EXTERNAL_ONCE command for the tp2 header would work.

 

Failing that, I'd settle for WeiDU evaluating AT_INTERACTIVE_EXITs nested inside ACTION_IF so I could invoke different external scripts (dependent on the system architecture) instead of having to selectively comment lines.

[SConrad]

IIRC, the source is free to use.

 

And yeh, it would be awesome. Preferably in a regexp or folder syntax, so that we could use OGG_TO_WAV ~mymod/audio~ ~override~.

[the bigg]

It'd be more useful to have the ogg > wav decode function in WeiDU itself, assuming that the source is available and free to use.

No, sorry. Oggdec is in C++, WeiDU is in Ocaml, and having them interface ain't easy (to my skills, I mean, not to somebody with more than a week of experience). Moreover, wav files might overshoot the 16 Mb limit (which is a problem in the same way as the abovehand).

 

Failing that, I still think performing the ogg > wav conversion prior to WeiDU is the best solution, so that the wav files get automatically included in WeiDU's onion layer approach. Perhaps a RUN_EXTERNAL_ONCE command for the tp2 header would work.

Yeah, that'd be possible - maybe. (the _ONCE part is on your shoulders via ACTION_IF).

 

Failing that, I'd settle for WeiDU evaluating AT_INTERACTIVE_EXITs nested inside ACTION_IF so I could invoke different external scripts (dependent on the system architecture) instead of having to selectively comment lines.

<{POST_SNAPBACK}>

They do, see the standard snippet for multiple languages readmes:

 

ACTION_IF FILE_EXISTS ~mymod\README.%LANGUAGE%.txt~ THEN BEGIN
 AT_INTERACTIVE_EXIT ~VIEW mymod\README.%LANGUAGE%.txt~
END ELSE BEGIN 
 AT_INTERACTIVE_EXIT ~VIEW mymod\README.txt~
END

[CamDawg]

It'd be more useful to have the ogg > wav decode function in WeiDU itself, assuming that the source is available and free to use.

No, sorry. Oggdec is in C++, WeiDU is in Ocaml, and having them interface ain't easy (to my skills, I mean, not to somebody with more than a week of experience). Moreover, wav files might overshoot the 16 Mb limit (which is a problem in the same way as the abovehand).

 

Failing that, I still think performing the ogg > wav conversion prior to WeiDU is the best solution, so that the wav files get automatically included in WeiDU's onion layer approach. Perhaps a RUN_EXTERNAL_ONCE command for the tp2 header would work.

Yeah, that'd be possible - maybe. (the _ONCE part is on your shoulders via ACTION_IF).

 

Failing that, I'd settle for WeiDU evaluating AT_INTERACTIVE_EXITs nested inside ACTION_IF so I could invoke different external scripts (dependent on the system architecture) instead of having to selectively comment lines.

They do, see the standard snippet for multiple languages readmes:

 

ACTION_IF FILE_EXISTS ~mymod\README.%LANGUAGE%.txt~ THEN BEGIN
 AT_INTERACTIVE_EXIT ~VIEW mymod\README.%LANGUAGE%.txt~
END ELSE BEGIN 
 AT_INTERACTIVE_EXIT ~VIEW mymod\README.txt~
END

 

Last time I tried this, it didn't work--predicating A_I_E on an A_I, unless Wes changed something in the last few builds.

[Grim Squeaker]

For now, I think I'll stick with my original method (with a batch file to delete the dummy files before the oggdec).

 

Ideally what we really want is http://forums.pocketplane.net/index.php/to...570.0.html]this.

[the bigg]

Last time I tried this, it didn't work--predicating A_I_E on an A_I, unless Wes changed something in the last few builds.

<{POST_SNAPBACK}>

This works:

ACTION_IF 1 THEN BEGIN
 AT_INTERACTIVE_EXIT ~echo interactive~
 AT_EXIT ~echo exit~
END

 

Also, I believe I'll try to find a way to add OGGDEC, TISUNPACK and COPY_LARGE to next build (COPY_LARGE being an action allowing to copy, but not patch, a file of more or less arbitrary size). This'd require some work on the backup process, unfortunately