Jump to content
Our Domain Name Has Changed! Read more... ×

Recommended Posts

Never mind - sorted. See post further down. I just tried to open Wrye Bash and after several minutes, found this error on the screen:

Traceback (most recent call last):
  File "bash\bash.py", line 227, in main
    _main(opts)
  File "bash\bash.py", line 393, in _main
    app.Init() # Link.Frame is set here !
  File "bash\basher\__init__.py", line 3981, in Init
    self.InitData(progress)
  File "bash\basher\__init__.py", line 4018, in InitData
    bosh.modInfos.refresh(booting=True)
  File "bash\bosh\__init__.py", line 1949, in refresh
    change = FileInfos.refresh(self, booting=booting)
  File "bash\bosh\__init__.py", line 1382, in refresh
    notify_bain=not booting)
  File "bash\bosh\__init__.py", line 2134, in new_info
    notify_bain)
  File "bash\bosh\__init__.py", line 1358, in new_info
    notify_bain=notify_bain)
  File "bash\bosh\__init__.py", line 1277, in new_info
    load_cache=True)
  File "bash\bosh\__init__.py", line 554, in __init__
    super(ModInfo, self).__init__(fullpath, load_cache)
  File "bash\bosh\__init__.py", line 393, in __init__
    super(FileInfo, self).__init__(g_path, load_cache)
  File "bash\bosh\__init__.py", line 274, in __init__
    self._reset_cache(self._stat_tuple(), load_cache)
  File "bash\bosh\__init__.py", line 559, in _reset_cache
    if load_cache: self.calculate_crc() # for added and hopefully updated
  File "bash\bosh\__init__.py", line 607, in calculate_crc
    path_crc = self.abs_path.crc
  File "bash\bolt.py", line 821, in crc
    for block in iter(partial(ins.read, 2097152), ''):
IOError: [Errno 22] Invalid argument

Previous to that, I built my Bashed Patch with Cbash and then attempted to build it normally. I couldn't tell if it built it or not, but I did see an error in a separate dialogue box. Bash is running so slowly, I have to do something, like opening it, or building a patch and then leave my computer.

Edited by AndalayBay
Issue resolved

Share this post


Link to post
Share on other sites

Further to my previous report, I tried running Bash in debug mode. Here are the logs.

Bash won't start at all now. I guess I'll try uninstalling/reinstalling.

Issue sorted - see post further down.

 

 

Edited by AndalayBay

Share this post


Link to post
Share on other sites
18 hours ago, AndalayBay said:

... Bash won't start at all now. I guess I'll try uninstalling/reinstalling.

If you're using the python source version, consider temporarily using the standalone version. It worked for me.

Share this post


Link to post
Share on other sites

@Utumno There is some kind of scope issue with how you prefer to import things. I was working with CptMcSplody to resolve issue 403 and after reading it I realized the fix needed to be in skyrim/records.py.

Initially I tried adding the code in the spoiler to skyrimse/records.py. I have reverted the changes so there is no point in reviewing a commit. With or without the changes listed below Skyrim SE uses MelModel from skyrim/records.py.
 

Spoiler

 


from ...bolt import Flags, sio, DataDict, winNewLines, \
    encode, struct_pack, struct_unpack
from ...brec import MelRecord, MelStructs, \
    MelObject, MelGroups, MelStruct, FID, MelGroup, MelString, \
    MreLeveledListBase, MelSet, MelFid, MelNull, MelOptStruct, MelFids, \
    MreHeaderBase, MelBase, MelUnicode, MelFidList, MelStructA, MreRecord, \
    MreGmstBase, MelLString, MelCountedFidList, MelOptStructA, \
    MelCountedFids, MelSortedFidList, MelStrings
