TES5Edit (by ElminsterAU)

[Electrocutor]

It'd be nice is STEP included a cleaning list for every mod too, so you could just remove all the crap that shouldn't be in there in the first place using xEdit. These things invariably cause small harm like removing weather or changing lights back to vanilla by accident.

[TechAngel85]

It'd be nice is STEP included a cleaning list for every mod too, so you could just remove all the crap that shouldn't be in there in the first place using xEdit. These things invariably cause small harm like removing weather or changing lights back to vanilla by accident.

If a mod needs to be cleaned, it's listed on the mod page on the wiki for that mod.

[Electrocutor]

I don't mean just the normal auto cleaning; I mean listing changes that are within the mods that shouldn't be there to be removed. For example, many mods contain vanilla cell overrides that revert sky or water flags, or change the RGB of lights back to vanilla when they have no reason to contain any cell changes at all.

[TechAngel85]

I don't mean just the normal auto cleaning; I mean listing changes that are within the mods that shouldn't be there to be removed. For example, many mods contain vanilla cell overrides that revert sky or water flags, or change the RGB of lights back to vanilla when they have no reason to contain any cell changes at all.

That's what the STEP Patches are for. They should be forwarding and fixing issues like that.

[tecknomage]

I use FO4Edit (aka TSE5Edit) and discovered there is no way to copy text to clipboard

 

It would be nice if users could highlight and copy text shown on-screen to the clipboard.

 

This would allow users to paste the text to a document, like a spreadsheet, to create cheat-code lists.

 

What I wanted to do with FO4Edit is copy the text under [FormID] "Key" so I could create a spreadsheet.

 

Please consider this feature to next update of TSE5Edit

[zilav]

Ctrl+C to copy text of focused node from the right pane.

[Kesta]

Ctrl+C to copy text of focused node from the right pane.

I think he want do make a list of every key with their id, so he'd like to copy the whole content of the key group in the left pane without having to go through individual records.

 

@tecknomage : Right click on "Key" in the left pane and select "apply script", and choose the . In the script, locate this line :

AddMessage('Processing: ' + FullPath(e));

and replace it with this one :

AddMessage(IntToHex(FormID(e), 8)+' '+GetElementEditValues(e, 'Full - Name'));

Click OK (you'll be asked to save the new script, choose a name and save it). The list you want will be printed in the "Messages" tab, from there you can copy paste it. 

 

 

Edit : @Zilav, uh, FormID(e) no good actually, how do I cast IInterface to lwbMainRecord ?

Edit2 : Ah, and FixedFormID instead of FormID would probably be better actually.

Edit3 : Nevermind, fixed it, the cast error  was about cardinal to string.

 

Edit @Tecknomage :

Keep in mind that the console isn't supposed to be a cheat engine but a developer tool (or it'd be available on console as well). I doubt you'll break anything with just adding keys to your inventory (however, using them to open quest-related door will probably screw the whole quest if done at the wrong time), however several "cheat codes" will just break your save on the long run, especially on FO4.

Edited February 28, 2016 by Kesta

[MrNoobMan]

Hello there, new person here.

Does anyone know if it is safe to remove the MagicDisallowEnchanting keyword from armour and weapons from the mods i have, as EzEs Artifact disenchating doesn't work with PerMa among others?

[Kesta]

 

Hello there, new person here.

Does anyone know if it is safe to remove the MagicDisallowEnchanting keyword from armour and weapons from the mods i have, as EzEs Artifact disenchating doesn't work with PerMa among others?

 

How is this question related to tes5edit ? That's just a modding question.

 

For your answer : this keyword is used to tell if you are allowed to disenchant an item to learn its enchantment or not. Typically used on unique items with unique enchantments such as the spellbreaker. So yes it's safe to remove it, that's how you create an "artifact disenchanting" mod.

[MrNoobMan]

How is this question related to tes5edit ? That's just a modding question.

 

For your answer : this keyword is used to tell if you are allowed to disenchant an item to learn its enchantment or not. Typically used on unique items with unique enchantments such as the spellbreaker. So yes it's safe to remove it, that's how you create an "artifact disenchanting" mod.

Thank you for your answer. I was planning on doing the editing using tes5edit and i was a bit unsure as to where to post

[TechAngel85]

Can you remove the warning in xEdit? I thought I had in the past, but perhaps not because I can't figure it out now.

[GrantSP]

Can you remove the warning in xEdit? I thought I had in the past, but perhaps not because I can't figure it out now.

Add the switch "-IKnowWhatImDoing".

 

