Jump to content

argent77

Modders
  • Posts

    1,609
  • Joined

Everything posted by argent77

  1. 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. 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
  3. Health bar position of the Demogorgon animation (1300.INI) is too low:
  4. 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 A7-AnimTest-v1.zip
  5. 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:
  6. [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:
  7. 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.
  8. That sounds like an original game bug. EEFP doesn't touch the door scripting. (Btw, that happened to me as well, especially in oBG2.)
  9. 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.
  10. [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.
  11. 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.
  12. 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. Examples:
  13. Baeloth's appearance starts with a helper creature, spawned via CreateCreature("BAINVI",[2038.2947],S) in AR2900.BCS.
  14. 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.
  15. It should work with iconv: iconv -f iso-8859-15 -t cp1252 oldfile.txt >newfile.txt
  16. 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.
  17. 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 Readme
  18. 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 Changelog: 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
  19. No, I tested it on an item I was just working on that uses this opcode. It could be that it works differently when applied via kit CLAB.
  20. I can't reproduce this issue in BG2EE. op244 effect drained the exact number of spell from a sorcerer in my tests.
  21. BGEE and SoD are installed as one game. The DLC Merger ensures that both campaigns can be properly modded. BG2EE is a separate game and has to be modded separately.
  22. Modmerge is outdated. Use DLC Merger instead. It can be installed like a regular mod. Just make sure to install it as the very first mod, because every other mod depends on it.
  23. I haven't heard about it from the other EE games yet. I was able to trigger this issue in BG2EE too. It looks like this combo should be avoided in all games.
  24. WeiDU handles patching of the game executable just like every other game resource that is patched by a mod. The bgmain.exe is a big file (over 7 MB). It's very unlikely that both mods patch the same byte sequence in the file. It should be fine to install both mods. But you should consult the readmes of the mods just in case.
  25. 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.) 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...