Mages Can't Use Scrolls

[Endarire]

@Caedwyr
What was your verdict?

[Caedwyr]

Changing Specifics from 2 to 0 fixes the problem.  I had to use Near Infinity, since I couldn't find that parameter in EEKeeper.  Also, at points in Siege of Dragonspear, it got reset to 2 and I had to go back in and edit things back to 0 to fix the item usability restrictions, mostly on wands and scrolls.

[Caedwyr]

This issue shows up again in BG2, but I have been able to fix it by setting Specifics to 0 from 2 for the affected NPCs.

[subtledoctor]

Are you saying that the games us messing with party members’ SPECIFIC values??

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

Edited July 27, 2021 by subtledoctor

[Caedwyr]

It seems to happen at chapter transitions.  At a minimum it happened when I went from BG1 to Siege of Dragonspear and again when I went from Siege of Dragonspear to BG2.  I also know it happened at least one other time during Siege of Dragonspear, though it may have happened after the Siege of Dragonspear prologue ended, since I just lived with the issue for most of the expansion.

Spoilers, but going from Chateau Irenicus to the first chapter of BG2 I do not know if the issue is still there, since the character it was happening to (Imoen) leaves the party.

[Oloriniel]

I"m experiencing this, I've just transitioned from BG1 to SoD, and Brandock can no longer scribe scrolls or use mage wands.
Also, Recorder has never been able to scribe scrolls even in BG1, but perhaps that's something borked with her kit (my main is a bard and has no problem with scrolls), and not chapter related.

Where in NI can I find the "specific" variable to change to 0 to fix this?

[Graion Dilach]

I've got the example using IWDEE, but the process is the same.

I'll take a look into this, though. A similar issue Andrea C. reported at one point was that SoD's reinitialization sequence reverted the BG1 sprites in the Nostalgia mod and it might be the same resource triggering this as well.

Edited July 11, 2022 by Graion Dilach

[jastey]

12 hours ago, Oloriniel said:

and Brandock can no longer scribe scrolls or use mage wands

I mean, he goes through one (two, several) crisis but that's a bit too much even for him. ^^ Thanks @Graion Dilach for the fix.

This is nohing I can prevent on the NPC mod's end, is it?

[Endarire]

Can you detect the problem and prevent or fix it in the mod as prudent?

[Oloriniel]

