argent77

This is a function that simplifies the process of adding new areas to the area list of the debug console. It is a generalized version of the function that I'm using in some of my own mods which install new areas (e.g. "Test Your Mettle!" or "Trials of the Luremaster). WeiDU function: Example code: // Example areas ACTION_DEFINE_ASSOCIATIVE_ARRAY my_areas_lua BEGIN // ARE resref => Area name "XR1000" => "My first outdoor area" "XR1001" => "First indoor area" "XR1002" => "Second indoor area" "XR2000" => "My second outdoor area" END // Adding areas to selected BGEE campaigns LAF ADD_AREAS_LUA INT_VAR bg1 = 1 // add to BG1 main campaign sod = 1 // add to SoD expansion tut = 1 // add to BG1 tutorial section STR_VAR comment = "Areas from my own mod" // an optional comment map_array = "my_areas_lua" // name of the associative array that has been defined above END

WTASIGHT.BCS is a vanilla script file and can therefore be subject to all kinds of patching by combat enhancement mods. But even without patching the Attack() instance in that script can prevent other script blocks from triggering. I'd suggest to assign your own custom attack script and use only attack actions that are automatically reevaluated after a set amount of time (e.g. AttackOneRound() or AttackReevaluate()).

How about Enhanced Edition Campaign Manager ?

I was able to reproduce this error by manually adding the entry "2 ALLIES" to SPECIFIC.IDS in BG2EE, so you can avoid this issue locally by installing EET on a clean BG2EE game. Fixing it in EET itself is probably more complicated. The relevant code portion seems to be generated dynamically during the EET core installation. The whole "code generation" part looks a bit too messy to me to mess with it.

These files are identical with the files from the Beamdog and Steam version. The only hint I could find in the EET code is an array with replacement strings, which also includes a "CULTIST => ALLIES" entry. Since there is an ALLIES_NEUTRAL entry in SPECIFIC.IDS (and that very entry is used by BDNOREST.BCS) it is possible that a bad replacement operation changes ALLIES_NEUTRAL into CULTIST_NEUTRAL under certain conditions and causes the compiler error afterwards. But that's only a guess for now.

I don't have the GOG version of the games. Maybe it differs somewhat from Beamdog and Steam version. Could you inspect SPECIFIC.IDS whether it contains a CULTIST_NEUTRAL entry in BGEE and/or BG2EE?

This error seems to come up occasionally (e.g. here or there). I've seen it mentioned several times on Discord as well. Unfortunately nobody made the effort yet to identify the cause and just tried with a clean BGEE installation instead. The SPECIFIC.IDS value "CULTIST_NEUTRAL" does not exist in the base game (BGEE or BG2EE), so it's most likely some kind of conflict with another mod.

[BG1] Kiel's Helmet (HELM14.ITM) should not apply a permanent morale bonus whenever the helmet is (re-)equipped Opcode 23 (Morale bonus) is applied with timing mode 1 (instant/permanent until death) instead of timing mode 2 (instant/while equipped).

You can create your own compatibility matrix for HANDLE_CHARSETS. I did the same for PST-UB to support Brazilian Portuguese translation: https://github.com/Argent77/PST-UB-reloaded/blob/devel/PST-UB-reloaded/PST-UB-reloaded.tp2#L26-L51

Component "Make Khalid a Fighter-Mage [Domi]": Khalid's creature file "khalid7.cre" is installed without valid name and tooltip strings. A comparison with the original CRE file in SoD also revealed different values in the global and local identifier fields (offsets 0x27c and 0x27e), but I don't know whether that is just a cosmetic issue.

Script commands can't be added to the "effect_codes" parameter directly. That would require a different (and more advanced) implementation of the function. You could resolve the SPLSTATE value separately though and then use it in the function parameter. SET splstate_value = IDS_OF_SYMBOL ("splstate" "CHARM_IMMUNITY") LPF a7_auto_apply_spl_effect INT_VAR def_target = 1 def_timing = 2 STR_VAR function_name = "ADD_ITEM_EQEFFECT" effect_codes = EVAL "op=328,p2=%splstate_value%,spec=1" END

Afaik Polymorph() only changes appearance. To completely replace the creature you could probably use opcode 151.

That's probably 252 CreateCreatureObjectOffset(S:ResRef*,O:Object*,P:Offset*) But I don't know if it can be used to place a creature "on top" of another creature.

This is the "fallen" variant of the Paladin kit A7_BOWKNIGHT from Improved Archer Kit. I can't say why this message is triggered by ToF. My guess is that is has something to do with a failed pattern matching, so maybe @DavidW knows more?

