Best method to override existing FGMessages (ADA/Alien Lines) ?
I’m creating a Mod to replace the English voice lines with localized German voices. Currently I’m using a simple “pak hack” (RemapDirectories ) to replace the .wem files, the audio files that Wwise creates, which are stored in .pak files, not .utocs. However, I also need to adjust the subtitle timings and the actual subtitles (many translations are sub-optimal), which are stored via FGMessages within .utoc-containers. Finally, it would probably also be easier to use my own sound events instead of adapting the .wem files to the existing events, so in effect I would probably exchange most of the FGMessage’s content.
I’m wondering which technique would be the best to do that.
CDO manipulation
I’m unsure if CDO’s even exist for DataAssets like the FGMessages and also, I’m wondering if CDO manipulation would eventually lead to all dialogue audio being held permanently in memory (not sure how Wwise would handle this if all FGMessages were loaded).
Pak Hack
Even though I regularly hear how bad ‘patching’ is, so far, I have the feeling that patching the vanilla assets (
ProjectParams.GeneratePatch) would be the easiest option for this particular use case. As far as I understand it, some SML features won’t work with it (no entry points?), which, however, wouldn't be relevant here anyway - concerns remain about the robustness when it comes to game updates.
But so far I have not been able to get this to work with .utoc content anyway. I remapped the content to the base game’s structure via DeploymentContext.RemapDirectories and flagged .GeneratePatch, but I heard there is another option that needs to be ticked, which I don’t know.
Function hooking
I guess in theory I could hook into some game function, that is processing the FGMessages, and replace certain data on the fly, I haven’t investigated this can of worms yet. But it seems quite complicated for what I have in mind.
What do you think would be the best approach?13 Replies
the dev branch of SML has some changes that allow you to use Wwise normally within the project, which would allow you to package your sounds as a normal mod. it is still in the process of being documented, the PR for those docs are here
https://github.com/satisfactorymodding/Documentation/pull/359
Pak hacks can't honour the built-in language picker settings.
MrHid is temporarily hosting that PR branch at this URL, this link will be down at some unknown point in the future https://rat-vocal-seriously.ngrok-free.app/satisfactory-modding/latest/Development/Satisfactory/Audio.html#_wwise
Audio :: DEV Satisfactory Modding Documentation
This page is a work in progress. Coffee Stain uses the Wwise audio system to play sounds in Satisfactory. To create new audio e...
data assets should still be editable via CDO edits to allow modifying the timing data you need. but assuming the wwise stuff works for your needs, you may want to define your own data assets for your new messages (I assume most of the settings will need to change?), then use CDO edits on whatever maps schematic->message to use your message asset instead
you will probably need the free wwise indie license to have as many sound events as you're planning to package in one project, but you can test on a small scale without it
alternatively, you could have 2 mods (1 hidden) where 1 of them exists just to be the pak patch of the WEMs and the second mod does the required message asset changes via normal means (probably CDOs)
IMHO that sounds like a nightmare to maintain
I don't recall the details but I think the message assets reference the Wwise event to play. So if doing CDO edits for some stuff, one might as well change that using CDO edits too
in my opinion, depends on the process Tharagon has to use to prepare the pack patch. it could be faster than putting stuff into Wwise the normal way
heading out for a bit, brb
I already have the unlimited indie license and the sound is technically working already 😉
Improving the Wwise stuff workflow would only be to make the process easier - but that's not the central point here. I only mentioned it to tell A) that I'm currently already using a pak hack and B) there might be not many members in the FMessage that I'll leave untouched, because the sound event is indeed part of the FMessage, which in my mind spoke in favor of replacing the Message completely instead of just manipulating them
@Rex [they/them] could you elaborate the "built-in language picker" problem? Which problem could this make?
It's my first thought on this
If switching the in-game language (using the game's language selector in the options), a pak hack won't be able to magically enable/disable itself. Not sure if anyone cares, though
To be honest, I don't really care about that. If you install the “German voices” mod you will get German dialogs, no matter which language you set. At least that should work quite independently of the savegame, so you can uninstall the mod at any time.
Does anyone know anything about the memory implications of such a CDO manipulation solution? As I understand it, I would have to keep all 400 messages in memory. As far as I remember it, while CDOs are in memory, also ALL dependencies are kept in memory, including all sound file. But that's old knowledge from back in the days, of Unreal Engine 4.18 or so. Since then a lot has changed in terms of sound and "audio streaming" and also I don't know how Wwise handles this.
How would you feel about the option of trying to “patch” the FMessages, i.e. to set Unreal's own overwrite mechanisms in motion? (I have not yet succeeded for .utocs - but it sounded like it was still possible, at least within limits)
You might be able to use the asset registry and then load the data asset, and then change the variables
Could you elaborate on that? Are you talking about (more or less) regularly loading the vanilla data assets and then manipulating the CDO? Or are you suggesting there could be a way to hook into the asset registry system to alter FMessages every time they are loaded, so there is no need to keep them all in memory?
You can use the asset registry to find all the ADA messages in memory or load them into memory. this returns a pointer to the data asset object.
You can then update the data assets variables directly. They should all be in memory by the time the mod is loaded so you dont need to worry about the load time when loading the asset.
Well, I guess if they're indeed already all in memory anyway without a mod doing anything, then manipulating the CDO (or asset instances) won't affect the memory footprint of the audio files.