Jump to content

Wrye Bash - All Games


Utumno

Recommended Posts

As a matter of fact, I do not. I'll load it up on my other rig & see if I can repro her error.

Edit: Uggh, Steam.. Didn't realize I hadn't downloaded it. Looks like the download won't be ready until long after I've gone to bed. I'll have to try it tomorrow. (Wish I'd known about GOG before I purchased the FO series!)

Link to comment
Share on other sites

I know everyone is busy with RL and all but did anyone test the form version thing I linked, twice? It only took me like 30 minutes so I won't feel too bad if nobody tests it but with the conversation that we had I figured someone would want to try it out.

Link to comment
Share on other sites

44 minutes ago, RavenMind said:

As a matter of fact, I do not. I'll load it up on my other rig & see if I can repro her error.

Edit: Uggh, Steam.. Didn't realize I hadn't downloaded it. Looks like the download won't be ready until long after I've gone to bed. I'll have to try it tomorrow. (Wish I'd known about GOG before I purchased the FO series!)

If you can repro the error then there is a possibility for a bug that needs to be fixed.

Link to comment
Share on other sites

34 minutes ago, Leonardo said:

If you can repro the error then there is a possibility for a bug that needs to be fixed.

Yep, and we'll have a good idea of where to look. I'll check it out tomorrow; Steam's still telling me I've got 5+ hours to go. :(

52 minutes ago, Sharlikran said:

I know everyone is busy with RL and all but did anyone test the form version thing I linked, twice? It only took me like 30 minutes so I won't feel too bad if nobody tests it but with the conversation that we had I figured someone would want to try it out.

I would Sharlikran, but I don't have SE downloaded right now, plus I don't know/haven't been around here long enough to be credible.

Link to comment
Share on other sites

Sorry to have wasted bandwidth, guys. BOSS correctly identified the problem as a corrupt Bashed Patch.

EDIT: Well, that allowed WB to load Obivion, but clicking on the Installers tab now fails with this traceback:

 

 

 

 

Traceback (most recent call last):
  File "bash\basher\__init__.py", line 3503, in OnShowPage
    self.currentPage.ShowPanel()
  File "bash\balt.py", line 1605, in _conversation_wrapper
    return func(*args, **kwargs)
  File "bash\basher\__init__.py", line 2848, in ShowPanel
    scan_data_dir)
  File "bash\balt.py", line 1605, in _conversation_wrapper
    return func(*args, **kwargs)
  File "bash\bosh\bain.py", line 1474, in _projects_walk_cache_wrapper
    return func(self, *args, **kwargs)
  File "bash\basher\__init__.py", line 2878, in _refresh_installers_if_needed
    refresh_info)
  File "bash\bosh\bain.py", line 1548, in irefresh
    changed = not self.loaded and self.__load(progress)
  File "bash\bosh\bain.py", line 1570, in __load
    self.dictFile.load()
  File "bash\bolt.py", line 1498, in load
    with path.open('rb') as ins:
  File "bash\bolt.py", line 909, in open
    return open(self._s,*args,**kwdargs)
IOError: [Errno 13] Permission denied: u'C:\\Bethesda Softworks\\Oblivion Mods\\Bash Installers\\Bash\\Installers.dat'
 


EDIT 2: NVM again. Deleting the contents of that folder and letting WB scan everything again fixed the problem. I appear to have gremlins.

Link to comment
Share on other sites

4 hours ago, Sharlikran said:

I know everyone is busy with RL and all but did anyone test the form version thing I linked, twice? It only took me like 30 minutes so I won't feel too bad if nobody tests it but with the conversation that we had I figured someone would want to try it out.

Can test it here, but for the moment running a strictly vanilla SSE rig bar USSEP. If you can cook up instructions together with dummy mods with ver 43 records etc that would help.

In fact such a thing as a test mod setup as part of the general debugging process would be the go. And an effectual tutorial/FAQ/wiki on all things debugging would go down well. It would also save the efforts of many of the more experienced/veteran modders that may be pressed for time. :)

Link to comment
Share on other sites

3 hours ago, lmstearn said:

Can test it here, but for the moment running a strictly vanilla SSE rig bar USSEP. If you can cook up instructions together with dummy mods with ver 43 records etc that would help.

