Mages Can't Use Scrolls

[jastey]

3 minutes ago, jastey said:

Is this still a thing if, as I said, the NPC was set to ALLIES once if not in party (but never if in party upon transition)?

SoD itself does it in the first area the NPC is spawned in, and then for all in bd0101, bd1000, bd3000, bd6200, and bd7100. At least locally, all my NPC mods are covered (Brandock is not present in bd6200, Grey never leaves the party).

And bdparty.bcs uses it for Global("bd_npc_camp","locals",3), too, so I guess there is my answer.

[subtledoctor]

9 hours ago, Graion Dilach said:

NPC mods need to be updated to ensure they reset the SPECIFICS in BD3000 if they don't do that and also update BD4000.

Why?

That's not rhetorical - I want to understand this advice better, because up-thread you say "the solution here is to set party members' SPECIFIC value to 0" but here you are saying "we need more scripts to set more NPCs' SPECIFIC value to 2." This seems contradictory.

What I mean is, I could provide a general explanation of what is going on with the game here. But if the author of an NPC mod is asking whether it should be done… shouldn’t it default to not being done? If a modder is contemplating this, knowing there is the prospect of inter-mod conflicts, shouldn’t the modder have a pretty specific idea of what this would achieve? Because it seems to me, so far, that people do not have a very specific idea of what this will achieve. 

I’ll happily update my stuff for improved compatibility. But after a point the problem is no longer “this mod has an adverse interaction” but instead “other mods are actively causing conflicts with a mod that has been working perfectly well for 5+ years, without stopping and considering how it could work better.”

Edited July 12, 2022 by subtledoctor

[Graion Dilach]

I was under the impression that during joining and leaving the party, the SPECIFIC value would be lost, so mods need to reset it to ALLIES multiple times to prevent mod conflicts. That's not the case however, because I wasn't looking at the DPLAYER scripts.

16 hours ago, subtledoctor said:

my mod changes it in the kit table, which is processed upon joining the party.

Not just there.

https://github.com/UnearthedArcana/refinements/blob/534ac33e02c2c053ffed403782354565438f7f74/refinements/lib/hla_thief.tpa#L515-L531

With the IDS overlap, NearInfinity's decompiler evaluates the resulting BCS block as

IF
	GlobalLT("ENDOFBG1","GLOBAL",2)
	OR(2)
		!Specifics(Myself,NORMAL)
		!Global("bd_joined","locals",0)
	InPartyAllowDead(Myself)
	GlobalGT("bd_plot","global",0)
	!Specifics(Myself,ALLIES) //would be !Specifics(Myself,D5_NO_UMD)
	Switch("D5NOUMD","locals")
THEN
	RESPONSE #0
		ChangeSpecifics(Myself,NORMAL)
		SetGlobal("bd_joined","locals",0)
		SetGlobal("bd_npc_camp","locals",0)
	RESPONSE #1
		ChangeSpecifics(Myself,ALLIES) //would be ChangeSpecifics(Myself,D5_NO_UMD)
		SetGlobal("bd_joined","locals",0)
		SetGlobal("bd_npc_camp","locals",0)
END

