Jump to content

Wrye Bash - All Games


Utumno

Recommended Posts

Also when testing without merge plugins the first time I went back and tested with all other tweaks active and these errors came up:

Traceback (most recent call last):
  File "bash\gui\events.py", line 180, in _post
  File "bash\balt.py", line 704, in _conversation_wrapper
  File "bash\basher\patcher_dialog.py", line 171, in PatchExecute
  File "bash\patcher\patch_files.py", line 435, in buildPatch
  File "bash\brec\record_groups.py", line 698, in keepRecords
  File "bash\brec\record_groups.py", line 518, in _call_super
  File "bash\brec\record_groups.py", line 441, in keepRecords
  File "bash\brec\record_groups.py", line 507, in _call_super
  File "bash\brec\record_groups.py", line 1188, in keepRecords
AttributeError: 'NoneType' object has no attribute 'fid'
base.py  205 _parse_csv_sources: Crowded Roads Revamped_Names.csv is not saved in UTF-8 format
Traceback (most recent call last):
  File "bash\patcher\base.py", line 196, in _parse_csv_sources
  File "bash\parsers.py", line 182, in read_csv
  File "<frozen codecs>", line 322, in decode
  File "encodings\utf_8_sig.py", line 69, in _buffer_decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 105: invalid start byte

base.py  205 _parse_csv_sources: Crowded Roads Revisited_Alternate_Names.csv is not saved in UTF-8 format
Traceback (most recent call last):
  File "bash\patcher\base.py", line 196, in _parse_csv_sources
  File "bash\parsers.py", line 182, in read_csv
  File "<frozen codecs>", line 322, in decode
  File "encodings\utf_8_sig.py", line 69, in _buffer_decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 125: invalid start byte

base.py  205 _parse_csv_sources: Crowded Roads Revisited_Names.csv is not saved in UTF-8 format
Traceback (most recent call last):
  File "bash\patcher\base.py", line 196, in _parse_csv_sources
  File "bash\parsers.py", line 182, in read_csv
  File "<frozen codecs>", line 322, in decode
  File "encodings\utf_8_sig.py", line 69, in _buffer_decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 115: invalid start byte

they went away of course when I chose default and turned off the offending options. But included here because I have them to report. I'm pretty sure those CSV files are included with Wrye Bash.

As for the BC UL thing ... I really don't want to bother Vorians with another thing that might be just a wrye bash problem.

Here is the log associated with the above errors:

Traceback (most recent call last):
  File "bash\gui\events.py", line 180, in _post
  File "bash\balt.py", line 704, in _conversation_wrapper
  File "bash\basher\patcher_dialog.py", line 171, in PatchExecute
  File "bash\patcher\patch_files.py", line 435, in buildPatch
  File "bash\brec\record_groups.py", line 698, in keepRecords
  File "bash\brec\record_groups.py", line 518, in _call_super
  File "bash\brec\record_groups.py", line 441, in keepRecords
  File "bash\brec\record_groups.py", line 507, in _call_super
  File "bash\brec\record_groups.py", line 1188, in keepRecords
AttributeError: 'NoneType' object has no attribute 'fid'
base.py  205 _parse_csv_sources: Crowded Roads Revamped_Names.csv is not saved in UTF-8 format
Traceback (most recent call last):
  File "bash\patcher\base.py", line 196, in _parse_csv_sources
  File "bash\parsers.py", line 182, in read_csv
  File "<frozen codecs>", line 322, in decode
  File "encodings\utf_8_sig.py", line 69, in _buffer_decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 105: invalid start byte

base.py  205 _parse_csv_sources: Crowded Roads Revisited_Alternate_Names.csv is not saved in UTF-8 format
Traceback (most recent call last):
  File "bash\patcher\base.py", line 196, in _parse_csv_sources
  File "bash\parsers.py", line 182, in read_csv
  File "<frozen codecs>", line 322, in decode
  File "encodings\utf_8_sig.py", line 69, in _buffer_decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 125: invalid start byte

base.py  205 _parse_csv_sources: Crowded Roads Revisited_Names.csv is not saved in UTF-8 format
Traceback (most recent call last):
  File "bash\patcher\base.py", line 196, in _parse_csv_sources
  File "bash\parsers.py", line 182, in read_csv
  File "<frozen codecs>", line 322, in decode
  File "encodings\utf_8_sig.py", line 69, in _buffer_decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 115: invalid start byte