In fact such a thing as a test mod setup as part of the general debugging process would be the go. And an effectual tutorial/FAQ/wiki on all things debugging would go down well. It would also save the efforts of many of the more experienced/veteran modders that may be pressed for time. :)

I understand that in a normal environment those are important. I'm just the messenger so to speak, and as they say don't kill the messenger.  I appreciate you offering to test and provide feedback, but I don't experience the issues so I'm not really able to provide any accurate or informative information.  I'm sure the vanilla setup is fine since you can't patch much anyway.

I'm just providing the suggestion. I'm just trying to be civil and objective and provide the required Form Version for testing.  If you need information as to what is happening, the current hypothesis, please refer to previous posts by other people, not my posts.  The reason none of my posts would be helpful is because I'm only clarifying the current hypothesis.  I don't have any test mods nor any idea what to test since I have no current issues.

On top of that I have programming classes and I'm behind as it is so I won't be available much. I'll can try to provide some feedback over the weekend but that's about it.

Link to comment
Share on other sites

15 hours ago, Supierce said:

Utumno, the latest WIP works fine with FO4, but when I try to open it for Oblivion, I get the following traceback:

 

  Hide contents

 

 



	Wrye Bash encountered an error.
Please post the information below to the official thread at:
https://www.afkmods.com/index.php?/topic/4966-wrye-bash-all-games/& or 
https://bethesda.net/community/topic/38798/relz-wrye-bash-oblivion-skyrim-skyrim-se-fallout-4/
Traceback (most recent call last):
  File "bash\bash.py", line 260, in main
    _main(opts)
  File "bash\bash.py", line 425, in _main
    app.Init() # Link.Frame is set here !
  File "bash\basher\__init__.py", line 3996, in Init
    self.InitData(progress)
  File "bash\basher\__init__.py", line 4034, in InitData
    bosh.modInfos = bosh.ModInfos()
  File "bash\bosh\__init__.py", line 1783, in __init__
    FileInfos.__init__(self, dirs['mods'], ModInfo)
  File "bash\bosh\__init__.py", line 1310, in __init__
    self._initDB(dir_)
  File "bash\bosh\__init__.py", line 1391, in _initDB
    super(FileInfos, self)._initDB(dir_)
  File "bash\bosh\__init__.py", line 1305, in _initDB
    bolt.PickleDict(self.bash_dir.join(u'Table.dat')))
  File "bash\bolt.py", line 1702, in __init__
    dictFile.load()
  File "bash\bolt.py", line 1498, in load
    with path.open('rb') as ins:
  File "bash\bolt.py", line 909, in open
    return open(self._s,*args,**kwdargs)
IOError: [Errno 13] Permission denied: u'C:\\Bethesda Softworks\\Oblivion Mods\\Bash Mod Data\\Table.dat'

 

 

At that point, WB laundhes a window that says, 'Initializing ModInfos', which can't be closed without rebooting my computer.

As always, let me know what you  need. Thank you!  :)

 

Hmmm - no need to reboot in that case, just kill Bash (python exe) from task manager - but still who can be possibly locking those files and especially for oblivion ?

 

Please download Process Explorer ( https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer ) and next time this happens -> Cntr + F > search for "Bash Mod Data" and see if it gets you the program that locks those files

 

@Daidalos the frozen project dialog is because of the changes for 373 - I am mostly worried that the bugdump is not produced however - the progress dialog should be easy to fix

 

EDIT: @Supierce - also, next time this happens please try to see if it also happens on dev - if it's Bash that does this we should absolutely pin it

Link to comment
Share on other sites

On 10/25/2017 at 2:16 PM, alt3rn1ty said:

I wont be around for a couple of weeks, my better half and I are off for a bit of fun in the sun to celebrate our anniversay :hug:

Hope you all behave while I'm away :beer:.

I'm a bit late but I hope you're having a fantastic anniversary trip! :D

On 10/25/2017 at 8:15 PM, Sharlikran said:

@Beermotor You can test that code I made for @Arthmoor  also if you want to test it. I don't know what tests to do because I don't have the issues. The only thing you can't do is you can't merge the old Skyrim format for the records that Bethesda changed unless they are already the proper format for Skyrim SE. I added error checking at the beginning even during the testing phase for my pre-alpha. So you won't be able to merge LTEX, MATO, MOVT, STAT, WATR, WEAP, WTHR.  That error checking was added Nov 3 2016, in this commit. So it's been that way for a while. I think you noticed that error already though.