Ps. We have a nice xEdit guide now that includes snippets like this. 

[TechAngel85]

Thank you! That waiting is annoying. lol!

[GamerPoets]

I know the topic mention above by TechAngel and Grant is old but it was the perfect question for me to start my new series with. Hope you like it = ) 

 

video

 

https://www.youtube.com/watch?v=4BDNYoPQ3jo

[airbreather]

Hey,

 

I'm looking into doing some automated plugin cleaning as part of a larger effort to automate as much of STEP as I can help with.  In doing so, I've stumbled upon some odd things that xEdit does which I don't completely understand, and I was wondering if someone could shed some light on it.  I'll list the full repro steps, but it should be the standard cleaning process, minus the UDR step.

 

Test case (xEdit 3.1.3):

1. Run xEdit with untouched Skyrim.esm and Update.esm files.  The files I'm looking at have MD5 checksums 15958064e1272509933b51d086bbd5b4 and 2476e42699d4d9236ddd2ea8b31f612d, respectively.
2. When prompted, ensure that nothing is checked except for Skyrim.esm and Update.esm and hit OK.
3. When loading is finished, right-click Update.esm and select Apply Filter for Cleaning.
4. When that's finished, right-click Update.esm again and select Remove "Identical to Master" records.
5. Promise the nag screen that you know what you're doing.
6. Attempt to close the window.  When prompted, ensure that Update.esm is checked; if you don't have a backup of Update.esm, you might also want to make sure that "Backup plugins" is checked as well so that you can run through this again.

At this point, your Update.esm file should now be 1332304 bytes long (down from 1518686) and have a MD5 checksum of cd5e3ba29f51a5fb903fea192d75507f.  If not, one of us did something wrong.

 

OK.  That cleaned file is what I want to talk about.  Unless I made some really horrible mistakes on my end, in addition to simply removing ITMs and updating the TES4 record, the above process has also made the following changes:

1. Records in the GMST, WEAP, NPC_, QUST, IDLE, PACK, CPTH, and SCEN top groups, as well as the groups that represent temporary children of cells 0006DAA0 and 0000923C were reordered so that they are sorted in increasing order by Id.
2. The {Ext block Y=-1, X=0} and {Ext block Y=0, X=0} sub-groups of the {Children of [WRLD:0000003C]} group were moved to the bottom of their parent group.
3. In the [WEAP:000BE25E] record, two bytes in the DNAM field were zeroed out.
4. In the [REFR:00109CD2] record, the payload was entirely wiped out.  It used to have a NAME field, but it doesn't anymore.
5. The following records used to have comparatively large OFST fields that have also been entirely wiped out: [WRLD:0000003C], [WRLD:0001691D], [WRLD:00034240], [WRLD:00094B35]
6. In the [DOBJ:00000031] record, the DNAM field's payload has shrunk from 2656 bytes to just 40 bytes.

My specific points of confusion (note that I'm not a "real" modder, so I'm looking at all of this from a "here's a bunch of bytes" perspective):

• Are #1 and #2 intentional?
  • If so, is there a reason not to sort records in, say, RACE or MGEF (probably a few others too) which seems to have its records ordered any which way?
  • If not, is this a problem?
  • It looks like the things that got sorted are just the things that had records deleted from them, so I'm guessing xEdit is just rewriting the edited groups based on its internal data model.
• Is #3 desirable?
  • If so, wouldn't this be better for something like USLEEP to take care of, rather than the Update.esm cleaning process?
  • If not, is it actually a bug in xEdit?
• What's the deal with #4?
  • I'm just completely confused about why we would want to do this.  Is this something that people don't usually see because it gets UDR'd later or something?
• The release notes for 3.0.32 make it sound like #5 was intentional.  Can you please help me understand what OFST is and why it's OK to aggressively delete it by default?
  • I've been using the UESP wiki as my primary source for everything, and the WRLD page leaves OFST as a big fat "unknown", so if nothing else, I'd like to at least update it to mention that xEdit seems to be able to just delete it with no apparent negative repercussions.
• Is #6 desirable?
  • 3.1.0's patch notes say "Improved DOBJ handling", but in theory based on my knowledge of what's going on here, this action shouldn't require any changes to DOBJ.
  • Though the original version does look like it has an "interesting" amount of padding.

Sorry for the barrage here.  From my perspective, I expected xEdit to make as few changes as possible when asked to just remove ITMs, so I was really surprised to see all these "extra" changes.

Edited September 30, 2016 by airbreather