Edited by Psymon
Link to comment
Share on other sites

@Psymon, thanks, I was finally able to replicate the AttributeError traceback. As for the UnicodeDecodeError tracebacks, Crowded Roads Revamped_Names.csv, Crowded Roads Revisited_Alternate_Names.csv, & Crowded Roads Revisited_Names.csv aren't included in WB, they were packaged in the Data\Bash Patches directory with some mods that you installed. The error suggests that they're not encoded correctly, but we could potentially confirm that if you can figure out what mods they're from & provide links to them.

@Utumno, to replicate the AttributeError traceback, it's a bit convoluted, but I managed to do it reliably. It did actually involve merging Better Cities Leyawiin - Oblivion Uncut.esp, but it wasn't enough on it's own. It required two additional steps, namely merging Oblivion Citadel Door Fix.esp from the UOP & loading either Better Cities LEYAWIIN.esp or Better Cities FULL.esp from BC (either of the v6.2.1 or v6.2.3 Update versions) after both of the merged plugins. I have no idea why it's so particular, but I couldn't replicate it without satisfying these three conditions simultaneously.

Edited by sibir
Link to comment
Share on other sites

1 hour ago, sibir said:

@Psymon, thanks, I was finally able to replicate the AttributeError traceback. As for the UnicodeDecodeError tracebacks, Crowded Roads Revamped_Names.csv, Crowded Roads Revisited_Alternate_Names.csv, & Crowded Roads Revisited_Names.csv aren't included in WB, they were packaged in the Data\Bash Patches directory with some mods that you installed. The error suggests that they're not encoded correctly, but we could potentially confirm that if you can figure out what mods they're from & provide links to them.

@Utumno, to replicate the AttributeError traceback, it's a bit convoluted, but I managed to do it reliably. It did actually involve merging Better Cities Leyawiin - Oblivion Uncut.esp, but it wasn't enough on it's own. It required two additional steps, namely merging Oblivion Citadel Door Fix.esp from the UOP & loading either Better Cities LEYAWIIN.esp or Better Cities FULL.esp from BC (either of the v6.2.1 or v6.2.3 Update versions) after both of the merged plugins. I have no idea why it's so particular, but I couldn't replicate it without satisfying these three conditions simultaneously.

I don't think that is correct about the .csv files. Go to the Advanced Readme. and search out those names ... worked better when not including the .csv part. Under the section called Default CSV Files.

I couldn't find the mod they were from and those mods with those names don't have .csv I could find. Then I removed them and since I install EVERYTHING through WB it should have popped up as missing on the BAIN tab and they didn't. So pretty sure it is from WB ... at least some edition since 310. This is fairly new install and i would have only had editions from 310 on.

[edit] Regarding the traceback thing. I can confirm that I indeed had all those plugins active in that load order. thanks ... and apologies it took so long. Off to mapping the next set of mods!

[edit 2] Oops I was wrong. I did try to install the stand alone 291 and that is where they are from. So probably a removed feature.

Edited by Psymon
Link to comment
Share on other sites

On 5/3/2023 at 8:29 AM, Psymon said:

I don't think that is correct about the .csv files. Go to the Advanced Readme. and search out those names ... worked better when not including the .csv part. Under the section called Default CSV Files.

I couldn't find the mod they were from and those mods with those names don't have .csv I could find. Then I removed them and since I install EVERYTHING through WB it should have popped up as missing on the BAIN tab and they didn't. So pretty sure it is from WB ... at least some edition since 310. This is fairly new install and i would have only had editions from 310 on.

[edit] Regarding the traceback thing. I can confirm that I indeed had all those plugins active in that load order. thanks ... and apologies it took so long. Off to mapping the next set of mods!

[edit 2] Oops I was wrong. I did try to install the stand alone 291 and that is where they are from. So probably a removed feature.

Yeah, they're from v291. Looks like they were merged into Random_NPC_Names.csvRandom_NPC_Alternate_Names.csv here (& that encoding error might've been fixed afterwards here). The old CSVs can just be discarded.

Edited by sibir
correction
Link to comment
Share on other sites

On 5/3/2023 at 5:27 PM, sibir said:

