polytope

10 hours ago, subtledoctor said:

It seems you prefer a long duration and single-target, versus short-duration and AoE. But how does a single-target Haste square with AoE Slow? Slow already seems quite strong; this would seem to make it even moreso. 

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.

14 hours ago, subtledoctor said:

You made me doubt myself, so I just tested - you are mistaken. I created a character in unmodded BGEE v2.6.6, and had her cast Haste on herself. Then I attacked Phlydia, who I set to cast Slow instead of her usual Acid Arrow. My Hasted character failed her save, and went straight from Hasted to Slowed.

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.

19 minutes ago, subtledoctor said:

This is not what happens. Slow dispels and replaces Haste. Haste dispels and replaces Slow. 

I made a mod to make it work as you describe, using the Spell Shield effect. 

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.

1 hour ago, Salk said:

If that is correct, couldn't we get to nerf a bit the Haste spell indirectly by having Slow automatically dispel its effects? And to not make the Slow spell too powerful we could make so that Slow would dispel Haste but not Improved Haste.

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.

11 hours ago, Endarire said:

To clarify regarding vanilla haste and attempting to balance it for SR, are we more concerned about players using it against the AI or the AI using it against players/parties?

10 hours ago, subtledoctor said:

I think the aim is to balance the spell as used by the player, without hampering the performance of the AI. 

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.

6 hours ago, Salk said:

My two cents here about Haste being AoE or not is that unless there is compelling reason to make it single target, I think we should stick to the canon AD&D 2nd Ed. version of the spell and keep it AoE. Even if it may be in some circumstances less convenient for the AI than it is for the player.

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).

1 hour ago, subtledoctor said:

I’m not talking about what scripts should do. I’m talking about how to make the spell work best with scripts as they exist right now. I have no idea what current AI scripts look like, my only data point is that scripts right now were written on the assumption that Haste is AoE. And therefore, changing the targeting parameters of the spell will likely be worse for unchanging AI scripts than for human players who can react dynamically to the change. 

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.

2 hours ago, subtledoctor said:

Well, that's why I lean toward keeping it AoE - even if the AI is dumb enough to cast Haste on a tiny goblin, as long as it is AoE then it will also effect the three nearby ogres. It means the AI doesn't have to be selective in its targeting.

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.

2 hours ago, subtledoctor said:

By contrast, having it be AoE is comparatively less useful for the player, since some of the player's party is more likely to be casters who will derive little benefit from it.

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.

10 hours ago, subtledoctor said:

Doesn’t work in pre-EE games. 

Having slept on this, it seems there are a few hard rules for this to work best with SCS and other scripts:

1) Should actually use opcode 16

2) Should be AoE

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.

15 hours ago, jmerry said:

lich|rakshasa

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:

1. Polymorphs into a smaller form like bat
2. Gains unbreakable invisibility, untargetable, damage immune, high movement rate
3. 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.

On 8/31/2023 at 4:03 AM, jmerry said:

This might need some adjustments to other resistance sources; a level 20 dwarven defender wearing full plate reaches 100% physical immunity when using Defensive Stance, for one. No fuss, just one item you were going to use anyway and the kit's core abilities. 100% physical immunity is virtually impossible to get in the standard game (there's a bug with the Wish version of Hardiness, and that's about it), and it just does crazy things on a tank.

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.

9 hours ago, DavidW said:

You could give Haste a 126 to set movement speed to a fixed (normal) amount before applying opcode 16.

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.

15 hours ago, DavidW said:

- Spell Immunity: Abjuration is a perfect counter to the vanilla Demilich's attacks (once you've saved against the original howl) and so sending in a character with SI:Abj to whittle it down gently is a pretty-much-guaranteed success strategy

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.

On 8/25/2023 at 1:16 AM, subtledoctor said:

 Apart from dumb scripts like Melissan’s who can spam it endlessly… but even there, if an enemy is going to cheese it endlessly, making them repeat it every 30 rounds doesn’t offend me. If that would be disruptive, the mod can just selectively apply permanent Haste to her, like Karhk.

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).

3 hours ago, Salk said:

I'm with Bartimaeus (and subtledoctor) on this.

About the Boots of Speed: I don't think kreso's idea was so insane if we were talking of a unique item, but if I am not mistaken, it is possible to acquire several copies in SoA/ToB. If I remember correctly there is a way to get two of them in BG1 as well.

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...

7 hours ago, Endarire said:

Haste is a great early game force multiplier.  Yes, you may be able to win a fight with a single fireball or skull trap using that same level 3 slot, but haste as it is has the benefit of being useful outside of combat for running more quickly across maps.  (Haste spam was how I got through much of point-to-point exploration, like in towns.)  Haste is a spell that can make the entire party feel important, and it's something that's just assumed to be always on at a certain point.

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.

19 hours ago, DavidW said:

I like quite a lot of this. How would you feel about me borrowing some of it for regular SCS demiliches? 

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.

18 hours ago, subtledoctor said:

I do recall kreso experimenting with Haste a fair amount in those years - last I heard from him he had the rather insane idea (IMHO!) of giving Boots of Speed a full-on perma-Haste effect, APR and all, in IR. But that never ended up happening.

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.

18 hours ago, subtledoctor said:

My take: the PnP spell has a crazy balancing mechanism (aging you a year); any BG version lacks than feature so we are necessarily dealing with a regional variant of the PnP spell. So I can justify deviating from PnP here. 

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.

1 hour ago, DavidW said:

You can do that (or base it on level, which is easier to read and doesn’t get confused by summons).

The problem is that a sensible threshold depends on the level of the caster. You can handle that I do it for healing spells - but it’s quite cumbersome.

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.

17 hours ago, subtledoctor said:

I don’t understand how.

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.

16 hours ago, DavidW said:

I don't see a simple way to guard against casting Haste on some weak creature, and that's immersion-breakingly stupid.

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.

1. 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.
2. Effect order application means an equipping percentile effect on a weapon wouldn't work with timed damage bonuses (such as berserk or other buffs)
3. As kjeron said, the percentage multiplier doesn't work properly for this opcode anyway.

43 minutes ago, Salk said:

Question about SR's haste opcode replacement: can't a workaround be used at script level?

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.

29 minutes ago, subtledoctor said:

This conversation is useful and I think it is certainly worth a discussion on the SR forum on whether to revert SR to using opcode 16. Especially since this led me to look up the opcode in the IESDP and learn for the first time that there is a “weak haste” parameter that SR could use.

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.

13 hours ago, subtledoctor said:

SR has removed the Haste opcode in favor of movement + APR bonuses for like 10 years. May be suboptimal in some ways but it is a very settled, longstanding change.

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.

13 hours ago, subtledoctor said:

(And in my current install with SR v4b19, Haste is party-wide, it uses the INAREAPA projectile.)

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.