Jump to content

[WIPz] TES5Edit


zilav

Recommended Posts

I haven't been following all of this, but what about adding a script that could be run to check for this before saving? The user would have to run the script manually, but that might be preferable to waiting for a message upon save.

Link to comment
Share on other sites

I've been away for a long time, and this is the first thread I've caught up reading.... Lots of wonderful stuff added since July!

 

Wondering why the versions of my two June navmesh scripts aren't yet included? In particular, cleaning edges fixes conflicts, and I've just used it to help somebody with their plugin.... It would be nice for them to help themselves.

 

 

It is included under the name "Skyrim - Check edge links in navmeshes.pas". I could easily forget something else since my Edit Scripts folder has like 5x times more scripts than shipped with TES5Edit.

Sorry, should have been more clear. In that archive, there's a somewhat newer version of the "Skyrim - Check edge links in navmeshes.pas", plus a version of "Skyrim - Clean edge links in navmeshes.pas" -- that somehow was missed in the past.

 

"Check edge links" is/was really mostly for checking the entire Skyrim navmesh all at once. It found a lot of problems, but they are/were hand fixed. Marginally useful for the general public.

 

"Clean edge links" is useful for many *many* patches, and should be done just before doing the ITM detect and clean. Any cleaned navmeshes will become ITMs -- and be cleared away, reducing conflicts!

Link to comment
Share on other sites

Also, I thought I'd completely mapped the navmesh edge bits. I see a bunch of Unknown listed. I'll look back through the archives and see what can be done....

Link to comment
Share on other sites

"Check edge links" is/was really mostly for checking the entire Skyrim navmesh all at once. It found a lot of problems, but they are/were hand fixed. Marginally useful for the general public.

 

"Clean edge links" is useful for many *many* patches, and should be done just before doing the ITM detect and clean. Any cleaned navmeshes will become ITMs -- and be cleared away, reducing conflicts!

I added them.
  • Like 1
Link to comment
Share on other sites

I haven't been following all of this, but what about adding a script that could be run to check for this before saving? The user would have to run the script manually, but that might be preferable to waiting for a message upon save.

Good idea, here it is :innocent:

{
  Report records that have internal FormID index greater than the number of plugin's masters.
}
unit ReportUnclampedFormIDs;

function Process(e: IInterface): Integer;
var
  idx: integer;
begin
  idx := GetElementNativeValues(e, 'Record Header\FormID') shr 24;
  if idx > MasterCount(GetFile(e)) then
    AddMessage(Format('[%s] Unclamped FormID index of %s for %s', [GetFileName(e), IntToHex(idx, 2), Name(e)]));
end;

end.

However I still don't understand why did it suddenly become a problem. There are probably hundreds or thousands of such mods for Oblivion, Fallout and Skyrim which work fine.

  • Like 1
Link to comment
Share on other sites

I would still REALLY prefer having this displayed in the UI properly instead of bolted on as a script since scripts feel like afterthoughts.

 

Honestly I don't understand the resistance to doing so.

Link to comment
Share on other sites

I'm not resistant, I just don't see any benefits from it, but clearly see possible problems in future. So I will add a note that records are unclamped similar to injection notes when plugins are being loaded in xEdit. Unclamped records usually occure because of manual masters changes in TES4 header, so basically all records new to a plugin become unclamped.

The latest xEdit version was downloaded more that 200.000 times as of now, and those users will see new messages (depending on LO of course) and start to wonder what does it mean, spam forum threads with questions, harass mod authors saying their plugins are corrupted because TES5Edit reports something iffy with them, blame that their game crashes because of unclamped records, etc. Even if we'll write in bold font on a main description page that those are not errors and can be ignored, nobody will read it. Ever. You know it better than me.

I can understand why you, an experienced modder, want to see them. But letting know of them everyone, every 200+ thousands users? I'd say no. That's why I'm "resistant".

As I said, unclamped records is a normal technique used by the beth games, official editors and xEdits to treat new records, this is not an error, doesn't cause any issues, doesn't cause conflicts, doesn't corrupt saved games, doesn't prevent cleaning, etc. What's the purpose of showing them to everyone besides experienced modders?

  • Like 1
Link to comment
Share on other sites

For one thing, I'm not convinced they aren't responsible for at least some amount of problems. At least in Skyrim. We all know the Skyrim engine is more fragile than its predecessors. Things crash far more often than they should be and are often traced back to plugins of questionable integrity.

 