Yeah, they're from v291. Looks like they were merged into Random_NPC_Names.csvRandom_NPC_Alternate_Names.csv here (& that encoding error might've been fixed afterwards here), both of which are now baked into the executable rather than distributed as separate CSV files. They can just be discarded.

Ok ... well can I ask, and not trying to beat a dead horse here, just trying to see if I should stop beating it ... lol.

I'm' still wanting to play with wrye morph. .... found the nexus page for it and reading the comments I see a fella named Mertz talking about needing a Python 2.7 interpreter to make use of the bashmon.

Now as far as my experience with python, mostly centered around whatever Wrye Bash needed circa 2008-2011. I think I had one other computer project made use of it. Many OS's later ... and that long since installing it. To my understanding most likely the required components are even changed in python? such that they would require the versions prevalent back then. OK ... well even just for the bashmon part?

Then the real question here ... which I know I asked before but cannot find an answer ... does installing either older or newer versions of python interfere with wrye bash 310+ functionality? Because if it doesn't and nothing else on the computer requires the older versions that is a cleaner option by far for testing.

And if there is any interest by anyone in implementing this into stand alone ... I promise and cross my heart to be ready to test any and every feature giving whatever feedback necessary. Same for anyone wanting or eager to try and implement a character morph mod via other means. I have plenty of ideas of applying rules, barriers, and other features for such a system.

thanks guys

Link to comment
Share on other sites

1 hour ago, Psymon said:

Ok ... well can I ask, and not trying to beat a dead horse here, just trying to see if I should stop beating it ... lol.

I'm' still wanting to play with wrye morph. .... found the nexus page for it and reading the comments I see a fella named Mertz talking about needing a Python 2.7 interpreter to make use of the bashmon.

Now as far as my experience with python, mostly centered around whatever Wrye Bash needed circa 2008-2011. I think I had one other computer project made use of it. Many OS's later ... and that long since installing it. To my understanding most likely the required components are even changed in python? such that they would require the versions prevalent back then. OK ... well even just for the bashmon part?

Then the real question here ... which I know I asked before but cannot find an answer ... does installing either older or newer versions of python interfere with wrye bash 310+ functionality? Because if it doesn't and nothing else on the computer requires the older versions that is a cleaner option by far for testing.

If you're using the standalone versions of v310+, which, IIRC, you are, no Python installation on your computer will interfere with it whatsoever. The standalone versions are standalone executables bundled with their own built-in Python interpreters that they use to the exclusion of any other interpreters you may have on your computer.

I've never used Bashmon & unfortunately don't have any advice on using it.

Link to comment
Share on other sites

On 5/8/2023 at 3:31 AM, sibir said:

I believe Mertz is actually @Beermotor, so maybe they can offer advice on using Bashmon.

Yes that's me on NexusMods. My nom de plume is Beermotor F. Mertz. :D

The last version of Bash that had BashMon was 291 back around 2011 I think.   The version over on NexusMods is the source version and as you mentioned you're going to have a very hard time getting it to run on most modern operating systems as Python 2.7 is all but dead at this point.

The good news is the v291 Standalone Executable package is still available over on Sourceforge in Wrye's Oblivion Works repo.

There are two older versions Bash with BashMon available:

The 291.1 installer version - I'm not 100% certain this has Bashmon but it is likely and I think that's a bugfix version for 291.

The &nbsp;291 standalone version -  This one should definitely have it.

It might be prudent to update the NexusMods Oblivion Wrye Bash page with one of those versions or link to the Sourceforge stuff.

Edited by Beermotor
Link to comment
Share on other sites

14 hours ago, Beermotor said:

I had a chance to take this one apart and I can confirm it has Bashmon.

Yeah I already commented on the fact that the stand alone version (that was linked to in prior posts) does not have it. Your source forge link is to a different account though.

Question ... say I'd rather extract the required folders out of the linked installer using 7z ... which of the 4 variants should I choose from the folders are named:

$_16_

$_17_

$_18_

$_19_

And my brain is attuned to looking for x86 x64 with this kind of folder exploration cuz I no coder scripter. Each just has the mopy and now removed but easy to replace data folder - already figured out how to navigate all that. as well as how to run multiple wrye bash installs with minimal interference. I'm almost there.

