5286 replies to this topic

[Ithildur]

The items do not 'disappear' as such (you're probably thinking of the items carried by the temporary NPCs which are specifically deleted by script in BGT); they were not actually in the creatures' inventories in BG1 or BGT, and they never dropped at all in BG1 or BGT (and I'd imagine Tutu was the same). LOLFixer's Inventory Unborker component puts them in inventory slots, which results in them dropping.

 

Inventory Unborker also does this with a lot of other cre files (219 in my install), which makes me concerned about other potential issues.

 

Have to admit, I'm also looking rather nervously now at the 800+ cre files tweaked by LOLFixer's component #5... I get the feeling some of these components have not been heavily 'field tested' (especially as the training mobs' loot issue happens very early on in the game and should be easy to discover; maybe most people go 'Hey, free loot!' and never report it), i.e. I feel like I'm doing the field testing now. Which is fine, that's the nature of mod useage after all, except... BWS probably shouldn't install these by default if that's the case.

Edited by Ithildur, 16 January 2016 - 03:30 AM.

[The Imp]

LOLFixer also does this with a lot of other cre files (219 in my install), which makes me concerned about other potential issues.

Like ? You get too many items. Well, your inventory is too small to handle most of them anyways, so you could just drop them anyways.

Not installing it by default... why do you thing it was done in the first place ? Could it be that it fixes more than it damages ?
Yes, it could be field tested a bit more, yeah, but we have what 2^1500 other possible mods that need testing too, and well we haven't got the time to not fix them all. And just to dhow you the number that is, it's:

Spoiler

1.4272477e+45 * 1.4272477e+45 *1.4272477e+45 * 1.4272477e+45 * 1.4272477e+45 * 1.4272477e+45 * 1.4272477e+45 * 1.4272477e+45 * 1.4272477e+45 * 1.4272477e+45

If you wish to, you can create a list of the .cre files that should not be edited by the Lolfixer according to you, and I am sure Lollorian will take a look at them, and approve or disapprove them, when you know what their circumstance is.

[Ithildur]

There's potential for other problems besides 'extra loot' when there's items in the inventory that weren't there before...

 

I'll see if I get to a point where I can compile a helpful and accurate list of problematic cre file fixes; if/when I do I'll post them, but that's going to take some time to play through the game and even then not all of the critters will be encountered every runthrough.

 

Problem with installing component xyz by default is that you have to hold such components to higher standards, if you're going to put BWS out there as a reliable and trustworthy package. Something like BG2Fixpack, that's a no brainer perhaps as a default 'always install this' (for non EE installs); it's established, field tested heavily, proven, and pretty much necessary for anything else. BGT is a 'default' if the package selected is a BGT package, obviously. Generalized Biffing might qualify for default for non EE games... maybe. Not many other mods, even SCS, should be locked into the installation by default without notice imo.

Edited by Ithildur, 16 January 2016 - 03:59 AM.

[The Imp]

Yeah, well, I lived when there was Megamoding but no BWS, BWP nor BP... you could strip all those away from the megamod and it still worke... well it was tried to be getting to work.

 

I don't see a problem arising from removal of any of those mods you mentioned.

The SCS had a reliance for the BG2Fixpack at points, but it and several other mods went around that and the BWS now sorta compensated for that fact even... see the discussion of the kit.ids without the BG2Fixpack on several forums, here and in G3.

The BWS is just the current tool. It's a part of a chain of lesser tools, and the mods are part of lesser mods. Or scraps of sorta better tools stolen by the Jarno Mikkola, like the LStest mod and the --change-log'ing. It's not like he could improve them in anyways or abuse them.  

[Lollorian]

Can we discuss this in the relevant thread please?

Here

 

Let's work this out shall we? Could you please attach all the creatures that the changelog generated along with the Big World Debug.txt (I think the BWS 7zes it ) in the thread I linked?

 

I'd like to help solution to the issue that doesn't involve deleting content from files on an extremely large scale. Any suggestions other than manually excluding each creature?

[dady977]

Hey guys, I just got this error in my current fresh BWS install, can someone help me solve it? Or atleast tell me what to do? Because in my previous BWS installation I didn't get this error at all.

 

Installing [Revised Critical Hit Aversion] [V4 Beta 8]

Copying and patching 4283 files ...

ERROR: [M#PIRBAN.ITM] -> [override/M#PIRBAN.ITM] Patching Failed (COPY) (Invalid_argument("Str.search_forward"))

Stopping installation because of error.

[The Imp]

Hey guys, I just got this error in my current fresh BWS install, can someone help me solve it? Or atleast tell me what to do?

 

Installing [Revised Critical Hit Aversion] [V4 Beta 8]

Copying and patching 4283 files ...

ERROR: [M#PIRBAN.ITM] -> [override/M#PIRBAN.ITM] Patching Failed (COPY) (Invalid_argument("Str.search_forward"))

Stopping installation because of error.

Report this to the mods forum, if it's not Item Revision or the Criticals, I believe that the item: "m#pirban.itm" reference is not in the mods tablets or something such... if it's the IR or the other, it was reported a bit ago, and the needs to update for the file reference compatibility.

Aka, the mod that gives the Pirate Bandanna and that mod is temporarily incompatible.

[dady977]

Hey guys, I just got this error in my current fresh BWS install, can someone help me solve it? Or atleast tell me what to do?

 

Installing [Revised Critical Hit Aversion] [V4 Beta 8]

Copying and patching 4283 files ...

ERROR: [M#PIRBAN.ITM] -> [override/M#PIRBAN.ITM] Patching Failed (COPY) (Invalid_argument("Str.search_forward"))

Stopping installation because of error.

Report this to the mods forum, if it's not Item Revision or the Criticals, I believe that the item: "m#pirban.itm" reference is not in the mods tablets or something such... if it's the IR or the other, it was reported a bit ago, and the needs to update for the file reference compatibility.

Aka, the mod that gives the Pirate Bandanna and that mod is temporarily incompatible.

Oh I get it, but I don't know the mod that gives the pirate bandana, so I really can't report it.

 

Also, should I just skip it or just wait until it get's compatible?

[agb1]

M#PIRBAN.ITM is from Amber NPC.

For now just move it out of override temporarily while you install the IRv4 component, then back in.

Edited by agb1, 16 January 2016 - 06:21 AM.

[dady977]

M#PIRBAN.ITM is from Amber NPC.

For now just move it out of override temporarily while you install the IRv4 component, then back in.

I wanted to do this, because you gave me a similar advice like this one yesterday, but I wanted to ask first to make sure if it's not gonna do anything to my current installation.

 

Thanks for the help, again.

[agb1]

In this case the only consequence is that the tweak being done to all other head-slot armor by that IRv4 component is not applied to M#PIRBAN.ITM. Namely removing immunity to critical hits if the original item had that property. I don't know if the pirate bandana even had that, but anyway it won't hurt your game either way.

[The Imp]

In this case the only consequence is that the tweak being done to all other head-slot armor by that IRv4 component is not applied to M#PIRBAN.ITM. Namely removing immunity to critical hits if the original item had that property. I don't know if the pirate bandana even had that, but anyway it won't hurt your game either way.

Actually, the bandana will also loose the property too, as the fact that determines it is the placement of the item, aka the head slot. Which the tweak removes, and adds to a few of the selected items.
In the future, always listen when agb1 says something, with more priority than me... unless I directly dispute his statement, after him. -why, cause he probably has more up to date info.

[agb1]

Imp, I haven't looked at the IRv4 code, just assumed it was patching all items, checking if head slot, then removing critical hit aversion.

If the tweak works as you said (modify/disable critical hit aversion effect globally, selectively apply new effect to selected items only), why does it do anything with M#PIRBAN?

[The Imp]

I would assume it would execute a .exe hack, be it with ToBEx or anything else, that would remove the critical hit ability from all helmet's, and then would allow adding the ability to the patched items. Aka without the item being in the game, it looses the ability because it didn't have it in the first place, kinda.

But that's conjecture... not established fact.

[subtledoctor]

I think this is important to clarify:

 

For me incompatibility is a technical issue caused by different concepts, not a question of right or wrong and it does not necessarily need to be resolved but just been brought to the users attention - the new overwrite error/warning feature of BWS takes care of user decisions now.

 

For the record, I think the idea of BWS presenting certain "standard" selections of activated mods is a very dangerous idea, and can be detrimental to potential new modders.  BWS is an installation tool; if it becomes a vehicle for a few people (the BWS folks) to impose their subjective opinions about which mods should be installed by default, it discourages experimentation and exploration.  I advise being wary or mission creep, here.

 

Incompatibility warnings should be restricted to mechanical problems - not subjective conceptual differences.  If a user reads about Mod A and likes it and wants to use it, and reads about Mod B and likes it and wants to use it, BWS should not dissuade them from using both unless doing so will cause actual bugs or crashes or installation failures.  And of course, incompatibility warnings should be the result of actual playtesting, not just reading a readme files and saying "well I don't like that sound of that."  Someone reporting an incompatibility should be able to show the problem caused by it, so that we can respond by 1) resolving the issue and making them compatible, or in the alternative, 2) adding a warning about the incompatibility to BWS.

 

Let's work with each other, here.

[Roxanne]

Incompatibility for the Sandrah mods in BWS

I suggest to take all checks for incompatibility for these mods out from BWS. The mods are beta and expert, thus they are already marked to be used with caution. Users deciding to implement such mods may read the readme or find out the hard way. Mods in such status should not ripple back issues to mods that are considered standard or established (regardless of the quality of such mods).

Reports for issues encountered from such constellations shall always be filed against the beta mod. It was a big mistake made in the past to deduct issues in e.g Tashia, Spell Revision or SCS from how they became apparent in Sandrah. If any repair or resolution is required it is the task of the beta mod to correct it.

[Lollorian]

I just updated the BWS to the latest master and the Add -> All option doesn't seem to check all mods - am I missing something? (my click properties is Expert )

 

 

@Roxanne:

Would it be possible to make sure that if you are handling issues in other mods through Sandrah, please implement them in such a way that in case the issue is fixed in the base mod (either via updates or BWPFixpack) Sandrah doesn't do anything?

[agb1]

I agree that BWS should enable more user choice, not less. Hence recent changes allowing expert users to override BWS rules even in cases where ignoring those rules might have game breaking consequences. I also agree that most conflict rules should be based on technical incompatibility.

However BWS also has a concept of warning/notice rules for cases of conceptual incompatibility - where installing X and Y together means that the core intent of X is thwarted by Y or there will be obvious inconsistencies (for example if X contains dialogue written assuming that an NPC is dead while Y prevents that NPC from dying).

Another recent change of mine has resulted in BWS not automatically solving these conceptual incompatibility rules when users first load up the tool; instead the choice is presented to the user.

For non-"warning" rules, BWS does initially solve conflicts by only selecting one of the eligible mods/components for each rule. The priority goes to the first mod/component listed, so I have adopted the practice of moving the newest or most recently updated mods to the front of these rules to encourage more players to try them.

BWS also has the concept of pre-selections: minimal, recommended, maximized, tactical, expert. We tag individual mods and components in these categories to provide a predefined selection of enabled and disabled components, from which users can then further customize as much as they want. Recommended is a judgment about quality and how well a mod fits into the game. This is a bit fuzzy still, but it is just a recommendation. The other categories have no quality control at this point; the only consistent policy is that mods which fail to install or which break the game technically (requiring more than basic CLUA skills to resolve) are categorized as expert pending analysis and patching. No mod or component should be permanently in the expert category - it is a queue for known problems until we solve them.

BWS also has notes about mods and components describing known problems, compatibility considerations, etc. Some of this is taken from mod readmes, some from forum threads, and some from direct examination of mods' code. The intent is to be as accurate as possible and reports from users are constantly improving this aspect of BWS.

I hope this addresses your concerns; if not, happy to consider further suggestions for improvement.

[agb1]

Regarding Tashia, my understanding is that its current code breaks the ToB ending if Tashia is not in the party. This was discovered because of an install failure with the new Imoen Romance led us to examine Tashia's code. Roxanne graciously created a patch but this has not yet been tested and added to either the mod or the BWFixpack and so BWS has Tashia's ToB version tagged as expert for now to avoid players unwittingly running into this now-known problem.

[agb1]

Lollorian, I will look into that. Like you, I would expect that to select everything if your click-properties are set to expert.