Jump to content

EET playthrough with 200+ mods


Recommended Posts

PI exposes all components and ignores REQUIRE_PREDICATE during install order building. However it doesn't bypass REQUIRE_PREDICATE during the install step, so if someone tries to install a component inappropriate for their install, the REQUIRE_PREDICATE message is logged and the component ends up "skipped" and marked as error-free internally, and the install progresses further.

For a while I tried to install IWDification's "additional portrait icons" component on the EEs, overlooking that being classic-only and never checking my own logs to notice it never even installed.

Edited by Graion Dilach
Link to comment
9 minutes ago, Graion Dilach said:

PI exposes all components and ignores REQUIRE_PREDICATE during install order building. However it doesn't bypass REQUIRE_PREDICATE during the install step, so if someone tries to install a component inappropriate for their install, the REQUIRE_PREDICATE message is logged and the component ends up "skipped" and marked as error-free internally, and the install progresses further.

Well, then it should have been impossible for Quester to install that component. (You can see the code in the link in the last post.) Yet, here we are.

I suppose it's possible this is a symptom of a broader bug with how Weidu handles subcomponent predicates...

Edited by subtledoctor
Link to comment

Yeah, and I can see from the first post in this topic that it shouldn't even get there, assuming everything went correctly. It was possible to trigger your bug in PI though, because up until very recently, PI never errored out on duplicates in the install order, and the duplicate would do a reinstall outright (uninstalling all the components until the first spot, but I never tested what got installed after it, all my cases I've triggered were caught during this process), which has the chance to trigger it.

I'm not sure though if the weidu.log in the first post currently is what PI attempted to install (in which case it should have skipped your component and not installing any of the four options) or ended up actually installing it.

Edited by Graion Dilach
Link to comment

Hello, I had the same crash with temple healing. I think it is that Jmerry component. I meant to put a post about it but haven't got round to it.

If you open the relevant temple .sto files in nearinfinity, there's a spell listed in brackets with null in front, if you change that to actually be null temples will work again.

Typing this on my phone is a pain in the arse.

@Quester

 

Link to comment
13 minutes ago, Nathan82 said:

Hello, I had the same crash with temple healing. I think it is that Jmerry component. I meant to put a post about it but haven't got round to it.

If it is that one, I made a hotfix for it as Quester mentioned. You can install the hotfix at any time, including mid-way through your game, and temple cures will start working. (He said he applied the hotfix and still got the crash, so his issue may be different. The Hotfix is very much specific to the JMerry mod.)

Link to comment
On 5/12/2022 at 2:29 PM, Graion Dilach said:

Basically all those entries between Vynd and Emily-BG1 shouldn't even exist, including Thalantyr and removing them would fix the problem. Apparently EET_end can't handle such dummy pdialog entries.