Or do I have to run the installer. I have extracted programs from installers before ... not that newb.

If though I could avoid having registry entries to worry about - all the better. I'm a big proponent of the portable utility approach.

If I get it working would be be worthwhile to have those all extracted into manual options. Maybe find a way to turn off all options but the bashmon components needed. Then include a nice looking guide on how to install it that way or with other Wrye Bash installs. Then links to wrye morph etc. I think it would be ideal of they were packaged together.

thanks guys ... almost there.

[edit]

OH Yeah, I forgot to ask. This installer version ... does or does not require anything python related be installed ... from other sources?

 

[edit 2]

OK I'm seeing better now. The installer will seemingly read my system then choose one of those versions of Mopy to place in the oblivion folder, then it will what? download the required python components? Or are they included because they don't seem to be when I look in 7zip. there are a few dll files but don't see anything else.

Seems it tries to download them. I guess trying is what Is necessary. Could be dead links.

Edited by Psymon
Link to comment
Share on other sites

On 5/3/2023 at 5:01 PM, sibir said:

@Psymon, thanks, I was finally able to replicate the AttributeError traceback. As for the UnicodeDecodeError tracebacks, Crowded Roads Revamped_Names.csv, Crowded Roads Revisited_Alternate_Names.csv, & Crowded Roads Revisited_Names.csv aren't included in WB, they were packaged in the Data\Bash Patches directory with some mods that you installed. The error suggests that they're not encoded correctly, but we could potentially confirm that if you can figure out what mods they're from & provide links to them.

@Utumno, to replicate the AttributeError traceback, it's a bit convoluted, but I managed to do it reliably. It did actually involve merging Better Cities Leyawiin - Oblivion Uncut.esp, but it wasn't enough on it's own. It required two additional steps, namely merging Oblivion Citadel Door Fix.esp from the UOP & loading either Better Cities LEYAWIIN.esp or Better Cities FULL.esp from BC (either of the v6.2.1 or v6.2.3 Update versions) after both of the merged plugins. I have no idea why it's so particular, but I couldn't replicate it without satisfying these three conditions simultaneously.

Thanks for the reproducer (and thanks @Psymon for keeping to beat that horse) - this is something I'd like to understand and fix before 311 - I will give it a whirl in the next few days - probably come next week though as I am away - hence the delay. If someone could bundle me the mods (and their masters) that would speed it up

Link to comment
Share on other sites

Well the horse I'm beating is wrye morph, but I, of course, appreciate that horse getting a whack or two as well. So thanks.

Then um ... wrye morph. Another NOPE in my face.

So downloaded the linked 291.1 and tried running the installer. It failed to install the python main file, but trying the link in the readme worked, so I installed all the linked stuff manually.

However when I ran the installer again to install the correct mopy folder -=because there are four variations to choose from???=-

The installer was not satisfied with the manual stuff installed and also wanted to install the ansi version of wxPython 2.8.12.1, so I let it.

Sorted all my folders backed everything up. As per usual set up all bain installer folder locations somewhere else and even set one up that would have a folder saying WRONG WRYE BASH DUMMY as an archinve if I unthinkingly open that installers folder in this wrye bash.

Failure to even load wrye bash with the log being included below.

Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
    bash.main()
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
    bash.main()
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
    bash.main()
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
    bash.main()
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
    bash.main()
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path

Now for certain ... I understand if no one has an answer or it is deemed not worth looking into. No answer is an answer I understand. If, however, others are also interested in rescuing this obscure and not repeated mod and have suggestions. let me know. I will leave python on my system and can easily test anything. If no reply in a few weeks may nuke all that.

thanks

 

Edited by Psymon
Link to comment
Share on other sites

4 hours ago, Psymon said:

Yeah I already commented on the fact that the stand alone version (that was linked to in prior posts) does not have it. Your source forge link is to a different account though.

Yes that's Wyre's old Sourceforge thingie. :)

 

2 minutes ago, Psymon said:

Failure to even load wrye bash with the log being included below.

  Reveal hidden contents

 

Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
    bash.main()
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
    bash.main()
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
    bash.main()
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
    bash.main()
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 31, in <module>
    bash.main()
  File "bash.pyo", line 276, in main
  File "basher.pyo", line 12988, in InitSettings
  File "bosh.pyo", line 31629, in initSettings
  File "bolt.pyo", line 917, in __init__
  File "bosh.pyo", line 228, in load
  File "bolt.pyo", line 875, in load
