Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Skyrim/SkyrimSE] Quests/QNAM in SMQN shouldn't show as benign conflict #1016

Closed
eterniti opened this issue May 22, 2022 · 6 comments
Closed

Comments

@eterniti
Copy link

eterniti commented May 22, 2022

What is the version of xEdit you are using?
SSEEdit/TESVEdit 4.0.4

Describe the bug
Quests and QNAM shouldn't show as benign conflict (see screenshot below) in TESVEdit/SSEEdit because these don't merge at runtime.
(see attached test case in additional content that proves that they don't merge at runtime)

To reproduce
Have three mods, 1, 2, 3, with 2&3 overriding a SMQN from 1 (as shown in screenshot)
Test case attachment provided in additional context.

Expected behavior
They should appear as bad conflict, as the changes in mod 3 override the content in mod 2, making mod 2 not work. In an ancient version of the program (3.2.1), these would actually display as conflict. It is my understanding that this behaviour was changed on the hypothesis that QNAM and quest merge at runtime, but test case proves that mod 3 destroys the functionality of mod 2 and that a patch that resolves the conflict is necessary for them to work together.

Screenshots
auil5s0

Additional context
The theory about QNAM and Quests in SMQN merging at runtime seem to have been originated here: https://www.afkmods.com/index.php?/topic/3940-skyrim-tes5edit-records-that-merge-at-runtime/
And in concrete from this part:
"SMQN - QNAM [Quest Count, Quests] subrecord: Data contained within the QNAM subrecord will merge at runtime as demonstrated by numerous mods which share these nodes to add quests to the lists which all function together properly."

This page is also linked in https://tes5edit.github.io/docs/5-conflict-detection-and-resolution.html#RecordsThatMergeAtRuntime
So it is my guess, and please correct me if I'm wrong, that the change of behaviour at some point of SSEEdit life (somewhere after 3.2.1) may have been done because of that information.

Now don't get me wrong. The information in the afkmods page seem to be correct... except that bit in concrete, which doesn't match the results in game of my tests. Since I don't expect to deny a information that has been around for 8 years and expect you to believe me out of the blue, I provided a detailed test case. I should also say that I originally encountred this issue in a real mod (not of mine). The test case is meant to be run in game. I provided two versions, one for Skyrim SE and other for the classic Skyrim. I tried to made them as simple as possible. They don't overwrite any vanilla or dlc content.

I also posted the test case in afkmods, but it seem these days people rarely use the forums and no one has tried it, so I'm posting this here too, since it affects xEdit aswell.
The test case shouldn't steal you more than 15-20 minutes of time. I'd appreciate if any of you could give it a try whenever you have some spare time. The .txt in the zip has the info about how to run the mods/tests that confirm issue.

If there is something not well expressed (sorry for that, english is not my mother language), or if you notice something strange in the tests, or you want me to test some other scenario, let me know.

SMQN Test Case.zip

@Arthmoor
Copy link

I've had a chance to test this now. The conclusions are mixed:

For LE, everything works as expected. There is no need for the patch .esp file. This was a fresh install of LE with no mods as I had long since uninstalled it and needed to get it back.

For SE, the patch .esp file is necessary and I'm able to duplicate your results exactly.

There is only one thing I did to both of these before using the scripts - I changed the call to Debug.Trace instead of Debug.Notification because I've had instances where those notifications are not reliable.

So it appears as though Bethesda did something in an SE update at some point which has removed the runtime merging of the QNAM group. I've checked my current game load order and this issue would only have affected a minor node between the Bruma mod and the Dawnguard DLC for follower commentary. So it also seems that somewhere along the way Bethesda also quietly resolved the conflicts the files used to have with each other, which was what prompted the original LE testing to begin with.

@ElminsterAU
Copy link
Collaborator

Thanks for testing. So the conclusion is: leave as is for LE, but consider it a normal conflict for SE?

@Arthmoor
Copy link

Yes, that's what I'd go with.

@eterniti
Copy link
Author

eterniti commented May 23, 2022

Thanks for testing. As for LE, I will give another try if you don't mind, the more tests the better. This time, I will remove all mods, and even SKSE itself, I think I'll just fully uninstall the game in Steam (and make sure that it really removed it) and install it again, as to be on the same scenario than you.

If Debug.Notification is unreliable, I will instead use something else, but personally I prefer something that can be observed in game itself, I think I will try giving a different fixed amount of money to the player in each hold. Even if for X reasons, the message the game does that gold has been added were also unreliable, the amount of gold in the player should be updated.

I'll report the results later. If for whatever chance, they don't match, I will add a second test case with the updated scripts.

Edit: on a second thought, instead of giving player gold (which can be problematic to count if you test multiple holds), I will giving the player exactly 1 arrow in each hold. but a different type of arrow in each hold. That should make the test less prone to mistakes.

@eterniti
Copy link
Author

eterniti commented May 23, 2022

Ok, I've run the new test and on my end, the issue persists in Skyrim LE and the quests don't merge on my end (e.g, the Eastmarch quest doesn't run on Test 4).

Here is exactly what I've done:

  • Uninstalled Skyrim LE using Steam.
  • Exited Steam
  • As it left quite a lot of files on the Skyrim folder, I deleted the folder.
  • Started Steam again, and installed Skyrim again.
  • Absolutely no mods installed. No SKSE. No USLEEP, no CRF. No ENB or any dll based things either. Just the mods in the test. No Mod Manager at all. Using just the launcher by Bethesda.
  • When doing test 4 (the most relevant), I made to sure to not have the "Patch Mod.esp" in the Data folder, to avoid any possible human error or black magic making that .esp load (which would nullify the results of Test 4)
    New_LE_Test_Case4

I attach Test Case 2.
Besides the change to arrows that I mentioned in the earlier post, I did another change to account for the possibility of human error or weirdness happening when doing Test 4.
These are the changes done to the mods:

  • The Base Mod, Derived Mod 1 and Derived Mod 2 have not have their esm/esp changed (but the scripts changed). I did however add one GlobalVariable to the "Patch Mod.esp", so please update that mod when running this test case.

  • The purpose of the change in "Patch Mod.esp" is to be used by the scripts of the other 3 mods, to print a message (both Trace and Notification) if Patch Mod.esp exists (if this message appears in screen or log in Test 4, then something went wrong and Patch Mod.esp was loaded somehow).

  • Change to the scripts: instead of Debug.Notification, they add one arrow to the player. Iron arrow in Whiterun, Steel arrow in Eastmarch, and Elven arrow in Haafingar. Besides being added to the inventory, the game prints a message on screen when the item is added and does a little sound effect, so multiple ways of checking it.
    Besides that, the scripts check for the GlobalVariable in Patch Mod.esp via Game.GetFormFromFile. The script only check its existence, not the value. If it exists, then it means "Patch Mod.esp" is loaded, and it prints "Notice: patch mod is running." via both Debug.Trace and Debug.Notification. This message should only appear on Test 5, if it appears on Test 4, then there is human error or weirdness.

So I proceeded to do Test 4. (before that I made to sure that I wouldn't have any arrow on me).
I did the test by just entering/leaving different buildings of Whiterun, Solitude and Windhelm multiple times. The arrows were being added in Whiterun and Solitude, but not in Windhelm. I made sure to test all of them to account for the possibility that if something changed the load order (e.g. put Derived Mod 2 above Derived Mod 1), then that would alter the result to the opposite.

And then I added "Patch Mod.esp" to the Data folder, made sure it was enabled and proceeded to Test 5.
This time the arrows were added in all cases. (And the notice about "patch mod is running" also showed)

SMQN TEST 2 (Skyrim LE).zip

ElminsterAU added a commit that referenced this issue Jan 1, 2023
ElminsterAU added a commit that referenced this issue Jan 1, 2023
@ElminsterAU
Copy link
Collaborator

should be fixed with commits above, will be in 4.x.4e

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants