Skyrim: Modify mod cleaning to remove bogus XLRL edits.

[GoogleCodeExporter]

A new problem for Skyrim that's come up for mod cleaning.

If you are working in the CK, edit a reference, then undo the edit using 
ctrl+z, one expects the CK to store that as a dirty edit. For Oblivion and both 
Fallouts, that's exactly what happens and the normal cleanup code will catch 
and remove these.

Skyrim's CK tacks on an extraneous XLRL subrecord to every reference that's 
edited, no matter what you do. This subrecord is not necessary for anything. 
It's generally harmless though, but if you've done an undo edit as above, this 
XLRL subrecord remains behind and becomes a wild edit.

It would be extremely beneficial if these wild XLRL edits could count as an ITM 
if they're the only edit being made to the reference.

The USKP has ~60 of them, identified thanks to a script dAb whipped up for me. 
Realistic Lighting Overhaul has somewhere into the hundreds though, and the 
author is understandably not keen on removing them all by hand.

Screenshot attached to illustrate the issue - "hide no conflict rows" was 
selected.

REFR, ACHR, ACRE, and PHZD records should be examined for this.

Original issue reported on code.google.com by arthmoor on 28 Feb 2013 at 11:34

Attachments:

• XLRL.jpg

[GoogleCodeExporter]

Can you upload the script ?

Original comment by HuguesLe...@gmail.com on 1 Mar 2013 at 1:46

[GoogleCodeExporter]

Sure, this only detects and he wasn't able to figure out how to deal with VMAD 
or the subrecord for linked refs.

Original comment by arthmoor on 1 Mar 2013 at 6:15

Attachments:

• FindXLRLDirtyEdits.pas

[GoogleCodeExporter]

Maybe just mark XLRL field as benign so they'll be ignored when ITM filtering?

Original comment by zila...@gmail.com on 4 Mar 2013 at 11:53

[GoogleCodeExporter]

No, that wouldn't be good because they're not benign subrecords. They're only 
useless if they're the only change made to a record.

Original comment by arthmoor on 4 Mar 2013 at 8:42

[GoogleCodeExporter]

Could I assume that if an XLRL SubRecord is added to a form that does not have 
one, this would be a benign change ?
Otherwise, checking for that on every MainRecord is going to be far too much 
time consuming for the default ITM detection.

Original comment by HuguesLe...@gmail.com on 4 Mar 2013 at 9:40

[GoogleCodeExporter]

If it's the ONLY thing being added to the form, then yes.

Original comment by arthmoor on 4 Mar 2013 at 9:47

[GoogleCodeExporter]

Do those two capture (from USKP) look ok for you ?

Original comment by HuguesLe...@gmail.com on 4 Mar 2013 at 10:13

• Changed state: Evaluating

Attachments:

• XLRLandStillConflict.PNG
• XLRLbutNoConflict.PNG

[GoogleCodeExporter]

Yes, those two pics look fine. As long as that XLRL remains editable that 
should be good to test.

Original comment by arthmoor on 4 Mar 2013 at 10:43

[GoogleCodeExporter]

I'll upload an experimental version for the others to check it. It is 
definitivly not very "proper".

Original comment by HuguesLe...@gmail.com on 4 Mar 2013 at 10:50

[GoogleCodeExporter]

Making them benign does just that - useless if they're the only change made to 
a record. As soon as anything else is changed in reference, the record is no 
longer ITM no matter the XLRL field.

Original comment by zila...@gmail.com on 5 Mar 2013 at 7:58

[GoogleCodeExporter]

However is there any difference between adding XLRL and modifying an existing 
one?

Original comment by zila...@gmail.com on 5 Mar 2013 at 8:54

[GoogleCodeExporter]

Modifying an existing one should not be treated as benign, obviously.

Original comment by arthmoor on 5 Mar 2013 at 9:53

[GoogleCodeExporter]

Obviously for you :)
For me not so much. CK adds them when touching a reference, but Skyrim.esm 
doesn't have them and still works just fine. So for me they are all benign no 
matter if added, removed or modified.

Original comment by zila...@gmail.com on 5 Mar 2013 at 4:59

[GoogleCodeExporter]

That may be, but why ask if you already concluded an answer? :P

It's not a field that can be edited directly in the CK, so what its values are 
is already beyond our control anyway.

Original comment by arthmoor on 5 Mar 2013 at 7:20

[GoogleCodeExporter]

Well, that's why I asked you how does it affect the game. Does assigning a 
bogus XLRL messes references, scripts, scenes or anything else? For example if 
I open USKP and change some XLRL to random location, will it break anything?

Original comment by zila...@gmail.com on 5 Mar 2013 at 8:08

[GoogleCodeExporter]

Assigning a bogus one might cause a few problems for aliases in quests but 
beyond that it probably won't have much effect.

BTW, the version you sent me with this change included seems to be working 
fine. No issues encountered thus far.

Original comment by arthmoor on 14 Mar 2013 at 12:54

[GoogleCodeExporter]

This ought to be closed now, right? It's active in 3.0.29 and working as 
desired.

Original comment by arthmoor on 20 Mar 2013 at 2:41

[GoogleCodeExporter]

Original comment by HuguesLe...@gmail.com on 20 Mar 2013 at 8:28

• Changed state: Fixed