TypeError: must be string, not Path

 

Now for certain ... I understand if no one has an answer or it is deemed not worth looking into. No answer is an answer I understand. If, however, others are also interested in rescuing this obscure and not repeated mod and have suggestions. let me know. I will leave python on my system and can easily test anything. If no reply in a few weeks may nuke all that.

thanks

 

I was at work yesterday and wasn't able to test until this morning.  I'm having the same problem you are it seems.

I unpacked 291 standalone and it won't run at all and immediately bugchecks. No idea why. It is entirely possible those are bad builds, particularly since the 291.1 Installer version didn't even place a Wrye Bash.exe in the Mopy folder. It isn't anywhere in the NSIS package either.

There are older binaries on there before 291 on Sourceforge that I haven't been able to test. It might be worth a test if you have time to work your way back through the versions. 

Worst case scenario you can run a specific old version of Bash just to do bashmon and stick with modern Bash (with all the bug fixes and modern tool support) for everything else.

 

Link to comment
Share on other sites

1 hour ago, Beermotor said:

Yes that's Wyre's old Sourceforge thingie. :)

 

I was at work yesterday and wasn't able to test until this morning.  I'm having the same problem you are it seems.

I unpacked 291 standalone and it won't run at all and immediately bugchecks. No idea why. It is entirely possible those are bad builds, particularly since the 291.1 Installer version didn't even place a Wrye Bash.exe in the Mopy folder. It isn't anywhere in the NSIS package either.

There are older binaries on there before 291 on Sourceforge that I haven't been able to test. It might be worth a test if you have time to work your way back through the versions. 

Worst case scenario you can run a specific old version of Bash just to do bashmon and stick with modern Bash (with all the bug fixes and modern tool support) for everything else.

 

That is or was the projected plan. Suggested to me by the team here ... is to use the latest Wrye Bash for everything and then with 291.1 or wherever I can find a working bashmon version for just that function. I was told to have it run in the background while playing ... not sure if that means launching through the older one, but that is getting ahead of just getting it to launch.

I did get the installer version to work, but like I wrote ... had to manually install python first. I found the stand alone from 291.1 was the first version to NOT have bashmon.

So if you have a variant to test ... I'm game. Preferably not having to run installer after installer. I have all the python set up. I just need a variant to test.

[EDIT]

Oh and not sure if the errors I'm getting are due to python not working in windows 10 or due to something else. If it is the former then probably a dead end after all.

Edited by Psymon
Link to comment
Share on other sites

4 hours ago, Infernio said:

The AttributeError thing should be fixed in the newest nightly, 311.202305141818.

No traceback anymore on my end.

Link to comment
Share on other sites

On 5/14/2023 at 3:31 PM, sibir said:

No traceback anymore on my end.

Which of the errors that I've reported does that fix? The better cities thing .. or the other one's too?

Then also a general question: What conditions trigger a longer time opening the BAIN tab? Like sometimes after starting bash it opens in just a few seconds, but never the first time if I've not run it for 12 hours. Then other times it seems to just take 2-3 minutes to open. I'm certain this has to do with depth of scanning for changes, but what triggers that kind if thing. If no options for it are chosen like refresh now.

Link to comment
Share on other sites

45 minutes ago, Psymon said:

Which of the errors that I've reported does that fix? The better cities thing .. or the other one's too?

Yes, the issue with some of the BC plugins & Oblivion Uncut. The issue with LandmarksOfCyrodiilLite.esp has also been fixed separately. I believe the BSA issues were issues with the BSAs themselves, not WB. Their authors would probably have to fix them, though maybe they can simply be repackaged. I have no clue unfortunately.

Link to comment
Share on other sites

Yes, you can repack them. Use something like BSArch or BAE to extract them, then repack either with the game's Archive tool or with BSArch.

Link to comment
Share on other sites

Oh ,,, ok, well just curious what is triggering those errors with wrye bash. Is there something wrong with the bsa that could be reported to mod authors? thanks

Link to comment
Share on other sites