from ...bass import null1, null2, null3, null4
from ...exception import BoltError, ModError, ModSizeError, StateError
from ..skyrim.records import MreActor, MelBipedObjectData, MelBounds, MelCoed, \
    MelColorN, MelComponents, MelCTDAHandler, MelConditions, MelDecalData, \
    MelDestructible, MelEffects, MreHasEffects, MelIcons, MelIcons2, \
    MelKeywords, MelMODS, MelOwnership, MelPerks, MelScrxen, \
    MelString16, MelString32, MelVmad, MreHeader, MreAact, MreAchr, MreActi, \
    MreAddn, MreAlch, MreAnio, MreAppa, MreArma, MreArmo, MreArto, \
    MreAspc, MreAstp, MreAvif, MelBookData, MreBook, MreBptd, MreCams, \
    MreCell, MreClas, MreClfm, MreClmt, MreCobj, MreColl, MreCont, MreCpth, \
    MreCsty, MreDebr, MreDial, MreDlbr, MreDlvw, MreDobj, MreDoor, MreDual, \
    MreEczn, MreEfsh, MreEnch, MreEqup, MreExpl, MreEyes, MreFact, MreFlor, \
    MreFlst, MreFstp, MreFsts, MreFurn, MreGmst, MreGras, MreHazd, MreHdpt, \
    MreIdle, MreIdlm, MreInfo, MreImad, MreImgs, MreIngr, MreIpctData, MreIpct, \
    MreIpds, MreKeym, MreKywd, MreLcrt, MreLctn, MreLgtm, MreLigh, MreLscr, \
    MreLeveledList, MreLvli, MreLvln, MreLvsp, MreMatt, \
    MreMesg, MreMgef, MreMisc, MreMovt, MreMstt, MreMusc, MreMust, MreNavi, \
    MreNavm, MelNpcCnto, MreNpc, MreOtft, MrePack, MrePerk, MreProj, MelItems, \
    MreQust, MreRace, MreRefr, MreRegn, MreRela, MreRevb, MreRfct, MreScen, \
    MreScrl, MreShou, MreSlgm, MreSmbn, MreSmen, MreSmqn, MreSnct, MreSndr, \
    MelSopmData, MreSopm, MreSoun, MreSpel, MelSpgdData, MreSpgd, \
    MreTact, MreTree, MreTxst, MreVtyp, MreWoop, MreWrld

 

 

 

 

This confirms an error that was reported with your official 307 version for Fallout NV. Importing Skyrim records for Skyrim SE and Importing Fallout 3 records for Fallout NV does not work in all cases with all classes.

Another thing that demonstrates a possible issue with the scope is when I replace just from ..skyrim.records import * and import the exact classes I want, then the classes in skyrimse/records.py don't see anything from bass, exception, brec or bolt. So it seems like much more is being imported when using import * from skyrim/records.py.

Share this post


Link to post
Share on other sites
On 9/24/2018 at 7:49 AM, Sharlikran said:

@Utumno There is some kind of scope issue with how you prefer to import things. I was working with CptMcSplody to resolve issue 403 and after reading it I realized the fix needed to be in skyrim/records.py.

Initially I tried adding the code in the spoiler to skyrimse/records.py. I have reverted the changes so there is no point in reviewing a commit. With or without the changes listed below Skyrim SE uses MelModel from skyrim/records.py.
 

  Hide contents

 



from ...bolt import Flags, sio, DataDict, winNewLines, \
    encode, struct_pack, struct_unpack
from ...brec import MelRecord, MelStructs, \
    MelObject, MelGroups, MelStruct, FID, MelGroup, MelString, \
    MreLeveledListBase, MelSet, MelFid, MelNull, MelOptStruct, MelFids, \
    MreHeaderBase, MelBase, MelUnicode, MelFidList, MelStructA, MreRecord, \
    MreGmstBase, MelLString, MelCountedFidList, MelOptStructA, \
    MelCountedFids, MelSortedFidList, MelStrings