Thank you, Graion Dilach, the screenshot is awesome and the fix worked just fine.  (And I'm reminded that I need your tweak for my next run, so I don't have to console in Davaeorn's key

[subtledoctor]

This is super annoying. And presumably about to hit me when my current EET game transitions to the SoD campaign. 

Does anyone know what part of EET is changing player characters’ SPECIFIC value? (And why?) Is it in a script somewhere?

Here's a thought/theory: this happens with the transition from BG1 to SoD, correct? Well, I noticed that in the course of importing BGEE resources into the BG2EE game, EET copies the BGEE version of SPECIFIC.IDS (among a lot of other things). So maybe EET is reading the BGEE version of that table, and using it in some way for party members as they leave the BG1 campaign?

In my current EET install, a SPECIFIC value of 2 represents the NO_UMD value - it prevents characters from using scrolls and wands. (This is from my own mod.) My mod registers that in SPECIFIC.IDS - it appends the value to the first empty value in that IDS table, which happens to be 2. But when that mod is installed, it is installed in BG2EE, so it appends to the BG2EE version of SPECIFIC.IDS. In the BGEE version of that table, there are no entries with a value of 2. So maybe, for some reason, EET is scanning the BGEE table and sees that there is no entry with a value of 2, and therefore thinks that it it safe to use that value with party members?

Now, if that supposition is correct, it is bad practice on the part of EET. If EET is going to use a SPECIFIC value, then it should be appending to the table so everyone else can see that value is used. Ideally it should be searching for the first empty value and using whatever that it, like my mod does. My BG2EE game has about 200 empty entries, so there is plenty of room for various mods to work together in this regard. (Well, sort of - messing with SPECIFIC values on a game-wide basis is going to cause some issues no matter what.)

But I'm not interested in casting blame, only in finding out how exactly this is happening. Then we could pretty easily make a hotfix for compatibility, and I could change my mods to avoid the conflict. But right now I don't know how to do that. I don't see any obvious references to SPECIFIC values in EET's code, and I'm not familiar with which scripts run during the transition to SoD. (And my game has both Endless BG1 and Transitions installed, so the transition could be a bit more complex than a straight EET install.)

Edited July 11, 2022 by subtledoctor

[Graion Dilach]

1 hour ago, subtledoctor said:

If EET is going to use a SPECIFIC value, then it should be appending to the table so everyone else can see that value is used. Ideally it should be searching for the first empty value and using whatever that it, like my mod does.

This is what's happening during the mod import and apparently another mod ignores this.

What EET does is that it tries to copy over all the SoD SPECIFIC.IDS values, unless the IDS value is already in use... and if that happens, it remaps SoD to the first available entry.

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.

Hell, this is how my SPECIFIC.IDS looks like after an EET import and before any other mod touching it:

5
1 NORMAL  
101 MAGIC
102 NO_MAGIC
12 SHARRAN
64 SHOU_MONK
65 SHOU_FLAYER
66 QUADIM_SPIDER
10 CULTIST
67 CULAK_SPIDER
250 SPIRIT
150 WATER_DWELLING
0 NONE
5 UNDERDARK
9 THIEF
2 ALLIES
11 ALLIES2
3 ALLIES3
15 ALLIES_NEUTRAL
16 ALLIES_NEUTRAL2
17 FIEND
18 ORC
19 NEUTRALS
20 HOSTILES
4 CRUSADERS
21 HOSTILES2
22 HOSTILES3
23 HOSTILES4
24 IRON_THRONE
30 SPAWN
40 DARK_MOON
50 SLAYER
60 FIEND_SUMMONED
6 SORCERER
77 CULT2
127 PRIEST
7 UNDEAD
160 BEETLE
161 SACRIFICE
183 DROW
201 AUTINN_CREW
202 LUCILLA_CREW
203 GOOD_DRUID
204 DARK_DRUID
205 PETRIFIED
251 SPECTACLES_QUEST

Do note that even ALLIES3 also happens to be a victim of this - it's 12 in SoD which conflicts with SHARRAN so it's migrated to 3.

It sounds to me that a mod which claims EET compatibility mindless claims the 2 SPECIFICS value without checking against it. I don't know which mod does it (I'm not playing with Refinements) but I went through my own EET megamod installs at hand and all use 2 as ALLIES without an overlap.

Edited July 11, 2022 by Graion Dilach

[jastey]

Again, if this is anything that could be addressed or even caused by any of my mods let me know. I don't understand half of what you are discussing.

[Graion Dilach]

There's a can of worms here anyway, because atleast BDSHOUT.BCS pulls in neutral characters to assist in a fight and uses a lot of SPECIFICS values as filter against it - one of them happens to be ALLIES. If a mod changes this, it can lead to joinable NPCs turning enemy in some scenarios.

EDIT: And, just for @jastey - this is not caused by your mods. I've looked at Brandock and it actually proves that a followup mod overwrote EET's ALLIES mapping in SPECIFICS - Brandock also sets it's SPECIFIC to ALLIES.

What happens here:

EET imports ALLIES as 2 in SPECIFICS.IDS and updates all scripts.
Brandock follows the setup and reuses the value.
Another mod comes in and somehow frees out the value from SPECIFICS.IDS.
Refinements comes in, detects 2 as free and claims it for NO_UMD.

Since no mod touches the SoD scripts, all these scripts end up using NO_UMD for ALLIES, leading to the current issue.

EDIT2: That other mod... is Refinements.

Installing Refinements on top of EET leads to...

5
1 NORMAL  
101 MAGIC
2 D5_NO_UMD
102 NO_MAGIC
12 SHARRAN
64 SHOU_MONK
65 SHOU_FLAYER
66 QUADIM_SPIDER
10 CULTIST
67 CULAK_SPIDER
250 SPIRIT
150 WATER_DWELLING
0 NONE
5 UNDERDARK
9 THIEF
2 ALLIES
11 ALLIES2
3 ALLIES3
15 ALLIES_NEUTRAL
16 ALLIES_NEUTRAL2
17 FIEND
18 ORC
19 NEUTRALS
20 HOSTILES
4 CRUSADERS
21 HOSTILES2
22 HOSTILES3
23 HOSTILES4
24 IRON_THRONE
30 SPAWN
40 DARK_MOON
50 SLAYER
60 FIEND_SUMMONED
6 SORCERER
77 CULT2
127 PRIEST
7 UNDEAD
160 BEETLE
161 SACRIFICE
183 DROW
201 AUTINN_CREW
202 LUCILLA_CREW
203 GOOD_DRUID
204 DARK_DRUID
205 PETRIFIED
251 SPECTACLES_QUEST

