Bubb

The crash is a divide-by-zero in Delay(). The condition is pretty unreliable because two events need to line up for it to fire: the Delay() trigger needs to return true at the same time the contingency is checked, (every 101 ticks). As lynx says Yes That's the fun part — you can't. Extra acting as both flags and parameters for some Condition values is annoying. op177 is crazy in that it doesn't "add" the EFF to the creature, it merely wraps / executes it. So that's why op232 doesn't get removed when you apply it via op177, though there's still no way to stop the string from firing. strrefs [0xF00000-0xF00537] index into enginest.2da, with the row being strref - 0xF00000. So, 0xF000F6 => row 246 => STRREF_GUI_FEEDBACK_CONTINGENCY_TRIGGER Effect source = the creature that cast the spell Effect host = the creature the effect is attached to Yes

Corrections: Parameter #1: Target: 2 => NearestEnemyOf() *which evaluates as [EVILCUTOFF] 3+ => [ANYONE] Parameter #2: Condition: 1 => See(NearestEnemyOf()) *which evaluates as See([EVILCUTOFF]) 8 => PersonalSpaceDistance([ANYONE],4) 9 => PersonalSpaceDistance([ANYONE],10) 10 => Delay(Extra) 13 => TimeOfDay(Extra) 14 => PersonalSpaceDistance([ANYONE],Extra) 15 => StateCheck(Myself,Extra) 16 => Die() Additional flags: Special: Extra: [Condition = 0] && [Extra | 1] => Trigger even if the effect host was the source of the hit [Extra | 1] => When triggered, display strref 0xF000F6 ("A contingency spell has been triggered") as effect host and remove effect [Extra | 2] => Fire subspell as effect source instead of effect host [Extra | 4] => Suppress subspell casting glow and string [Extra | 8] => Suppress subspell range check Misc notes: 1) [param3 != 0] acts as if [Extra | 1] was specified, (and maintains the portrait icon) 2) New to v2.6, when: Starting Spell() And the resref being cast (first 7 letters) is a parent resource of an active op232 effect on the caster And the active op232 originated from op234 [param2=0/1] or was defined with [Extra | 1] or [param3 != 0] => Remove the active op232, (only remove one instance, even if more would have met the above)

The animation INIs could use a good cleaning — many of them ended up with dead fields / the wrong fields all together. Not really important from a bug-fixing perspective, (if the fields are incorrect the engine falls back to hardcoded defaults), though it would make working with them easier.

I ask because some people have fought me on this, saying that it's like that in PnP. I agree that it seems silly from a gameplay perspective, but I don't know what the intent was, (or if that PnP claim is true).

