kjeron

op282 can do a variety of things depending on which stat it's setting, but that one's not associated with seeing invisibility. Actually they are implemented in a very similar manner - both impose an attack roll penalty on their attacker. For what it's worth, they both modify the +/- value on the "left" side of the displayed attack roll, not the number needed on the "right" side to hit/miss. Yes, sorry, that line should have been under STATE_INVISIBLE, not any invisibility. I've correct the post for others who see it.

It's all built into the invisibility opcode/states. Normal Invisibility: maintains STATE_INVISIBLE, which in turn does the following: provides a non-cumulative +4 bonus to your melee attack rolls. required for backstabs. if your backstab modifier is 2x or more, your attacks will ignore the targets dexterity AC modifier. if EA > 30, sprite is completely hidden, including selection/targeting circle. other creatures cannot detect you through the "See()" trigger (or through various object selectors), unless they have stat(81) set by op193. terminates itself after taking any "hostile" action. Weak Invisibility: maintains STATE_IMPROVEDINVISIBILITY, which in turn does the following: provides a non-cumulative +4 bonus to all saving throws. Improved Invisibility: duplicates itself on application, with the duplicate set to provide Normal Invisibility. otherwise identical to Weak Invisibility. Either invisibility STATE provides the following (unless the other creature has stat(81) set by op193): other creatures suffer a non-cumulative -4 penalty on attack rolls against you (it is NOT an AC bonus, though the outcome is the same). other creatures cannot target you with spells or abilities (unless said spell/ability is flagged to allow targeting invisible creatures). Does not stop forced methods of spellcasting that ignore the normal spellcasting rules. op47 and op116 will remove any Invisibility, provided they are not blocked. op136 will only remove Normal Invisibility. op282 is unrelated to see invisibility. * I can only test EE mechanics, not originals.

ActionOverride works just fine on dead creatures, they are however still limited to only taking actions allowed by dead creatures (primarily rthose in INSTANT.IDS). Similar results occur with Helpless creatures.

It still triggers when Area-Effect spells are actually cast on a creature (and not a point/location), such as through scripts and opcodes. The trigger is quite literal - the spell must be cast targeting the creature, not just affect the creature.

It's always been that way, only the non-instant modes could ever specify a casting level. op146, Param2=0: Param1=0: Casts spell at (Caster level) Param1=(non-zero): Casts spell at (Param1) level op146, Param2=1: Casts spell instantly at (Caster level) op146, Param2=2: Casts spell instantly at (Param1) level (This mode is new, specific to the EE's, and functions closer to op326/op333 (they share the same targeting and reflection mechanics) than the other modes of op146 or op148. op148, Param2=0: Param1=0: Casts spell at (Caster level) Param1=(non-zero): Casts spell at (Param1) level op148, Param2=(non-zero): (Effect target) Casts spell instantly at (Caster level) If you're looking for an opcode to instantly cast a normal spell at a specified level (at a creature or a point), there isn't one. op326/op333 and op146/param2=2 can cast a spell instantly at a specific level targeting a creature, but do so differently. The spell is cast at the spells/projectiles target(s), not necessarily the effect target. This target will inherit any "Self" targeted effects in the spell, not the caster. The target's Magic Resistance will not affect the effects of these opcodes spells. Any "Original-Caster" targeted effects in their spell may target the caster or the target depending on the spells projectile. If PRO is invalid, target becomes "Original Caster", otherwise caster will remain "Original Caster". Any Enemy-only or Ally-only projectiles in the spell will base their targeting off the target of these opcodes. If you use "Preset target" and target an enemy, that enemy will determine the enemy-ally of the projectile of the spell, not the caster. As such, they should not be used to cast to normal spells, unless you are looking to specifically exploit this behavior. Such as casting "Armor of Faith", normally a "Self-only" spell, on someone else at a specified level. When spell turning reflects these opcodes, the target of their spells effects changes depending on its projectile. If PRO is valid, target becomes "Original Caster", but remains "Self" and "Preset" target. If PRO is invalid, caster becomes "Self", "Preset", and "Original Caster" targets. This can be avoided by setting the power level of these opcodes to 0 to bypass spell turning, only targeting "self" with these opcodes, or exploited to cast some spells to bypass Spell Turning. "Invalid" projectile refers to any projectile index that is not listed in PROJECTL.IDS (with a relevant .PRO file) or hardcoded.

Yes it should. Error should be elsewhere. "Bit Not Match" is just the negated result of "Bit Match", it only looks for matching set bits, not matching unset bits. (Value) Bit Match (0b00000000) = false (Value) Bit Not Match (0b00000000) = true (15 << 4) Bit Not Match (0b1xxx0000) = false (15 << 4) Bit Not Match (0b0000xxxx) = true

It's the kitid assigned by weidu, 0x4080 belongs to the conjurer (TRUECLASS 0x4000 + CONJURER 0x80). Putting other kits, especially those that can cast wizard spells, in that slot will cause problems. It would be best if the Conjurer kit actually occupied that slot (row 128) in kitlist.2da, so weidu would skip it. Abjurer has the same problems with kitid 0x4040, kitlist.2da row 64.

It wouldn't matter for op148, as it target's "Self" anyway. Op146 only needs a power level when it's applying actual subspells, not when it's applying a base spell. This will insure the proper projectile is checked for reflection. If an op146 casting "Hold Person" had a power level, the entire spell could be reflected when it shouldn't (as it's normally an AoE spell).