It's being made worse by people who still insist on using Snip (unclamped IDs are one unmistakeable sign of such use) and by people who are running broken merge scripts that are not reconciling their form IDs properly. You need only ask KNakamura about how bad some of this stuff gets.

 

I want to also stress again that I was not asking you to make a huge spammy display out of it the way record injections are. I am aware that the output may be significantly larger if that's done. I've been asking for a simple one-liner stating the mod has unclamped form IDs. You can even include something about how they'll be fixed when the file is saved since that's happening now anyway.

 

People have seen record injections for ages btw, and nobody ever spends a great deal of time fielding questions about why they exist, are they safe, what do they do etc. So I really don't see there being some big flood of stuff about unclamped IDs either. TES5Edit is an advanced tool. Not something noobs should be playing with. Withholding information that people using the tool can use to make informed decisions seems silly.

 

I'm not trying to be a pain here. I'm just trying to make it clear why this information shouldn't be kept in the shadows the way it has been. We really DO NOT know how the game is handling these things and I'd much rather play it safe if I can know stuff I'm using has these.

Link to comment
Share on other sites

This part has not change at all in Skyrim.

I really don't think that this can lead to ANY issue as the values that would need to be clamped WILL be clamped when they are loaded in memory by the runtime or the editor.

Link to comment
Share on other sites

Using TES4Edit r1848, I have attached a bug report. I get a repeatable assertion failure from a specific ESP when expanding "Worldspace > Tamriel > Block 0,1 > Sub-Block 0,4 > 00003499 > Temporary" and also "0000349A > Temporary" - these cells are immediately west of Castle Bruma.

 

My guess is that it relates to either land records or pathgrid records, but I don't know for certain.

 

I have no idea whether this is bad records or an error in xEdit.

 

 

I'm not resistant, I just don't see any benefits from it, but clearly see possible problems in future. So I will add a note that records are unclamped similar to injection notes when plugins are being loaded in xEdit. Unclamped records usually occure because of manual masters changes in TES4 header, so basically all records new to a plugin become unclamped.

The latest xEdit version was downloaded more that 200.000 times as of now, and those users will see new messages (depending on LO of course) and start to wonder what does it mean, spam forum threads with questions, harass mod authors saying their plugins are corrupted because TES5Edit reports something iffy with them, blame that their game crashes because of unclamped records, etc. Even if we'll write in bold font on a main description page that those are not errors and can be ignored, nobody will read it. Ever. You know it better than me.

I can understand why you, an experienced modder, want to see them. But letting know of them everyone, every 200+ thousands users? I'd say no. That's why I'm "resistant".

As I said, unclamped records is a normal technique used by the beth games, official editors and xEdits to treat new records, this is not an error, doesn't cause any issues, doesn't cause conflicts, doesn't corrupt saved games, doesn't prevent cleaning, etc. What's the purpose of showing them to everyone besides experienced modders?

 

 

For one thing, I'm not convinced they aren't responsible for at least some amount of problems. At least in Skyrim. We all know the Skyrim engine is more fragile than its predecessors. Things crash far more often than they should be and are often traced back to plugins of questionable integrity.

 

It's being made worse by people who still insist on using Snip (unclamped IDs are one unmistakeable sign of such use) and by people who are running broken merge scripts that are not reconciling their form IDs properly. You need only ask KNakamura about how bad some of this stuff gets.

 

I want to also stress again that I was not asking you to make a huge spammy display out of it the way record injections are. I am aware that the output may be significantly larger if that's done. I've been asking for a simple one-liner stating the mod has unclamped form IDs. You can even include something about how they'll be fixed when the file is saved since that's happening now anyway.

 

People have seen record injections for ages btw, and nobody ever spends a great deal of time fielding questions about why they exist, are they safe, what do they do etc. So I really don't see there being some big flood of stuff about unclamped IDs either. TES5Edit is an advanced tool. Not something noobs should be playing with. Withholding information that people using the tool can use to make informed decisions seems silly.

 

I'm not trying to be a pain here. I'm just trying to make it clear why this information shouldn't be kept in the shadows the way it has been. We really DO NOT know how the game is handling these things and I'd much rather play it safe if I can know stuff I'm using has these.

 

Hide the message unless the "-iknowwhatimdoing" flag is used. This will prevent the majority of users from ever seeing the message.

TES5Edit_bugreport.txt

Link to comment
Share on other sites

