Jump to content


  • Content Count

  • Joined

  • Last visited

  1. Thank you for you detailed post and yes, we are aware that the current handling of record form versions is not ideal as you have seen in issue #403. The current situation is a balance between warning SSE users about old plugins that need to be updated and not crashing Oldrim when merging certain plugins into the bashed patch. We do aim for a more comprehensive fix regarding the Oldrim issues, but that requires rewriting some of the patching code to actually be aware of form versions (right now it basically ignores them and just copies whatever it sees) and this may take some time.
  2. Thank you for your tests @alt3rn1ty. I don't know why you can not see the error in FO4, I can replicate it there too, but that probably just means that for some reason refreshBashTags() was not called for you for FO4. I have committed a fix for this, but as far as I can tell the error itself should be benign, as in not impact functionality.
  3. Missed that one in my tests. Will fix asap.
  4. Hey @Utumno since I have now (hopefully) finished updating the loot api integration, what issue should I work on next? Before you said that #390 Restore Settings is the next focus. Is that still the case? I seem to recall skimming over some posts of you working on something related to that.
  5. Admittedly the automated line breaking created a very complicated nesting of parantheses, but the expression is balanced. The open paranthesis on line 979 is closed by the second to last paranthesis on line 981. So nothing to worry about, but thanks for looking at the code. Help is always appreciated
  6. To make sure I understand the load-order implications of ESL files correctly: What happens if there is a conflict between an ESL flagged as a master and a normal esp? Will the game detect the conflict and leave out the conflicting record when merging all the ESL files into FE (meaning the ESP wins) or will it write the ESPs version of the conflicting record into FE or will the ESL file win the conflict, despite being in a higher block according to the save file headers?
  7. @Utumno I think we should leave the loot update out of the beta, I tried integrating the new version and it throws "Runtime Error: bad cast" even in minimal examples. I have already contacted Wrinkly about it here, but I do not know how long fixing this is going to take.
  8. The newest version of the loot api will not work because v2.0.0 had a bunch of changes to the API and Wrye Bash was not yet updated to support it. See WrinklyNinja's post on the subject.
  9. Done. I'll now go and see what I can do about showing startup errors as discussed in #373.
  10. I have managed to package bash after rebasing utumno-scandir onto utumno-wip so this should represent the latest version we have. I did not however manage to pack loot api with it. Standalone Version, Installer Version
  11. The results so far seem quite encouraging. @Utumno Ok, I'll rebase utumno-scandir over your wip branch and try to compile it. Should I push it if it works or should I create my own branch of utumno-scandir for that? Aside from that I have a question regarding packaging wrye bash with the loot api. The wiki guide to making releases has no mention of the loot api, but the build failed when I did not have loot_api.dll in my Mopy\ folder, so I downloaded the latest loot api release from the github page, pasted loot_api.dll and loot_api.lib into \Mopy\ and the build completed. However it
  12. The utumno-scandir branch is a little bit behind dev, the last update was commited on 2017-04-23. As for holding up the next beta, scandir implementation is listed for the 307 Milestone as Issue 371. I was out of the loop for a little while, so I do not know what was planned for the next beta release. I just saw the issue, tried my hand at compiling the branch and had more success than Utumno had had, so he asked me to share this version to see if it also worked for other people. At this point I think it's not about doing some detailed testing but rather seeing if it runs at all. In
  13. Greetings to all after a larger period of absence. I was successful in compiling a test release-version of Wrye Bash based on Utumnos scandir branch. It should offer significant performance improvements when reading directories. We need help with testing if it works on different system configurations and to see if scandir is correctly recognized everywhere. To see if Wrye Bash is using scandir a new startup message was added to the debug log: Wrye Bash starting Using Wrye Bash Version 307 (Standalone) OS info: Windows-7-6.1.7601-SP1 Python version: 2.7.13 wxPython version: 2.8.12
  • Create New...