Capitalization fixed in text are being treated as dirty edits.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Edit any record containing text.
2. Change capitalization.
3. Observe it is regarded as a dirty edit.

What is the expected output?
The change should be highlighted in yellow.

What do you see instead?
It is highlighted in green, which will cause it to get cleaned out.

What version of the product are you using? On what operating system?
TES5Edit 3.0.25

Please provide any additional information below.
Image attached for example.

Original issue reported on code.google.com by arthmoor on 12 Nov 2012 at 11:37

Attachments:

• NotDirty.jpg

[GoogleCodeExporter]

That would be quite a breaking change.
For example from your screenshot, lets assume that the model path differs in 
some record:
Clutter\Books\Book02LowPoly02.nif
clutter\Books\Book02LowPoly02.nif
This record will no longer be cleaned even if all other fields are equal. And 
no, it is impossible (ok possible, but very hard) to apply case sensitivity 
only to particular fields.

Also "case sensitivity" I assume usually applies only to unofficial patches (I 
can't imagine why other mods would try to do that). So I can write a workaround 
script for you, it will replace EDID in such not to be cleaned records with 
misc text, then you clean plugin, then apply script again to restore original 
EDIDs.
FormIDs/EDIDs will be stored in a text file, so easy to update them.
Give me link to that plugin and list FormIDs not to be cleaned (via PM in beth 
forum).

Original comment by zila...@gmail.com on 13 Nov 2012 at 7:25

• Changed state: Started

[GoogleCodeExporter]

You'd be surprised what other mods try to do. I forced it to leave this one 
alone by dirtying up the text for the book in the DESC field, but I'd really 
rather avoid having to do that just to keep Edit's hands off of it.

I really can't see this being an issue for anything other than FULL and DESC 
fields anyway. Unless there's more places to hide text I'm not aware of.

Original comment by arthmoor on 13 Nov 2012 at 7:42

[GoogleCodeExporter]

If I read the code correctly all string comparison were meant to be case 
sensitive! But because {$IFDEF DCC6OrLater} is no longer define all the case 
sensitive code got deactivated.
To solve Athmoor problem without breaking the current logic is:
  I neutralized the 4 wrong define (We all use version greater than 5!)
  I made all string SortKey equals to UpperCase(String).
  I then created a wbStringKCDef (for Keep Case) where SortKey = String
Then I realized the proper fields to be made case sensitive are infact the 
translated field!
  So I created a wbLStringKCdef and applied it at the moment to FULL and DESC. But maybe it should apply to almost all wbLString ? 

uploaded as r1085

Original comment by HuguesLe...@gmail.com on 7 Jan 2013 at 12:59

[GoogleCodeExporter]

Only translated fields can be case sensitive, others should not for reasons I 
stated above. wbLString is only used for translatable parts, so it can be 
sensitive (except node name in body part data, but I don't think it'll affect 
anything).

Original comment by zila...@gmail.com on 7 Jan 2013 at 6:16

[GoogleCodeExporter]

I agree for Skyrim (LString only), but I intend to backport that change to 
FalloutNV sometime...

Original comment by HuguesLe...@gmail.com on 7 Jan 2013 at 10:14

[GoogleCodeExporter]

Original comment by HuguesLe...@gmail.com on 14 Jan 2013 at 12:21

[GoogleCodeExporter]

Fixed with 3.0.28

Original comment by HuguesLe...@gmail.com on 9 Feb 2013 at 6:50

• Changed state: Fixed