Using TES4Edit r1848, I have attached a bug report. I get a repeatable assertion failure from a specific ESP when expanding "Worldspace > Tamriel > Block 0,1 > Sub-Block 0,4 > 00003499 > Temporary" and also "0000349A > Temporary" - these cells are immediately west of Castle Bruma.

My guess is that it relates to either land records or pathgrid records, but I don't know for certain.

I have no idea whether this is bad records or an error in xEdit.

I don't get any errors there with only Oblivion.esm loaded. Do you have any other mods changing those cells?
  • Like 1
Link to comment
Share on other sites

I don't get any errors there with only Oblivion.esm loaded. Do you have any other mods changing those cells?

 

Yes, as I said it was from a specific ESP. I can PM you the ESP and the ESM/Ps it depends on if you want.

Link to comment
Share on other sites

Yes, as I said it was from a specific ESP. I can PM you the ESP and the ESM/Ps it depends on if you want.

Does those plugins load fine in CS? What if you resave them in CS and load back in xEdit?

No need to post full plugins, just leave those cells and remove everything else.

  • Like 1
Link to comment
Share on other sites

If you can confirm this flag to be "AutoGen" by toggling in TES5Edit on and off, and checking in CK that "Autgen" appears and disappears constantly, then we will define it. I found a lot of flags in CK to be unreliable, like "Initially disabled" flag for navmeshes.

I finally got around to playing with this some more. My steps:

  1. Load Skyrim.esm and Update.esm in the CK.
  2. Find Tamriel world cell -17, 32 (contains one NavMesh, an AutoGen)
  3. Enter NavMesh editing mode.
  4. Clear the AutoGen flag using the menu "NavMesh -> Clear Cell Auto Generated" entry. (this does not seem to flag the data as changed for the purposes of saving the esp)
  5. ... So get the data to save by simply selecting an edge, face or vertex of the Cell's NavMesh.
  6. Save the esp and open it in TES5Edit.

In TES5Edit the NavMesh appears as an ITM with the Unknown 26 flag now missing. Repeating the above steps, leaving out step 4, produces an esp that contains an ITM NavMesh with the Unknown 26 flag present. Repeating the above steps, leaving out step 4, and actually moving a vertex in the NavMesh auto clears the AutoGen Flag and TES5Edit confirms this with Unknown 26 now missing.

 

Hopefully this helps. I can try this on additional NavMesh records if you need.

Link to comment
Share on other sites

For one thing, I'm not convinced they aren't responsible for at least some amount of problems. At least in Skyrim. We all know the Skyrim engine is more fragile than its predecessors. Things crash far more often than they should be and are often traced back to plugins of questionable integrity.

 

It's being made worse by people who still insist on using Snip (unclamped IDs are one unmistakeable sign of such use) and by people who are running broken merge scripts that are not reconciling their form IDs properly. You need only ask KNakamura about how bad some of this stuff gets.

 

I want to also stress again that I was not asking you to make a huge spammy display out of it the way record injections are. I am aware that the output may be significantly larger if that's done. I've been asking for a simple one-liner stating the mod has unclamped form IDs. You can even include something about how they'll be fixed when the file is saved since that's happening now anyway.

 

People have seen record injections for ages btw, and nobody ever spends a great deal of time fielding questions about why they exist, are they safe, what do they do etc. So I really don't see there being some big flood of stuff about unclamped IDs either. TES5Edit is an advanced tool. Not something noobs should be playing with. Withholding information that people using the tool can use to make informed decisions seems silly.

 

I'm not trying to be a pain here. I'm just trying to make it clear why this information shouldn't be kept in the shadows the way it has been. We really DO NOT know how the game is handling these things and I'd much rather play it safe if I can know stuff I'm using has these.

 

I don't mean to be one these users that comes to the forums asking what these things are :P But as someone who uses TES5Edit extensively, it might be a good idea to have some sort of FAQ perhaps for those who wish to know more about it.

 

IE: what are Injectable records and unclamped IDs? Are they bad? Can they be ignored? Should I start to worry and format my hard drive? I know that Snip was a tool used to make mods during the dawn of Skyrim modding, I know the mods made from it cause issues. How are the two related?

Link to comment
Share on other sites

Does those plugins load fine in CS? What if you resave them in CS and load back in xEdit?

No need to post full plugins, just leave those cells and remove everything else.

 

CSE can load and save the file without any trouble at all. How come the bug report doesn't tell you what caused xEdit to fail?

 

EDIT

I have used CSE Details to mark the pathgrid record as Ignored then resaved. Now xEdit has no problems, so it was failing to read the pathgrid record for some reason.

