Jump to content

DavidW

Gibberlings
  • Posts

    6,422
  • Joined

  • Last visited

Everything posted by DavidW

  1. Well, try changing the animation of *your* creature to ghast and see if it makes a difference.
  2. I *think* buttons are connected to the animation.
  3. Theres an ids entries for SR spells thread on the SR forum; the code is in that thread. & sure, help yourself.
  4. Exactly. There is no good general argument for using mod prefixes in spell.ids. But in this very specific case we need to identify spells using an alternate numbering scheme. The SR in MONSTER_SUMMONING_SR identifies a numbering scheme named after a mod, not a mod per se. Mikes use of Roman numerals also achieves this; I just think it risks confusion and bugs when scripting.
  5. Incidentally, if anyone wants to do an automated conversion of the SR spells to ADD_SPELL and isn't scared of advanced WEIDU, the IWDSpells package I posted last month on GitHub will probably work with minimal modification. It's designed to run in your IWDEE install, take a list of spells, collect their resources recursively, and then prep to install them on a BG2EE install, but you could pretty easily adapt it to take an SR install as input. You'd need to issue IDS entries to the SR resources first.
  6. The reasons I'm avoiding the I-IX monster-summoning IDS entries are (a) Icewind Dale conventions, and (b) logical consistency with the vanilla system. I appreciate that on the SR forums people are focused around multiple-spell-mod compatibility. But I actually need to script for these spells (and, ultimately, spell.ids is in the first instance there for scripting purposes). I want a unified command that will cast the 5th-level MS spell, irrespective of which if any spell mod is installed, and I want a unified command that will cast the 8th-level monster summoning spell, whether IWDification or SR is installed. I could use Mike's suggested SR conventions throughout, but ultimately I'm thinking in terms of the vanilla system as primary, so I don't want to have to change the IDS there even if SR is not installed. I guess I could use MONSTER_SUMMONING_I and MONSTER_SUMMONING_II for the first- and second-level spells since they only appear in SR, but it is an obvious recipe for bugs to have to distinguish between MONSTER_SUMMONING_I and MONSTER_SUMMONING_1. I agree that in general it is a bad idea to include mod prefixes in the ids entry, for exactly Mike's reason. But in the particular case of monster summoning, Demi chose to change the vanilla-game conventions, so that there is a genuine conflict between spell system naming rules. We have a vanilla/AD&D convention (Monster summoning counts up from level 3, animal summoning from level 4) and a Spell Revisions / 3e convention (both count up from level 1). I suppose I could have gone for MONSTER_SUMMONING_3E_1 but so far as I know no other mod implements the SR conventions, and in practice I think referring to the convention by the name of its signature mod is clearer. In any case, since we're fairly committed to overloading spell.ids, if someone wants to superimpose the I-IX conventions for their own use, nothing is stopping them.
  7. Just to say that I’ve implemented this in SCS v32, with Subtledoctor’s streamlining of the summoning.
  8. While it might have been better in the first place if SR had been coded with ADD_SPELL, I’m unconvinced that at this point it is worth it, given the sheer amount of work and the very large number of bugs it would risk. (I had to do essentially the same thing for IWD-in-BG2, and again for my automated conversion of the IWDEE spell system; it is not trivial, even if you have sufficiently advanced WEIDU-fu to automate most of it.) You can achieve 90% of the compatibility goals by just adding IDS entries for the SR spells and mandating that SR is installed before other spell mods (which is structurally a good idea anyway given how systematic its changes are - the spell system is not really all that modular). I posted some suggested IDS code last month; it doesn’t even have to be in SR itself (I install it in SCS v32).
  9. It’s hard to control escalation, at least not without tailoring it to specific encounter areas.
  10. (3) is fairly clearly a deliberate exploit, and I have a don’t-block-deliberate-exploits policy.
  11. Look, I dont mind these questions exactly, but you could download windows Grep or similar, do a search for simulacr or whatever other resource youre interested in inside the stratagems folder, and get an answer in 15 seconds. It will probably be more accurate than my imperfect memory, unless Im myself answering by grepping the mod. In this particular case, I *think* I stopped overwriting simulacr when I decided enemy simulacra and projected images werent worth the trouble, several years back.
  12. My impression is that v31 is fairly stable. There are some quite serious coding differences between v31 and v32, such that I cant promise stability if you upgrade mid game.
  13. Don't look at me, I'm afraid: v31 is a maintenance release and I wasn't involved on it. This was never intended behavior though. (It's faintly possible that SCS is erroneously going with the OSX-vanilla version - which did work this way - on OSX-EE.)
  14. Qua SCS author, I don't care: I work with the system I'm given. (And since I don't myself use SR, I don't have a dog in the fight.) But if you want my advice as an author of AI, my guess, from a tactical point of view, is that making ordinary spell-deflection-type spells blocked by Spell Deflection - even by the lowest-level version - makes spell-protection spells a bit overpowered. I'd be inclined to advise either leaving HLA AoE unblocked by Spell Deflection, or else gating it so only the most powerful such spells - Spell Trap, say - actually protect from HLAs. (I haven't thought too much about the technical implementability of that, though.) But I'd also advise that it won't make a huge difference either way. For what it's worth, SCS v32 will use single-target spells against Spell-Deflection-protected opponents provided (a) the spell is two levels or more below the maximum level the mage can cast (so level 9 mages will use level 1-3 single-target spells to use up Spell Deflection, but won't waste L4 or L5 spells); (b) the spell isn't breach. I don't bother checking Spell Deflection for AoE spells, partly because it's a bit fiddly since the NWN component is optional, mostly because with AoE spells you've got a reasonable chance of hitting other people (and in solo play, AoE spells are less valuable anyway so you might as well use them to burn through Spell Deflection). My feeling is that if HLAs were blocked by Spell Deflection, that would probably lead to slightly silly behavior, so if you want that as a tie-break, it's probably better to make HLAs not blocked by Spell Deflection. (Especially as I'm not likely to further update SCS to reflect SR updates until there's an official v4.) But I don't think it's a big deal.
  15. An “understanding” is probably a bit vague for my needs, especially as the thread you link to suggests that wizard spells are work in progress. SCS will throw an install fail if it thinks the IWD resources are present but they aren’t.
  16. 3rd edition D&D (which I guess is the relevant baseline for NWN) offers Spell Immunity, which works on AoE but is gated by level ( maximum 8th level for the 8th-level version, maximum 9th level for an Epic version) and Spell Turning, which isn’t gated by level but only works on single-target spells. At least in the core rules, there’s no way to give yourself immunity to epic-level AoE.
  17. I can reproduce the duplicate Tamah (very slight change in new Ascension that breaks SCS's search-and-replace). I can partially reproduce the summoning problem with Demogorgon (there is a typo in new Ascension that accidentally nerfs DG's summoning; I'll fix it SCS-side). I can't reproduce the Yaga-Shura invincibility bug. Can you say more about the endgame bugs?
  18. I ignore IWD for AI purposes if SR is installed - partly to keep the combinatorics under control, but mostly because the whole point of SR (as I understand it) is to do a systematic rebalance of the spell system, so if SR is present, I want to work in its spell system, not a hybrid. SCS's version of the IWD spell system is installable with SR present, and is compatible on a technical level (i.e., duplicate spells are skipped, NWN area-effect spell deflection gets implemented for IWD AoE spells) but I don't make any effort to achieve conceptual compatibility. MOD_IS_INSTALLED. In principle, if (a) it is a complete implementation of the arcane and divine spell systems with no missing spells other than Contact Outer Plane,(b) it doesn't make significant other changes, (c ) I'm given a simple way to detect it. But I'm not going to actively support it (i.e., do install checks with it present) because the combinatorics of install-checking is already almost unmanageable.
  19. Fairly subtle. Under the hood, the implementation is very different: SCS's is an automated pull of the resources from IWD:EE, IWDification is more case-by-case. That *probably* makes SCS's more reliable, against which, it's been less tested in the wild. In terms of what's visible to players, I made some slightly different calls on harmonizing the spell systems from IWDification. e.g., I use the BG2 water elemental graphic; I include the IWD version of Mordenkainen's sword (renamed) alongside the BG2 version; I synchronise the two sorts of elemental summoning spells. It's plausible that the two will merge (for IWD:EE) at some point. Yes. I won't give all the details here, but as one example: Mordenkainen's Force Missiles gets a lower level cap. (The current version, put into a Sequencer, could do >500 hp damage, which I think is a little excessive.) I'll say something about prebuffs in a later post, since they've been restructured. Sometime between next weekend and the impending collision with the Andromeda Galaxy in 3 billion years. AKA I don't give release estimates. (The occasional times I have, I've usually regretted it.) On the other hand, I don't usually give sneak previews either. So you can probably infer from the fact that I'm doing it that I'm confident of a reasonably close release date. (It's just a matter of testing the panoply of different install options that are relevant in the modern BG2 environment.)
  20. Continuing to discuss features of v32 while I'm killing time doing install tests of it: "Under the hood", so to speak, SCS's system for mages and priests has undergone some major changes. There are a number of reasons for that, but one of them is to support a wider variety of different spell systems. In v31 and earlier, the core spell system was pretty much hardcoded in; there were various tweaks to allow for other spell systems (notably SR) but they were somewhat awkward and pretty partial. The restructuring of SCS makes it much easier to support multiple systems from the get-go. SCS v32 will support three different spell systems: 1) The "vanilla" system, along with SCS's usual tweaks: antimagic can affect invisible creatures, mantle is slightly more powerful, Skull Trap is capped at 12d6, etc. In v32 these are installed by default (they can be disabled using the ini file). That's recognising the fact that for a long time, SCS AI has pretty much assumed these tweaks are installed, and its AI behaves oddly without them. (This is part of a general design goal for v32: if there's some option where I actively say 'I don't recommend this', I want it moved out of the ordinary install structure, without making it unavailable for power users who know what they're doing.) 2) Spell Revisions - specifically, SR v4b15. v31 and earlier were officially supporting v3 of SR, which - although still the "official" version - is badly out of date. v32 goes to quite a lot of effort to systematically allow for SR in its spell choices, sequencers, contingencies, targetting, prebuffing, and strategy. (And almost all of SCS's spell tweaks are disabled on an SR install.) 3) The vanilla system augmented with (almost) all the new spells from Icewind Dale. v32 will ship with its own conversion of these spells (for EE only), or you can use IWDification (and on vanilla BG2, you'll have to). Again SCS tweaks the spell system a bit (slightly more drastically than I do for the vanilla system, in a couple of cases); again, the tweaks are installed by default but can be disabled at the ini. As with SR, IWD spells are systematically mixed into spell choices, sequencers, and the like. Version 32, slightly more than previous versions, errs somewhat on the side of using an interesting mixture of spells over making tactically optimal choices. I'm trying to strengthen the degree to which spellcasters of different feel different as opponents. (For instance, invokers basically don't use illusions any more; necromancers have a preference for cold-based energy damage when they use non-necromantic spells; fiend summoning has been cut back and mostly is restricted to liches.) This is still fairly subtle on the vanilla spell system but should be more noticeable on the other two systems, where I have a wider range of spells to choose from. One goal of the new difficulty system is that even a player who doesn't really want to upgrade the AI can still use SCS, on the easiest setting, to let enemies use the new spells in SR or IWDification.
  21. Technically I only said, "yes, I've decided". I'll say something more about spell systems in v32 shortly. (But yes, short answer is that I've improved SR compatibility.)
  22. Tactics hasn't been supported for over a decade. I will probably do an Ascension/SCS compatibility check on at least EE before releasing v32.
  23. I'm aware of this; I think I have a local fix, but given the persistence of the bug I need to test it more (and it might as well wait for v32 at this point, as it's reasonably imminent).
  24. Very much like that. AoE targeting, yes: I do that on any difficulty above Easiest. Enemy numbers, mostly no: I've mostly implemented difficulty sliding in the AI part of SCS, not the tactical-challenge part, and there's not much scope there. But it shows up in a couple of places: most importantly, random spawns are tied to the slider.
×
×
  • Create New...