kjeron

Are you reading the identified name or unidentified name? UNID name of most rings is just "Ring", whereas Joia's Flamedance Ring is both the ID and UNID name.

244 SaveLocation(S:Area*,S:Global*,P:Point*) 245 SaveObjectLocation(S:Area*,S:Global*,O:Object*) 246 CreateCreatureAtLocation(S:GLOBAL*,S:Area*,S:ResRef*) 297 MoveToSavedLocation(S:GLOBAL*,S:Area*) 0x40E4 NearSavedLocation(O:Object*,S:Global*,I:Range*)

It affects abilities that target the creature op219 is attached to, if the abilities source matches the IDS values specified in op219. Think of it as a combination of opcode 0's specific AC modifiers (crush/slash/pierce/missile) and op346 (save vs. Spell school). Except that it specifies an IDS value, rather than a damage type or spell school, and has a fixed bonus (2).

Luck affects the d10 modifier applied when using the skill.

Since the creature stat cannot be negative, the amount provided by Race and Dexterity is an effective minimum.

That feedback should result either from specifying invalid game entries (such as bg3 iwd3 sod) or from using invalid whitespace between them (not space or tab).

It's not really auto-pause, but any pause that occurs at the same time as applying the effects will allow movement. Apparently there is at least one positive side-effect of this bug.

It's not specific to just GENERAL. Any usage of Op72 is subject to becoming permanent (as timing mode 1) under a variety of conditions. It's possible that it's not intended to be usable as a temporary change, for the very reason that it can interfere with such checks.

The spells filter GENERAL:DEAD. A creature's GENERAL value does not change when they die, but the engine is able to detect a STATE_DEAD creature as GENERAL:DEAD, so long as they're GENERAL value is not actively being overwritten with op72 using timing mode 2 or 9 (any other timing mode would expire upon death). GENERAL:FROZEN works similarly in regards to STATE_FROZEN_DEATH and STATE_STONE_DEATH.

It's level (0x34) needs to be >0 if you intend to cast it normally.

The "Hit Immediately" bit will do that in the explosion projectile, but always. There is a bug in v2.6 when targeting yourself with a cone (defaults to 360 degrees), may be related. Beyond that would have to see the files.

The Pillar mechanic did not change - it stacks all cycles/sequences of an animation on top of one another (vertically). The existing animations that formerly used the Pillar mechanic were combined into a single (very tall) animation, to remove the "tearing" that would occur between each animation when using certain zoom levels.

No, it was a weidu mod, but it was overwriting instead of patching a file, using the BG2EE version as a base, which uses different string refs from the BGEE version.

Once you save and reload, the effect no longer properly tracks it's caster or target (but does track the caster level). The effect the creature is attached to will become the caster (but it will still use the stored caster level). Any spell with a non-instant projectile will fail (not projectile 0|default, 1|None, or any Single-target PRO using "Hit Immediately"). Several of the newer (EE) spellcasting opcodes work this way. op366 -> subspell subspell -> PRO=1, op146 (self/instant/caster level) -> subspell2 subspell2 -> (intended PRO/effects)

INSTANT and ACTSLEEP are only half the issue. Every action is hardcoded to whether it will allow usage instantly, while dead, asleep, or otherwise helpless. You can remove actions from them and they will stop working (instantly). To add actions someone just has to take the time to rigorously test every action not already listed. If you add "ForceSpell()" to INSTANT.IDS, you can use that action while the game is paused and though the character won't fully animate, the spell will be cast. Of course doing so may screw up numerous scripts that assume otherwise. If you add "Spell()" to INSTANT.IDS, the character will take the ready stance, but not take any action until the game is unpaused.

Splprot.2da was given an overhaul of it's initial column labels, for better readability, as well as made consistent across all 3 games:

Not necessarily new to v2.6, but became relevant with v2.6: Opcode 111 cannot utilize timing mode 4096, treating it as timing mode 0 or 10 instead (didn't determine which, but it doesn't really matter). Presently, in order to replicate timing mode 4096, set opcode 111 to use timing mode 1, and apply opcode 112 (for the same item) with timing mode 7, for the same duration you would have used with timing mode 4096.

@RaduzielThe final effect of RABDF.spl, is an op206 blocking itself, which prevents the game from reapplying the spell when it processes the CLAB file at CHARGEN.

