CrevsDaak

Okay I figured the bug out, wasn't too hard, seems like Cornugons have an invalid animation value of -1 written to them. It also cries about water elementals but those are working fine, they just seem to be missing from animate.ids on my install, pretty odd. Attached hotfix appends water elementals' animation code to animate.ids and it gives cornugons the correct animation ID. c7-animfix.tp2

That's caused by a creature without a correct animation being summoned... If you can check which spells the mage there has, this is fairly easy to debug I think. Even better if you got to see the string of which spell got cast. Edit: missed this post. What'd the error say? It'd be very helpful to see the debug file for it, though it's only those two spells that had any EE opcodes in my install, so you should be good regardless.

Sure https://github.com/BGforgeNet/happy-ie Have in mind it's not complete I think, and very different from what my simple effects fixer does (in fact, it doesn't even offer that functionality AFAIK).

If you care you can just add a PATCH_PRINT in there (particularly if you're going to tell me what to do..... This means you know about it yourself right?). It doesn't matter what files have erroneous opcodes, you just want them out so you can play the game. And "not be relevant" is BS, any opcode > 318 WILL CRASH YOUR GAME and it *always* prints out that same CGameEffect.cpp error message. The fact that you ask somebody to post their graphics config is pointless and misleading, as it has absolutely nothing to do with this, and shows that you know nothing about this. I don't think that you understand what something called fxfix is supposed to do and does. It fixes effects. That's it. You can check out Magus' happy-ie for any other debugging needs you may have. It also only installs on the ToB engine, so it's pointless to check what game it's being ran on, all it does is fix effects, not debug other people's mods (since if they don't care to fix it, I'm just wasting my time, and if you care, you can edit the file, add PATCH_PRINT and find out!). The point of this tool is to provide users a non-time consuming, non-single-file-tinkering way of solving effect-related crashes, as it's very easy to do so, and lets you actually play the game. I would suggest that you stick to topics you are more knowledgeable on! You have to consider that because the Lich fear aura is built off copying Demon Fear, to fix this issue one would always require re-installing, and if any other mod added extra, valid effects to it you'd be deleting them, so overwriting the file is not generally a good idea.

for DavidW: the bug reported in this OP is the same as the one reported on this thread: It's just demon fear having like sixty EE opcodes for unexplained and mysterious reasons.

That's usually caused by leftover EE opcodes in this day and age (rarely anything has actually broken effects anymore). I've made a small mod/tool that removes all EE modifiers that are left over from mods in oBG2 installs. https://github.com/CrevsDaak/c7-fxfix Installing this will get rid of this particular type of crash. Have in mind another crash-inducing bug exists in current versions of SCS for oBG2. Specific fix for that one on that thread as well. You'll need to copy and paste an installer for other mods, those setup-*.exe files, and rename them into setup-c7-fxfix.exe etc.

You should go into the Fine-tune settings menu and manually set the components you want to their lower difficulties, and then set your game's difficulty to Core Rules, as I think that low game difficulty giving you those buffs is hardcoded behavior and partly why it's been implemented this way (the other one is double damage from Insane on oBG2 since there's no way to turn that off I think? Don't think ToBEx covers that but I might be misremembering it).

The issue with not being able to end the game due to a global variable bug is not known? Damn, I thought it must have been, so I never brought it up (when I got it and googled it, people on arcanecoast.ru (I think?) seemed to have had figured it out, and so I assumed that), otherwise I would've posted about it earlier, I apologize for not checking. Specifically, the issue I refer to is the following: a) not being able to travel to the Forest of Tethyr via the Pocket Plane after resolving the issue of Balthazar (doesn't matter how it is resolved) because dialogue with the Pocket Plane invisible creature never happens (itpplane.bcs just sends you back) b) AFTER traveling to the Forest of Tethyr, not being able to enter the final fight with Smellyssan Both issues are related to and caused by the fact that they check the global fin_balth_checkpoint_passed which is never set to 1, which is what gets checked. Instead, the dialogues with Balthazar et al sources of DMWWGroveRevealed, set that to 1 in order to allow the player to travel there. The check for fin_balth_checkpoint_passed==1 in ppguy01.dlg should be removed, and let that trigger be just DMWWGrove==2, as that's set once the player has already gone and talked to the heads in the grove, and it's already there. The check for fin_balth_checkpoint_passed==1 in itpplane.bcs should be changed for DMWWGroveRevealed==1 which is set once either Balthazar and the other two are dead, or once you talk him out of fighting you and kill the mage version of Smellyssan. Note that DMWWGrove and DMWWGroveRevealed are both handled perfectly, and simply changing this fixes all the related bugs (the two issues listed above) completely. Attached is a small fix that patches both files in order to remove fin_balth_checkpoint_passed in favour of the other variables. Edit: re: @Angel yes, this issue is specific to Ascension+Wheels (which is why it won't ever happen w/o Ascension). But it's entirely caused by something Wheels modifies (which is sending you back to the Grove), while also leaving that variable from Ascension in the Pocket Plane checks. Just changing those two files as I've done (though it isn't robust enough for actual deployment I think) is enough to fix this issue. c7-fixwheels.tp2

