Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

warmfrost85's Achievements


Clanfriend (1/10)



  1. You can make changes so the STAT.DNAM, etc. (except for SPGD) isn't an issue and doesn't need to be reported? I don't know the internals and history of those records so not sure how you'll do that. Just let me know whenever you're done with the update. Thanks. ...and thanks for the work you do on xEdit. As I understand it, we'll know that when Sharlikran is done with the above changes. I just have a hunch I'm misunderstanding Sharlikran's comment a little.
  2. @Utumno, Do you mean create a standalone installer rather than python only version? I haven't explored that route yet. Also IMO, this needs to include @Beermotor's Experimental branch code to get the additional Bash tag functionality to get the most benefit from Sharlikran's code.
  3. @SharlikranYes, my original change hid your error messages for author mods and DLCs. That was a mistake on my part. Now that I understand the issue better, I made a change that only displays your error messages for user created mods/plugins. The message does not displayed for official DLCs. I created a branch in my repository off the current dev branch to make the code reviewable. 742367c This would need to be applied to Beermotor's branch to overwrite my first attempt. I've used it with @Beermotor's experimental branch and it works as expected. It also keeps these invalid records out of the batched patch. I used this mod for testing: https://www.nexusmods.com/skyrimspecialedition/mods/15246 It has the form 43 issue and does display the message as expected but more importantly doesn't display it for any official DLC. Wrye Bash SSE expects a newer format for STAT.DNAM than found. Load and save mihailimperialhalberds.esp with the Skyrim SE CK STAT.DNAM: Expected size == 12, but got: 8 Error loading 'STAT' record and/or subrecord: 05005907 eid = u'mihailhalberd3static' subrecord = 'DNAM' subrecord size = 8 file pos = 2682 Error in mihailimperialhalberds.esp Does my second attempt work for you? If so, this should be applied to Beermotor's experimental branch. BTW: I wrote an xEdit script to scan selected mods checking all records for non form 44s. It catches a lot of junk. Is there already an xEdit script that scans selected plugin's records for non 44 forms, not just the header? If not, that would be a nice addition to the standard xEdit script library. I'm not offering my version. A new one would need to be written by an expert like you. fyi: @Utumno
  4. @Arthmoor I'm talking about the record definitions in the Beth files, so this case is not a form 43 vs form 44 issue. BTW: I wrote an xEdit script that scans my load order looking for non form 44s in all records anywhere not just the header record. Absolutely amazing how many non form 44s I find in SSE mods. I've created a Bashed Patch for my current load order of about 120 mods, all have form 44s (I've verified they're clean), but yet the resulting Bashed Patch's leveled list has form 40s and the tweak to double my jump height has a form 30. The patcher definitely has issues that are not related to bad forms in the source mods. Since I have a good test case, out of curiosity I'll probably look at the patcher code, coming up for air eventually. This "bad" Bashed Patch could explain some of my random CTD when play testing this new character. Edit: Of course I can re-save the Bashed Patch in the CK which fixes it.
  5. Thanks @Sharlikranfor your explanation although I'm talking about Beth files, not user created files. Here is my relevant comment from that commit for easy reference. When creating a bashed patch for these Beermotor's enabled Skryim SE bash tags, WB was complaining that Skyrim.esm has invalid record lengths and must be resaved in the CK. Asking the user the resave in CK is not true in this case. For STAT.DNAM and WATR.DNAM records it looks like SSE's Skyrim.esm and Update.esm files contains both Skyrim LE and Skyrim SE record definitions. When I say optional field, I mean Skyrim SE's new 'Noise Properties - Flowmap Scale' field at the bottom of the WATR.DNAM definition. I see this in xEdit's wbDefinitionsTES5.pas file with the following line. // SSE wbFloat('Noise Properties - Flowmap Scale') For STAT.DNAM, the optional record is SE's 'snowflag' and some unused data. From xEdit SE definition for STAT.DNAM: // SSE wbInteger('Flags', itU8, wbFlags([ {0x01} 'Considered Snow' ])), wbByteArray('Unused', 3, cpIgnore) I know you're well aware of these definitions in xEdit and WB, so I'm only showing them here to explain my interpretation. My change to WB for SSE only, is to allow the SSE patchers to accept both LE and SE definitions in the Bethesda files. I use the record length to determine if it's an LE or SE record. Example: If the STAT.DNAM record length is 8, I assume it's an LE record. If the length is 12, I assume it's a SE record. Any other length is an assumed error. I then alter the python format pattern to match the expected record structure if an LE record is detected. I don't add or ignore any data in the file. If my interpretation is correct, is my solution a valid in this SSE only case? If not, how do you recommend this be approached? Thanks.
  6. @SharlikranIt looks like dumpData() just tosses the 'optional' field. Is that the preferred way to handle 'optional' fields? I was not aware of dataDump() before this. Since I did touch skyrimse/records.py to fix, does that mean Beermotor's experimental branch that enables more Bash tags is not acceptable?
  7. Since a regex pattern parses the description starting with '{{', it's unlikely a valid description begins with '{{bash:' and ends with '}}'. It's possible but there's at least one SSE mod that I use routinely that has it mixed case. Of course I can just change it to uppercase myself but that fix breaks as soon as I download an updated version. That mod updates a lot, in fact it was updated just two days ago. Maybe this is a one-off mod and shouldn't be accommodated. How is something like this decided? Either I contact the mod author and say it must be uppercase or WB becomes more forgiving. I'm in favor of being more forgiving with this issue. The downside to accepting mixed case seems very remote.
  8. Note sure whether to post this here or as an issue at github. I'll start here. WB reads the bash tags from a plugin header record expecting this format: {{BASH:tag,tag}} WB is looking for "BASH" uppercase, a case sensitive search. The mod Another Sorting Mod has mixed case so the tags are not recognized in the header, e.g. {{Bash:Names,Stats}}. I assume there are other mods like this. Is this behavior intentional? If so, why? I noticed this when using Beermotor's branch with the additional Bash tags enabled. It's an easy to make it case insensitive by adding 're.I' which I have done in my personal WB repository and now works as I expect. maBashKeys = re.search(u'{{ *BASH *:([^}]+)}}',description,flags=re.U|re.I) @UtumnoShould this have been posted as an issue in github instead? Or maybe it's not considered an issue.
  9. Agreed. In the code I called it a "hack". The right way would seem to let the patcher's record definitions have optional subrecords (or fields, not sure what they're called). Optional subrecords is a change which I don't have the knowledge to implement. My monkey patch involves just a few lines of code. Something easy to remove when a proper fix is added. Also since LE and SE are so related I think this "hack" is only relevant to Skyrim and will not spread. IMO, enabling these additional Skyrim SE Bash tags was well worth that small technical debt. In my personal repository, I've been using these additional SE Bash tags for months now without issue. Of course that doesn't mean there are no issues, just none that I've noticed. If I didn't have these available I'd have to use Mator Smash which I assume others are using in the mean time. As always it's your call. Personally it doesn't matter to me since I'll continue to use them privately but would prefer them incorporated into the main repository so others can benefit.
  10. Is that the same as asking, "When will more Skyrim SE Bash tags be enabled?"
  11. Yes, during play testing rarely, but occasionally, I did experience what seemed like a hard linked file timestamp not updating so WB continued to think the file was "mismatched". Rather than spend a lot of time investigating I just copied the file so it was "new" then reinstalled it via WB to continue my game!! Those kind of issues can be a real sink hole, difficult to support with different versions of windows, file editors, etc. Doing something for personal use is much easier than for general use. I also agree some editors change a file (preserving the hard link) and others save the file as new (breaking the hard link). Breaking the hard link is not issue for me. Not updating a file timestamp is a big deal and outside of my control. This type of profiling may not be compatible for general use which would be a big shame because it's very helpful. I'm not giving up yet. Because of those hard linked issues I consider it an advanced feature only for someone willing to spend the time on it. Once such files are identified, the user can just unlink the affected files and all is well. Maybe the question is: Should WB support two profiling systems: one for the general user (current system) and one for advanced/adventurous users (hard links)? A junction pointing to a folder of real files would solve the above issues but it would be VERY slow to create a new profile from an existing profile (mod list) and consume A LOT of disk space so that seems to be a no go. My motivation in contacting the team was to share some code which might be helpful. I would work on it until it was considered viable (not just dump it on you @Utumno). It works so well for my personal needs that I wanted to share with others who may find value in it. I've been exclusively using WB for over a year now and have fallen in love with the control it offers. Although to be honest I'm starting to get Skyrim burnout. Yes, if you have tasks that relate to profiles, I'll take a look and then decide. BTW: I've started looking into creating a FOMOD Installer, well actually an FOMOD Unpacker for personal use. From what I read in the forums, there's probably a greater need for a FOMOD Unpacker than profiles. A Fomod archive is easy to install using NMM. There was no alternative for the profiling system I wanted so I had to write my own. I'll continue poking around with a fomod unpacker but that's a BIG task which I may never finish. Just curious, is a fomod unpacker on the road map anywhere? Don't want to step on more toes. haha
  12. @Beermotor My current version only uses hard linked files. It doesn't use NTFS junctions. That tool makes it easy to hard link all files in a folder and its subfolders... done in one command. The ideal version uses junctions to reference folders containing hard linked files! This allows the user to create a nearly unlimited number of profiles with almost no impact on disk storage. When you can create a snapshot of your profile (mod setup) at any point in time (without worrying about filling your hard drive), it alters how you approach modding. In fact if you can create a 'backup' profile at any time is there a need for the settings backup and restore functionality? I'm sure I just riled up some one with that statement. After all a backup is just a snapshot of the user's setup at a given point in time. That can be achieved using a settings backup archive or a backup profile, depending on the definition of profile. To restore a profile from 'backup' is just a matter of switching to the backup profile. Here I mean a profile with a suffix " (backup)" or some other descriptive wording. I am well aware that I have (and always will have) very limited knowledge of WB and can easily waste peoples time discussing things that are not possible. However, I view my lack of knowledge of WB as an asset as I'll ask questions about things that others may take for granted. There are always legacy issues, conversion issues, etc. so this may not be possible. Although it works great for my needs and I plan to keep it for my personal use. Since hard links only work for files on a single drive, setups where the game and save folders are on different drives may be the roadblock to adopting a single profile system. It might be possible to work around that limitation but I didn't explore a solution since I was concentrating on MY needs. Utumno is correct. We need a definition of "profile". I make a distinction between data associated with a profile and data associated with the game (warning, gray areas ahead). For example, to me cli arguments are game data not profile data. After Christmas, I'll submit my definition of 'Profile'. What's your definition/characteristics/properties of the ideal profile?
  13. @Utumno I've pulled your latest beta 2 commits into my local repository, rebased locally, then force push to my remote warmfrost85-250-profiles branch. Unfortunately the force rebase commit doesn't have your commit and line comments. That makes sense but I didn't realize that would happen. I don't think there is a way to avoid this because of the rebase. I can still see your commit comments in the issue 250 tracker log but that's not a good way to handle it. https://github.com/warmfrost85/wrye-bash/commit/dad8e05de8080e11a49e16bcb7a0d4d742ed0a82 I removed the '#250' wording from the commit message to avoid cluttering the issue 250 log history every time I do a rebase, but apparently there are advantages to recording there. Is this an unavoidable price of rebasing?
  14. I had a personal need for profiles that easily allowed experimentation but both NMM and MO corrupted my profiles so I moved to WB. I also had problems with WB's profiles not refreshing correctly so I used WB's save and restore but that was cumbersome and not what I wanted. I looked at WB's issues list on github and noticed issue 250 - Profiles. I liked that approach so with much motivation I began exploring the code and implemented profiles as described in #250. I see @Utumno plans to work on this so I could be quiet and not share this code but that doesn't feel right. So hopefully this offer doesn't come across as stepping on anyone's toes. I assume he has a very particular vision for profiles so my implementation may not fit WB's long term vision. I've been successfully using this alternate profile system for a few months now with Skyrim LE, SE and Oblivion. With work on release 308 about to begin, I thought this is a good moment to share. The code is in my github repository, warmfrost85-250-profiles branch, which is rebased on WB's current dev branch. Unfortunately I referenced that issue a few times and messed up its activity log. Sorry. Not sure if github allows that to be cleaned up. The documentation for this solution is in the spoiler below and in the git commit comment. Any feedback or comments are encouraged.
  15. Is this now the official Wrye Bash forum for questions, comments, suggestions, etc.? Is there a separate developer forum? I've been exclusively using WB for 6 months now and love it. I view it as the best way to automate manual installs.
  • Create New...