from ...bass import null1, null2, null3, null4
from ...exception import BoltError, ModError, ModSizeError, StateError
from ..skyrim.records import MreActor, MelBipedObjectData, MelBounds, MelCoed, \
    MelColorN, MelComponents, MelCTDAHandler, MelConditions, MelDecalData, \
    MelDestructible, MelEffects, MreHasEffects, MelIcons, MelIcons2, \
    MelKeywords, MelMODS, MelOwnership, MelPerks, MelScrxen, \
    MelString16, MelString32, MelVmad, MreHeader, MreAact, MreAchr, MreActi, \
    MreAddn, MreAlch, MreAnio, MreAppa, MreArma, MreArmo, MreArto, \
    MreAspc, MreAstp, MreAvif, MelBookData, MreBook, MreBptd, MreCams, \
    MreCell, MreClas, MreClfm, MreClmt, MreCobj, MreColl, MreCont, MreCpth, \
    MreCsty, MreDebr, MreDial, MreDlbr, MreDlvw, MreDobj, MreDoor, MreDual, \
    MreEczn, MreEfsh, MreEnch, MreEqup, MreExpl, MreEyes, MreFact, MreFlor, \
    MreFlst, MreFstp, MreFsts, MreFurn, MreGmst, MreGras, MreHazd, MreHdpt, \
    MreIdle, MreIdlm, MreInfo, MreImad, MreImgs, MreIngr, MreIpctData, MreIpct, \
    MreIpds, MreKeym, MreKywd, MreLcrt, MreLctn, MreLgtm, MreLigh, MreLscr, \
    MreLeveledList, MreLvli, MreLvln, MreLvsp, MreMatt, \
    MreMesg, MreMgef, MreMisc, MreMovt, MreMstt, MreMusc, MreMust, MreNavi, \
    MreNavm, MelNpcCnto, MreNpc, MreOtft, MrePack, MrePerk, MreProj, MelItems, \
    MreQust, MreRace, MreRefr, MreRegn, MreRela, MreRevb, MreRfct, MreScen, \
    MreScrl, MreShou, MreSlgm, MreSmbn, MreSmen, MreSmqn, MreSnct, MreSndr, \
    MelSopmData, MreSopm, MreSoun, MreSpel, MelSpgdData, MreSpgd, \
    MreTact, MreTree, MreTxst, MreVtyp, MreWoop, MreWrld

 

 

 

 

This confirms an error that was reported with your official 307 version for Fallout NV. Importing Skyrim records for Skyrim SE and Importing Fallout 3 records for Fallout NV does not work in all cases with all classes.

Another thing that demonstrates a possible issue with the scope is when I replace just from ..skyrim.records import * and import the exact classes I want, then the classes in skyrimse/records.py don't see anything from bass, exception, brec or bolt. So it seems like much more is being imported when using import * from skyrim/records.py.

9

Ok yep there might be - import * is frowned upon for good reason. I did not get what the issue is exactly, however - can you point me to a commit with the issue and I will try and fix?

Share this post


Link to post
Share on other sites

Hi I recently reinstalled Oblivion after having modded it previously a few months ago, as far as I know, nothing had changed except for me uninstalling and then reinstalling Oblivion. After booting the game through Steam I load my most recent save file and hit an infinite loading screen, I tried starting a new game and several older save files, as well as rebuilding the patch - nothing worked I still got an infinite loading screen. Later I uninstalled Oblivion again as well as Wrye bash intending to do a completely clean install of everything and a brand new patch for good measure but on starting the Oblivion version of Wrye Bash I received this message:

 

Traceback (most recent call last):
  File "bash\bash.pyo", line 227, in main
  File "bash\bash.pyo", line 393, in _main
  File "bash\basher\__init__.pyo", line 3981, in Init
  File "bash\basher\__init__.pyo", line 4021, in InitData
  File "bash\bosh\__init__.pyo", line 2726, in refresh
  File "bash\bosh\__init__.pyo", line 1382, in refresh
  File "bash\bosh\__init__.pyo", line 1358, in new_info
  File "bash\bosh\__init__.pyo", line 1277, in new_info
  File "bash\bosh\__init__.pyo", line 393, in __init__
  File "bash\bosh\__init__.pyo", line 274, in __init__
  File "bash\bosh\__init__.pyo", line 405, in _reset_cache
  File "bash\bosh\__init__.pyo", line 1108, in readHeader
  File "bash\bosh\save_headers.pyo", line 62, in __init__
  File "bash\bosh\save_headers.pyo", line 78, in load_header
  File "bash\bosh\save_headers.pyo", line 88, in load_image_data
