Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by aVENGER_(RR)

  1. That's how it works in 2E AD&D, unless you're a Strifeleader of Cyric in which case the Aerial Servant can fight for the caster. Bioware's developers probably wanted to make the spell more appealing, so they made the Aerial Servant fight for any priest. It would have been of little use in BG2 otherwise.
  2. Just a small heads up, aTweaks' Shambling Mounds will also use 11 HD and thereby match their PnP counterparts more closely than the shamblers provided by RR currently do. For consistency, aTweaks will also detect and adjust Shambling Mounds from other mods (including RR).
  3. Agreed, and I'm sure that Wisp will take that into account when he gets to PnP Mind Flayers. I personally find Bioware's "brain drain on-hit" implementation extremely silly.
  4. True, but with some restrictions. Water Elementals can only use Drown on helpless (held or sleeping) targets and it doesn't work on creatures that do not breathe (undead, constructs, elementals...) nor on large/incorporeal creatures. Note that this is handled via the Water Elemental AI script and not within the spell itself.
  5. If it helps, here's aTweaks' version of the Aerial Servant.
  6. Blindness sets STATE_BLIND which is used as a script check in my AI. Reducing the visual range does not. It depends on how much your lower the visual range. Reducing it by half probably wouldn't be that much of a problem, but going any lower than that without setting STATE_BLIND would almost certainly cause issues.
  7. aTweaks' Dryads also have Speak With Plants (a.k.a. "Unentangle"), Wild Empathy and Dimension Door. Not for aTweaks/RR AI. The only requirement is that reduced visual range is caused by the blindness opcode and therefore sets STATE_BLIND. Also, it should be noted that all effects caused by cloud spells have a base duration of 6 seconds and get re-applied every round but only if the victim actually remains within the cloud.
  8. If you do this, you might also want to make those spells party-friendly. Otherwise you'll get enemy priests harming their own neutral aligned summons (i.e. animals and elementals) with Unholy Blight while the party could accidentally kill neutral aligned commoners with Holy Smite during battles that take place in the city.
  9. That is all well and good, but it's still out of scope for Item Revisions. If you want to do this, make a separate mod/component named "Remove spurious Critical Hit immunity from opponents" or something and then hand-pick the target creatures. Most of them probably fall under Bioware's "Boss Immunity" stuff but there are also some creatures that should legitimately be immune to criticals. In aTweaks, we deliberately grant this immunity to elementals, slimes and mists and I'm sure that you don't want to intentionally break that. Admittedly, I haven't been to BWL much since the Iron Curtain went up, so I may have lost my appreciation for the finer aspects of modding debates. *insert snarky comment about IR breaking "dependencies" or some such*
  10. Personally, I see no problem here as long as it's planned as an optional component. The problem is that making such a change in the manner which Ardanis proposed can break other people's work. To clarify, I have no problem with Item Revisions removing critical hit immunity from Ioun Stones, helmets, hoods and similar headgear which is available to the party. My issue is with removing critical hit immunity from undroppable items which were deliberately placed on creatures to grant them this trait.
  11. I'm my view, removing critical immunity from items that are not available to the player is far beyond the scope of an Item Revisions mod. Again, I'd urge you to reconsider. While, I'm sure you're joking, I wasn't even aware that there is a Creature Revisions mod nor that we needed anyone's permission to reference PnP source material.
  12. In theory, yes, but remember that it is possible to flag items as undroppable in the CRE file as well, so your approach is not 100% error proof. If you are already doing mass patching, a better way would be to have a list of designated items which need to be changed instead of automatically modifying every single helmet-slot item in the game.
  13. I hope you mean all head slot items available to the player and not every single helmet-type item in the game. There are many instances where a helmet-type item is deliberately used to make a creature immune to critical hits, both in the ummodded game and in certain mods. For example, vanilla Bodhi has HELMNOAN.ITM in her helmet slot which makes her immune to criticals, while aTweaks' elementals use RR#ETRAI.ITM in for similar reasons.
  14. And while we are still off topic, when you find some time, please update the descriptions of all items and spells in IR/SR which grant +X to AC vs. creature Y (opcode #219) and remove the "saving throw bonus" references as that isn't implemented.
  15. It's also useful in cases when a large summon (i.e. an Earth Elemental) gets stuck behind a doorway or when you want to replace one summon with a different one without waiting for the duration to expire. Removing the cap would probably make it largely redundant though. While it's true that the CoC party carries much more magical gear than regular opponents, I think the readme makes it pretty clear that this is intended as they are supposed to be a high level group of adventurers, similar to the player's own party. And, as we all know, the player's party is always fully decked out in magical bling from head to toe. Eh? The luck opcode doesn't provide a bonus to saving throws on its own, and I don't add this manually. Again, luck doesn't provide a bonus to thieving skills on its own. Thanks, for the vote of confidence. In this particular case though, I disagree with you. Venduris' sword, cloak and Luckstone are meant to be at artifact-level. For that tier, I don't think they are so different from Carsomyr or the Staff of the Magi. Also, you get Venduris' Luckstone very late in Chapter 6 which isn't necessarily the case with the aforementioned two. However, I should probably update the description to make it clearer as to what bonuses the item actually provides.
  16. Believe it if you will, but I had almost the same in mind I believe you. Dismissing summons has been a standard feature in NWN/NWN2 since waaay back, and I'm actually a bit surprised that it wasn't modded into BG2 much earlier. In ToEE, you could even dismiss some area-effect spells like Web and Entangle, but I'm not sure how well that would translate into BG2.
  17. Just a heads up, in case this might be useful. If you like it, feel free to borrow aTweaks' approach for allowing the player to dismiss summoned creatures. The technical details can be found here.
  18. I thought it was pretty good for disabling low-level spellcasters. As you may know, some of RR's Shadow Thieves carry level 1-2 spell scrolls and Deafness seemed like a nice fit. Another thing to note, if you want any of SR's new spells to be used by SCS/RR/aTweaks' AI, the chances for that are much better if you make them party friendly. Since RR already adds Sound Burst as a bard HLA, Sonic Blast sounds better to me.
  19. RR's AI does use Deafness actually. Therefore I'd prefer it is stays either party friendly or single-target, whichever is more convenient for you.
  20. Best wishes mate, and thanks for all of your work on Detectable Spells. It's greatly appreciated.
  21. This is fixed by Rogue Rebalancing for BG2 and will be addressed for Tutu as well as of RR v3.9. BTW, the original description of the Dagger of Venom doesn't mention that the poison damage can be avoided by a successful save vs. death. That too is fixed by RR but you might still want to include it into the fixpack's GTU.
  22. Hi Andyr! First of all, congratulation on the new release, it's good to see you back at BG2 modding again. Now, I have a few compatibility notes regarding Rogue Rebalancing and Song & Silence v2: 1) It appears that in S&S v2 you are still copying a few 2DA's (CLABBA02.2DA and LUBA0.2DA.) instead of patching them. This could potentially cause compatibility issues if S&S is installed after a mod which also alters these files (such as Rogue Rebalancing) so I recommend using SET_2DA_ENTRY_LATER and SET_2DA_ENTRY_NOW to patch the files instead. 2) You might want to check whether the BG2 Fixpack is installed before applying the Blade's pickpocket fix. The fixpack also does this so the Blade might accidentally end up with a double pickpocket penalty if both mods are installed in an improper order. I've deprecated that fix from Rogue Rebalancing for this very reason. 3) You change the Swashbuckler's kit description in a somewhat unorthodox way - by replacing its entry in KITLIST.2DA. Since WeiDU now natively supports the uninstalling of changes made by STRING_SET I'd recommend using that method instead. Also, you might want to make a check if Rogue Rebalancing is installed since it also alters the Swashbuckler's kit description and omit your update in that case. 4) It seems that you have assigned your own custom 2DA's for the default Bard kits (i.e. LUA!1.2DA). Since S&S doesn't currently alter the HLA tables in any way it might be best to temporarily remove those lines from your .tp2 since they might cause problems with other mods which also alter the Bard HLA tables (i.e. Rogue Rebalancing and/or Refinements) if S&S is installed after them. BTW, these issues should not create any significant problems if Song and Silence is installed before any other mods which also make changes to the thief and bard kits. Still, it might be wise to address them in a future release to ensure maximum compatibility. Cheers!
  23. IIRC this was mostly fixed in v3.5. Essentially, the problem arose when I was coding v3.11 (back in 2003.) and at that time I had no idea how to make an existing dialogue pause the game so I simply recompiled it with a 0 value after BEGIN. As of v3.5 I use COPY_EXISTING ~BMTHIEF.DLG~ followed by WRITE_LONG 0x30 0 to achieve the same effect and afterwards I simply append the rest of my dialogue. However, v3.5 still has a tiny bit of leftover code from the earlier versions which REPLACEs a small part of the BMTHIEF dialogue (state 0 to be precise). No worries though, that code will no longer be present in v3.6 since I now prefer to use less destructive WeiDU commands like ADD_STATE_TRIGGER and ADD_TRANS_ACTION in all of my .D files. Update: The incompatibility issue has been completely resolved in RR v3.6.
  24. What exactly was/is causing a compatibility problem between RR and Amber? I'd like to resolve this in the upcoming v3.6 if it's still an issue.
  • Create New...