Now to clarify, you can merge those if they have been saved with the Skyrim SE CK first.

I have tested with it and I'm about to write a post with my findings in it.  So far: very very good.

 

On 10/25/2017 at 8:26 PM, RavenMind said:

@Utumno This info is what alt3rn1ty was refering to about Nexus. Basically issuing a PR statement/warning about building Bashed Patches for SSE with Form 43 records &/or improperly ported mods. I tried to just post the most relevant info for you to keep it as short a read as possible. Still wound up long, but at least it's in one spot. Full posts are linked to.

(snip)

{My apologies to everyone for cutting up your posts. This was done in an attempt at brevity. I linked to the originals, and if you feel I've removed anything important, please let me know.)

We need to keep you around to write outreach messages. :) I really like your wording of the statement.  That's practically perfect.

So touching base with everyone else:

@Utumno I got your messages from GitHub. I'm on call this weekend and sick, so I've got some downtime and should be able to get in there. Posting here in case you see this first, but I'll reply over there too. 

@Supierce I've been getting an urge to play some Fallout 4 so I'll see if I can reproduce what you ran into.

Link to comment
Share on other sites

@Sharlikran I ran a patch up for SSE with the code you put up to test. All the form versions appear correct but I have not had the chance to throw it into the game to check it to see if it still causes corruption issues.

Link to comment
Share on other sites

On 10/25/2017 at 8:15 PM, Sharlikran said:

@Beermotor You can test that code I made for @Arthmoor  also if you want to test it. I don't know what tests to do because I don't have the issues. The only thing you can't do is you can't merge the old Skyrim format for the records that Bethesda changed unless they are already the proper format for Skyrim SE. I added error checking at the beginning even during the testing phase for my pre-alpha. So you won't be able to merge LTEX, MATO, MOVT, STAT, WATR, WEAP, WTHR.  That error checking was added Nov 3 2016, in this commit. So it's been that way for a while. I think you noticed that error already though.

Now to clarify, you can merge those if they have been saved with the Skyrim SE CK first.

As promised I did a quick test and got some very satisfying results.  For the images below I created a fresh Bashed Patch then renamed it 'Bashed Patch, 9.esp' for comparisons.

First off the Bashed Patch TES4 header was in form version 44.

Spoiler

Sharlikran-bashedpatch-tes4header.PNG.47214324553e02c6c571a6400ad10a17.PNG

Checking random records to find one that was not v44 in the master and original bashed patch:

ARMO record:

Spoiler

Sharlikran-bashedpatch-recordversions.thumb.PNG.a05689dae6eb29d23360d68827069854.PNG

COBL record

Spoiler

Sharlikran-bashedpatch-recordversions-COBL.thumb.PNG.9b0b713b642edd56e5ab8b3a82fbc816.PNG

Will test in game. I actually have a prime example of a poorly ported plugin that I'm going to keep around for testing purposes.

I'm going to be kind of scarce this weekend due to being on call but I will check in now and again if there's anything else I can test.

Link to comment
Share on other sites

I would want to see what the dictionary actually contains and whether or not it's effected by `mergeClasses` or the dictionary assigned to `brec.MreRecord.type_class` and `brec.MreRecord.simpleTypes`. Determining what format to use i.e. '=4sIi3I', '=4s5I' , '=4sI4s3I', and '=4sI2h3I' is determined by get_dict_key which covers all 11 types show in the UESP Wiki.

Link to comment
Share on other sites

After reviewing it a bit more I may have left it out because of get_dict_key which gets the proper format for pack and unpack, and get_unique_label which makes sure that either a 4 char signature or a signed integer is used. I commented out type 4 and 5 for get_unique_label because that is handled in the CELL patcher and trying to pass out a tuple caused a TypeError, IIRC. Which is why I handle GRUP type 4 and 5 similar to how the original code handled it in def pack(self) with self.label[0], self.label[1]. Be sure those are in that order so it doesn't reverse the CELL X, Y position.

Link to comment
Share on other sites

1 hour ago, Beermotor said:

Will test in game. I actually have a prime example of a poorly ported plugin that I'm going to keep around for testing purposes.

I'm going to be kind of scarce this weekend due to being on call but I will check in now and again if there's anything else I can test.