Yeah, my bad, param1 is called Value on NI, and param2 is Modifier type. I was going off the IESDP names, oops.

Add an effect on him (Save -> pick a save -> baldur.gam -> select Wilson on the panel on the top right, go to the Edit tab on his menu, scroll down and double click on the last line, then go to the Edit tab of that new window, hit Add button at the bottom -> Effect), set opcode to 126, target to 1, timing mode to 9 (important, otherwise he'll lose it on death), and then set param1 (stat modifier) to 8, or higher if you want (I'd personally go with 10 so he isn't slower than other party members), param2 (type) to 1. I think probability 1 is naturally set to 100, but if it isn't, set that too.

On line 329 of stratagems/ssl/library.slb, TARGET=Celestials is defined, but in line 330, its sole corresponding potential target object, is the malformed object identifier [GOODCUTOFF.0.0.0.182] which refers to an index not present in specific.ids (however it could be added, in order to detect celestials, but this is not done). While this most likely does nothing in the EEs, it makes oBG2 crash with a "ASSERTION FAILED! Return Address: 0x940CB5 File: ObjCreatureAI.cpp Line: 19722" message. Fixing it by adding a custom 182 - CELESTIAL identifier number to specific.ids is probably ideal, can also be fixed in other non-intended ways. Attached is a hotfix that will fix this issue by appending to specific.ids and assigning the value to celestials' creature files. c7fixcelestialspecific.tp2

Forgot to mention the important part: the bug described in the OP is in fact fixed, however the bug with Liches (and Demon Fear) is different, and rather new, however I wouldn't be able to point out exactly when it was introduced.

Note that this bug only occurs because of out-of-bounds opcodes being present in several spells modified by SCS or other mods (for example, Demon Fear and, as a consequence of being a direct copy of it, Liches' Fear aura). As a hotfix you can just install the attached mod (put the .tp2 file on the folder with the chitin.key, rename some setup-*.exe into setup-c7obg2spellfixer.exe and run that), all it does is patch out the opcodes that would cause your game to crash. If this doesn't fix your crashes, start by posting your WeiDU.log, doing a --change-log on the liches and etc etc. Also you might crash on the Yaga-Shura Lt.s since those haven't been fixed in the latest version of SCS either sadly. c7obg2spellfixer.tp2

Same old github repo as it was before. Angel's fix is already in too, just forgot to post anywhere about it.

Just off looking at that image, you're using some variant of this " character instead of the regular one WeiDU expects, just change the slightly tilted ones for the ones you have below on the language strings and you should be good.

Pretty sure aTweaks uses AddAreaType() to add a custom flag to Strongholds (and I think Inns as well, unsure, but that's just patched in at install time) for it's own Scribe Scrolls component, which ToF has outdated via sheer mechanical advantages, but it'd be cool if it could be limited to those zones as well. As for rations, strongholds should definitely restore them, and it would be nice if one could obtain access to something like the Create Food and Water or the P&P version of Goodberries (though that one requires recently picked berries I think, not something you'd find out and about anywhere...) as well, in order to let the player solve the issue that way if they so prefer (which would revert the rest situation back to vanilla rest spamming but if you get interrupted enough times it'd have much bigger consequences. And you still have to cast the spell and use up a spell slot every fifth rest or so).

Happens to me with Imoen right after she wakes you up in Chateau Irenicus. I had it happen once before changing her class to Thief and kit to Swashbuckler. Then it worked once, but after I dual-classed to Mage, I had a certain mage level in which I was unable to select any proficiencies (though I had many already allocated due to the revised profs component I believe), and ever since I haven't been able to get her to get past the 32 profs issue somehow, despite it having worked once for her Thief levels. WeiDU.log

Big disclaimer: this issue ONLY applies to vBG2 with ToBEx with Casting Fixes disabled. Toggling it off is sadly necessary to run the game on wine, since that ToBEx option causes the game to crash whenever a spell is cast otherwise (note that it does not occur under actual Windows). Now, there is no need for this fix outside of this very specific situation which happens to me, as this bug does not occur normally, since it IS fixed by setting Casting Fixes=1 on the ToBEx ini files. So, with that said, the issue is caused by opcode 232 (cast spell on condition) being applied infinitely when the game is paused on the same tick that it is applied in. I'm not sure if it occurs when other conditions aside from 8 - PersonalSpaceDistance('Target',4) are set, but that's exactly what's breaking here so, yeah... You'd imagine this happens very rarely but in my experience not only it is extremely easy to replicate but also will permanently kill off your party members constantly, as it happens very often on regular play due to so many SCS Clerics using the spell or any of its variants. The way I got around fixing this is not the most convenient, it uses multiple delayed applications of opcode 146 (cast spell on creature) in order to simulate the per-round application of the effect upon nearby creatures that opcode 232 caused, and only works because of the party-friendly AoE projectile from sppr603d,spl (the secondary spell Blade Barrier uses to apply its damage). If that causes any bugs or differing behavior, well... It's probably minor compared to how bad this bug was. Amelyssan's Blade Barrier from Ascension, Globe of Blades and Circle of Bones are all patched if found, together with their respective SCS pre-buff variants. Hopefully this is of some use to anyone else. I coded it for my own use and for whatever fun I had wrangling with Circles of Bones, but it's a "common enough" bug under these odd conditions that I thought I'd share it. You can find this fix on its own github repo.

Huh, checking on my ToF bg2ee install, this issue remains, though, what I assume happens is that the EE corrects the value and appropriately applies the effect despite the mismatch on the Type field's possible values. Otherwise this would have not gone unreported for so long. weidu.exe --change-log yaga02.cre [weidu.exe] WeiDU version 24900 [.\chitin.key] 191 BIFFs, 62570 resources [.\lang\en_us\dialog.tlk] 109272 string entries [ascension/lang/english/setup.tra] has 32 translation strings [stratagems/lang/english/setup.tra] has 262 translation strings Mods affecting YAGA02.CRE: 00000: /* created or unbiffed */ ~ASCENSION/ASCENSION.TP2~ 0 1500 // Tougher Yaga-Shura2.0.26 00001: ~STRATAGEMS/SETUP-STRATAGEMS.TP2~ 0 5900 // Initialise AI components (required for all tactical and AI components)35.4 00002: ~STRATAGEMS/SETUP-STRATAGEMS.TP2~ 0 6030 // Smarter Mages35.4 00003: ~STRATAGEMS/SETUP-STRATAGEMS.TP2~ 0 6100 // Potions for NPCs35.4 00004: ~STRATAGEMS/SETUP-STRATAGEMS.TP2~ 0 6820 // Smarter Yaga-Shura35.4 Opcode 30 in particular seems to be currently being added by line 27 on stratagems/ascencion/yagashura.tpa (snippet also includes lines 26 & 28), MAKE_PATCH add_effect_inline=>~opcode=>30 target=>1 power=>4 parameter1=>100 duration=>600 resist_dispel=>1~ END which is puzzling because there's no reason for Param2 to be set to 4 instead of the Power field being modified. Timing is also off, as it's dispellable and has a duration, but it's set to 9 (insta & perma). I suppose fixing it is pretty easy though, just add a value for parameter2 that's within the game's value range, unsure if the duration or dispellability should work like that (persoanlly I would give them natural 100% fire res so Yaga-Shura himself doesn't fry them w/his Ascension abilities. In case that's even party unfriendly... I don't remember if it hits them or not).

Param2 on opcode 30 is the Type field, dictates how the Fire resistance is applied (additive, set to a value, percentage of existing). Should always be within [0-2].

Line 21 on the patch, yes, will be on line 91 if applied. It's this line: m.ab_fx.add{s_opcode=172 s_resource:="%spl_cancel_scribing%" s_timing=4 s_duration=60 s_target=1} // remove the cancel ability after 60s I've also noticed that XP_PLACEHOLDER isn't properly replaced (unsure why, the code is there) and will show up upon Scribe Scrolls being used instead of the correct amount of XP.

That's partly correct, as the engine will always choose the highest required level ability header at the time of the spell being cast, but the targeting is set in place by what the player originally chose, which is limited by what the engine considers the spell's possible targets to be, which is not checked when the spell cast action is queued, because the engine does not know what specific header to use for the effects yet (seems like the level check is performed once the spell starts being casted) and thus is not able to detect what to target solely off the required level if the specific header has not been cast yet. Casting the healing spell on a secondary target forces stats from one header (casting time, targeting), the one chosen by the player's choice of target at the time of commanding the action, to be used in conjunction with the effects the other, higher level one, because the header choice is partly carried out when the spell is targeted, and then the effects applied are from the one with the correct required level because the engine could already determine that. This only seems to cause issues with spells that have differing targets allowed at different required levels (which is why it hasn't been encountered until now), though I suppose it might also happen with casting speed and range. That's a pretty good idea, I didn't know that would work either since I assumed the stat check was performed on the target itself, but it's actually checking on its own target, and then applying the effects to the target inherited from the parent ability header. It's actually really nice that it works this way because this allows for really crazy stuff to be done (and fixes both bugs). I'm glad I could help, thanks for putting this mod together, I've been enjoying it a lot. Also, the single-line fix to removing the Cancel Scribe Scrolls ability fixes another, different bug, which is that if you rest after hitting Scribe Scrolls without doing anything, it's still there permanently (or, if you use it, gives you more uses of Scribe Scrolls). Very minor but it polishes how well it already works.

Okay, I actually fixed both bugs, took me a while to get the SFO syntax right, but here it is. What I ended up doing is: Changed the minimal and casting level boost for Scribe Scrolls to 195. Changed the minimal and casting level boost for Empowered Healing 1 to 65, scaling further as the level requirement of healing spells go up. Changed the minimal and casting level boost for Empowered Healing 2 to 130, scaling further as the level requirement of healing spells go up. Made it so the Cancel Scribe Scrolls ability is removed after 60s via opcode 172. The scaling changes to the level requirement on healing spells fixes the maximum healing amount bug. Now a lv8 caster will heal 35hp instead of 45 with Cure Medium Wounds. The changes to the number of levels boosted and required to trigger the effects fix the bug noted in the OP. Note that all changes are required to accommodate for very high player levels. Mostly just number changes on a lot of specific lines except for the three extra lines adding in the scaling and removing the Cancel Scribe Scrolls ability after some time. The numbers 65, 130 and 195 I chose because there's a good number of levels before each breakpoint can be reached in-game using regular caster level bonus, meaning it shouldn't ever break as long as nothing gives more than 10 bonus caster levels to a lv50 character. Hope this helps! empowered_healing.patch item_crafting.patch

OK, I am pretty confident I've figured out what's causing this, it's the level boost that's required to trigger Scribe Scrolls, but at the same time used to discern which tier of Empowered Healing to apply. The way I would fix Scribe Scrolls being triggered by any healing spell because of Empowered Healing is by changing the behaviour of how it is triggered, since if the spell ability that generates the scroll itself was to be put onto an external spell that went through opcode 326 via a particular spell state set by the innate Scribe Scrolls ability itself (same thing Empowered Healing does), then it would never trigger upon healing spells being cast, however, you'd be adding as many new spells as the game already has spells, which is not ideal. However, I do not have any better ideas. Doing this still conflicts with Empowered Healing so it's pointless. And, on top of that, if a level boost is applied upon casting healing spells AT ALL, and nothing is changed, the maximum value for the post-boost level is used, which ends up giving a bigger heal at low levels (Cure Medium Wounds for example heals for 45 hp due to the base 15, plus 15 per level, times 1.5, while for example, at (real) caster level 8 it should heal for 35 instead). One way of fixing this would be to add the required caster levels of the Empowered Healing variants to the spell ability headers of those triggered spells, meaning that, for example, sppr103d.spl would have its minimum casting levels raised to 201, 202, 203 etc instead of just 1, 2, 3 which just make the game use the maximum bonus for healing at the lowest level you can cast the spell at. Because there would be no overlap with Scribe Scrolls, I would also suggest making it so that lower required levels are used, since lv50 characters with bonus caster levels from other sources could end up hitting above 255 and thus the spell would have no effect. 75 and 175 would never overlap nor hit 255 for example. Edit: this post is largely outdated, just leaving it up here for uhh the purpose of historical records...

Only installed the additional spells, spell tweaks, feats and NPC management, and the bug is pretty easy to reproduce though I have very little idea as to what triggers or causes it (reused splstat.ids values is my sole theory and it's only because Empowered Healing uses that). The bug consists of, after a cleric has chosen Empowered Healing, after casting any healing spell once, if any other spell is casted afterwards, the effects of having used Scribe Scrolls are applied (though not properly). Further testing on an install with ONLY the feats system installed reveals that this still occurs, with Empowered Healing causing the Scribe Scrolls effect to occur after the first cast of any healing spell, leading the second spell to fail, and, if a third spell is cast, that spell targets the caster automatically yet still fails, but it is interesting that it changes the targeting behaviour. Image and logs attached for the sake of it, don't think there is much point given how easily replicable this bug is. WeiDU.log WeiDU.log