polytope

I believe you shouldn't revert offensive spells from AoE to single target as the AI will fail to understand how these interact with things that protect from single target spells. Note that the duration of Slow and Haste spells already didn't match in vanilla.

Another change between the original BG2 and the EE engine, frankly an unwelcome one for me as it's less granular (reversing rather than neutralizing). I did say "vanilla game" back when SR was designed, before EE.

Well yeah, there's a difference between suboptimal performance of an AI enemy versus brokenness. The AI is always somewhat hampered, relatively speaking, to the player. It's definitely what happens in vanilla prior to Spell Revisions, Hasting a Slowed character puts them at normal speed, not hasted. As does Slowing a Hasted character.

It wouldn't solve the crucial issue of AI not recognizing Haste or how to dispel/reverse it, as in the current SR. On this subject, the opcodes #16 and #40 for Haste and Slow perfectly negate each other in the vanilla game, although the spells/items that apply them don't always. Example: Character receives a Haste spell, then is Slowed by a mage, or even a mustard jelly, now they're moving at normal speed, then they're slowed again, perhaps by a stone golem, or a confused PC with the flail of ages, now they're moving at Slowed speed, then they use an oil of speed, back to normal speed, then the party mage casts Improved Haste on them, now they're not only Hasted, but actually Improved Hasted with double normal attack rate, with all these effects overlapping. The problem is that in vanilla Slow spells and (some) items apply additional penalties to armor class and THAC0 concurrent with the Slowed state, those aren't negated by Haste. Another issue is that on fixpacked/EE installs, Improved Haste protects from regular Haste but as a result if an Improved Hasted char is Slowed you can't use a Haste spell to simply "cure" it, the protection from Haste should be stripped by Slow, as for the additional debuffs of Slow spells these should either be removed by Haste or tbh, just get rid of this aspect to the spell, Slowing the target to half normal apr/move and the associated initiative penalty as well as the doubling of spell casting times is already very powerful, no need to make it more so.

Surely the main thing is to ensure nothing is broken, i.e. the AI doesn't get caught in an unrealistic loop where it can't detect the Hasted state and pointlessly reuses Haste spells/oils, a slightly less problematic issue is dispel checks, and the AI failing to recognize Hasted characters as targets for Remove Magic. The balancing of the spell relative to other low level wizard buffs is the main project of the Spell Revisions mod, although I haven't played with it for a while, I do try to support compatibility on the basis of its popularity. Some time ago it was decided by the authors that Haste needed a nerf to be in line with competing 3rd level spells, I'm arguing that of all aspects that could be changed in this regard of Haste, the opcode itself is the worst choice, the duration second worst (radically changing the duration of a spell also leads to the AI doing inappropriate things, as would substantial changes to the casting time), this leaves the number of targets affected as the least harmful obvious solution in terms of balance and compatibility.

Yes, but in PnP it ages the recipient by an entire year, that's a tradeoff that prevents overuse of the spell. In this cRPG however, where things are streamlined a bit that feature - which ensures Haste is a spell for emergencies or career-defining special occasions - was removed. Compared to other wizard buffs of neighboring levels (Strength, Luck, Improved Invisibility, Spirit Armor) which are single target with minimal drawbacks if any (can't target other beneficial spells on an Improved Invisible character, chance of minor damage with Spirit Armor) it seems appropriate for Haste as implemented in game to also be single target. The alternative of reducing the duration seems worse, because it makes it easier to simply wait it out when the AI uses it. For instance with a 5-round duration it can almost be waited out with one of the ProMW or Mantle type spells, not even needing to kite the hasted enemy all over the map (which is admittedly difficult, if they're hasted and you aren't, easier with the boots of speed). Well, DavidW said on page 1 that currently only fighter/mages get it in SCS and cast it upon themselves, so would be indifferent to this change. In vanilla game scripts I believe the check is usually for SPECIFICS.ids i.e. a scripting trigger like NearestMyGroupOfType(). I'm pretty sure though (between various AI mods and vanilla), that the most frequent thing the AI checks for regarding Haste is STATE_HASTED for the purpose of either knowing whether an ally has been buffed with it or deciding to throw a Remove Magic at enemies, so that opcode shouldn't be removed from the spell.