OverflowError: Python int too large to convert to C long
 

One other note is that the Skyrim SE version of Wrye Bash loads fine. Thanks in advance for the help.

Share this post


Link to post
Share on other sites
On 9/25/2018 at 5:59 AM, Utumno said:

Ok yep there might be - import * is frowned upon for good reason. I did not get what the issue is exactly, however - can you point me to a commit with the issue and I will try and fix?

Quote

I have reverted the changes so there is no point in reviewing a commit.

Adding class MelModel to skyrimse/records.py, the class was not used. Instead class MelModel was used from skyrim/records.py. I made branch dev-imports with the change since as mentioned I reverted it.

Share this post


Link to post
Share on other sites

@Utumno When you have time can add the ability to install custom tool files to the data directory. For example xEdit uses a file .modgroups. It can, if the author chose, be included in a download and it goes in the Data directory where the esp/esm/esl is. The game doesn't use it but xEdit will. Those files have been around for a decade but nobody ever used them. Elminster has quite a few examples and if it catches on, people could start including them.

I tried to install the file but couldn't

Modgroups.zip

Share this post


Link to post
Share on other sites

Bash appears to already support this. It installed the .modgroups file I included with UFO4P into my main install I play the game on and didn't complain about it. It shows up as a matched file in BAIN too.

Share this post


Link to post
Share on other sites

Did you try the file I provided Arthmoor? That file will not install by itself. However, I appreciate it when people respond after testing the users comment first so I thought I would take my own advice and download your Fallout 4 Patch. I noticed it did exactly as you mentioned. However, it occurred to me at that moment that maybe the installer was overlooking the files as being valid because there wasn't at least one valid file in the archive/project.

So I thought, hey, what if I make an empty file of 0kb with no TES4header but I call it 1nivWICSkyCloaksPatch.esp because maybe there is a regex command that could be installing the .modgroups file simply because there is an accompanying plugin. Meaning that what you see Arthmoor is because the installer is looking for one valid file, in this case an .esp file, but then looks for 1nivWICSkyCloaksPatch[anything][.][anything] not that the code actually supports installing .modgroups files.

Once I did that BAIN recognized the .modgroups files. Which isn't necessarily a bug but it probably shouldn't work that way. In fact so that I wouldn't install a 0kb file I just unchecked it in the window, and then installed the .modgroups files. I even did it in the Oblivion folder just for fun.

So it works but that seems like it's not really how it should be working. I'd prefer to hear what Utumno has to say after discovering that by making a 0kb file with the .esp extension that then the files installed. It would be better in my opinion to have it specifically recognize them. If someone wanted to install Elminster's ModGroup files or ModGroup files from another author on the nexus they would have to fool Wrye Bash also.

Share this post


Link to post
Share on other sites

Currently I am still preferring to use Wrye Bash as my mod manager. However, there is something that will be a hindrance to users. Elminster is currently my real world example. I know it is the intention of the project to remain capable of building a Bash Patch and being a viable mod manager.  I am leery of posting this because I am sure there are people who do not have over 50, or 100 mods installed and may have few to no .esl files installed and therefore things work fine.

I would like to ask that it be considered, before responding, that you don't know how many people have heavily modded games. That you don't know whether or not someone has over 255 mods and how many .esl files they have. Consider that even if you personally know only a few people that for sure have a type of setup that makes Wrye Bash unusable to them, there is an unaccounted for amount of people that also have more then enough files.

Starfield will be released at some point and I don't see why we should wait to see if it uses .esl files or not. They may make slight improvements that make .esl files more useful and more popular. They could choose to not change anything because the .esl file system is already in place and there is no reason to change something that works. It is also unlikely because of what would be involved, but they could overhaul plugins to use 2 bytes instead of one byte for the load order of the plugin and depreciate .esl files. Again changes like that are unlikely because what is already in place works.

