Endarire Posted May 2, 2021 Share Posted May 2, 2021 @Caedwyr What was your verdict? Quote Link to comment
Caedwyr Posted July 17, 2021 Share Posted July 17, 2021 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. Quote Link to comment
Caedwyr Posted July 23, 2021 Share Posted July 23, 2021 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. Quote Link to comment
subtledoctor Posted July 27, 2021 Share Posted July 27, 2021 (edited) 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 Quote Link to comment
Caedwyr Posted July 27, 2021 Share Posted July 27, 2021 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. Quote Link to comment
Oloriniel Posted July 10, 2022 Share Posted July 10, 2022 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? Quote Link to comment
Graion Dilach Posted July 11, 2022 Share Posted July 11, 2022 (edited) 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 Quote Link to comment
jastey Posted July 11, 2022 Share Posted July 11, 2022 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? Quote Link to comment
Endarire Posted July 11, 2022 Share Posted July 11, 2022 Can you detect the problem and prevent or fix it in the mod as prudent? Quote Link to comment
Oloriniel Posted July 11, 2022 Share Posted July 11, 2022 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 Quote Link to comment
subtledoctor Posted July 11, 2022 Share Posted July 11, 2022 (edited) 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 Quote Link to comment
Graion Dilach Posted July 11, 2022 Share Posted July 11, 2022 (edited) 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 Quote Link to comment
jastey Posted July 11, 2022 Share Posted July 11, 2022 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. Quote Link to comment
Graion Dilach Posted July 11, 2022 Share Posted July 11, 2022 (edited) 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 Quote Link to comment
subtledoctor Posted July 11, 2022 Share Posted July 11, 2022 (edited) 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 Quote Link to comment
Recommended Posts
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.