Put RL first. If you have time that's fine. Just refer to my previous post because I have error checking so that that Wrye Bash tells the user when one of the records that Bethesda changed for Skyrim SE is not in use by the plugin.  Which means it's still Form Version 43 or lower.  It's very rudimentary but basically if it's not in the format for Form Version 44 then the user would receive a warning.

Link to comment
Share on other sites

Spoiler

 


{'BPTD': 'BPTD', 'KUYM': 'KEYM', 'MUSC': 'MUSC', 'MUSG': 'MESG', 'I^GR': 'INGR', 'AQCT': 'AACT', 'DUAL': 'DUAL', 'LSTN': 'LCTN', 'SSPT': 'SCPT', 'MUST': 'MUST', 'AVIF': 'AVIF', 'ASTI': 'ACTI', 'ITLE': 'IDLE', 'SSOL': 'SCOL', 'S]EN': 'SMEN', 'ITLM': 'IDLM', 'G]ST': 'GMST', 'QUST': 'QUST', 'C_NT': 'CONT', 'IPDS': 'IPDS', 'I]AD': 'IMAD', 'KYWD': 'KYWD', 'D_BJ': 'DOBJ', 'CULL': 'CELL', 'LVLI': 'LVLI', 'LVLN': 'LVLN', 'DUBR': 'DEBR', 'CPTH': 'CPTH', 'CQMS': 'CAMS', 'D\\VW': 'DLVW', 'MQTO': 'MATO', 'TREE': 'TREE', 'WQTR': 'WATR', 'S_PM': 'SOPM', 'MQTT': 'MATT', 'NQVI': 'NAVI', 'RUVB': 'REVB', 'STAT': 'STAT', 'HQZD': 'HAZD', 'VTYP': 'VTYP', 'C\\MT': 'CLMT', 'PWAT': 'PWAT', 'A\\CH': 'ALCH', 'E^CH': 'ENCH', 'ESZN': 'ECZN', 'C_LL': 'COLL', 'RQCE': 'RACE', 'ASTP': 'ASTP', 'I]GS': 'IMGS', 'TXST': 'TXST', 'G\\OB': 'GLOB', 'MWEF': 'MGEF', 'LUNS': 'LENS', 'EYES': 'EYES', 'MSTT': 'MSTT', 'S^CT': 'SNCT', 'LVSP': 'LVSP', 'NPC_': 'NPC_', 'C\\FM': 'CLFM', 'F\\ST': 'FLST', 'WTHR': 'WTHR', 'DYAL': 'DIAL', 'V_LI': 'VOLI', 'PROJ': 'PROJ', 'EQUP': 'EQUP', 'MYSC': 'MISC', 'D\\BR': 'DLBR', 'S]BN': 'SMBN', 'B_OK': 'BOOK', 'S^DR': 'SNDR', 'ATDN': 'ADDN', 'C_BJ': 'COBJ', 'A^IO': 'ANIO', 'FURN': 'FURN', 'LSCR': 'LSCR', 'ASPC': 'ASPC', 'LYGH': 'LIGH', 'RULA': 'RELA', 'GRAS': 'GRAS', 'S\\GM': 'SLGM', 'EXPL': 'EXPL', 'APPA': 'APPA', 'S_UN': 'SOUN', 'HTPT': 'HDPT', 'RWDL': 'RGDL', 'FQCT': 'FACT', 'FSTP': 'FSTP', 'FSTS': 'FSTS', 'CSTY': 'CSTY', 'OTFT': 'OTFT', 'WRLD': 'WRLD', 'TQCT': 'TACT', 'HQIR': 'HAIR', 'LTEX': 'LTEX', 'ARMO': 'ARMO', 'PQCK': 'PACK', 'D_OR': 'DOOR', 'ARTO': 'ARTO', 'C\\DC': 'CLDC', 'RVCT': 'RFCT', 'ARMA': 'ARMA', 'RUGN': 'REGN', 'EVSH': 'EFSH', 'SSRL': 'SCRL', 'A]MO': 'AMMO', 'W_OP': 'WOOP', 'C\\AS': 'CLAS', 'LWTM': 'LGTM', 'LSRT': 'LCRT', 'F\\OR': 'FLOR', 'SPEL': 'SPEL', 'WUAP': 'WEAP', 'SXOU': 'SHOU', 'M_VT': 'MOVT', 'SPGD': 'SPGD', 'IPCT': 'IPCT', 'PURK': 'PERK', 'SSEN': 'SCEN', 'S]QN': 'SMQN'}

 

 

