kjeron

@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

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([

(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

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.

The REPLACE_TEXTUALLY is likely catching the "EXIT" in this global: GlobalLT("BD_EXIT","BD0114",1) From State Trigger 2 of CORWINJ.dlg.

It suppresses the other two for it's duration, as op50 has priority, but they do resume once it has finished. The only bug is that cycle speed is capped to the first upper byte (0 - 255). Any value above 255 results in no color glow.

You would need to add a new script block before (or after) the current one: IF OR(6) CheckSpellState(Player1,NEW_SPELLSTATE) CheckSpellState(Player2,NEW_SPELLSTATE) CheckSpellState(Player3,NEW_SPELLSTATE) CheckSpellState(Player4,NEW_SPELLSTATE) CheckSpellState(Player5,NEW_SPELLSTATE) CheckSpellState(Player6,NEW_SPELLSTATE) THEN RESPONSE #100 Continue() END and modify the current script check: IF SpellCast([PC],0) !CheckSpellState(Player1,NEW_SPELLSTATE) !CheckSpellState(Player2,NEW_SPELLSTATE) !CheckSpellState(Player3,NEW_SPELLSTATE) !CheckSpellSt

!SpellCast() is broken, so you can't specify individual spells to ignore. It works okay by itself, but when paired with SpellCast(), it is generally ignored. IF SpellCast(Player1,0) !SpellCast(Player1,0) THEN This returns true for any wizard spell, despite the obvious contradiction.

The dialogs are attempting to cast "D5ST_05" instead of "D5ST_5", so all of the single-digit "sets" are failing.

No, setting a creature's EA value with op72 sets an exact value, not a relative value. Duration = 1 second. You don't need the charm to last, the effect just has to process long enough that you initially gain control of them. After it expires, control will default based on it's EA value, which as ALLY(4) will be controllable by the player. (It actually takes a minimum of 2 ticks for this to occur, were you to use timing mode 10)

Those opcodes have no trouble setting lower base values. The issue is somewhere else.