There are a few problems with doing this. If you pick up another item in the inventory without first removing the helmet -> crash. If you load the game with the first helmet already equipped -> crash. The effects of the created item continue to pile up every time you equip the first (though simple to fix, append op321 to the top of the created item's effect list, just as you would a spell). Otherwise they remain, stacked, until you save&reload. The item being equipped is protected from removal/drain/drop opcodes while it's effect stack processes. How or why I do not know, but that is why you are unable to remove it upon equipping it. The item created with op143 has no such protection, and you can actually drop the created helmet with an op264 on equip.

The vanilla NPC's are global even before they join. But yeah, testing conditions were botched. Either way, the opcode sets the script in the creature substructure, which is why AREA and SPECIFICS are not saved. For non-global creatures, this means that it cannot replace any scripts that creature has assigned in the *.ARE file (both get run). For global creatures, it makes no difference, as they don't have scripts assigned in the *.ARE.

@Bubb I may be remembering wrong, but: Isn't it only the 0x0### triggers that allow object selectors to include invisible objects (as well as a few other normally undetectable conditions). While the 0x4### triggers as well as all actions do not allow object selectors to include invisible objects without op193. Then their's ActionOverride(), which allows it's object specifier to include the active creature.

It does that if you have an unidentifiable IDS label in the script block. ~TriggerOverride(Player1,True())~ ends up in the dialog file as: NextTriggerObject(Player1) True() ~TriggerOverride(Player0,True())~ ends up in the dialog file as: TriggerOverride(Player0,True()) Because 'Player0' is not a defined object label by default. It's expecting you to define "Player0" later on, because with dialog files, you can. It does however spit out a warning during the install. There are also situations where it doesn't do that when it should, such as converting "StateCheck([PC.2.ELF.101],0)" into: StateCheck([PC.ANIMAL.ELF.ANKHEG],STATE_NORMAL) Instead of leaving it as "[PC.2.ELF.101],0" The value of those labels (ANIMAL, ANKHEG, STATE_NORMAL) may change, and that is NOT what was specified.

(Examples from BGSoD) CHPTEXT5.2DA, second column of "DEFAULT" row: 15839 String #15839 (in dialog.tlk) has "CHAPTER4.WAV" specified as it's associated sound. Chapter and Dream Background images are defined in "BGEE.LUA": chapterBackgrounds = {} chapterBackgrounds[0] = "GUICHP0A" chapterBackgrounds[1] = "GUICHP1A" chapterBackgrounds[2] = "GUICHP2A" chapterBackgrounds[3] = "GUICHP3A" chapterBackgrounds[4] = "GUICHP4A" chapterBackgrounds[5] = "GUICHP5A" chapterBackgrounds[6] = "GUICHP6A" chapterBackgrounds[7] = "GUICHP7A" chapterBackgrounds[8] = "GUICHP1B" chapterBackgrounds[9] = "GUICHP2B" chapterBackgrounds[10] = "GUICHP3B" chapterBackgrounds[11] = "GUICHP4B" chapterBackgrounds[12] = "GUICHP5B" chapterBackgrounds[13] = "GUICHP6B" chapterBackgrounds[20] = "BPEND" chapterBackgrounds[52] = "GUIDRM2" chapterBackgrounds[53] = "GUIDRM3" chapterBackgrounds[54] = "GUIDRM4" chapterBackgrounds[55] = "GUIDRM5" chapterBackgrounds[56] = "GUIDRM6" chapterBackgrounds[57] = "GUIDRM7" chapterBackgrounds[58] = "ARRIVE" chapterBackgrounds[59] = "LEAVE" chapterBackgrounds[100] = "GUICHP6B" 0 - 19 are likely directly linked to their chapter, but I've no idea how 20, 52-59, or 100 are linked to those events.

The condition is checked on the target of op326. The projectile of the subspell will determine it's targeting: If it uses projectile #0, "Self", "Preset target", and "Original Caster" will all refer to the target of op326. If it uses any other projectile, it uses the "living actor" target for both it's "Self" and "Preset target", while "Original Caster" functions normally.

I found the issue. A few of the references to "currentSpellLevel" didn't get updated for IWDEE's different method. Normal Sequencers are only displaying the spells for the level you last visited on the Magebook screen. New version uploaded (v.59) https://forums.beamdog.com/discussion/73435/tool-ui-based-spell-learning-for-sorcerers-shamans/p1.