That is the dictionary for topIgTypes. Do you know what it does?  I see a key or 'I^NG' with a value of 'INGR' and the significance isn't apparent because for Skyrim SE INGR is mergable so it wouldn't be ignored. Why is 'G]ST' the key for 'GMST' and why is 'F\\OR' the key for 'FLOR'?

I was going to look into that a bit and see if it was effected by other routines, but I'm not so sure I want to unless I know what it's really for.

Now on the other hand recordTypes makes a bit more sense.

set(['ANIO', 'BPTD', 'CONT', 'MUSC', 'OTFT', 'ENCH', 'EFSH', 'CLMT', 'MOVT', 'MUST', 'AVIF', 'LCRT', 'PERK', 'SMQN', 'QUST', 'IPDS', 'RELA', 'KYWD', 'LVLI', 'LVLN', 'NAVI', 'GLOB', 'LIGH', 'CPTH', 'CLFM', 'DEBR', 'WATR', 'DIAL', 'SCOL', 'TREE', 'ACTI', 'SPEL', 'ADDN', 'PACK', 'GMST', 'STAT', 'VTYP', 'SMEN', 'SCEN', 'PWAT', 'REGN', 'COLL', 'PGRE', 'ASTP', 'FLOR', 'REVB', 'TXST', 'SOUN', 'BOOK', 'INGR', 'EYES', 'DOOR', 'MSTT', 'IMAD', 'DLBR', 'MISC', 'LVSP', 'NPC_', 'MATT', 'CLDC', 'WOOP', 'ASPC', 'PROJ', 'EQUP', 'HAIR', 'FURN', 'LAND', 'LSCR', 'WTHR', 'HDPT', 'GRAS', 'ARMO', 'IDLE', 'SNDR', 'EXPL', 'IDLM', 'CLAS', 'APPA', 'ARMA', 'REFR', 'SNCT', 'ACHR', 'FSTP', 'FSTS', 'CSTY', 'WEAP', 'IMGS', 'DUAL', 'WRLD', 'VOLI', 'INFO', 'SMBN', 'LTEX', 'RFCT', 'ECZN', 'HAZD', 'LGTM', 'SCRL', 'COBJ', 'ALCH', 'FLST', 'PHZD', 'TES4', 'AACT', 'CAMS', 'MGEF', 'DOBJ', 'CELL', 'RACE', 'ARTO', 'SLGM', 'SHOU', 'NAVM', 'ACRE', 'TACT', 'RGDL', 'LENS', 'KEYM', 'MATO', 'MESG', 'SOPM', 'DLVW', 'SCPT', 'GRUP', 'SPGD', 'FACT', 'IPCT', 'LCTN', 'AMMO'])

That's pretty clear that it is the aggregate collection of the valid record plus the records that are not a top group such as a placed object like PHZD which is a Placed Hazard.

According to pycharm topIgTypes  is not used so it was only for class RecordHeader. Now that I see what PyCharm is saying, and looking at the contents of the dictionary, it makes no sense to me. What I am doing is better IMO because I look at the record and evaluate the type of the record. If it is a normal record then I process it as such. If it is a GRUP record I convert the field know as label, to the proper signature.  So if you have a GRUP record of 'PERK', the record signature is still GRUP, but the label is PERK because only PERK records will follow the GRUP marker. GRUP is like an index. If it is a different type of GRUP record then I convert the field known as label to whatever value it's supposed to be according the the UESP Wiki. I have compared that with the xEdit source as well though.

Link to comment
Share on other sites

I got a problem with my install and my googlefu has come up short. Since my win10 just updated to the new fall update I tried to update Wrye to the more recent 307.201710222147, and now it crashes on startup with this error I haven't found anywhere else

Error! Unable to start Wrye Bash.


Please ensure Wrye Bash is correctly installed.