@subtledoctor  You're welcome.

Edited July 11, 2022 by Graion Dilach

[subtledoctor]

1 hour ago, Graion Dilach said:

It sounds to me that a mod which claims EET compatibility mindless claims the 2 SPECIFICS value without checking against it.

No, it is designed to check against the current table and find the lowest unused value. Admittedly my mod uses a macro that I didn't write, I inherited it from... Ardanis, maybe? God, I forget now. But I've been using a version of this macro for years and years, and never had a conflict with it before now. I adapted it to append entries to SPLSTATE.IDS as well and that one gets a lot of use, and that version has never had a problem either.

Looking again, however, it seems like my EET game in fact does have two entries with a value of 2 in SPECIFIC.IDS. So this macro has failed to avoid doubling up. If anyone wants to look at it and suggest fixes, I would be more than happy to update my mods.

Spoiler

//GENERATE NEW SPECIFICS MACRO_________________________________________________________
//
DEFINE_ACTION_FUNCTION d5_resolve_specific INT_VAR index=0 delete=0 STR_VAR new_specific_id = ~blah~ RET new_specific_ind BEGIN
 OUTER_SET min_new=1
 COPY_EXISTING ~specific.ids~ override
  new_specific_ind=0
  found=0
  READ_2DA_ENTRIES_NOW stats 2
  FOR (row=1;row<stats;row+=1) BEGIN
    READ_2DA_ENTRY_FORMER stats row 0 ind
    READ_2DA_ENTRY_FORMER stats row 1 str
    SET $stat("%row%") = ind
    PATCH_IF index BEGIN
      PATCH_IF ind=index BEGIN
        REMOVE_2DA_ROW row 2
        found=1
        PATCH_IF delete=0 BEGIN
          INSERT_2DA_ROW row 2 ~%index% %new_specific_id%~
        END
        row=stats
      END
    END ELSE BEGIN
      PATCH_IF ~%str%~ STRING_EQUAL_CASE ~%new_specific_id%~ BEGIN
        new_specific_ind=ind
        found=1
     /* row=stats */ // don't stop looking, the same ID may be assigned to a greater index, which takes priority when compiling
      END
    END
   END
   PATCH_IF found=0 BEGIN
    new_specific_ind=min_new
    PHP_EACH stat AS row => ind BEGIN
      PATCH_IF found=0 && (row+1 < stats) BEGIN // not at the end of file
        next_row = row+1
        next_ind = EVAL $stat("%next_row%")
        PATCH_IF index BEGIN
          PATCH_IF index<next_ind && index>ind BEGIN
            INSERT_2DA_ROW next_row 2 ~%index% %new_specific_id%~
            found=1
          END
        END ELSE BEGIN
          PATCH_IF new_specific_ind<next_ind BEGIN
            PATCH_IF ind<new_specific_ind BEGIN
              INSERT_2DA_ROW next_row 2 ~%new_specific_ind% %new_specific_id%~
              found=1
            END ELSE BEGIN
              new_specific_ind+=1
              PATCH_IF new_specific_ind<next_ind BEGIN
                INSERT_2DA_ROW next_row 2 ~%new_specific_ind% %new_specific_id%~
                found=1
              END
            END
          END
        END
      END ELSE BEGIN // at the end of file
        PATCH_IF found=0 BEGIN
          PATCH_IF index BEGIN
            INSERT_2DA_ROW stats 2 ~%index% %new_specific_id%~
          END ELSE BEGIN
            PATCH_IF new_specific_ind>ind BEGIN
              INSERT_2DA_ROW stats 2 ~%new_specific_ind% %new_specific_id%~
            END ELSE BEGIN
              new_specific_ind+=1
              INSERT_2DA_ROW stats 2 ~%new_specific_ind% %new_specific_id%~
            END
          END
        END
      END
    END // PHP_EACH
  END
END

Off the top of my head, maybe it's related to the fact that my SPECIFIC.IDS table after EET is installed is all jumbled and out of order? Maybe this macro assumes the table is ordered according to value? (I thought I've seen it handle out-of-order values... but clearly there is a problem here.)

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.

Edited July 11, 2022 by subtledoctor