Jump to content


  • Posts

  • Joined

Posts posted by argent77

  1. 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.

  2. 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



  3. 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:







  4. [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)





  5. 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.

  6. 22 minutes ago, Trouveur80 said:

    In BG2EE 2.6.6with EEfixpack installed, I just ran into this bug : https://forums.beamdog.com/discussion/27228/known-7344-head-statue-in-spellhold-not-opening

    I had journal update and XP rewards but the way didn't open the first time I clicked on it, and it worked the second time but granted me again the XP reward.

    That sounds like an original game bug. EEFP doesn't touch the door scripting. (Btw, that happened to me as well, especially in oBG2.)

  7. Offset to the script resref is incorrect. It is 0x48 instead of 0x3c (IESDP info). I would also suggest to add the "NULL" argument to READ_ASCII, so that trailing \0 characters are skipped.

    As subtledoctor mentioned, don't compare the script with "None". This is only a symbolic placeholder in NI to indicate that the script field is empty. Use an empty string instead.

  8. [BG1] Tersus in the Bandit Camp should not give you 6 leather armor if the party consists of fewer than 6 members

    Tersus always gives you 6 leather armor in his dialog. That's not a bug per se but probably just legacy scripting from oBG1 that has been ported to BGEE.

    I'd suggest to fix it by adding multiple dialog transitions which check for currenty party size and hand out an appropriate number of leather armor.

    Edit: I didn't test thoroughly enough. This is only a problem in EET. BGEE seems to have a different targeting behavior than BG2EE and doesn't create additional armor if targets don't exist.

  9. Temple services like Raise Dead or Resurrection are level-dependent while scrolls are not. The higher your level the higher the price of the service. The base prices for these services are actually quite cheap. A level 1 character can be raised for 100 gold and resurrected for 150 gold.

    Edit: It looks like prices for Raise Dead and Resurrection are capped at 10,000 and 15,000 gold respectively, so they won't rise indefinitely.

  10. Several BAM files that are used for displaying GUI elements use the (pvrz-based) BAM V2 format. These files can produce the same visual glitches around borders as seen by map tilesets. Since BAM V1 supports alpha-blending it should be possible to fix these glitches by converting the affected files to the BAM V1 format.






  11. From a technical standpoint it is the order of state trigger entries in the DLG resource that defines the "weight" of a state. That's why WEIGHT only makes sense for dialog states with state triggers.

    A good example for WEIGHT'ed states is 25SPELL.DLG in BG2 where state 0 is actually considered as the least important state in the opening states order.

  12. On 5/11/2024 at 4:22 AM, deratiseur said:

    This effect works very well when applied to a mage, but is buggy when applied to a sorcerer: with the sorcerer, the parameter must be X+1 for the effect to be correct. For example, if I apply -3 spells to a sorcerer, he'll only lose 2.

    Opcode 42 also worked as intended in my tests, as long as negative amounts are limited to -1. Otherwise, strange things can happen. This is also noted in the IESDP description of the effect. You can add multiple effect instances if you want to reduce the slot amount by more than one slot.

  13. Wares of the Planes is a mod that introduces a large number of weapons and accessories from the Planescape universe to the Baldur's Gate series. The items can be purchased from a unique travelling merchant who is available throughout the whole game series. The mod is available for BG:EE, SoD, BG2:EE and EET.

    Version 1.2 introduces a good number of new and interesting artifacts from the Planescape universe and fixes several spelling errors.

    You can grab the mod from the download link below.

    Download: GitHub

    Discussion: G3, Beamdog


  14. New release: Wares of the Planes 1.2

    This version introduces a good number of new and interesting artifacts from the Planescape universe.

    A detailed list of item descriptions can be found here: item-descriptions.txt


    • Added new items for sale: Vambraces of Evil's Warding, Baku's Horn, Abigail +1, Dûrgaläd +3, Fiendblight +2, Wesley's Hourglass, Wesley's Improved Hourglass (upgraded by Cespenar), Thanatos +2, Thanatos +4 (upgraded by Cespenar)
    • Fixed spelling errors
  15. 1 hour ago, jastey said:

    Is this gab also in BG(II)(EE)?Thinking about mod cutscenes that might have put both in, too.

    I haven't heard about it from the other EE games yet. But they all use the same engine, so it could affect these games, too. In any case, I don't see a need for an EndCutSceneMode() if it's followed by a Dialog() call. (Unless the dialog is not guaranteed to trigger. In that case it would make sense to add EndCutSceneMode() *after* the Dialog() call.)


    1 hour ago, jastey said:

    I can't check IWDEE right now. Is this also a thing if the order is first [Start]Dialog and then EndCutSceneMode()?

    That should be fine. The dialog should have ended cutscene mode already, so the final EndCutSceneMode() call does nothing except waste two AI ticks.

  • Create New...