Traceback (most recent call last):
  File "bash\bash.py", line 351, in _main
    import bosh # this imports balt (DUH) which imports wx
  File "Wrye Bash Launcher.pyw", line 76, in load_module
    exec compile(code, initfile, 'exec') in mod.__dict__
  File "bash\bosh\__init__.py", line 47, in <module>
    from ._mergeability import isPBashMergeable, isCBashMergeable
  File "Wrye Bash Launcher.pyw", line 63, in load_module
    mod = imp.load_source(fullname,filename+ext,fp)
  File "bash\bosh\_mergeability.py", line 30, in <module>
    from ..load_order import cached_is_active
  File "Wrye Bash Launcher.pyw", line 63, in load_module
    mod = imp.load_source(fullname,filename+ext,fp)
  File "bash\load_order.py", line 45, in <module>
    import balt
  File "Wrye Bash Launcher.pyw", line 63, in load_module
    mod = imp.load_source(fullname,filename+ext,fp)
  File "bash\balt.py", line 814, in <module>
    import wx.lib.iewin as _wx_lib_iewin
  File "C:\Program Files (x86)\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\iewin.py", line 15, in <module>
    import wx.lib.activex
  File "C:\Program Files (x86)\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\activex.py", line 37, in <module>
    import comtypes.client as cc
  File "C:\Program Files (x86)\Python27\lib\site-packages\comtypes\client\__init__.py", line 33, in <module>
    gen_dir = _find_gen_dir()
  File "C:\Program Files (x86)\Python27\lib\site-packages\comtypes\client\_code_cache.py", line 30, in _find_gen_dir
    if not _is_writeable(gen.__path__):
  File "C:\Program Files (x86)\Python27\lib\site-packages\comtypes\client\_code_cache.py", line 110, in _is_writeable
    tempfile.TemporaryFile(dir=path[0])
  File "C:\Program Files (x86)\Python27\lib\tempfile.py", line 475, in NamedTemporaryFile
    (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags)
  File "C:\Program Files (x86)\Python27\lib\tempfile.py", line 257, in _mkstemp_inner
    raise IOError, (_errno.EEXIST, "No usable temporary file name found")
ImportError: caused by ImportError(u'caused by ImportError(u\'caused by ImportError(u"caused by IOError(17, \\\'No usable temporary file name found\\\')",)\',)',)

Running Wrye by itself instantly causes this crash while running it through MO causes a "Cannot be completed because the folder is open in another program" infinite loop, which canceling out causes another crash with a similar error. It's a fresh install and I also reinstalled Python from scratch as well. Doesn't matter where or which drive the Mopy folder is, it will still cause the same crash regardless.

EDIT: Just found out that it was crashing only because python.exe wasn't given admin permissions. The folder infinite loop is still occuring though I'm about to reinstall Python straight to C instead of program files.

EDIT: It's fixed now. The instructions I was using didn't make it clear but DON'T install Python to Program Files, instead install it elsewhere but there, I'll leave the post here in case someone else tries to google that error

Link to comment
Share on other sites

Latest utumno-wip attempts to fix the form version bug - please make bashed patches and test nothing broke. It also has a fix for esls load order (I force them to load amongst the esms) and various others fixups but before I pack a standalone I need this tested.

If all goes well we're pretty much done - what remains is

-  decide on handling of displaying esl masters for a save -  as discussed I display them all at the end as the save file has them all together after the espms - but this needs fixing 

- display a warning for SSE plugins with form version 43 in the header?

@Arthmoor what you say ? Especially about the saves - that's not trivial and I want some thought to go into this

 

@Sharlikran probably topIgTypes is a relic of unknown purpose - for the moment I kept it but if someone remembers what's about welcome (@Arthmoor or @zilav ?) Needs lot of work to further refactor RecordHeader and related code - later if ever

@Al3ph python needs not be placed anywhere specially - that's comtypes dependency that blows - not sure why - I need to rip it off, I wait on @nycz for this

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

This is entirely unrelated to anything you guys are discussing right now, but I figured I should post it just in case. There's also a chance you're familiar with this issue, in which case I apologize for bringing it up again. I took this screenshot about two weeks ago when I noticed that my bashed patch ran into a weird precision error when calculating weight and texture lighting (every weight record is 30, while the Bashed Patch figured it was 30.000002).

I was told that python in particular has float point precision issues, but IEEE 754 should be able to represent 30 and in this particular case there shouldn't be any arithmetic operations running on the number.