The engine still has to read them to process dialog files. Their actions/triggers are just plain text, not compiled.

Why leave out known information? I've never seen any behavior beyond the enable/disable delay, but my experience with this is only the EE's. You can alter the feedback by the string in DIALOG.TLK or the reference in ENGINEST.2DA.

What's confusing about it?

The polymorph opcode itself disables spellcasting in addition to any redundant op145 effects present on the item. It also disables the Select-Spell and Quick-Spell buttons. Blocking/Removing op144/145 won't have any effect. The only spells you can cast with a true polymorph are innates located in the Special Abilities menu, and Wizard/Priest spells located in the Special Abilities menu that use Ability Target 7. To retain spellcasting you would have to use a fake polymorph (animation only). You could then switch the disabling effects for op177, targeting EFF files of those disabling effects with a shared custom parent resource, and have the HLA provide immunity to those parent resources (op318).

Your assumption is correct. You would have to make the robes usable by all clerics, then restrict all other kits from wearing them, either through op319 on the item, or op180 applied in the Kit's CLAB. Item restrictions are all additive, you can't selectively allow an item to be used by one or two.

@Cahir I specify the default MOS file used by the different games (BGEE+SoD, BGEE-SoD/BG2EE, or IWDEE). I'm guessing it detects SoD, but EET either doesn't import or renames the MOS file used by SoD. I've made a small update (v.29) to prioritize the BGEE/BG2EE MOS over the SoD version if EET is detected. If you don't want to reinstall, it should be fixable by opening UI.MENU, and replacing the string any instance of the string "GUICGWDE" with "GUISMF".

@Cahir the transparent class selection is possibly from my Dual-to-Kit mod, as the Chargen and Dual-class processes utilize some of the same menu sections for class/kit selection.

@subtledoctor - The variable "TB#SecondWind" is only set during component 10 ~Install revised HLAs for all classes~ and component 11 ~Choose which classes get revised HLAs~. The code setting it is in "hlab.tpa", which is only called by those two components. The individual HLA components for each class will not have that variable set if one of those two components is not (re)installed along with them. There are likely other variables set in "hlab.tpa" that are needed by the individual class components, and "TB#SecondWind" is just the first to be used.

Doesn't help that it's in someone else's thread (something I didn't realize at the time). It's rather old by now, so it may need updating.

It DOES update the creature's EA value, as can easily be checked with script triggers, Ctrl+M or by examining a save file. You assume that includes whether the creature is controllable, it does not. Petrification - let me guess, you're using op272 instead of 177/183/283 or 248/249? As I said, the immunity opcodes are still subject to their normal limitations. Those opcodes cannot block effects applied internally by the engine, and op272 applies it's effects in a similar such manner. It's no different from an op101 specifying op13 (Immunity to effect: Kill) failing to prevent lethal damage from applying a kill effect. This is actually where 7eyes.2da comes in, as it can block such internal effects that the immunity opcodes cannot. It's also another reason why op272 should never be used for anything other than 146 and similar spell-casting opcodes.

Your expecting it to do something else. ChangeEnemyAlly() only changes the EA value, it doesn't alter the creature's controllable flag. Not sure what you're trying to show about petrification - it doesn't put the creature in the lie down animation, so whatever you're using has been modified, obvious by the spells name: "So be it. Bye Bye mon cowboy". But I don't see how any of this has anything to do with what I was talking about regarding immunity. Her Belt protects against enough, but not everything.

All immunity/protection opcodes can block EFF files based on their content, as long as both are setup properly (which varies by protection/immunity opcode). However, 7eyes.2da cannot. They are still subject to their normal limitations - i.e. Deflection effects can only block effects originating from others. However, op101 is NOT a deflection effect - it will block effects (including EFFs) regardless of their source (though some opcodes and engine mechanics have options to specifically bypass op101 separately from this). Casting/Global effects have no parent resource, so using EFF files is the only way to block them by resource (aside from blocking the empty/null resource, which WILL block them, but which also has undesirable side-effects). The word "Spell" is not missing - it was renamed because it was misleading, as the opcode can also block effects from items, as well as EFF files of any resource type, unlike op206, which is limited to spell effect and EFF files with resource type "Spell". Cutscene's suppress any effect that may cause them to crash or hang, or at least that's the intent you're seeing. Not seeing the issue with ChangeEnemyAlly() in BG2EE. EA value is altered as specified.

target=self, param2=2 param2=0 plays the animation at the location of each affected creature/object (VEF>VVC>BAM) param2=1 attaches the animation to each affected creature/object (VVC>BAM) param2=2 plays the animation at the targeted location, once per affected creature/object (VEF>VVC>BAM)

00025: ~DRAGONSPEAR_UI/DRAGONSPEAR_UI.TP2~ 0 1 // Install SoD GUI Overhaul Core Componentv2.41 Should be one of the first mods installed.

A variety of mods use it. The table "SequencerMenu" should be defined in either "BGEE.LUA" or "M_SQLIST.LUA", depending on which version the mod is using. Both are prone to breaking (the former more so) if you install UI mods afterwards, as some simply overwrite any changes made by other mods.

EA value 127 appears to be "Area Object" (at least Doors, Containers, Regions & Animations) It is included in EA groups 31|NOTGOOD, 126|ANYTHING, and 199|NOTEVIL. Is this new/exclusive to the EE's?

condition = hp < 102 or condition = hp% < 102 Otherwise I don't know why it's failing for you - it works fine for me. Testing it with op324(immunity feedback) instead of 318 might help locate the problem.