Due to ALLIES being set during the (mod) NPC introduction before this block has a chance to evaluate, the Specifics check will return true and the D5NOUMD local never gets evaluated to reset the value. If you fix the IDS overlap bug, this will fix itself as well. (And yes, this isn't EET, but SoD, again.)

[subtledoctor]

Huh. I don't understand that scripting and definitely did not add it to Refinements... must have come in in some pull request or other... maybe for this very purpose? I can't tell what that is doing.

At any rate,

5 minutes ago, Graion Dilach said:

fix the IDS overlap bug

it has already been fixed.

[Graion Dilach]

It very much looks like to handle the SoD SPECIFICS values, indeed. Hooking into this script this way ensures that even if the camp migration overwrites the SPECIFICS from D5_NO_UMD to ALLIES, you'll reevaluate it during joining again (and this always gets evaluated after a SPECIFICS reset). The ENDOFBG1 is EET, which will pass (2 is SoA), the SPECIFICS will be ALLIES or D5_NO_UMD which passes the Or(), the bdplot is a "still-in-SoD" check and on that point checking D5_NO_UMD just resets it to itself or to NORMAL which is the SoD intended value.

I'd be less worried about this if LeaveParty() would also receive a similar scripting to clean up D5_NO_UMD to NORMAL when the character isn't part of the party, but I'll assume from your SoD playthrough that losing NORMAL will not cause issues here.

You really shouldn't bash EET just because you don't know it's internals well.

[subtledoctor]

19 hours ago, subtledoctor said:

I don't have enough information

On 4/1/2021 at 11:09 AM, subtledoctor said:

If something about the chapter progression in EET is messing with SPECIFIC values, then that is very much something I want to know about.

On 7/27/2021 at 12:09 AM, subtledoctor said:

Any information about when this happens would be very helpful. It must be in a script somewhere...

On 7/11/2022 at 12:36 PM, subtledoctor said:

But I'm not interested in casting blame, only in finding out how exactly this is happening.

22 hours ago, subtledoctor said:

it would still be good to know why EET is setting the SPECIFIC value of party members

6 hours ago, subtledoctor said:

It seems like more work is needed to harden party members from being affected in this way… so I’m trying to figure out the best way to reinforce the distinction

4 hours ago, subtledoctor said:

Why? That's not rhetorical - I want to understand better

Does that sound like "bashing?" Or was I ASKING for more information about EET's internals??

You seem to have this all figured out, but you are more interested in being defensive than elucidating. I'm trying to understand this better so that I can make things work better for other people. You seem more interested in defending EET's honor in some weird way, than in helping. I had mods around that were working perfectly for years, and even after SoD came along and started using the same mechanic, but it all seemed to work fine - I saw no problems myself and there were no complaints from players. Then all of a sudden there are a number of complaints of a bad interaction, and every single one of those complaints was from someone playing EET. Given that information, what am I supposed to infer??

And so I ask and ask, and ask... and ask again, for more information that I can use to resolve the issue. Because this scripting stuff is WAY outside my area of expertise. Did anyone ever answer those questions? NPC modders are inserting code relating to specifics into their mods - have any of them explained why? No. You seem to have this all figured out, but you're more interested in bitching and moaning about being "bashed" - no wait, bitching and moaning about something else completely unrelated to you being "bashed."

Jesus. Grow some thicker damn skin and try being helpful.

Edited July 12, 2022 by subtledoctor

[Graion Dilach]

22 hours ago, subtledoctor said:

EDIT - it would still be good to know why EET is setting the SPECIFIC value of party members anyway, since that still results in mod conflicts.

22 hours ago, subtledoctor said:

Not for party members. SoD uses those SPECIFIC values, but AFAIK it does not apply them to party members at the beginning of the campaign. Only EET does that.

20 hours ago, subtledoctor said:

I still don't know where EET's script is that does this to party members. This is something that needs to be undone, or prevented, and I don't have enough information to do so. Easy enough to fix the overlapping IDS entries, but messing with SPECIFIC values of party members is going to cause problems that other mods will need to deal with.

You assumed EET changes SPECIFICS in a way SoD doesn't and you never even gave a moment to doubt your own theory, even after we found out that Refinements has a bug with the way it extends the IDS. I've went through on an EET and a SoD game, comparing them, looking up all the scenarios where ALLIES is set and you always dismissed them without any constructive criticism.

Also, note that I didn't have a reproduction case. I was never affected because I never install the components which would introduce D5_NO_UMD. The only reason I decided to be involved was because I am trying to be helpful. I even assumed you know your own code and you're correct that this is outside your mod's scope which is why I concentrated on debugging on a clean version of the setups.

You accuse me being defensive, but guess what? These were how you responded to my debugging. If you only deny my references without actually pointing to a file to compare against, or any other information to roll with, I will perceive it dismissive. If you don't see the problem with your own tone, then I really shouldn't attempt to assist your problems.

Also, for the record, here is the commit where you introduced that script.

You owe me an apology. And until then, you're no longer welcome.

[jastey]

42 minutes ago, subtledoctor said:

NPC modders are inserting code relating to specifics into their mods - have any of them explained why? No.

"Because the game NPC also did this." For SoD, I went straight by the book, I mean examples in the game. I even mindlessly copied and added script actions like the specifics setting because that's how it's done for the original SoD NPCs. I don't know why it's in there and I didn't go deep enough to find out (after going pretty deep and writing tutorials about it.).

[Graion Dilach]

55 minutes ago, subtledoctor said:

I'm trying to understand this better so that I can make things work better for other people. You seem more interested in defending EET's honor in some weird way, than in helping

Also, for the record - just because you're not aware of it, I can still prove this wrong and even can showcase how I listen to your ramblings. At one point you said you're not trusting the megamods because their spells aren't added in a way to make it compatible with SR and IWDification. I heard you, realized you were right, filed https://github.com/SpellholdStudios/DSotSC/pull/23 and currently trying to fix SoS in https://github.com/SpellholdStudios/Shadows_over_Soubar/pull/26 (with CtB being the next one) to ensure this problem gets resolved in the actively maintained megamods atleast. That had nothing to do with EET, only with your random rants. I even consider trying to wrap my head around ClassSpellTool to have a library to parse it in a more mod-friendly way (partially for Tome & Blood and partially for Random Graion Tweaks).

Sure, when I play BG, I play EET, but that doesn't mean I only look at EET issues. I also am really slowly trying to recode sarevok57's IWDEE megamod into WeiDU (but I won't get anywhere with it until August I think). It is true that I wouldn't touch the classic engine with a ten-foot-long pole unless I have to and I do have a dismissive tone regarding it which I will acknowledge but I will not break legacy functionality intentionally when the project has it, as seen how I looked into a BG1UB bug.

[subtledoctor]

None of what you quoted has any bashing? So I honestly don’t understand where you are coming from, demanding apologies and such. Even in what *you* quoted, I was saying 1) there is a conflict here, and 2) I don’t have enough information to fix things. 

