Invoking map save by WorldEdit programatically

[Blazing Ardor]

Hello all,

I am in the process of writing a tool that automates fixing facial dialogue animations by using the same techniques employed in native campaign maps. It will work by unpacking a map file, patch the .w3s, .wtg, and .wts files, and repack them. The map would need to have a "Cinematic - Play Dialogue from Speaker" or "Cinematic - Transmission From Unit" triggers referencing campaign dialogue audio, and the tool will patch the .w3s file to add full dialogue capabilities, copying data from the native maps that use them, as well as converting transmission triggers to dialogue triggers.

Most of the research is completed, and I'll have tons to share, people to thank, and plan on releasing the tool with a guide when appropriate.

An issue however I ran into automating the saving of map files. The changes the tool will make influence the embedded map's JASS code file generation, as well as the conversation.json file. Potentially others, not sure. But patching the .w3s file does influence the editor to update other files upon saving. I am trying to automate this function, so I can have the tool batch process maps, and not need human intervention to save a map after patching is completed to regenerate files.

I've looked into known available parameters to pass into the .exe, but didn't see anything of use.

I also decompiled the code to study it, looking for ways to automate this. I didn't see any additional new parameters not mentioned elsewhere, but did notice an "automation" parameter, as well as code that implies the editor has a debug mode that can be turned on somehow. Not sure if those would be helpful.

I've even looked into the possibility of calling WE code from it's .exe from my tool, or even WE memory manipulation to invoke the "Save Map" command, as well as closing it. Opening a map can be done with the -loadfile parameter. Not sure if these are viable options.

I've also been looking through the War3Net.Build project, and it's been a huge help and answering some questions. But it also seems like it is not yet 1:1 with the native builder.

Does anyone have any ideas or suggestions on how to automate this? If not, any suggestions to provide the best user experience?

Thank you for your time, and I look forward to any feedback!

 

[sethmachine]

Do you expect the map to be updated in the World Editor and reloaded?

Or you just want to edit and save a map outside of the World Editor GUI?

I'm assuming you're manually updating the MPQ archive with StormLib or something and then save back to an MPQ archive (.W3X/.W3M) file.

But then it sounds like there are other files in the MPQ archive that are dependent or affected by the changes you made to the .w3s, .wtg, etc?

I suspect what the World Editor is doing is figuring out the diff and updating the affected sections. So you'd have to do that yourself unless the EXE exposes a way to trigger this.

What are all the files in the MPQ that need to be updated if you do your .w3s update? But yes saving to the MPQ won't trigger anything special, because it doesn't really know how any of the files interact or relate to each other. That's specific to the game itself.

I have some experience directly editing MPQ files using StormLib programmatically, e.g. for StarCraft: GitHub - sethmachine/richchk: Edit StarCraft maps in Python. And in general you need to handle updating the affected sections/files on your own if there are "cascading" or interdependent changes.

 

[Blazing Ardor]

Hey sethmachine, thanks for replying.

What you said all sounds correct. There are files inside the MPQ archive that are dependent on the files my program would change. Notably, changes my program would make to the war3map.w3s file and the war3map.wtg file would affect the war3map.j file and the conversation.json file. AFAIK these are the only two dependent files.

My goal was to find a way to programmatically have the WE do this regeneration, if possible, to take advantage of any updates made to map regeneration by Blizzard, or to cover any files or edge cases I may miss. Whether or not the editor is open (.dll injecting) or closed (referencing the compiled code somehow), or even loaded/reloaded isn't super relevant to me as long as I could make use of that step WE does upon saving.

I may end up writing some code to update these files as well, if having WE help out with it somehow proves too troublesome, but I am still currently exploring all options.