Just wanted you to know that I ran into this same issue today (probably as a result of the same mod) and was despairing of finding a solution, so thank you! (Now we'll see if this giant house of cards I installed today actually stays up!) 

Link to comment

@subtledoctor The reason why Quester was able to install component 1203 despite using BG2EE engine and EET is because PI is using is using "--force-install DESIGNATED" and at the same time, PI is unable to parse tp2 file and extract any logic conditions due to complexity of such task. Even the "parsing" part require significant amount of work (GLR parser) so it's not something that I can do in nearest future. Maybe someday there will be tp3 that could solve such problems.

Link to comment
On 9/20/2022 at 8:49 PM, subtledoctor said:

What game are you playing? EET? EET is on the BG2EE engine, meaning it already uses BG2 opposition schools. If you are playing BGEE or BG2EE then that option should not be available. Since EET is within the BG2EE game, likewise, that option should be unavailable. If you install the mod to force BG2 opposition schools in a game already using BG2 opposition schools... well, I wouldn't necessarily expect bugs, but I wouldn't be surprised by them either.

In other words, if you are playing BGEE, SoD, BG2EE, or EET, then your game already uses BG2 opposition schools. In this case you should only use the mod to switch to IWD opposition schools or no opposition schools.

EDIT - I guess PI operates by employing the --force-install tag, which could theoretically override the actual mod code that prevents this component being installed on EET...? It's possible that forcing it to install when it doesn't want to somehow overrides the way the .tp2 code passes a string variable to the function, and so the function used the default value which is "none" and which removes all opposition schools.

EDIT 2 - or maybe PI just had its strings confused, and you saw "BG2 Opposition Schools" which is component 1203, and in fact PI force-installed component 1201,
"No Opposition Schools."

In any case the answer remains: if you are playing one of the BG games and you want BG2 opposition schools, your game already has what you want so just don't install this component at all.

Not sure what the best path is now... it's installed pretty early in your stack, I would not try to uninstall it at this point.

...

As far as temples go: best bet is to open a temple .STO file in Near Infinity and check out the cures they are selling. If there is a problem, it might be pretty obvious. (Like if one of the cures being sold has no name, there might be no resource there. In such a case the easy fix is to simply delete the faulty cure from the list of things being sold. The tedious part is performing this fix on every  .STO file that needs it.)

Well silly me. I didn't even realize. I have now removed that component for my next installation.

On the temple cures topic, interestingly it seems in my game it's not J8#GRNF.spl which is faulty (which is what your fix mod fixes), but J8#LRNF.spl. Looking in NI, it doesn't have a name. I'm guessing this is due to some interaction with another mod that changes temple cures.  After looking through my weidu.log again, I realize I have two mods doing similar things to temples:

~MIH_SP\SETUP-MIH_SP.TP2~ #0 #15 // Expanded Temple Services: v5

~ATWEAKS\SETUP-ATWEAKS.TP2~ #0 #510 // Expanded temple services: v4.53

I don't know which causes the issue with jtweaks, but maybe the atweaks one since that is installed after in my install?

Edit: So I'm removing that line with the missing spell from the relevant store in NI, I click Save. Load the game up....and still, it crashes upon trying to open the Cures page at temples. What the heck. I thought that would do it.

Edited by Quester
Link to comment
17 minutes ago, Quester said:

On the temple cures topic, interestingly it seems in my game it's not J8#GRNF.spl which is faulty (which is what your fix mod fixes), but J8#LRNF.spl.

If J8#GRNF is Greater Restoration, maybe J8#LRNF is Lesser Restoration? In that case, simply make  a copy of SPPR417.spl  and name the copy "J8#LRNF.spl" and drop that renamed copy into your override folder. Boom, no more crashes.

Link to comment
13 minutes ago, subtledoctor said:

If J8#GRNF is Greater Restoration, maybe J8#LRNF is Lesser Restoration? In that case, simply make  a copy of SPPR417.spl  and name the copy "J8#LRNF.spl" and drop that renamed copy into your override folder. Boom, no more crashes.

But removing the spell from the store should also solve the problem, right? Strangely, it doesn't. See my edit above.

Admittedly this is my first time ever using Near Infinity, but this particular thing seemed straightforward enough. Find store, delete line, save.

Edited by Quester
Link to comment

It’s possible the .STO file is your savegame once you’ve already been there…? I’m not sure. But if that’s the case, fixing the missing reference by making a clone of SPPR417.spl will still work. EDIT - also this has the advantage of fixing all temple .STO files in one step, rather than having to fix each one individually.

Edited by subtledoctor
Link to comment

Yup, that did fix the crashing! Wonderful. However I now have two different Lesser Restoration offered. One costs 300gp and the other 600gp. So I guess it was supposed to be something else. Maybe just Restoration, which the MiH component is supposed to add to some temples. At any rate I think it's safe to say that I shouldn't install two versions of Expanded Temple Services together. Getting rid of the MiH one for next installation.

On a more depressing note, the stutters are back, and they're bad. I now get them in every save game, even where before everything ran smoothly. I don't understand. (Note this happened before the temple fix, so at least that doesn't have anything to do with it.)

Sure I was planning to do another reinstall soon anyway, but I would like to find the cause for these stutters first, as I fear they will just return again even if I reinstall.

Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...