There are people on the Nexus in the Wrye Bash comments section starting to express their concern about mods being disabled. Once has mentioned it is no longer possible to use Wrye Bash at all. Again one or two people only means those people were willing to post their feedback.

Other mod managers such as MO2 which Elminster uses and NMM don't count .esl files toward the total count of mods. I don't know what Vortex does with .esl files. For people wanting to make a Bash Patch that have 350 files, which Elminster has, could not do so. 

This goes back to how I mentioned that there needs to be, not a wiki page of the 10,000 mile high exacting detail PEP8 type document, but there needs to be an accepted way for Wrye Bash to sort mods in order to patch them. If you need some kind of word from someone else, this is Elminster's approved summary of ESL vs ESM for now including load order.

Now Elminster feels that automated patches are the devil but there is also another reason he could not make a Bash Patch. Because you can't have all the files active that he has active using MO2. That is one reason. The other reason is that all of his .esp files that qualify to be .esl files are really .esp files with the ESL Flag. With that you probably don't want to make a Bash Patch with .esp files flagged as ESL because all the ESL flag does is change mapping. Read the link I provided.

It just doesn't make sense to have the maximum amount of files, pushing the limits of what Wrye can do, have the Bash Patch at FD (which it can't be FE anymore) only to have all the files that map to FE override the Bash Patch. So I feel whether or not it looks odd on the mods tab the sorting needs to be what makes building the Bash Patch work. Not what looks pleasing.

I still feel, like I did almost a year ago, feel all .esm and false flagged files should be first, DLCs and CCs, esp files without ESM or ESL flags, the Bash Patch, then any file with an ESL flag or .esl extension. Such as:

  • Game's Master
  • Update.esm [Skyrim SE]
  • DLCs in official order
  • CCs in official order
  • All ESM (flag after load) in plugins.txt order
  • All non-ESM (flag after load) in plugins.txt order
  • Bashed Patch, 0.esp
  • All ESL flagged files or .esl file (without the ESM flag) in plugins.txt order

Caveats:

  • Inside the "ESM block" you can have .esl, .esm, and .esp files mixed in any order based on plugins.txt, as long as they all have the ESM flag (implicit or explicit)
  • Inside the "non-ESM block" you can have only .esp (because it's impossible to have a .esm or .esl without ESM flag)

At this point this evolution needs to be considered.  The fact that MO2, NMM, and maybe Vortex can function with over 255 files isn't the main point. They don't make a Bash Patch. Now that Elminster made the recent changes to xEdit, it can load easily 350, 550, or even 1000 files so more and more users will end up with that kind of load order. This isn't a hypothetical situation anymore.  Building a Bash Patch will not be possible because Wrye Bash still can't handle the files in the way people are using them.

All testing is being done with people from other teams. I don't even know what the teams are because in Discord they are just labeled as Mod Authors or tool developers. The SKSE team is one team in particular that has been talking to Elminster and they all agree on the functionality of .esl files and ESL flagged files. I just highly doubt people are going to go out of their way to document solid evidence and concrete programming guidelines.

Share this post


Link to post
Share on other sites

Just thought of something about .esl files. If an .esl file can be merged, then it doesnt need to be an .esl file, it can stay an .esp file and be merged.

Then a user could load their plugins and look for or resolve other conflicts with xEdit.

Share this post


Link to post
Share on other sites
7 hours ago, Sharlikran said:

It just doesn't make sense to have the maximum amount of files, pushing the limits of what Wrye can do, have the Bash Patch at FD (which it can't be FE anymore) only to have all the files that map to FE override the Bash Patch.

Not sure if you were there when this was discussed or not, but it's been tested and verified already by several participants in the xEdit Discord. Files  mapped to FE will not override the Bashed Patch. They will still conduct their overrides in accordance with the load order that's been specified in the plugins.txt file. Elminster has verified this. I've verified this. Pretty sure Roy verified it too. As have several other interested parties in this whole ESL thing.

The patch isn't going to break the new order of things. What does need to happen though is Bash has to be updated in some way to account for these new ESL flagged files mixed in with the regular .esp files and that's something well beyond my ability to even think about with the way Bash's file system works. Right now it's respecting their proper load order only because of the happy accident that it knows nothing about what ESLified .esp files are supposed to do.

