Jump to content

[WIPz] TES5Edit


zilav

Recommended Posts

You know, this is not a bug report really :) Version 3.1 is 3.0.33, that doesn't make sense at all. I wouldn't trust a word of a user with 18 posts registered probably several days ago.

Need steps to reproduce and a test plugin(s).

  • Like 1
Link to comment
Share on other sites

You know, this is not a bug report really :) Version 3.1 is 3.0.33, that doesn't make sense at all. I wouldn't trust a word of a user with 18 posts registered probably several days ago.

Need steps to reproduce and a test plugin(s).

 

Well, the access violations are in the log, it's hard to argue with that-

Access violation at address 007ABD6A in module 'TES5Edit.exe'. Read of address 00000000

And the test plugins are also in the log-

Merging SMIM-DragonbornTernFix.esp
Merging SMIM-DungeonsCliffsIceSkirts.esp
Merging SMIM-FurnitureChestSnowFix.esp
Merging SMIM-ShackRoofFixes.esp
Merging SMIM-ShackRoofFixesDragonborn.esp

Merging SMIM-FarmhouseFlickeringFix.esp

And the record is also in the log-

Failed to copy GRUP Cell Temporary Children of RiverwoodGerdursHouse "Hod and Gerdur's House" [CELL:000133C7]

As I said before, it may or may not be a bug report.  I'll have to look into these plugins to see if I can recreate the access violation, and then look at the records to see if I can see a reason why it might happen.

Link to comment
Share on other sites

Was unable to recreate issue with TES5Edit 3.10 svn1910 with script or copying manually.
Also tested with 3.1.1 svn1915, unable to recreate issue.  Assuming user error.

Link to comment
Share on other sites

Another user had the same access violation error when copying a CELL's child group.  Again, I couldn't recreate their error when I applied the script.  The only thing I can imagine is that something is happening which is machine specific, perhaps something to do with windows/permission settings/something else?  Hell if I know, this has me beat.

gydKk.png

Link to comment
Share on other sites

You should not copy GRUP records at all, check ElementType(e) = etMainRecord before even trying. xEdit handles GRUP records itself.

  • Like 1
Link to comment
Share on other sites

You should not copy GRUP records at all, check ElementType(e) = etMainRecord before even trying. xEdit handles GRUP records itself.

 

But will that return true for CELL/WRLD records which have subrecords as well as child groups?

Link to comment
Share on other sites

But will that return true for CELL/WRLD records which have subrecords as well as child groups?

Needed groups are created automatically when you copy main records.

  • Like 1
Link to comment
Share on other sites

I don't really think this should be TES5Edit's responsibility to take account of, but I found an issue with string[] script properties that have been initialized but are emtpy.  In HelmetToggle2.02b.esp the mz_ScriptSpellQuest record is interpretted incorrectly due to an empty string[] script property.  I was able to resolve this in the CK by removing the edited value of the script property, setting it to <<Using Default Script Value>> instead.  I think that mod authors should never set a string[] script property to an empty array, but I thought I'd mention this here anyways.  I can provide screenshots as well if that would help.

 

Regards,
-Mator

Link to comment
Share on other sites

I agree, I have seen mods with poorly manage the properties and they have unresolved references. Sometimes I want that cleared out during cleaning but it's probably not a good idea. It's just something I find disappointing when I see authors do that.

Link to comment
Share on other sites

I agree, I have seen mods with poorly manage the properties and they have unresolved references. Sometimes I want that cleared out during cleaning but it's probably not a good idea. It's just something I find disappointing when I see authors do that.

 

Well this isn't even an unresolved reference, this is a expected # bytes of data, but found #.  It breaks the entire subrecord structure in the VMAD.

 

I too, dislike unresolved references.  But those aren't something xEdit can do anything about.  What I'm talking about here is due to xEdit not taking into account the fact that a string[] property can be an empty string array.

Link to comment
Share on other sites

If an empty string array is causing xEdit to throw errors and then break the VMAD structure from there, that's something that should be fixed so it's handled properly. I'd assume it's because an empty string[] is considered a valid type the CK will save to the file rather than just leaving out when it's set to the "Using Default Script Vale" setting.

Link to comment
Share on other sites

Upload a test plugin with a record that cannot be copied as override (or as new record) please.

 

Ok.  Just a moment.

Link to comment
Share on other sites

