Jump to content

Sharlikran

Members
  • Content Count

    649
  • Joined

  • Last visited

1 Follower

About Sharlikran

  • Rank
    Clanholder

Recent Profile Visitors

1839 profile views
  1. @NoorX I'm a little concerned here. I tried installing Weapons Armor Clothing Clutter Fixes and made sure it was showing in the stats patcher. I had to restart Wrye Bash for the bash tags to show up which was weird but it worked. I made a Bash Patch and I can't reproduce the issue. Also, not that you would know this, but MreArmo has never had that attribute. I added the unofficial patch to have something else with the Stats bash tag. I could not reproduce the error with that either. I made sure I tried the utumno-wip branch, then I tired 307.201905311918, then I tried my variation which is 307.201904161810, and none of those three versions caused the error. I suggest uninstalling from the Windows control panel. Then manually go to each game folder and manually delete any Mopy folder you find for any of the games you use Wrye Bash with. Then install Wrye bash again but of course since you are reporting the issue officially, you have to use the official code which is 307.201905311918. Problem is I used that version and had no issues. Plus the stats patcher should be set up to not worry about records that don't have criticalMultiplier, because it only exists in Weapon and it would break the patcher if it looked for that in each thing the patcher covers. statsTypes = { 'ALCH':('eid', 'weight', 'value'), 'AMMO':('eid', 'value', 'damage'), 'APPA':('eid', 'weight', 'value'), 'ARMO':('eid', 'weight', 'value', 'armorRating'), 'BOOK':('eid', 'weight', 'value'), 'INGR':('eid', 'weight', 'value'), 'KEYM':('eid', 'weight', 'value'), 'LIGH':('eid', 'weight', 'value', 'duration'), 'MISC':('eid', 'weight', 'value'), 'SLGM':('eid', 'weight', 'value'), 'WEAP':('eid', 'weight', 'value', 'damage', 'speed', 'reach', 'enchantPoints', 'stagger', 'critDamage','criticalMultiplier', 'criticalEffect',), And also the stats patcher covers those records and criticalMultiplier is only in WEAP. ARMO is what MreArmo refers to. So since I have no idea how that could occur then I have to guess at stuff. First you must stick with one version. If you switch between multiple versions the data files used will become corrupt and could allow all kinds of stupid things to happen. I say that because there are people who really dislike that there is no merge patcher in the latest code. That patcher uses a common variable with the ESL support. So because it's the same variable things will not work correctly. Second I have been seeing odd issues lately that make no sense. So I have to reiterate something. We do not support the use of Wrye Bash except with the expected environment. Which is Windows (ONLY!) and no other mod managers involved. So using MO or MO2 is not supported. Wine or the use of Proton for Steam and Wine is not supported. I would not think that using the Python code instead of the Standalone EXE would make a difference. However, I don't use the EXE. I guess you could try the python code but if you do then you need to download this zip file and then set up python. I just don't see how it would be different. So in the end I have to say, can't reproduce.
  2. I think I know what it is but I won't be able to address that and provide an update until well after 18:00 GMT -7 because I'll be at work. Thanks for the report.
  3. @NoorX can you check if unchecking the tweak settings resolves that? Then uncheck one patcher at a time until it doesn't error so I know what patcher to look at? If I can fix it I will but if I can't then at least I can narrow it down for someone else.
  4. @Utumno Sorry in advance. I have closed all the comments sections and made a sticky post as to why. In short it is not efficient to get bug fixes when bugs occur due to current refactoring. Currently there are 6 comments sections, afk mods, discord, and the GitHub issue tracker. All three of you (Utumno, Ganda, and Inferno) have school or other things you are doing. So you are not getting any useful reports from users if you happened to cause an issue. I have been removing the broken code and will still do so and offer a working version if the changes break Wrye Bash completely. However, if users report the issue here and it gets fixed then they will know and can get the update because everyone is being directed to one location. The LOOT API needs to be a priority. Unfortunately I can not make the changes. I have no idea what the issue is. Users with LOOT 14.3 or any version of 14.x will have MSVC 2017 installed. Anyone with the standalone EXE, the latest LOOT 14.x, and MSVC 2017 will find that Wrye Bash crashes. Once you delete the loot.dll or rename it, then Wrye Bash launches fine but the LOOT API is not recognized and will not automatically import bash tags. Also in my own quest to fix this I have found that there may be a fair chance that py2exe simply can not handle what is happening in 2019. Since it was compiled with MSVC 2008 and released in 2008, I feel there is a good chance it has come to the point that it must be updated. For those with LOOT 14.x, MSVC 2017, and Wrye Bash, to have bash tags imported automatically you unfortunately have to use the Python version if you want to use the latest code. The idea of making Wrye Bash work without the loot api has been suggested but I think it's rather obvious that would fail miserably. You would have to use a yaml library (adding another dependency) and then read the yaml files and parse them. I would feel more confident that could happen if people were more active and if the FOMOD addition worked properly with all files. Which it doesn't and people have been reporting that mostly on Discord.
  5. Removed because of regressions in main official code.
  6. @Kelsenellenelvian xEdit 4.0.2 should address that if you mark it as modified. If not unfortunately only the ck will fix it.
  7. I'm not going to address that. People are using an older version of xEdit and don't want to update. There is and never has been a 20 byte version of that subrecord. Mark the record as modified and see if that fixes it.
  8. @NorthMammoth The day is before the month in your screen shot. In America we don't have that and the way Wrye Bash is written it probably doesn't take that into account. I know it doesn't for save games also. I still have not had time to look into that. So for time zone keep Auckland Wellington but for Date and Time it needs to look like I have below. If that doesn't work then I need to know.
  9. @unitetsu Python 2.7 is at end of life this year. The Python organization will not be adding cp65001 or code page 65001 which is new to Windows 10 to Python 2.7. No it is not something we can add as it's enormously complex. Attempts have been made to alias it but that will not work according to stacktrace and python.org. You can read their bug report if you wish but it was closed because they have no desire to add support for that. It has been added to Python 3.3. Before you ask no we can not upgrade Wrye bash at this time to use Python 3.3. You will have to set your system to a different language. I don't have windows 10 so I can't help with that. users on the nexus report that US EN works fine.
  10. @NorthMammoth What is best is to post your error once and then stop. In addition to that only post bug reports from the "utumno-wop" branch. Anything from my github is a personal version I'm using and I release as a courtesy. It's based off of utumno-wip but it's not technically supported. The second thing is to do what you did a different post where you show the entire bash log using the -d parameter. That shows the extra information needed to give you an answer. I can't tell you why it's doing that but here is my guess based off the last few lines in the bash log. You are using windows 10, you have your language set to "en_NZ" which uses a different date format for files. Please realize I would have no idea if the current maintainer Utumno has Windows 10. If he does he probably isn't setting it to "en_NZ" and using a different time format. So that's most likely the issue. If you use an American time date format it might work just fine. Then kindly and patiently wait for a fix. To help with the fix though please provide a screen shot of your language settings.
  11. @Sharlikran Could you finish one way or another the issue you posted for Paint.NET DDS Plugin

    The plugin has one remaining issue, waiting since 2017 for your input. Otherwise I think it has no issues currently

    https://github.com/0xC0000054/pdn-ddsfiletype-plus/issues/1

  12. It only effects certain people. From what I understand when there is a space somewhere in the path.
  13. @Malonn Lojack started it but it's far from what it would need to be. Another user was going to work on it but stopped mid way. Nothing more has been done about that, that I am aware of. Even if I experimented with it, I wouldn't until I could upgrade wxPython to something that 3.x uses. Pretty much 4.x until I would try it. I'd be shooting in the dark though.
  14. @Langeston Okay updated my version to include the fix for the temp folder. It should work and provide you the updated ESL support and it shouldn't error when using a 7zip archive to install a mod. I am still seeing glitchy BAIN installs which is odd because I use the FOMOD code that the original author and Ganda updated. I don't quite know what's going on as I haven't touched that part of the code. You may find the need to use install missing or Anneal until that's all investigated. There may be a regression somewhere else.
  15. Yes that is the version I have been working on to have improved ESL support. It should work fine for most people as it has most of the code the official version does. The new one is linked below but it only fixes an issue if you have a space in your temp folder. Otherwise it's probably not needed for most people.

Support us on Patreon!

Patreon
×
×
  • Create New...