Scripts fragments not renamed correctly

[ThyWoof]

zMerge renames the script whenever the form ID gets remapped. I believe this happens in the fixFragment method. For some reason the last line isn't renaming the script on the final merge:

xelib.SetValue(a.handle, fileName);

For example, I had a merge with LAL and the start quest FORM ID got renamed. Logs show:

Parsing "D:\OneDrive\TOOLS\ModOrganizer\mods\Alternate Start - Live Another Life\Scripts\arth_qf_lalstartquest_02000daf.pex" completed, 0 bytes unparsed. Writing "D:\OneDrive\TOOLS\ModOrganizer\mods\nx-overhaul\Scripts\arth_qf_lalstartquest_00001A32.pex" completed, 4566 bytes written.

Map file for LAL:

"Alternate Start - Live Another Life.esp": { "000DA8": "001A31", "000DAF": "001A32", "00184B": "001A33" }

When I open the final merge I still see a reference to 02000DAF script. Do we really need to rename the scripts? Can't we simply write with the same name and comment out the non-working SetValue call?

[matortheeternal]

thanks for the report. unfortunately the game is kind of weird with script fragments, that's why we have to rename them (hypothetically it should work to just not rename them, but it didn't appear to work in practice when testing several years ago)

your report has been noted, I'll investigate and see if I can fix the issue. :+1:

[ThyWoof]

Agreed on getting scripts with correct name. I guess what isn't working in my scenario (Skyrim SE, MO2) is the call xelib.SetValue(a.handle, fileName) on scriptFragmentHandler.js isn't changing the script name on the merged file. The PEX files are correct and I see the new script name there when I decompile.

[matortheeternal]

Yeah, I understood the issue from your report and will investigate. :)

[cal2195]

I'm having the same issue, and I think the plugins aren't working correctly in game because of it. Looking at the rest of the xelib.SetValue references, they all have 3 parameters, but this call only has 2 - could that be the issue?

I'd really like to find a solution as Merge Plugins Standalone doesn't support Vortex.

[cal2195]

I just tested the fix there and it doesn't solve the issue - I've traced the whole code and can't figure out why!

The value gets set as confirmed by a GetValue afterwards, but it doesn't seem to get saved into the file (also, all the ScriptName references are still the old value too...?)

[cal2195]

I think the issue might be that it's replacing the value in the original plugin, rather than the merged one?

[cal2195]

I can confirm this is the issue. After refactoring the code to use the merged plugin, it correctly stores the value! :tada:

This leaves two issues though:

1. In order to do this, I had to move the script fragment scanning until after the records are merged, as the fragment records aren't present in the merged plugin until then - this fixes the actual merge, but the fragments don't show up in the "Data" tab anymore - I guess we could scan for them twice?

2. The script names are still incorrect in the merged plugin, and I don't think there's any code to change them - I think we just need to implement it like the filename replacement.

Thoughts?

[cal2195]

I've tested changing the first fragment script name and it works too - is there a way so specify all indexes in a a collection? Like a wildcard?

[cal2195]

Got it! 🎉

Script names and file name is now updated correctly in the merged plugin! I'll tidy it up and see if I can get the "Data" tab working again, and then make a PR!

[cal2195]

Do you know if tif fragments need to be handled? I can't find them referenced in the esp file.

[cal2195]

Also, do you know if all VMAD\\Script Fragments\\Fragments\\*\\scriptName will always match the parent VMAD\\Script Fragments\\fileName?

If so, I have this coded up, but if not, this will be more tricky to prevent overwriting the wrong script entries...

[cal2195]

Also, I fixed the "Data" issue by scanning before, and after for now! 👍

[cal2195]

Just tested merging a larger set of mods there - seems to be working well! 👍 Will wait for your response before posting a PR!

[matortheeternal]

Sounds good, looks like this code had multiple major oversights. Crazy. Looking forward to the PR.