Time Stop and Blade Barrier

[jmerry]

As currently implemented, Blade Barrier and similar spells interact very oddly with time stop effects. Freeze two characters in melee range, one with a Blade Barrier (or Globe of Blades, or Circle of Bones, or any mod spell that uses the same mechanics), and the spell triggers several times to no immediate effect ... until stopped time wears off. Then all of those suspended triggers hit at once, for a potential massive burst of damage.

This came up in an SCS discussion; v35 has a tweak that sets Blade Barrier and Globe of Blades to "save for half" instead of "save negates", powerful enemy mages may summon planetars, and those planetars use Globe of Blades and are permanently hasted. Wait, haste? As it turns out, haste doubles the frequency of the blade spells since they use op232. Which means that a planetar standing next to someone for the full duration of a Time Stop piles up about five blade hits - about 140 average damage on a successful save. Ouch.

This feels wrong. Spells like Blade Barrier are meant to create a hostile area, not pile up massive bursts of damage.

[The mechanics: The blade spells establish an op232 effect that casts a subspell once per round if anyone is sufficiently close. That subspell deals damage as its only effect, and has a projectile that hits everyone around the caster with no travel time. In a time stop, the op232 effect triggers normally but the projectile is suspended and can't connect until time resumes. At which point all the suspended instances of the damage subspell hit in the same tick.]

Anyway, I had an idea. Add a second effect to the damage subspell, granting op206 immunity to itself for a duration of zero. That way, the first hit deals damage and any additional instances of the spell in the same tick are silently blocked. I ran a quick test, and it seemed to work well.

Thoughts? Other Time Stop interactions that could use a look?

[polytope]

A suggestion, Time Stop could grant global immunity to all creatures on the map against Blade Barier / Globe of Blades for a duration 1 second longer than the Time Stop itself, this can also be applied to other annoying things that tick during time stops, like for instance lava floors in a couple of places, which were implemented as .spl files if I'm not mistaken.

Note that this problem is realistically only seen with SCS, thus it is tenuously fixpack material, I don't recall a lot of situations in base game where you're fighting enemy planetars and someone then casts Time Stop (Dorn's quest in ToB maybe? Never played it.), besides the fact that the inescapable overpoweredness it's mostly due to the "save for half" option also added by SCS to BB/GoB spells, thus six ticks (because planetars are permahasted, that's another sort of bug) each for 5d10 unavoidable damage when the Time Stop ends. RIP.

Really, the blade spells being accelerated by Haste is almost as weird as the Time stop interaction, or maybe not, since you can cast Haste on a Mordy sword.

Edited July 3 by polytope

[CrevsDaak]

18 hours ago, jmerry said:

Thoughts?

I am very biased in supporting this particular change so I think that it should go in, but I'm not sure if it warrants being base game fixpack material.

[rigidjelly]

Full time lurker reporting in.

I believe focusing on the timestop->planetar->instant GoB->giblets interaction muddies the waters somewhat. For the sake of clarity

1. Haste is bugging out a spell (again). Ideally this would be fixed, though as far as I understand the closest anyone has gotten is by tearing out the haste opcode from the spells and replacing it with separated pieces that simulate the intended effects. (source: I am not a coder)

2. Timestop is bugging out a spell (again). If the tweak jmerry proposed works, and, better yet, if it can be extended to other janky interactions, that sounds to me like a bugfix falling under either "Spell stacking fixes, both self- and cross-" or "Resolving conflicts between spell description and what the spell actually does" straight from the list CamDawg posted in the "What exactly are we trying to fix?" thread regarding how fixes were broadly determined for the BG2FP.

Super-duper-ideally timestop would freeze all spells/spell durations, but that's probably code stuff and outside the scope of a fixpack.

[polytope]

4 hours ago, rigidjelly said:

1. Haste is bugging out a spell (again). Ideally this would be fixed, though as far as I understand the closest anyone has gotten is by tearing out the haste opcode from the spells and replacing it with separated pieces that simulate the intended effects. (source: I am not a coder)

No, decoupling the haste opcode from the spell is the worse solution (besides the fact that Planetars' perma-hasted states don't derive from a Haste spell), because scripts check for STATE_HASTED and all such scripts are then broken.

A much better solution to prevent unintentional spell tick frequency increase is to replace opcode 232 with time-delayed 146.

[Galactygon]

On 7/4/2024 at 1:25 AM, CrevsDaak said:

I am very biased in supporting this particular change so I think that it should go in, but I'm not sure if it warrants being base game fixpack material.

Seconded, a zero duration effect is a great idea!

On 7/11/2024 at 11:59 PM, rigidjelly said:

Super-duper-ideally timestop would freeze all spells/spell durations, but that's probably code stuff and outside the scope of a fixpack.

Yes, except for the caster and those immune to a time stop. There is no way around a code fix unfortunately.

[Isewein]

I've consciously used this as a tactic a couple of times. Not sure whether it can be justified as an in-game exploit or not. Mechanically, of course, Time Stop freezes everyone else, but I suppose in reality the blades should get frozen with them - *unless* the Blade Barries is on the caster, in which case I would argue, if I were the GM, that it continues moving with the PC just as their clothes do.

Edited July 13 by Isewein

[RoyalProtector]

This sounds to me more like a tweak than a fix. The underlying problem is in the code, which is that Time Stop does not stop ongoing effects' duration or effects per round. Without that being fixed, any fix of this sort will be hacky and underwhelming. Like, yeah, sure, it is a ton of damage, but the timer is still ticking and those things also go to waste. I would rather just... not do that, to not make things too easy or unfair.

(Though I believe I recall poisoned enemies stop receiving poison damage in TS, which is something that really annoyed me in my Shadowdancer playthroughs since Shadowstep uses the time stop opcode).

13 hours ago, Isewein said:

*unless* the Blade Barries is on the caster, in which case I would argue, if I were the GM, that is continues moving with the PC just as his clothes do.

I also do think this is a good point. Is there really any reason to think the caster would freeze magical effects on themselves? Are their weapons frozen? Their non-living tissue? But it's rather a matter of how fair this is, which is why it's best as a tweak, in my opinion.

[RoyalProtector]

And... That bug will not be fixed, unless their code becomes open source, methinks.

[CrevsDaak]

On 7/12/2024 at 2:18 AM, polytope said:

A much better solution to prevent unintentional spell tick frequency increase is to replace opcode 232 with time-delayed 146.

Yeah, this is what I did. Works well enough, although the way in which spell deals damage varies a bit gameplay-wise. It gets applied on an exact timer instead of when creatures enter the area, which can lead to potentially dealing less damage in some weird cases, but it makes it more reliable and predictable in general (in fact, you actually deal more damage vs. multiple targets moving in and out of the effect's range, because the area check on opcode 232 has a full round of cooldown). However, this difference in behaviour can be remedied if desired (I wouldn't bother), by adding a 6 seconds immunity to being hit again by it, and making it go off every second, but that's just pointless I think, since it'd make the spell deal way more damage than in vanilla.

I need to polish it a bit more before it's comparably as-good as op232, but it definitely solves the Haste-related issues (and the infinite op232 application while paused bug I was getting on wine'd BGT). Particularly, I need to prevent it from stacking with multiple casts of itself (although due to addition of the op206 effect suggested on the OP this shouldn't be an issue anymore, at least in how stacked casts would impact gameplay), but I think putting the opcode 146 effect pile on a secondary spell (only real way to prevent this spell from stacking with itself via a self-targeted op206 without killing upcoming ticks) is a better idea either way.

On 7/13/2024 at 1:15 PM, RoyalProtector said:

I also do think this is a good point. Is there really any reason to think the caster would freeze magical effects on themselves?

This came up on the topic that spawned the OP and I've already mentioned this, not because I like that it works this way, but because I'd rather the game's consistent in how visual effects match the effects and gameplay actions that occur. So, the main issue with letting it run amok during TS is that the BB graphic effect itself freezes, even when active on the Time Stop caster themselves.

[Galactygon]

Yes, it's a fundamental difference between opcode 232 and staggered delayed effects (or via opcodes 272/333) which requires a 5 second protection effect.

1. With opcode 232 and no protection effect (or just a 0-duration one) you can inflict damage with multiple blade barriers if several characters have it active at the same time, but on the other hand it only activates a up to a certain frequency if creatures move in/out of the area of effect.
2. With a repeating spell and a 5 second protection effect you can only have a target be affected once per round, regardless of the number of barriers the target passes through. But on the other hand, the barriers affect more targets if they move in/out of the area of effect. I guess a large number of staggered effects are preferrable if we take into account the haste/slow bug. I forgot if haste/slow affects frequency for opcode 333, maybe opcode 333 is preferrable? @Luke @kjeron

I'm personally a fan of the second method since it's more flexible and less OP in certain situations, but the first method is already consequently used throughout the game. My view is either change all such spells to use the second method or change nothing at all. The 0-duration fix I fully endorse even if we keep the first method, since it's just a fix.

Edited July 15 by Galactygon

[Luke]

@Galactygon

Haste/slow does not affect frequency for opcode 333.

However, Time Stop does not "freeze" opcode 333... This means that in iwdee creatures affected by Shroud of Flame (which makes extensive use of op333) keep suffering fire damage during Time Stop... Intended...?

Edited July 15 by Luke

[Galactygon]

As far as damage is concerned, just as much as Melf's Acid Arrow which continues during a TS. Ideally, a TS should also pause any 333s not carried by the caster or any creatures with stat IMMUNE_TO_TIME_STOP and at the same time increment the durations & delays of all effects carried by frozen creatures by whatever duration (ticks) the TS lasts. And recalculate the delay/duration of effects applied onto frozen creatures during a TS (instantaneous effects should still happen if not applied by a projectile). But that's not what's happens.

That being said, Shroud of Flame will still force only one saving throw onto surrounding creatures when TS expires because method 2 is used.

[Jarno Mikkola]

21 hours ago, Galactygon said:

Ideally, a TS should also pause any 333s not carried by the caster

Why ? Why not just all ?

[Galactygon]

Persistent repeating effects like poison, disease and opc272 are paused for frozen creatures but still continue for active creatures (caster & those with IMMUNE_TO_TIME_STOP) during a TS. That is correct behavior; these effects should continue for the active creatures during a TS.