kjeron

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.