Here's something that's up for debate, quoting past me: Bug(?): Should backstabs (which invert a creature's AC Dex modifier) make a creature with a Dex penalty harder to hit?

TriggerOverride() is just a compiler-shortcut for NextTriggerObject() + WhateverTrigger(), so it really doesn't matter whether you write it out or use the shortcut. It's convenient shorthand, but it still suffers from the same bugs. But yes, since NextTriggerObject() isn't intended to be a standalone trigger, it's probably safer to use TriggerOverride().

Both Balquo and Galactygon say this is a bug: https://forums.beamdog.com/discussion/comment/1169333/#Comment_1169333

Quoting past me regarding NextTriggerObject() and how it breaks the trigger block it is in if it evaluates to an invalid creature:

To quote the IESDP, here's another bug with event triggers, (they really are the worst):

Right, that's the intended formula, (with CHECK_MODE=1, Luck=0). The IESDP description I quoted is the observed behavior of the engine, not the intended behavior. I left out this note from the IESDP which I probably should of kept, I'll edit it in: Inverting the last condition in the psedocode, (changing the > to <), aligns the behavior with ToBEx. EDIT — Ok, I've finished editing my previous post. Let me know if it still needs work.

The IESDP lists the following behavior for CONCENTR.2DA's CHECK_MODE: And here's some reversed pseudocode from the engine backing that up: The final condition is flipped — the behavior should be the following, based on TobEx: Do NOT disrupt if (1d20 - 1) + (Luck or Constitution/2) >= (Spell Level) + (Damage Taken or 15) not Disrupt if (1d20 - 1) + (Luck or Constitution/2) > (Spell Level) + (Damage Taken or 15) I.E. A greater Roll/Luck/Constitution should decrease the chance of disruption, not increase it.

Casters can't be disrupted by damage if they are facing SSW(1), SWW(3), NWW(5), NNW(7), NNE(9), NEE(11), SEE(13), or SSE(15). This happens because the disruption code is only checked if the caster is in the correct orientation to face the target. SEQ_DAMAGE rounds a creature's orientation down to the nearest even direction, causing the caster to momentarily not face the target, making the check fail. Here's an example:

Here's one I had fixed in old-EEex: Event triggers (IDS < 0x4000) "lock on" to a specific creature when using standard objects. For example: IF Global("B3TEST","GLOBAL",1) AttackedBy(PartySlot1,DEFAULT) THEN RESPONSE #100 DisplayStringHead(Myself,1) // No, I'm sorry, none of them sound familiar. END The AttackedBy() will only return true for whoever the party leader was during its first evaluation, even if you change the party order.

That happens because the engine checks if the creature hiding can see any enemies, not if any enemies can see the creature. An exe patch could approximate a fix by changing that check to use the default range of 14, (instead of the current visual range, which is 2 when blinded).

Yes, there's been a regression. op206's string is now bound by: if (!pEffect->m_sourceRes.IsValid() || (pImmunitySpell->m_error != 0xf00074 && pImmunitySpell->m_error != 0xf00080)) { uint nNewFeedback = 0xffffffff; if (pImmunitySpell->m_error == 0xf00074) { nNewFeedback = 0xf00073; } pImmunitySpell->m_error = nNewFeedback; } Basically, the strref has to be 0xF00074 or 0xF00080 for the engine to display it.

For CGameAnimationTypeMonsterQuadrant (0x1000-0x11FF), the engine disables shadows if: extend_direction == 0 && extend_direction_test != 8 It does this by setting the shadow rgb at palette index (1) to 0x0 (if false_color == 0) or 0xFF00 (if false_color != 0). Looks like the animation renders correctly if you set extend_direction_test=8, so maybe that's a way to enable the shadow?

AR4000 is hardcoded into the action that upgrades SoA to ToB, (MoveToExpansion). MoveToExpansion() is always called when entering ToB — if you're starting from SoA a script calls MoveToExpansion(), and if you're starting a new game the engine evaluates STARTARE.2DA, then runs MoveToExpansion(), (that's why you get the glitchy Elthan dialog). While hacky, your only option might be to have AR4000.BCS move the party somewhere else.

What exactly are you trying to do? The configurable UI hotkeys are defined in BGEE.LUA by the keybindings table, though the ordinals all have hardcoded meanings and aren't really customizable. Basic custom hotkeys can be defined in UI.MENU by (ab)using a new menu definition. For example, add: menu { name 'B3_HOTKEYS' ignoreEsc label { on M action " Infinity_DisplayString('Hello from B3_HOTKEYS!') " } } and edit the 'START' menu's onOpen to push 'B3_HOTKEYS', (something like): menu { name 'START' align center center ignoreesc onOpen " Infinity_PushMenu('B3_HOTKEYS') What this does is add an invisible, non-closable menu that listens for the "M" key to be pressed, running whatever Lua code is in the label's action. The Lua environment has very little functionality to interact with the game engine though, so depending on what you want to do, it's probably impossible.

EEex isn't needed; pretty sure a standard UI mod could display the bag in a sorted order.

If it helps any, scraping EE v2.6 results in the following section->key entries. I've left out some sections that the engine dynamically reads from since they aren't very interesting. Some of these keys are probably non-functional:

The v2.0 keybinding system relies on spell tooltips. Apparently quicksave isn't properly handled and falls down into the spell keybindings code. It ends up searching the spell list for an empty tooltip, and since the internal innate abilities you add have a blank strref assigned, it matches and casts.

No, I meant what I posted. EEex versions >= v0.9.0-alpha are for EE v2.6. The transition to a 64bit executable forced EEex to change significantly, which broke backwards compatibility with mods. So, if you want to play High Powers, which was designed for the "old" EEex, you have to downgrade to EE v2.5 and use the EEex version that goes along with it, as I linked.

0x410f is an EEex trigger — EEex_IsImmuneToOpcode(O:Object*,I:Opcode*) High Power Baldur's Gate requires EEex and will only work using: 1) Windows 2) EE v2.5 3) EEex v0.8.7-alpha

Via the power of the Wayback Machine, here are the links to the thread's attachments: https://us.v-cdn.net/5019558/uploads/editor/br/96zoon5rgt6w.rar https://us.v-cdn.net/5019558/uploads/editor/kr/qytbc6bm4cai.rar

I'm not sure exactly what caused it, but I think Skie got interrupted executing: EscapeAreaMove("AR0700",3325,1240,SSW) (this is from a dialog) The engine uses opcode 186 to actually move the creature, and that effect got saved on her CRE entry in the SAV. On load the engine processes this opcode before the game has been fully initialized and it crashes. Edit: Or something like that; iirc when Skie attempts to move it crashes because she's not internally assigned to an area.