argent77

59 minutes ago, Dan_P said:

As you can see, it pads out the tables, but for entries above 40, it also adds effects that were added to QD_MC files.

Specifically, it adds all effects given for the first multiclass kit installed before the table was extended.

Good catch. It was caused by an existing bug that was dormant until now but had been exposed by the improved table padding algorithm. It was the result of an unintentional use of the same array name in two different functions.

Issue has been fixed in ADD_KIT_EX v0.6.2.

21 minutes ago, Morgoth said:

Another question: Sword of ruin +2 is not damaging the displacer beast lord. Is that supposed to happen?

No, the creature doesn't appear to be immune to any weapon enchantments. However, a Mirror Image effect is triggered whenever it is attacked. Maybe you're just unlucky and always hit the image.

@Dan_P ADD_KIT_EX has been updated to v0.6.1 which fixes the issues mentioned in this topic.

13 hours ago, Dan_P said:

I tested with clean BG2EE v2.6.6 (Steam version) with The Workshop Kitpack and Thief Evasion from beta 3 of ToF.

This is the weidu log:

// Log of Currently Installed WeiDU Mods
// The top of the file is the 'oldest' mod
// ~TP2_File~ #language_number #component_number // [Subcomponent Name -> ] Component Name [ : Version]
~D2-WORKSHOPKITS/D2-WORKSHOPKITS.TP2~ #0 #9999 // The Workshop Kitpack -> Base kits + multiclass variants: 4.7
~D2-WORKSHOPKITS/D2-WORKSHOPKITS.TP2~ #0 #10 // Misc item pack: 4.7
~DW_TALENTS/DW_TALENTS.TP2~ #0 #40450 // Thieves gain the Evasion ability (on a successful save for half damage against abilities that require you to dodge, take no damage): Beta 3

No files in override before install.

Thanks. I have identified an issue that can lead to non-padded table entries under certain conditions. It'll be fixed in the next release of ADD_KIT_EX.

14 hours ago, DavidW said:

The fix is obviously to make kit_edit_clab a bit more permissive. (One thing it won't naturally do, even with that change, is preserve the QD_MULTI row name - the QD_xxxx entries will get put in a normal ABILITYx line. Is that going to cause any problems?)

That will currently cause problems if multiclass kits are installed before and after ToF since ADD_KIT_EX explicitly checks for the "QD_MULTI" keyword to determine whether to initialize files related to the multiclass kit mechanism. Making the check more robust is a trivial matter, but that will require kit mods to update to the next ADD_KIT_EX version. The same is true for mods that use @subtledoctor's QDMULTI library directly.

25 minutes ago, DavidW said:

There's a second problem, which is that the pre-evasion CLABTH01 isn't a legal 2da file: there are 40 column headers but the last four rows have 50 entries. kit_edit_clab won't care (it will just ignore the rows after entry 40) but other functions I use would care. I should probably encourage them to be more tolerant; that said, it would also be a good idea if the ADD_KIT_EX function didn't break the 2da format.

ADD_KIT_EX shouldn't break any 2da resources. Missing entries will be automatically (and semi-intelligently) filled by the function to leave a valid 2da file.

@Dan_P Could you please provide a repro case if the file above was created by ADD_KIT_EX in that state?

I have noticed another peculiar behavior of the PSTEE engine variant. It looks like the max. range of ranged spells or abilities is only considered by the engine after entering a new area. If you save and reload then the engine appears to limit the range to the visual range of characters in the BGEE engine (which is smaller than the visual range in PSTEE) until you enter a new area.

Edit: I think this is caused by the effective visual range of creatures which is reduced to the visual range of the BGEE engine after a reload. It seems to affect everything (even the scripting of creatures to detect enemies) except the range for clearing the fog of war which still works correctly.

I agree with jmerry. The rest spawn calculation in IWDEE seems to be correct.

It's looks like oIWD calculates the numbers differently. The secondary cap (offset 0xa4) appears to be used as some kind of multiplier. I also didn't notice a change in the number of spawned instances when I increased the power level of the creatures.

In any case, I think the rest spawn works as intended in IWDEE considering that the calculations have changed quite a bit.

It looks like encounter probability is indeed calculated differently in oIWD.

Based on my tests the reduction to 20 percent is a good approximation - maybe even a bit low. 22 or 23 percent would be closer to the original spawn rate. The oIWD calculation seems to distribute the rest encounters more evenly, but that's not something we can control.

I have also noticed that the number of spawned creatures appears to be calculated differently. In my test setup I got between 1 to 3 instances of a creature type per rest encounter in oIWD. The same setup in IWDEE would always spawn a single creature. I don't know if this indicates a bug or just a different spawn number calculation.

The probabilities of hostile rest encounters have been greatly reduced in IWDEE compared to oIWD. It looks like this was a systematic change since all encounter probabilities were reduced to 20 percent of the original value.

@CamDawg Do you know whether (or why?) this was intentionally changed by BD? Should it be reverted to the original values by the EEFP?

Comparison of rest encounter probabilities (oIWD and IWDEE):

AREA        IWD_DAY     IWDEE_DAY   IWD_NIGHT   IWDEE_NIGHT
AR1200      6           1           6           1
AR1201      15          3           15          3
AR2000      40          8           70          14
AR2001      30          6           50          10
AR3000      25          5           25          5
AR3001      20          4           20          4
AR3501      25          5           25          5
AR3502      30          6           30          6
AR3503      30          6           30          6
AR3601      50          10          50          10
AR3602      60          12          60          12
AR4001      50          10          50          10
AR4002      10          2           10          2
AR4003      50          10          50          10
AR4005      50          10          50          10
AR5001      35          7           35          7
AR5002      40          8           40          8
AR5003      45          9           45          9
AR5104      40          8           40          8
AR5202      35          7           35          7
AR5203      40          8           40          8
AR5204      20          4           20          4
AR5301      50          10          50          10
AR5302      50          10          50          10
AR5303      50          10          50          10
AR5304      15          3           15          3
AR5402      50          10          50          10
AR5403      50          10          50          10
AR5404      20          4           20          4
AR6001      15          3           15          3
AR6002      10          2           10          2
AR6003      15          3           15          3
AR6004      20          4           20          4
AR6008      10          2           10          2
AR6009      10          2           10          2
AR7004      40          8           40          8
AR7005      30          6           30          6
AR8001      40          8           40          8
AR8003      35          7           35          7
AR8005      35          7           35          7
AR8006      40          8           40          8
AR8007      40          8           40          8
AR8008      40          8           40          8
AR8009      35          7           35          7
AR8011      40          8           40          8
AR9300      30          6           70          14
AR9400      40          8           60          12
AR9500      33          6           33          6
AR9501      60          12          60          12
AR9502      60          12          60          12
AR9601      30          6           30          6
AR9602      40          8           40          8
AR9700      33          6           33          6
AR9709      33          6           33          6
AR9710      33          6           33          6
AR9711      40          8           40          8
AR9712      40          8           40          8
AR9713      33          6           33          6
AR9714      40          8           40          8
AR9716      40          8           40          8
AR9717      40          8           40          8
AR9718      40          8           40          8
AR9800      n/a         8           n/a         8

9 minutes ago, Sam. said:

From PSTEE I believe I did:

  Reveal hidden contents

A0508BL[2-4]
A0508TR[1-2]
A1201G1[LR]
A1201G2[LR]
A1201G3[LR]
A1202GB[1-4]
A13WZC2[AB]
A13WZC[AB]

It's always possible I've missed some, in which case if you get me a list I'll be happy to do them.

Yes, the fixed BAM resources were already present in EEFP. However, they were not installed because the relevant WeiDU code was missing for PSTEE. This commit should fix it.

1 hour ago, Galactygon said:

I think @Sam. already recombined all the area animations, including the PST:EE ones.

You're right, there is already an animation fix (#1, #2). But it looks like the commit lacks the code for applying the fix to PST:EE.

On 3/19/2022 at 11:18 PM, CamDawg said:

I'll start with an oldie but goodie: using the auto-pause for 'spell cast' causes all sorts of issues. To replicate, start an IWDEE game with a druid and at least one other character. Memorize some Sunscorch spells on your druid, rest your party, and enable 'Spell Cast' on the auto-pause menu. Cast Sunscorch on the other party member.

Pausing on the moment the spell is cast causes each individual effect in the spell to be rolled separately for saves and probability.

The (auto-)pause feature also seems to affect area background animations that consist of multiple parts. They will eventually go out of sync when the pause feature is used frequently. A good example are the swinging chains in the PST Modron Maze boss room (AR13WZ).

8 minutes ago, critto said:

Here's arm64 build of the version 2.4-20231231: https://drive.google.com/file/d/1P-8Y-yBmG3Mnqk_8Tcd7Vwugr6cYjX2l/view?usp=sharing 

Thank you! Added to the GitHub Releases page.

There is a bug in the INI processing mechanism for spawning creatures. The "events" key in the [spawn_main] section is supposed to accept a comma-separated list of group section names. However, only the last entry in the list is apparently considered by the engine.

Bubb confirmed this issue as a buggy implementation in the engine itself:

Quote

The engine is supposed to parse all sections listed in the events= key, but due to a bug it only parses the last one. (It reads the string correctly, but then fails to iterate the sections – it starts at the last section name and attempts to iterate forward, which is the wrong direction).

This bug currently impacts IWD:EE map AR8005 (Lower Dorn's Deep building, ground floor) where creature spawns are defined that are supposed to be triggered whenever the Shriekers detect an intruder. As it is currently scripted, the Shriekers are basically pointless since they don't do anything harmful (except maybe getting on the player's nerves with their constant shrieking).

6 minutes ago, polytope said:

18 hours ago, argent77 said:

That's not a solution either since Death effects can be protected against by Death Ward.

A similar discussion came up in another recent thread, you're unlikely to be level 7 when you meet Shoal, need to ensure it bypasses Mirror Image though which instant death effects by default do and it's toggleable for damage on EEs.

Imo being able to protect against the death effect should not be a real issue. However, the spell also sets a global which is then incorrectly evaluated in the following conversation and leads to the wrong dialog branch.

There is another potential loophole with this quest. If you are a spellcaster then you can initiate Shoal's dialog with your familiar which is then either killed or brought to near-dead status in place of a party member.

Aside from the nonsensical-looking dialog options when you talk to Shoal with your familiar, if the familiar is killed then the resurrection attempt by Shoal doesn't work since it only covers regular party members.

Changing damage type sounds like the best solution for this issue to me.

Changing the effect to "Set cur. HP to 0" seems to put the target into some kind of "undead" state. The target has 0 HP and a grayed out portrait but can still walk around and interact with the world.

1 hour ago, Trouveur80 said:

So I am wondering if the death effect from the kiss should be more like the level 6 Death spell instead of doing flat damage, in order to prevent perma death and thus allows Shoal to raise the dead NPC like her dialog suggests ?

That's not a solution either since Death effects can be protected against by Death Ward.

6 minutes ago, jastey said:

I'm pretty sure that a permanent death is not intended here. My faint recall from oBG1 is that the NPC died, yes, but could be raised again.

That's the normal case in BG:EE as well. However, it looks like party members can permanently die if game difficulty is Core Rules or higher and cur. HP difference to max. HP is 20 or more.

Bag of Torments

Bag of Torments is a mod for PST:EE that adds a number of containers to the game which can be purchased from various shops. One of the containers may also trigger a small quest.

Version 1.3 updates German setup prompts and adds labels for Project Infinity.

You can grab the latest release from the download link below.

Links:

• Forums: Beamdog, SHS
• Download: GitHub
• Readme

[sod] Several BG1 cinematics are missing in the Movies list (Options > Movies) for playback

The following BG1-specific movies are not listed in MOVIDESC.2DA when SoD is installed:

• BGENTER (Entering Baldur's Gate)
• CAMP (Bandit Camp)
• ELDRCITY (The Undercity)
• ENDMOVIE (Conclusion)
• FRARMINN (The Friendly Arm Inn)
• MINEFLOD (The Flooded Mine)
• NASHKELL (Entering Nashkel)
• WRECK (Shipwreck)

As @jmerry suspected your code lacks a condition for the whole dialog state. Adding a simple "True()" condition should be enough to make the dialog work:

IF ~True()~ THEN BEGIN FirstMeeting
  // ...
END

If you add more dialog states then you should replace "True()" with more specific conditions, e.g. "NumTimesTalkedTo(0)" for an initial greeting.