argent77

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.

6 minutes ago, ptifab said:

 I've tried to apply a specific parameter to p2 (IDS_OF_SYMBOL), but it cannot convert it into an integer. Do you know if i can adapt your function to go with that kind of parameters ?

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.

45 minutes ago, ptifab said:

The warning message is: "Cannot find parent class for kit A7_FALLEN_BOWKNIGHT: it's not in kitlist.2da and it's not in class.ids"

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?

1 hour ago, jastey said:

I think CreateCreatureObject is what you need, with 0,0 so it spawns directly where the cre is. Example:

CreateCreatureObject("C#AJSHBO","C#Ajantis",0,0,0)

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.

3 hours ago, subtledoctor said:

I want to set something up in a blue-circle NPC's override script such that, once a certain battle begins, it starts a timer (maybe 5 rounds or so), and then when the timer is up (so should be in the thick of battle), they "transform" into a red-circle monster.

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.

29 minutes ago, svj said:

Would that new statecheck work and not conflict other mods perhaps adding same?

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.

2 minutes ago, svj said:

No such check in state.ids

!StateCheck("rqt5clf1",CD_STATE_NOTVALID)

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.

52 minutes ago, Jarno Mikkola said:

Erhm, problem I keep hearing is, this: https://github.com/Gibberlings3/EET/blob/master/EET/lib/bhaalspawn_abilities.tpa#L217 is not actually 50% vs 50%, but far from it, as the response is recalculated with every iteration it goes through, and as it has no natural total of 100, it slips to be more probable for the first than 50%.

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

36 minutes ago, jmerry said:

But ... the animation is also widely used as an "invisible" placeholder. Mimics. Sparring dummies. Invisible stalkers. Mephit portals. Various objects that you can talk to but aren't supposed to attack. Globally changing the animation's parameters might have deleterious effects on that alternate use.

In other words, additional testing needed.

Since this animation is mostly used for humanoid-sized creatures I think it looks generally more natural with adjusted health bar positions - even for invisible creatures such as Invisible Stalkers or the Mephit portals.

More screenshots:

[BG1,BG2,IWD] Doom Guard creature animations should display damage indicator at correct height

Damage indicator for creatures that use the Doom Guard animation is currently shown at the feet of the creatures. A "height_offset" definition with an appropriate value should be added to the respective INI files to adjust it to correct height.

Affected animations:
- 6405.INI (doom_guard)
- 6406.INI (doom_guard_larger)

Screenshot:

More info in topic: Creature animations with incorrect health bar positions

10 minutes ago, Trouveur80 said:

Do you think it could be fixed in the EEFP? Or it's out of scope? 

First step would be to find out why it breaks sometimes. The scripting hasn't changed since oBG2 and looks good in NI. But complex scripting like that probably shouldn't be executed directly in a dialog though.