Link to comment
Share on other sites

CSE can load and save the file without any trouble at all. How come the bug report doesn't tell you what caused xEdit to fail?

I have several ideas where it happens, but hard to tell without looking at the plugin itself. Those errors are too generic to pinpoint the problem.
  • Like 1
Link to comment
Share on other sites

Are bash tags actually stored in the ESP or just in Wrye Bash.  Can they be viewed and changed in TES5Edit?

 

Wrye Bash has its own taglist.txt file when shipped, but also Wrye Bash will utilise BOSS / LOOT masterlist with its more up to date list of tags for mods ( suggestions for tags usually go to the BOSS / LOOT topic to be added .. Or at least thats how it used to work, with LOOT being more automated now the masterlist does not have a team of volunteers so dedicated to the task, so those will get added less often than they used to )

 

When a new version of Wrye Bash comes along, usually a new snapshot of the masterlist will be used to update the included taglist, and so on

 

http://wrye-bash.github.io/docs/Wrye%20Bash%20Advanced%20Readme.html#patch-tags

 

With the old BOSS, it could upload any metadata to the svn I think, for later inclusion by the team ( instead of them having to go through loads of forum posts, reports would be more direct ).

LOOT is still in beta, but I think Wrinkly has plans to do something similar eventually. You can already add user metadata locally on your own machine per mod.

 

 

You could also put the info in your mod description - Then users just select the mod, then right click and add their own ..

 

In Wrye Bash

 

Select ( left click ) Plugin

 

Right click Bash tags window and turn off automatic

 

From the same right click menu select appropriate tags for the mod

 

screenshot

 

Wrye Bash does not currently have as many tags as it used to have with Oblivion, but if development continues it will expand again as more patchers are done for Skyrim.

 

 

So no, not stored in the plugin, but the taglist gets updated by various sources ( see linked documentation above ) including direct input via Wrye Bash.

 

Though you can "copy to description", where Bash will also use them from within the plugins description text.

 

So sort of stored in the plugin ..

 

018Sjw1.jpg

Link to comment
Share on other sites

Are bash tags actually stored in the ESP or just in Wrye Bash.  Can they be viewed and changed in TES5Edit?

You can store them in the ESP but not everyone does that. Wrye Bash will look in three places. Alt3rn1ty mentioned the first two, the taglist.yaml (was taglist.txt) and the LOOT masterlist.yaml. The third is the plugin header. Just shift double click the description field to open the multi line editor. Put the bash tags suggestions there. Wrye Bash will read them.
Link to comment
Share on other sites

Thank you for the helpful info!  I have a strange thing going on with my mod Longer Durations and Annoyance Fixes.  If I don't use any bash tags the four spells get added to the bashed patch Leveled List but the 'Leveled Item' - 'VendorGold' settings don't get transferred at all.  If I use bash tags Delev and Relev the bashed patch ignores the 'Leveled Item' - 'VendorGold' settings (as it should) but only adds one of the spells (out of four) to the Leveled lists.  I apologize that this isn't the right forum for this.  I did successfully add the bash tags to the ESP's description using your instructions and they do show up in Wrye Bash correctly.  Am I using the wrong tags or did I set something up incorrectly?

Link to comment
Share on other sites

There's also technically a 4th - in Wrye Bash itself. The blank box at the bottom right of the display for a plugin file will have a list there that can be changed in Wrye Bash and is only stored in Wrye Bash.

Link to comment
Share on other sites

I figured it out.  There was no issue after all.  The spells are added to the leveled lists even though they don't show up in the bashed patch.  Only the leveled spells that required "merging' were included in the bashed patch once I added the Delev and Relev bash tags.  I really appreciate the expert help here from alt3rn1ty, Sharlikran, and Arthmoor!  I am now a bash tag hero, lol.

 

bTFu0U.jpg

 

It's a beautiful thing! :imp:

Link to comment
Share on other sites

The spells are added to the leveled lists even though they don't show up in the bashed patch.  Only the leveled spells that required "merging' were included in the bashed patch once I added the Delev and Relev bash tags.

Yeah if there are no conflicting records from other mods loading later than your mod, Wrye Bash does not need to import / merge anything into the bashed patch because the mods records are already winning, if they were tagged to import / merge and were not winning a conflict, then Wrye Bash would add them to the bashed patch to make them win ( loaded last ).

Nothing is merged or imported unnecessarily.

+1 for having a good look over Sharlikrans linked posts.

Edit : Time for a //endofftopic I feel

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...