I disagree, if the AI can't find a single worthwhile target for Haste it shouldn't cast it. In your example one of those ogres (which anyway is barely worth Hasting, as I said I'd put the limit at about ghasts) would register as a Haste target, either in order or reverse order of proximity, but the script still couldn't evaluate the arrangement of monsters on the battlefield and how many are likely to be caught in an AoE spell, so it would be down largely to chance whether an AoE rather than a single target is more beneficial to the enemy AI. And yes, it will be immersion breaking for the enemy mage to cast AoE haste on a random goblin or whatever when there's a high level fighter in LoS but still outside the AoE, so the scripts will still need to be a bit selective even with an AoE. The player always makes better use of AoE magic (beneficial or damaging) than the AI. It's useful for a mage to be hasted if only to be harder to catch (and to have six attacks per round with Melf's Minute Meteors rather than five). Single class priests actually benefit more from Haste, relatively speaking, than warriors, as they can buff themselves to high strength and low THAC0 values, and use decent weapons, but lag sorely behind fighters in APR; a Hasted fighter might go from 3-4 (if dual wielding) to 4-5, an increase of between 25 and 33.33...% for a priest Haste will most likely double their APR (except for priests of Lathander where it's more like a 50% increase) and help them land more attacks (highly damaging, once priest strength enhancing spells are factored in) before their buffs run out.

Definitely the first, but less so the second. If Haste is single target it should occupy a lower priority slot in the scripting block, alongside the other 3rd level spells, probably. I believe the consensus is that some SCS script conditions really do need a rewrite as of the current version, for instance Lia's game breaking tendency to injure herself and turn hostile in the Ducal palace. In any case the AI doesn't - and can't - really evaluate the utility of single target vs AoE spells even with SCS, it's just too complex to keep track of where other actors are in comparison to your main target on the Infinity Engine, whereas a player can eye the situation up and make that decision in a second, it's the same reason enemy thieves can "backstab" you from any direction.

If I'm not wrong that could be extended to vampires in the recent versions of EE (even the old versions of ToBEx), they won't suffer spell disruption from Cloudkill if immune to poison damage. I don't believe SCS gives the invoker kit to any vampire, though.

Getting trapped "under" creatures with big selection areas can definitely happen on the original engine but seems more common with EE from all reports, along with possibly related pathfinding problems, it's evidently an engine level problem in any case which means there's unlikely to be a clean fix forthcoming from the community soon. Old school way of preventing this bug, rather than teleporting directly to the character, the creature with teleport abilities spawns an undetectably invisible small creature which is scripted to stick close to the least protected character in sight (high movement rate) switching from MoveToObject() over to RandomWalkContinuous() when within a range of about 4, this little guy acts as nothing but the target for larger teleporters. Unfortunately this is not suitable when there are multiple large creatures trying to teleport in an area, gated balors for instance. A possible solution is to rework the teleporting so that the creature: Polymorphs into a smaller form like bat Gains unbreakable invisibility, untargetable, damage immune, high movement rate Flips back to normal when within a certain range of whoever they were moving toward As I said, unlikely to be a clean solution in the immediate future.

Balance wise, if I had my preferences, both Hardiness and Defensive Stance would be completely revised to double hp for the HLA (like Tenser's Transformation) and for the stance to grant temp hp of about 5 + 3/level (up to 125 at the level cap). This would allow a plethora of wearable items or wielded weapons to be sources of physical damage resistance without worrying about the immunity problem (you've only got so many item slots), since the range of classes (and kits) who get Hardiness/Defensive Stance is a smaller subset of those who could use these items. Unfortunately, to avoid AI glitches it would need to come late in the install order and every in game script block referencing the conditions for use of Hardiness and Defensive Stance would need to replace the check for physical resistance with a different check for an associated scripting state. It would be slightly less of a headache than reworking Haste as discussed in the other thread, as we've only got 2 spell-like abilities to check for by filename, but numerous sources of the haste opcode.

That should work quite robustly for PCs because of durational effects taking precedence over equipping effects. However: Need to make sure all boot-equivalents in game actually set to a value rather than increment. Need to make sure it applies to all player usable sources of Haste, oils of speed, Mazzy innate etc. Monsters subject to Haste spells will move at hasted PC speed rather than double their natural speed, when some are quite a bit faster or slower normally (a filter for the movement rate modification to affect only PC races is easy enough to add, including vampires I guess for EE, vampires are fast anyway). So this fix requires editing more files than just the boots, but is probably a safer option overall.

My version is capable of dealing with spell protections, but not a Protection from Magic scroll unless the separate SCS component to make that removable by Spellstrike is included (I feel that the scroll duration is the main issue, it's far longer than in PnP). Much like with dragons, which do need a means of stripping characters who are protected from their breath and physical attacks, so some degree of access to actual magic is needed, but the battle should still revolve around those uniquely Draconic (or in this case spooky undead) threats. I wouldn't even mind seeing (some) dragons get "Lair actions" - based upon their color type - as in 5th ed, to get around the usual 1 spell equivalent action per round limit that lets the party get ahead of them.

Original Melissan is immune to Haste, like a monk, although she'll cast it on her gated demons, Ascension Melissan is already perma-Hasted, doesn't caste Haste (the alu-fiends she may gate in do, they won't appear in the original game). The boots are balanced if and only if they don't stack with Haste, the number of boots isn't the real issue. From early-mid game unless soloing or playing in a party with no arcane casters your characters will usually be hasted in any noteworthy battle, but if movement rate from Haste stacks with the boots some (and eventually probably all) of them will have not only Haste (which they'd have anyway) but the additional advantage of quadruple speed. Trust me on this. It should also be noted that in SCS the werewolf and greater werewolf "tokens" of the shapeshifter kit likewise grant permanent haste, as do the forms of fire elemental, salamander and spider.

By default in SCS it's a save vs death at -5, although really seems like it should be a save vs spells or no-save as in my version. If the demilich has a lot of magical protections, I'll concede that a save is probably necessary because you'll need a few rounds to strip it and make it vulnerable to damage. Otherwise, it's a race against time to see how much damage your party can do the highly resistant skull as it picks off characters one by one...

This thread wasn't asking our opinions on the value of Haste relative to other 3rd level spells, as all experienced players know that it particularly shines. The discussion was about how Haste could be reasonably nerfed as part of SR purview of balancing the spell system without breaking AI scripts or worsening the existing imbalance. Please avoid making GPT-like responses that only address keywords rather than anyone's arguments.

I'd be fine with that. It will increase audience reach to have it appear in a better known mod. My scripts probably have too many OR() conditions in the targeting blocks - it doesn't slow things down too much, because they're fought alone - mostly in identifying PCs with +4 weapons as threats, however since those are auto-detectable by stats on an SCS install the block can be pared down considerably.

This is how it was (although with type 2 haste) in original BG prior fixpack, it's also how Improved Anvil handles it; although the boots are far harder to acquire - or produce rather - than in vanilla or even SCS. In my view it's in fact more balanced than a movement rate bonus that stacks with Haste, the boots explicitly don't stack with haste in PnP. An item with perma-Haste (type 0 haste anyway, APR incremented by 1 and capped at 6) is powerful, shall we say, on par with the Girdle of Hill Giant Strength. Quadrupled movement rate on the other hand makes a character practically unkillable by enemies reliant on melee attacks. Of course, it's not a solution as far as scripting goes, because a character with the boots and nothing else would be STATE_HASTED for the purpose of AI dispel checks. On the other hand, the boots might legitimately be a good candidate to attach the current SR pseudo-haste onto, in addition to preventing the Haste spell and opcode while worn, and either removing the effects (on the EE engine) or preventing the equipage of boots of speed if currently hasted (on classic). This circumvents all the above nonsense entirely. However the PnP version in 1st and 2nd edition actually doubled APR, equivalent to mass Improved Haste, although even a year of aging isn't as big a deal if a gray elf PC for example (although it's still hardly a spell to be used regularly). I think it's never been properly balanced, the balancing act is that if the party has Haste, enemies (of appropriate level) should too.

I suggested xp value rather than level because there are some creatures with disproportionately dangerous physical attacks relative to their HD (like mindflayers - although SCS does raise their level - and the aforementioned ghasts). Of course there are other monsters whose threat level is hardly increased by haste and would need to be filtered by class/race (like beholders, ofc the Twisted Rune encounter is about the only case where a mage might cast haste on a beholder). I can understand that clerics need to make complex choices about who to deliver a Heal spell to, because they've potentially got it memorized by level 11, but on the other hand it's the 2nd highest spell tier for clerics, and near the top priority even for 25th level clerics. A mage however would be casting Haste when their script has reached a point indicating a 3rd level spell is the most appropriate to use (besides Remove Magic which would typically be used earlier), either because they've used their higher level spells, can't see a suitable/vulnerable target for high level magic or are under Improved Alacrity. This would be equally true of 8th level mages, 12th level mages and 20th level mages.

For a spell like Regeneration, break the effect up into 6 second duration subspells consecutively cast, each of which restores x hp every second using opcode #17 with a delay. That's already how SR handles Blade Barrier. If you want to keep the regeneration opcode, halve the value and divide the spell into two concurrently running subspells, one of which would be removed by Haste (a less preferable solution, in my view). Regeneration from items, meh, rarely fast enough to save a character in battle. Poison and disease effects doubling, you know, I think that's a good downside of Haste right there, even if unintentional.

Hmm, how about a trigger like: CheckStatGT(ThirdNearest([EVILCUTOFF]),649,XPVALUE) So Haste won't be cast on anything weaker than a ghast. Or if that's too weak set a threshold of 1999 or whatever else you think worthwhile for an enemy mage to buff.

The problem is threefold. Your character, unless a swashbuckler or kensai most likely doesn't have a damage bonus that could be multiplied, i.e. 130% of zero is zero. Effect order application means an equipping percentile effect on a weapon wouldn't work with timed damage bonuses (such as berserk or other buffs) As kjeron said, the percentage multiplier doesn't work properly for this opcode anyway.

Sure, you can parse and replace scripts at install time, but what about subsequently installed mods coming after Spell Revisions? SCS makes allowances, others might not. Weak haste opcode #16 type 2 just ensures APR are rounded up to the nearest whole number, it will not work well with fractional APR bonuses for this reason (although can only reach 5 attacks per round, type 0 haste allows up to 6) and still doubles the rate at which timed effects tick (as I've said, I think it's easier to work around unwanted doubling of frequencies of in game effects than the scripts that check for hasted states). #317 allows the same types, but is used in vanilla almost exclusively as type 1 - equivalent to Improved Haste.

It genuinely breaks several vanilla game scripts, because some creatures employ Haste as a spell like ability, rather than having it memorized. From MELISS01.bcs IF !Allegiance(LastSeenBy(Myself),GOODCUTOFF) !See([GOODCUTOFF]) See([EVILCUTOFF]) !StateCheck([EVILCUTOFF],STATE_HASTED) !GlobalTimerNotExpired("MelissanHaste","LOCALS") THEN RESPONSE #100 SetGlobalTimer("MelissanHaste","LOCALS",THREE_ROUNDS) ForceSpell([EVILCUTOFF],WIZARD_HASTE) // SPWI305.SPL (Haste) END Gets into a useless endless loop trying to haste a monster which will of course never be hasted if opcode #16 is stripped from haste. That was my point, in earlier SR versions 3rd level Haste was single target, which is fine, that would be a reasonable nerf of a too-powerful 3rd level spell and doesn't cause the AI problems. The problem arises when the opcode itself is changed, not only for vanilla and SCS but for every other mod that introduces new AI scripts and assumes Haste has an associated detectable state.

I didn't mean it as an insult, I know you have a lot of other things going on and it takes time to play through a full campaign which is practically the only way anyone can be certain they haven't inadvertently introduced a bug or missed a case somewhere. Even my much smaller mods sometimes have unexpected compatibility issues.