6 hours ago, Graion Dilach said:

here is the commit where you introduced that script.

It may be under my name - because I’m the only one who has bothered to amend Refinements. But it was donated by someone else. I would have no idea how to do that - I still don’t have much idea of what that does. I’ve never heard of the Switch() trigger, and even after I just looked it up on the IESDP I still don’t understand what it does. 

6 hours ago, Graion Dilach said:

You assumed EET changes SPECIFICS in a way SoD doesn't

No, I inferred that from the facts that 1) nobody ever reported any conflict like this with SoD alone, only with EET. And that 2) I have personally played SoD and in no place did it ever change the value of party members, whereas people in this thread seem to have suggested that it happened to party members. Those are relevant, and inferences from those facts might be wrong, but don’t be so shitty as to suggest such inferences are unreasonable, or assumptions. The inference that EET - a mod - does something particular during the campaign transition while importing two entire games into a third game, is completely reasonable. (And TBH I still haven’t heard and reasonable explanation if how this is happening to NPCs in the party.)

6 hours ago, Graion Dilach said:

I've went through on an EET and a SoD game, comparing them, looking up all the scenarios where ALLIES is set

Why didn’t you say that? Instead you’re all “bro, didn’t you even read BD1010.bcs??” Which, of course I didn’t look at that. I had no information suggesting that was relevant. And after I did look at that script, and finally got some more relevant information, you’re like “bro but why didn’t you even look at BD3000.bcs and BD4000.bcs??” Which, again, no I didn’t know to look at those either. Why drag that out? Why the attitude? If you’ve looked at all this stuff and have useful information why not just say it?? Even the code snippet you took from somewhere didn’t work, I ended up writing my own macro from scratch. You injected so much pissy attitude into this thread, compared to the little that was actually helpful. And then demanding apologies for imagined slights, like you’re some kind of prince and people owe you some kind of special deference. It’s maddening. 

6 hours ago, jastey said:

Because the game NPC also did this." For SoD, I went straight by the book, I mean examples in the game

Thanks, that’s good to know. I saw that, for instance, the Drake mod has special code for this, and I didn’t know if maybe there was some tutorial out there that is like “when adding NPCs to SoD you need to add scripted changes to specifics values, because X. Like, maybe there is information out there and I just didn’t know where to find it. I guess not, but thanks anyway. 

Edited July 13, 2022 by subtledoctor

[Graion Dilach]

