Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by DavidW

  1. Yeah, so when and what exactly did the Liches do to earn their super powers to get to level 29 ? Through long years of study, one assumes. I have always been fine with people cheating if they want to. To quote Wes Weimer, "I'm not the police".
  2. But mine has the head start that comes from just having got back from the UK and being jet-lagged
  3. CamDawg: I've pushed a fix for this to the repo. All the SCS-added components now install correctly on a completely clean SoD install. (I guess my previous one still had the SCS-created folders there even though I'd uninstalled SCS itself.) Reading the Tweaks readme more carefully, I also note that the SCS-borrowed 'stackable ankheg shells/bandit scalps/whatever' component is obsolete, because 'stackable gems' already does it. So maybe deprecate this too? (I haven't implemented that yet though.)
  4. That's a fragment of SCS that obviously wasn't excised quite surgically enough. I'll have a look for a good fix.
  5. It should happen automatically. SCS makes undroppable clones of the potion - dw#ptn08 is a copy of the Potion of Healing, for instance - and gives creatures the original or the undroppable one at random. I'm pretty sure undroppable items are hardcoded not to be stealable (if you did steal one, you'd have an undroppable item clogging up your inventory). As a point of design, the reason I do it that way rather than using the 'undroppable'/'unstealable' flags on the creature itself is that I can use the game's internal random-loot-item mechanic to decide at spawn-time what item a creature has.
  6. Insofar as that's true, the academic in me would want to take issue with you referring to "SR"'s spell system, since I got there first and SR originally built its system very closely around SCS (largely because Demi wanted to maintain SCS compatibility) and has only later wandered away. But actually I think the changes are by now fairly significant: 1) SR's approach to Improved Invisibility is actually a major change to the system, because an SR wizard with Detect Invisibility running can cast *Breach* at an invisible enemy, and doesn't need to do anything to drop that enemy's anti-invisibility protections. In SCS, Improved Invisibility is one of the two ways in which wizards block Breach (the other being spell-defense spells that can be dropped by Ruby Ray and friends), and in turn blocking Breach is the key to survival. Improved Invisibility requires True Sight or Oracle to drop (both of which are relatively high level), can be protected by SI:Divination, and can be put back up again. None of that works out in SR. (The existence of SI:Div isn't the point - SR's Nondetection is functionally identical - it's that Detect Invisible targets the *player* and can't be blocked, either by protections or by recasting Invisibility). So for better or for worse, SR's approach to invisibility really changes the game. Now I can take down a lich pretty quickly at high levels, for instance, by Spellstrike + Breach + Sarevok (perhaps +1 spell if I need to clear out a Spell Shield). The extra chunk of action economy required to drop the lich's (probable) II or Shadow Door makes a material difference. 2) As you note, SR cuts a big hole in SCS's spell system by removing SI:Abjuration. I don't agree that spell's a silver bullet (not least because it's self-only, so no use for party play) but it does fill an important niche, especially for solo players. 3) Spell Deflection and Spell Turning are in principle importantly different because you can burn spell slots to get through Spell Deflection but you can't do that with Spell Turning unless you're immune to your own attacks (and even then, you're burning down your own spell slots). Spell Trap and Spell Turning differ in occasional situations only (a glabrezu at full hit points might spam PW:Stun to drop Spell Turning, but not Spell Trap). These are differences that v31 and below of SCS haven't really exploited, to be sure. On a couple of details: "Cheat" means that player and enemy use the same 'laws of physics', so I take issue with the idea that this is a borderline case (even more so since this is an implementation of by-the-book AD&D). Lots of spells in BG2 get more powerful with level; RM is one of them; I don't see it as cheating any more than it's cheating for enemy Horrid Wiltings to do more damage than yours. I also don't think it's correct that RM is 'de facto, available to the AI and unavailable to players'. I agree that's true in what's probably the most iconic SCS context - a single super-high-level mage against a party - but it won't be true in: (i) many party-vs-party encounters, at all stages of the game; (ii) combat with fiends, especially in the late game; (iii) many solo-play situations, where the PC is much higher level than the normal calibration; (iv) for bards, who are significantly higher level than same-XP mages. This is neither here nor there, but that bit always bothered me about SCS. The in-game spell descriptions say that the spells have a small area effect, and that that's why it works. Earlier implementations of this tweak actually worked that way (and so were perfectly legal in the normal system), but it can be a bit fiddly, and advantages the AI in certain ways - hence the current implementation, which relies on ToBEx or EE. The name should probably be 'bypass' or something, not 'penetrate'. (But, as I discuss above, moving to SR's system would quite radically change the spell-combat structure, so I'm not going to do it in core SR even though I think it's elegant. I have implemented it in v32's SR support.)
  7. You missed one from your list: vanilla with SCS's slight tweaks. I suspect that's actually the system most people encounter: non-SCS AI isn't really sophisticated enough that the player needs to understand the spell-combat system, and on the basis of various reports I think only a minority of SCS players use SR. SCS makes two tweaks. Firstly, antimagic attacks can penetrate improved invisibility; secondly, and much more importantly, breach is blocked by spell deflection/turning/trap and by SI:Abjuration (in other words: it gets its MAGICATTACK sectype removed). For the record, I remain perfectly happy with that system, though of course I'm happy to try to be helpful with other systems too if they have wide support. (And of course that system has the advantage of being the one I was actually using when I coded and playtested the SCS 'Smarter Mages' system, whereas at least my support of other systems is mostly based on theory.)
  8. I hadn't originally understood what you meant here. But: WEIDU can't actually use a function before it's defined. But you can include a function in part of the definition of another function before defining it (as I did above). WEIDU isn't strongly typed and doesn't do any kind of validation on variables when you define things; if you do LAF my_function END the install will fail if my_function isn't defined, but the failure happens at install time. You can put that line in a function or macro before you define my_function, provided that you define it before actually running that function or macro.
  9. Congratulation on input variable validation and substitution of a single character to three variables. But now you need to also take input from the installer, as you have not done so thus far. Aka you made a useful function, but you are not using it yet. Sorry, that’s the most of other people’s coding I’m willing to do right now!
  10. I think I'm going to say, "wait for SCS v32 and then have a look at how the AI works and see if you can do what you need within it or if you need changes". (v30 and below uses a discrete list of breachables; v32 uses spellstates.) I strongly recommend against trying to "deceive the AI", because then you're hostage to AI changes. (If you're working within the intended functioning of the AI, changes are unlikely to cause problems; if you're trying to hack the code, it's much more likely that the hack will stop working when the mod updates.) I haven't gone through your list in detail, but one quick observation: RM doesn't just remove "good" effects, it removes anything (at least in vanilla BG2, and I think in SR too). So one aspect of RM scripting is to be careful not to dispel bad effects.
  11. It's just computation and variable substitution; of course it can be done in tp2. Here's a quick version (perhaps there are more elegant ones): // Checks if each of key_1, key_2, key_3 is a letter; replaces it with default value if not; uppercases it in any case. // Then if any two of key_i, key_j are equal, replaces all three with default values DEFINE_ACTION_FUNCTION verify_hotkeys STR_VAR key_1="" key_2="" key_3="" default_1="A" default_2="B" default_3="C" RET key_1 key_2 key_3 BEGIN OUTER_FOR (i=1;i<=3;i+=1) BEGIN OUTER_SPRINT letter $key("%i%") LAF is_a_letter STR_VAR letter RET value END ACTION_IF !value BEGIN OUTER_SPRINT letter $default("%i%") END ACTION_TO_UPPER letter OUTER_SPRINT $key("%i%") "%letter%" END ACTION_IF ("%key_1%" STRING_EQUAL "%key_2%") || ("%key_1%" STRING_EQUAL "%key_3%") || ("%key_2%" STRING_EQUAL "%key_3%") BEGIN OUTER_FOR (i=1;i<=3;i+=1) BEGIN OUTER_SPRINT $key("%i%") $default("%i%") END END END /// Returns true iff input is A-Z or a-z DEFINE_ACTION_FUNCTION is_a_letter STR_VAR letter="" RET value BEGIN ACTION_IF !(STRING_LENGTH "%letter%"=1) BEGIN OUTER_SET value=0 END ELSE BEGIN ACTION_IF "%letter%" STRING_MATCHES_REGEXP "[A-Za-z]" BEGIN OUTER_SET value=0 END ELSE BEGIN OUTER_SET value=1 END END END
  12. Code that to 3 variables and well see on going with that... I don't understand what this means.
  13. Or else just define some defaults, and revert to the defaults unless the player choices pass validation.
  14. Hey, I have to take issue with that. Zeitgeist is not properly released, but it is today (or indeed, as of years ago) no less useful for (un)installing mods than WeiDU on the command line. It is less a matter of Zeitgeist being unfinished (it is, but that is beside the point) and much more a matter of mods being adapted for interactive installs and more or less unsuited for non-interactive installs, regardless of how they are done (Zeitgeist, command line or otherwise). Supporting all the same mods as WeiDU itself is a given and that includes mods that use READLN. However, if you install mods non-interactively, I'd say it becomes clear that READLN is out of place, in a way that it isn't when the process is interactive. I hope READLN will eventually fall out of style, but it will remain supported. I'm really happy to stand corrected - but last time I tried Zeitgeist it looked as if it wasn't in official-release mode - there were some quite serious graphical glitches. (I couldn't get it to untick tickboxes, in particular.)
  15. That doesn't seem quite right. As long as people are in the WEIDU paradigm and aren't megamodding, READLN has advantages: if I write a mod that gives you a cute little puppy and lets you name it, entering the name in the field of a READLN is simpler and more direct than the ini alternative. (That's even more obvious for certain tools: I routinely use a micromod that lets me label all script blocks of a given BCS for debugging purposes, and it's way easier to specify the script via READLN than via an ini.) The point (I take it) is that READLN is a problem for uninstall/reinstall stacks and does not play nice with non-interactive install tools like BWS or Zeitgeist. I think not all mods are equal here. There are some mods that are popular enough that if your install tool doesn't work with them, people won' use it. For instance: SCS, Tweaks, Ascension, Quest Pack, Unfinished Business, BG1NPC, probably SR/IR, some of the better-loved NPC mods, and probably a handful of others that I'm not au fait with because I haven't really kept up with that side of things for some while. You need to make sure your tool works on those mods at the outset, and that means you need to work with their authors to achieve compatibility. But that list is, I think, *relatively* small. If you (or indeed Wisp) release a non-interactive GUI install tool that supports lots of mods including all the ones on that list, and that is smooth and easy to use, the pressure on other mods to adopt to it will rise sharply. (If someone releases an install tool that's incompatible with SCS, I'm going to shrug, because SCS is popular enough that the tool won't get widely adopted. If someone releases an install tool that's incompatible with Wheels of Prophecy, which afaict is way less popular, there's much more incentive for me to fix WoP to restore compatibility.)
  16. As a matter of general design principles: 1) if a mod is completely static (as I guess ancient megamods like CTB are?) and doesn't need bugfixes or compatibility recodings (here I'm not so sure), then you might as well do a separate EE version. 2) if a mod is still being revised or recoded, or if it really needs recoding as well as EE-compatibilising, *in principle* it's better to do a combined install, because it avoids all sorts of versioning problems, fixes not being mirrored, etc. (The main reason I combined SCS and SCSII wasn't convenience for BGT players, it was that it had become impossible to maintain the vast amount of overlapping code in two mods without it getting infuriating) However... 3) … coding a mod for multi-game install is harder than coding it for a single game. So it's more demanding on the coder, and if that person isn't sure what they're doing it's probably less risky to do parallel single-game versions. That depends on the mod itself and how complex its coding is: you can't recode a mod without understanding its original code, and mods vary: at one extreme, it's just a bunch of COPY statements, at the other, it's SCS, which I imagine looks to third parties trying to bugfix it rather like an ancient and decaying piece of alien technology discovered in the Martian desert.
  17. Why it’s not triggering, I’ve no idea. But use [GOODCUTOFF] rather than [PC] if you want to catch allies.
  18. Huh. That's a very good development, which I missed entirely.
  19. I'm not sure what most of these have to do with SCS (they're ToBEx features that weren't applied in SCS even on vanilla ToB) but in any case the chance of my implementing anything that requires engine hacks is somewhere between zero and none. I do give full immunity to elemental effects that you have 100% resistance to, in v32, and I might do sleep-awaken if I have a spare moment, but it's a low priority compared to actually getting a robustly releasable v32. (Release date tentatively somewhere between next week and the impending collision with the Andromeda Galaxy.)
  20. On getting SCS changes made: It is not the case that SCS has hooks to let third parties edit it, other than for their own private use. Revised SCS is an unauthorized mirror, albeit one I don't really object to pending v32 releasing, since I was difficult contact at the time. But I don't want third parties tweaking SCS. However, SCS has quite a lot of features to let *me* customize it for different mods. Getting me to include compatibility with a spell system modification requires one of four things: 1) I want to use this myself; 2) Lots of players are already using it; 3) Someone else does most of the work; 4) I'm feeling randomly helpful and it's not too difficult. Here (1) doesn't apply (I'm fine with the vanilla system) and (2) doesn't yet apply, but 3 and 4 are possible, though I'm reluctant to put very much if any time into supporting anything until it's released and stable. (I recognize there's a chicken-and-egg problem, though.) Looking at your description, it *seems* (correct me if this is wrong) that there are two changes from default SCS behavior: 1) Use spells on spell-deflection creatures to burn through their defenses 2) Don't use dispel magic on people protected by deflections. (I'm not going to use Breach anyway.) I'm already experimenting with (1) in SCS v32. (2) is fairly easy to do: you need to set a detectable state (let's call it DO_NOT_DISPEL) in the spell with 328/318 (I assume you know how that's done?) and I will check for that in the dispel block. There are a few other contexts where that would be useful, so I can do it anyway, which means I don't specifically need to detect your mod. Did I miss any AI-side changes?
  21. What Jarno says basically - but more generally, why would I want to take somebody else’s mod and integrate it into one of mine? (I guess I might adapt a chunk of another mod if I really liked it but thought I could improve on it - like SCS’s adaptation of Tactics Bodhi - but I can’t see why I’d decide to do that for some mod I don’t know just off the basis of someone else’s suggesting it.
  22. As far as I know, it’s still there. Are you on EE? It doesn’t work there (it needs ToBEx).
  23. Makes sense. But if you're going to do a "definitive, updated version", shouldn't it just be v4, not yet another beta? Two reasons: 1) It saves me maybe 20-50 lines of code in every mage script. Which might not seem to matter in a 10,000 line script, but I only keep SCS scripts as short as that by trying to be disciplined about avoiding bloat. (And leaving out all the SI detection lines on SR installs probably saves me several hundred lines on average.) 2) As a matter of good coding practice, I'm not leaving pieces in the code that don't have a clearly identified purpose. That leads to confusion and bugs. In particular, if SCS mages respond in a certain way to enemy spellcasting, I want that to happen because I've intentionally decided it should happen, not as a consequence of SCS's behavior effectively being hacked by another mod. Otherwise I will lose track of how the system is actually supposed to work. If v4 is actually released, and it turns out that I need to avoid Minor Globes when casting Dispel Magic on SR installs, that can always be done just by checking for MINORGLOBE. (But in any case, I don't want to make that change until it is actually necessary in response to something implemented in an official, released version of the mod - after all, this whole conversation is the result of a post made less than 24 hours ago, and for all I know it will dissolve like smoke in another 24 hours.)
  24. Just to be clear from an SCS perspective: I will code (indeed, basically have coded) SCS v32 to match the spell system in SR v4b15 if it’s installed. I will not subsequently be changing the way SCS reacts to SR, until and unless there is a new “official” release of SR (i.e. a proper v4). I don’t want to chase a moving target. I’d also recommend reading (at least the first page of) the “revised SCS” thread; it’s clear from there that at least Kreso, and probably also Demi, were just fine, rightly or wrongly, with SR making solo play very difficult.
  • Create New...