Sorry for just throwing this out there without much in the way of supporting information. However, the discussion for FO3Edit started with a plugin that had a placed object in it. The main focus of my comment isn't the subrecord but the implication by users that 3.0.32 loaded it just fine and mentioned the out of order subrecord, while 3.1 throws an exception. You can see the portion of the error log in the FO3Edit comments section.  If you search the FNVEdit thread for "Read of address" you do get other reports of the same thing for other versions and different circumstances.  The oblivion comments section has nothing.  Althought the Skyrim thread has a few hits they are again, under different circumstances.  I think the only one that has a reproducible error is Fallout 3 Experiment -Grytobia.  Even though there are arguments as to why it should be considered a TTW mod, would there be a chance that a more appropriate error message could be shown?  That is if you can figure out where it's happening.

Link to comment
Share on other sites

Upload a test plugin with a record that cannot be copied as override (or as new record) please.

 

You can download HelmetToggle2.02b.esp here-

http://www.nexusmods.com/skyrim/mods/22765

(total download is 4kb, plugin has only 11 records in it)

My fixed ESP is here-

http://puu.sh/gC1se.esp

 

 

For opening the plugin in the CK you'll need to have SKSE and the SKI_ (skyUI) base scripts, as it does use an MCM menu script as base.

Here's a

in TES5Edit 3.1.1.

 

The raw messages data-

[00:00] Checking for Errors in [02] HelmetToggle2.02b.esp

[00:00] mz_ScriptSpellQuest "Script Spell Quest" [QUST:02000D66]

[00:00]     QUST \ VMAD - Virtual Machine Adapter \ Data \ Quest VMAD \ Scripts \ Script \ Properties \ Property \ Type -> <Unknown: 0>

[00:00]     QUST \ VMAD - Virtual Machine Adapter \ Data \ Quest VMAD \ Scripts \ Script \ Properties \ Property \ propertyName -> Expected 28527 bytes of data, found 256

[00:00]     QUST \ VMAD - Virtual Machine Adapter \ Data \ Quest VMAD \ Scripts \ Script \ Properties \ Property \ Type -> Expected 1 bytes of data, found 0

[00:00]     QUST \ VMAD - Virtual Machine Adapter \ Data \ Quest VMAD \ Scripts \ Script \ Properties \ Property \ Flags -> Expected 1 bytes of data, found 0

[00:00]     QUST \ VMAD - Virtual Machine Adapter \ Data \ Quest VMAD \ Scripts \ Script \ Properties \ Property \ Value -> Expected 4 bytes of data, found 0

[00:00] All Done!

Here's a screenshot of the corrupted data in TES5Edit:

gCKT1.png

Here's a screenshot of the part of the plugin file that's being interpretted incorrectly in HxD:

gCL6j.png

 

 

Here's a screenshot of the offending edit in the Creation Kit:

gCLsN.png

 

I think I went a bit all out.  xD

Link to comment
Share on other sites

Looking at both the Editor and Runtime for FO3 and FNV, PBEA is a valid record, and its content is handled by the same routine that handles base Reference or other Placed projectiles. You can add one into the game through the GECK by duplicating one of the existing missiles, change its type to Beam and then drop it in a cell.

 

EDIT: and no, the record type was not supported by 3.0.32 either so it didn't load without errors. The difference is 3.1 generates a second error (assertion) after detecting the "bad" form type which locks editing the plugin.

 

The solution here is to add the form type to the definition, which I should do a bit later.

Link to comment
Share on other sites

The difference is 3.1 generates a second error (assertion) after detecting the "bad" form type which locks editing the plugin.

I actually don't remember that change in any svn versions, is it on purpose or some bug slipped?
  • Like 1
Link to comment
Share on other sites

Sorry it's an exception not an assertion: EAccessViolation.

I used the wrong term.

 

On the other hand, it avoids trying to make changes to the plugin xEdit couldn't do safely anyway :)

Link to comment
Share on other sites

@Mator: It looks like undefined or incomplete properties are not consistent between plugins and save. I altered the plugin definition to expect no value if the type is null, instead of an empty integer.

I have no idea where Skyrim memorizes it's an array of string though, in the script source ?

Link to comment
Share on other sites

I saw one of my scripts that had an array for the property have two [] after the type. When it wasn't an array it was just string or integer. Sometimes authors don't want to include the source so not sure you can always check for that. I can't get the plugin until maybe tomorrow but I could show you the plugin I'm working on with the array and the source script.

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...