4 hours ago, subtledoctor said:

I’ve never heard of the Switch() trigger, and even after I just looked it up on the IESDP I still don’t understand what it does.

https://en.wikipedia.org/wiki/Switch_statement The response values are matched against the integer value of the variable in question. If the variable is 0 then RESPONSE #0 is triggered, if 1 then RESPONSE #1, if 2 then RESPONSE #2 and so on. The documentation is indeed unclear if it allows to have a fallback case (usually referred as case: default) in BCS scripting, so it's safe to assume it doesn't.

4 hours ago, subtledoctor said:

(And TBH I still haven’t heard and reasonable explanation if how this is happening to NPCs in the party.)

That's caused by the DPLAYER2.BCS block your mod is patching. DPLAYER2.BCS runs constantly on every joined NPC in party as their default script. (DPLAYER3.BCS is the PC.)

4 hours ago, subtledoctor said:

Why didn’t you say that? Instead you’re all “bro, didn’t you even read BD1010.bcs??” Which, of course I didn’t look at that. I had no information suggesting that was relevant. And after I did look at that script, and finally got some more relevant information, you’re like “bro but why didn’t you even look at BD3000.bcs and BD4000.bcs??” Which, again, no I didn’t know to look at those either. Why drag that out? Why the attitude? If you’ve looked at all this stuff and have useful information why not just say it??

I did?

On 7/11/2022 at 7:59 PM, Graion Dilach said:

SoD uses ChangeSpecifics(ALLIES) in a lot of the NPC scripting(BD0101.BCS, BD3000.BCS and BD4000.BCS all sets this on all NPCs apparently as part of the camp transition). ALLIES is 10 in BGEE. However ALLIES doesn't exist in BG2EE and 10 is already used for CULTIST there. So EET looks at the first available index in SPECIFICS, which happens to be.... 2.

I thought I was straightforward enough and do not need formatting to point out that I was looking after the ChangeSpecifics(ALLIES) hits in NearInfinity because the 2 you perceived wrong was corresponding to ALLIES and so the query I've looked at to find out where that gets set (actually, I only searched for ChangeSpecifics to see how long an ALLIES is kept up if it's set once). Yes, I did overlooked the DPLAYER2 query your mod is patching back then (think I was only concentrating to the SoD scripts alone because I thought if the scope is in SoD then the SoD scripts have the answer).

Edited July 13, 2022 by Graion Dilach

[subtledoctor]

13 hours ago, Graion Dilach said:

DPLAYER2.BCS runs constantly on every joined NPC in party as their default script

See, I didn't even know that. (And, btw - Jesus, the things I could have accomplished if I had known that...!)

13 hours ago, Graion Dilach said:

I was only concentrating to the SoD scripts alone because I thought if the scope is in SoD then the SoD scripts have the answer

See, even if ultimately correct, I think this was a less reasonable inference than the one that it had to do with EET. Consider this thread is rife with statements like

• "This issue shows up again in BG2"
• "It seems to happen at chapter transitions"
• "I'm experiencing this, I've just transitioned from BG1 to SoD" (emphasis mine)
• "the problem starts the moment BG1 ends"
• "The only difference between these two screenshots is that [the normal one] is a new game with an imported save and [the problematic one] is from an EET save that's played through BG1 and SOD just waking up in Irenicus's dungeon." (emphasis mine)

Everything suggests that the problem was related to transitions from one campaign to another. And SoD and BG2EE don't have any transitions from one campaign to another. Only EET does. If people are saying it is in BG2 why focus on SoD?

At any rate it is fixed now, this thread can be put to bed.

Edited July 13, 2022 by subtledoctor

[DavidW]

SoD does have transitions between campaigns: the transition from the original BG1 campaign to the SoD campaign.

[subtledoctor]

28 minutes ago, DavidW said:

SoD does have transitions between campaigns: the transition from the original BG1 campaign to the SoD campaign.

Ah. My version does not - it contains only the SoD campaign. I guess that's what I was looking at.

Edited July 13, 2022 by subtledoctor

[DavidW]

I've never seen that - is it the iPad version or something? The standard SoD download includes all of BGEE. In fact, the campaign.2da machinery that EET uses was built for SoD.