CreateCreatureObject() always spawns the creature next to the target creature. The three numeric parameters don't have any special meaning (except for the first one which defines the orientation). Polymorph() or PolymorphCopy() could work, however. You could apply a spell that performs the transformation with an execution delay of 30 seconds. It has the advantage that it can't be blocked by status changes or busy scripts. The werewolf transformation of the "fighters" in the Windspear Hills area does something like this. The spell for their transformation is SPWI948.SPL.

A side effect of fixing glitches in multi-part creature animations is that their health bar location is placed at an unusually high offset (see screenshot below). This issue can also be fixed by adding an explicit "height_offset" definition to their animation definitions.

Yes.

In a mod you would add it like this to prevent that the entry is added multiple times. APPEND "state.ids" "0x80101FEF CD_STATE_NOTVALID" UNLESS "CD_STATE_NOTVALID" CD_STATE_NOTVALID combines all of the individual disabling states as well as the various death states (STATE_DEAD, STATE_FROZEN_DEATH, ...), so it should cover all situations you have previously covered with the death check and individual state checks. The reason why your first code sample (without REPLY) doesn't work as intended is that dialog transitions are checked bottom-up, and the first matching state will be executed. That's always "IF ~~ THEN GOTO EyesandEars" in your case. That can be fixed by reordering your list of transitions.

Is this for original BG2? In that case you might have to add this entry manually to STATE.IDS: 0x80101FEF CD_STATE_NOTVALID

You can probably reduce all those checks to a single check: !StateCheck("rqt5clf1",CD_STATE_NOTVALID)

Effect opcode 262 can be used to increase the visual range You could create an item with this opcode as a while-equipped effect. Default visual range is 14. Max. range seems to be 23.

I can't confirm your claim. In my tests the RESPONSE probabilities were calculated independently for every script block, even if they use Continue(). They were also (more or less) evenly distributed without favoring a specific RESPONSE block.

Bhaalspawn abilities are somewhat randomized by the engine when you start a new character in BG2. Bubb reverse-engineered the exact odds a while ago when I implemented it for EET. The actual probabilities are outlined here: https://github.com/Gibberlings3/EET/blob/master/EET/lib/bhaalspawn_abilities.tpa#L24-L37

Health bar position of the Demogorgon animation (1300.INI) is too low:

Originally posted here: Health bar positions are automatically calculated based on the dimension of the creature animation BAM, unless they are explicitly defined in their associated INI files by the "height_offset" attribute. There are several creature animations with incorrect health bar positions, either because they don't contain the "height_offset" attribute or use an incorrect height. The most obvious cases are 6405.INI and 6406.INI which both define an invisible creature animation for various creatures and helper creatures. But there are more cases, especially in BG2EE and IWDEE, which don't define explicit height positions for any creature animations. BGEE/SoD looks (mostly) fine. In many cases it looks like health bar positions are calculated differently every time a creature is spawned. This could be bug in the game engine when no explicit height value is defined. It seems to use the dimension of the first available animation frame to calculate health bar position. This is especially apparent with creatures that have very dynamic animations, like the Ravager. I have attached a small test mod that spawns creature instances for every available creature animation in a dedicated area for closer inspection. Creature animations to fix: 6405.INI (DOOM_GUARD): [BGEE, BG2EE, IWDEE] Set height_offset=65 6406.INI (DOOM_GUARD_LARGER): [BGEE, BG2EE, IWDEE] Set height_offset=65 1300.INI (DEMOGORGON): [BG2EE, IWDEE] Set height_offset=140 1200.INI (DRAGON_RED ) [BG2EE, IWDEE] Set height_offset=260 1201.INI (DRAGON_BLACK): [BGEE, BG2EE, IWDEE] Set height_offset=260 1202.INI (DRAGON_SILVER): [BGEE, BG2EE, IWDEE] Set height_offset=260 1203.INI (DRAGON_GREEN): [BGEE, BG2EE, IWDEE] Set height_offset=260 1204.INI (DRAGON_AQUA): [BGEE, BG2EE, IWDEE] Set height_offset=260 1205.INI (DRAGON_BLUE): [BGEE, BG2EE, IWDEE] Set height_offset=260 1206.INI (DRAGON_BROWN): [BGEE, BG2EE, IWDEE] Set height_offset=260 1207.INI (DRAGON_MULTICOLOR): [BGEE, BG2EE, IWDEE] Set height_offset=260 1208.INI (DRAGON_PURPLE): [BGEE, BG2EE, IWDEE] Set height_offset=260 A7-AnimTest-v1.zip