Share this post


Link to post
Share on other sites
14 hours ago, Sharlikran said:

Adding class MelModel to skyrimse/records.py, the class was not used. Instead class MelModel was used from skyrim/records.py. I made branch dev-imports with the change since as mentioned I reverted it.

3

Hmmm, MelModel is used inside other records in skyrim/records - so yes inside those other record classes it's the definition from that same file that is used - so the skyrim one

By the time you import skyrimse/records whether you define MelModel there or not the classes you imported from skyrim use their MelModel

The only cure I can see is defining that MelModel in skyrimse (and falloutnv) and copy the classes that use it from skyrim/fo3 inside the se/nv files.

Same should be repeated for other such cases if any

Could you do that? I will see if I can come up with some hack so we avoid that

On 9/25/2018 at 8:53 PM, Boma_Ye said:

Hi I recently reinstalled Oblivion after having modded it previously a few months ago, as far as I know, nothing had changed except for me uninstalling and then reinstalling Oblivion. After booting the game through Steam I load my most recent save file and hit an infinite loading screen, I tried starting a new game and several older save files, as well as rebuilding the patch - nothing worked I still got an infinite loading screen. Later I uninstalled Oblivion again as well as Wrye bash intending to do a completely clean install of everything and a brand new patch for good measure but on starting the Oblivion version of Wrye Bash I received this message:

 

Traceback (most recent call last):
  File "bash\bash.pyo", line 227, in main
  File "bash\bash.pyo", line 393, in _main
  File "bash\basher\__init__.pyo", line 3981, in Init
  File "bash\basher\__init__.pyo", line 4021, in InitData
  File "bash\bosh\__init__.pyo", line 2726, in refresh
  File "bash\bosh\__init__.pyo", line 1382, in refresh
  File "bash\bosh\__init__.pyo", line 1358, in new_info
  File "bash\bosh\__init__.pyo", line 1277, in new_info
  File "bash\bosh\__init__.pyo", line 393, in __init__
  File "bash\bosh\__init__.pyo", line 274, in __init__
  File "bash\bosh\__init__.pyo", line 405, in _reset_cache
  File "bash\bosh\__init__.pyo", line 1108, in readHeader
  File "bash\bosh\save_headers.pyo", line 62, in __init__
  File "bash\bosh\save_headers.pyo", line 78, in load_header
  File "bash\bosh\save_headers.pyo", line 88, in load_image_data
OverflowError: Python int too large to convert to C long
 

One other note is that the Skyrim SE version of Wrye Bash loads fine. Thanks in advance for the help.

Please post me the needed info - > bugdump

Share this post


Link to post
Share on other sites

Hi, I was looking for some clues to make a bashed patch well done, since I want to install different mods that add lots of items, so I thought that probably merging the leveled lists would be useful. I looked all over the internet but I couldn't find answers to my personal doubts, so I thought to ask you and maybe you can help me. My questions are the following.

 

1) Do I really need to sort my load order with LOOT before using Wrye Bash? I mean, I spent several months to create my working load order and I don't want to mess everything. Or maybe I just need to launch LOOT so that Wrye Bash can detect my plugins in the right way? If it's so, then no problem.
 

2) Do I really need to check ALL my plugins? Everyone on the internet says so but I don't want to, since I have several compatibility patches (for example, they simply address, remove some duplicates, and things like that) that make specific changes and I don't want to include them and f*** things up. Or is it safe?
Also, do I really need to check even bethesda master files? In my bashed patch, I would include only SOME specific mods. I don't even want to put the bashed patch at the very bottom of my load order but just down the last mod included in the bashed patch. Then having the compatibility patches AFTER the bashed patch. What happens if I do so? Is it wrong?

3) In order to just have different items from different mods co-exist, I think I just need to check "Merge leveled lists" in Wrye Bash, I don't want to check other stuff. Is it all I actually need to check for what I need? (My only doubt is about "Import Inventory", is it needed?)