Personally, I don't know if character weight even accounts that low (I'm pretty sure it rounds to the hundredth decimal or ignores anything past that) and I do not know the repercussions of character lighting being 1 point off (don't believe it would cause in facegen issues). From the people I talked to, it was recommended at the very least I should report this as a bug.

Thanks!

1508463325_SSEEdit.png

Link to comment
Share on other sites

DylanJames, would you do me a small favor please, would you load all your mods including the ones that are disabled, ghosted, merged, or whatever (load them all literally) into xEdit.  I'd like to know if you could look for two things please. 1) Does any mod have that value for NAM7? 2) Are any mods missing the NAM7 subrecord?

Link to comment
Share on other sites

2 hours ago, Utumno said:

 

@Sharlikran probably topIgTypes is a relic of unknown purpose - for the moment I kept it but if someone remembers what's about welcome (@Arthmoor or @zilav ?) Needs lot of work to further refactor RecordHeader and related code - later if ever

 

@Utumno Thank you for the refactored code for class RecordHeader. It's nice to see how you would do things differently then the code I presented. I commented on it and if you have a moment, could you please update the code I suggested for the Cell Coordinates. I don't know what packing and unpacking a signed 32 bit integer into 2 16 bit integers will do and since it's for the CELL records, which can make things somewhat unstable when they are not processed properly, it might be best to make that adjustment.

Also I know you have been very busy with that code, but in the interest of keeping the Form Version 44 records current and up to date, would you please cherry pick the 3 Skyrim SE updates into utumno-wip?  Those testing, if they compare AMMO records, will be loosing one byte because Bethesda updated that record. It's not based off of the Form Version but it is properly handled to cover any From Version presented to Wrye Bash and ensure it is the correct format for Skyrim SE. The other thing Bethesda addressed is that they finally fixed the bug in SPGD that I reported. And last, MreLens isn't mergable because I didn't realize that Bethesda had duplicate signatures and because of how the elements are assigned in MelSet, Wrye Bash can't handle duplicate signatures without a custom unpacker.

  • Like 1
Link to comment
Share on other sites

1 hour ago, Utumno said:

Latest utumno-wip attempts to fix the form version bug - please make bashed patches and test nothing broke. It also has a fix for esls load order (I force them to load amongst the esms) and various others fixups but before I pack a standalone I need this tested.

If all goes well we're pretty much done - what remains is

-  decide on handling of displaying esl masters for a save -  as discussed I display them all at the end as the save file has them all together after the espms - but this needs fixing 

- display a warning for SSE plugins with form version 43 in the header?

@Arthmoor what you say ? Especially about the saves - that's not trivial and I want some thought to go into this

 

@Sharlikran probably topIgTypes is a relic of unknown purpose - for the moment I kept it but if someone remembers what's about welcome (@Arthmoor or @zilav ?) Needs lot of work to further refactor RecordHeader and related code - later if ever

I'll give the new version a look and let you know. As far as displaying the ESL files, I still think it would be best if they were placed in the order the save itself thinks they're being handled in. I noticed something odd about that the other day though and need to take a bit of time to look it over again to be sure. I think I may end up needing to update my post on the subject.

I think we definitely want to issue a warning if any mods with Form 43 in the TES4 header are present. Don't block them from being used, just pop up a warning box about it. It's a serious enough problem that it should not simply be ignored because a few random people think it isn't a real issue.

Building a patch needs to abort though if an SSE mod record is going to be imported but it's not from a mod that's using Form 44 for that record type. When the CK saves a file in SSE, all forms are version 44. So there should be no reason to see mixed versions in anything other than Bethesda's original 5 files.

I know nothing about what topIgTypes is so I'll defer to anyone else who might on what to do with it.

Link to comment
Share on other sites

4 hours ago, Utumno said:

Latest utumno-wip attempts to fix the form version bug - please make bashed patches and test nothing broke. It also has a fix for esls load order (I force them to load amongst the esms) and various others fixups but before I pack a standalone I need this tested.

Thumbs up with Oblivion and FO4!  :)

Link to comment
Share on other sites

Ok, I've had a chance to check load positioning on ESL files again now that their index numbers are showing up in the saves tab (somehow they weren't before, but are now) and I've modified the relevant thread to reflect the updated findings.

The Mods tab currently agrees with the logic seen in the actual load order the save masters present, but the saves tab itself still has the plugins ordered wrong. Not sure what the deal is there, but hey.

Somewhat disappointing that they chose to push ESLs converted from normal ESPs onto the top side of the load stack instead of just letting them get sorted amongst the other ESP files. That kind of restricts their usefulness.

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