bsa_files.py  697 _read_bsa_file: i:\games\bethesda softworks\oblivion\Data\WAC.bsa reports wrong folder names length 14668 - actual: 12918 (number of folders is 441)
bsa_files.py  697 _read_bsa_file: i:\games\bethesda softworks\oblivion\Data\Rathunas01.bsa reports wrong folder names length 11361 - actual: 10514 (number of folders is 269)
bsa_files.py  697 _read_bsa_file: i:\games\bethesda softworks\oblivion\Data\CRTRenewed.bsa reports wrong folder names length 2882 - actual: 2844 (number of folders is 98)

The messages tell you what's wrong: the "folder names length" field inside the BSA claims the total length of all folder names combined is X bytes, but when we go to read the folder names, we actually read Y bytes in total. This isn't a problem for Wrye Bash because the folder names length is technically redundant, but it could be a problem if a program relies on it (e.g. to pre-allocate a buffer, which could lead to a buffer overflow if the length is wrong). Hence WB warning about it.

Edited by Infernio
Link to comment
Share on other sites

ok. Perhaps an issue that comes up from using the older BSA tools.

So um anyone got any ideas why this mod is triggering this background color in wrye bash.

no other mod has the same background color and tested this by file redate and uninstall/reinstall.

also it has no bash tags and LOOT did not recommend any,

thanks

SkycaptainCantTouchMe.jpg

Edited by Psymon
clarification and typos
Link to comment
Share on other sites

That's because of the "∩" (U+2229, "INTERSECTION") character, which can't be encoded in the Windows-1252 encoding WB uses for plugins.txt. It's still kind of an open question if that is the correct encoding and if it isn't, what encoding the games actually use for plugins.txt.

No idea why that character would be there, it's a mathematical operator. Maybe a badly encoded filename.

Edited by Infernio
Link to comment
Share on other sites

22 hours ago, Infernio said:

That's because of the "∩" (U+2229, "INTERSECTION") character, which can't be encoded in the Windows-1252 encoding WB uses for plugins.txt. It's still kind of an open question if that is the correct encoding and if it isn't, what encoding the games actually use for plugins.txt.

No idea why that character would be there, it's a mathematical operator. Maybe a badly encoded filename.

It is an old skycaptain mod that is supposed to prevent NPCs from being able to hit you when another NPC is in the way. It comes that way, and he is long gone for asking. I'll try to rename. Thanks.

It comes with another plugin that will stop NPC attacks from landing a hit if you power attack them first. the animation still plays but no connect. What I think the partner mod is by same guy called Friendly Fire which reduces the amount of Fighting between factions where a misfire or something happens. It doesn't handle you attacking Companions and i found the bashed patch settings to increase that tolerance.

So the net result I'm going for is less fighting between NPCs. But since they will be focused on me then to reduce how much space they need to actually get at me and reduce the group thrashing. Good for if you set the self as essential. I know he went on to make Deadly Reflex that so many like, but I remain a duke patrick fan.also using Reneer creature mod, Kuertee NPCs yield, and those too tend to help with the out of control riots that can happen. Seems to me the game super touchy about stats that then don't reflect actual real world behavior. (my little sales pitch for these mods)

Is setting the player as essential a valid bashed patch settings feature request? If so .. then I submit my humble request.

This I have learned is a way better way of playing the game ... especially if it takes 2+ minutes to load a save. Roleplays great when with companions. None of this cheats when you play with TIE like mods in my opinion. What is the point of surviving an encounter you can't win, as they just keep one-shoting the player, or the quest failed, or companion not also set to essential. etc.

This leads me to wonder if the current settings on unconsciousness length related to the player or just NPCs?

Also is there a consistent direct link for me to test this latest nightly with fixes? I look in git but not obvious. thanks guys

Edited by Psymon
Link to comment
Share on other sites

10 hours ago, Psymon said:

Also is there a consistent direct link for me to test this latest nightly with fixes? I look in git but not obvious. thanks guys

Yes, the second post in this thread has a link to the latest WIP build which is a snapshot of the nightly branch on GitHub. If you want to run the very latest from the nightly branch (it's the same as the WIP build as of writing), you can either install the artifact for the latest commit on GitHub (press the green checkmark, then Details, then Summary, then scroll down to Artifacts) or clone the repo & run it with the required Python install. Also, FYI, the screenshot renaming bug should be fixed in the latest WIP build.

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