4) Another thing I read everywhere on the internet is that for EVERY mod that I add in the future, I will need to rebuild my bashed patch. If the mod doesn't change leveled lists or has different leveled lists that don't conflict with the others (for example, a quest mod in its own new land), do I really need to rebuild my bashed patch?

Share this post


Link to post
Share on other sites

@Sharlikran for a possible hack see https://stackoverflow.com/a/10028797/281545

So maybe do in se records file

from ..skyrim import records as skyrim_records

class MelModel(...):

    ...

skyrim_records.MelModel = MelModel

Now if you could replace the 

from ..skyrim.records import *

with importing only the needed classes that would be great - and will help to spot those bugs much more easily

If this hack works then we should scan the record classes for such mod elements that are used inside the classes and repeat the hack for other such mod elements that are used inside the skyrim/fo3 records that are imported in skyrimse/nv

Good catch actually!

Share this post


Link to post
Share on other sites

@Sharlikran - forget my hack that won't work cause the skyrim.MelModel is used on import time in the class definitions - so the instances in melSet will all be instances of the skyrim .MelModel hack or not hack. I will have to think carefully - if you can please remove the star imports and I will have a more careful look in the weekend hopefully

Share this post


Link to post
Share on other sites
4 hours ago, Varil92 said:

4) Another thing I read everywhere on the internet is that for EVERY mod that I add in the future, I will need to rebuild my bashed patch. If the mod doesn't change leveled lists or has different leveled lists that don't conflict with the others (for example, a quest mod in its own new land), do I really need to rebuild my bashed patch?

Yes, you do need to rebuild the bashed patch for a couple of reasons.

All mods that's loaded before another mod won't work properly, because the mod in question will win over other previous loaded mods.

The bashed patch will ensure that all installed mods will work regardless what loadorder one will have after sorting a loadorder in LOOT, which also add tags (not the bashed patch) to certain mods during the mod sorting sequence and in some cases the bashed patch is depending of what bash tag LOOT have added to a mod.

Also, this is important, any mod that has different levelled lists won't work properly due for not being handle by the bashed patch, plus the main purpose of using the bashed patch is to reduce mod slots in a heavy modded game and including the levelled lists into the bashed patch ensure the game will be stable regardless how many mods (max 255 mods, I think) one is allowed to use at the same time.

Share this post


Link to post
Share on other sites

@Arthmoor no I was not there I will have to look for it. Once I get wrye bash to sort the files differently and be able to get all 350 of his files activated and sorted with LOOT (he gave me his userlist.yaml) I can experiment making a bash patch without breaking something.

Thanks for letting me know this has been discussed I appreciate it.

I only hope i can make sense of the sorting code as it's quite complex in wrye bash.

Then there is the fact that all of wrye bash uses a standard formid since that is what was needed for over a decade. Now for esl its FE xxx yyy where x is the light slot and yyy is the id. I dont think it will be easy to correct that but wrye bash has always used long fids which is (filename, yyyyyy) to have more then 255 files so that will have to suffice. I just hope it works. ;)

 

 

Share this post


Link to post
Share on other sites

@Utumno I added as you requested the imports and tested it. It will make a Bash Patch but without using MelModel in the skyrimse folder.

Also would you be so kind as to export your Pycharm settings into their jar file and attach it. There are enough changes that your repo of settings no longer works with the latest Pro Student Version.

Share this post


Link to post
Share on other sites
On 9/28/2018 at 7:28 AM, Sharlikran said:

@Utumno I added as you requested the imports and tested it. It will make a Bash Patch but without using MelModel in the skyrimse folder.

Also would you be so kind as to export your Pycharm settings into their jar file and attach it. There are enough changes that your repo of settings no longer works with the latest Pro Student Version.

Could you please do that also for faloutnv? I think I have a solution will try and code it ASAP. However we must pinpoint which other Mo0dEelemnts are defined per game as MelModel

My settings https://www.dropbox.com/s/ky0l5311koud75d/.idea.7z?dl=0

 

Share this post


Link to post
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

Support us on Patreon!

×