TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged

File: DROD Bomb Explosion.patch (11.1 KB)
Downloaded 41 times.
License: Public Domain

This was actually first posted by Briareos in the 3.1 TCB Patch Candidate thread, but during my double check of things, I noticed this hasn't been fixed.

Essentially, because Black Gates drop as soon as tarstuff is destroyed, and bombs destroy tarstuff immediately, the order that bombs explode can cause some bombs to penetrate Black Gates while others don't. The example room Briareos brought up was "Don't Kill The Messenger : Messenger 1 : Entrance", which is now impossible to complete.

I'll look and see how I attempted to fix this last time I saw it (I didn't get a diff of the fix and then forgot about it and deleted the directory when the Build 54 source came around, so I'll have to recreate it), but I think my proposed approach was to create a CoordSet of squares affected by explosions and *then* deal with those simultaneously.

That seems to be the only gameplay-specific bug I could see left over from the thread. There's still the more thorough way of removing briar roots to implement and a bunch of what would be valid Feature Requests, but this one seems important to get out of the way quickly, especially given Schik's Great Demo Verification is fast upcoming.

EDIT: ...*or* I could remember that I haven't emptied my Recycle Bin in a while, and that the directory was still sitting there. That cut down time taken quite a bit.

Anyways, reimplemented the fix, did a quick retest: no demo breakages on my end, nothing looking untowards, and the bug Briareos brought up becomes fixed. Attached the changes to this post.

The basic idea behind the changes was to split ProcessExplosionSquare to ExpandExplosion (which is designed to find out which squares need to be affected by an explosion) and ProcessExplosionSquare (which looks at an individual square and destroys/activates what's on it). ExpandExplosion basically works just like ProcessExplosionSquare used to, except that it treats all squares that should explode as if they were orbs, adding them to the explosion coordset. This coordset is then used by ProcessExplosionSquare in exactly the same way that the activations coordset was iterated through and passed to ActivateOrb.

There's a few kludges that I had to do to make this work:

1) CueEvents had to be passed to ExpandExplosion as well because Tarstuff wanted to know what direction the bomb that destroyed it was, so that it can make the pretty shrapnel fly the right way. The actual destruction of Tarstuff is held off until ProcessExplosionSquare is dealt with.

2) Obstacles had to be allowed to be processed as part of an explosion, just like orbs, because even though the obstacle can *stop* an explosion, breakable walls that the obstacle was on top of could still have been destroyed in the first check. If walls were protected by obstacles on top of them, this wouldn't be a problem. Not sure if this should be changed - I mean, it makes a kind of sense that the wall covers more area than the obstacle and as such could be exploded out from under it, even if the obstacle protects everything else on the square.

===

The only routines that used ProcessExplosionSquare were BombExplode in DbRooms.cpp and Explode in Phoenix.cpp, and I've updated those to work. As always, hope I haven't missed anything.

EDIT 2: Oh, one thing did occur to me. Fegundos setting off bombs have their explosion completely resolved *before* a bomb chain reaction occurs. I wasn't sure whether this was a bug or not, so left that functionality as is. This does mean that a Fegundo explosion can destroy tar (and drop a Black Gate) or toggle an orb, and if it activates a chain reaction on the same turn, the bombs will be able to make use of the changed state (or even, for example, retoggle the orb). It was like this in 3.0, so no changes there.

If we decide that this is not what we want, however, we'd need to pass the explosions CoordSet to ExplodeBomb, as well as what squares should be marked "FegundoSafe" (in order to prevent the Fegundo from blowing up itself... although on further reflection, I don't think even this causes ash created on this turn to blow up, so it might not even be needed).

That said, such a change is highly debatable, and we can probably leave it as is. But it seemed prudent to mention it.

---

[Last edited by TFMurphy at 10-10-2007 02:00 PM]

mrimer
Level: Legendary Smitemaster

Rank Points: 5064
Registered: 02-04-2003
IP: Logged

Before I apply your fix, I'd want to make sure I understand completely. The krux of the matter is that, due to Gerry's (iirc) 3.1 change where destroying tar now causes black gates to toggle immediately, now explosions no longer expand completely if a black gate blocks them in mid-explosion, right?

If that's the issue, I agree this is a new bug and needs to be fixed right away in a patch.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged

Either blocks or unblocks. As an example:

.......
....TT.
....TT.
...O...
...#...
.......
.......

In this example, if the bomb (O) explodes, it will destroy the Tar (T) and the Black Gate (#) will fall before the southern area of the explosion is processed, allowing the bomb to hit the entire 7x7 area.

But in this one:

.......
.......
...#...
...O...
.TT....
.TT....
.......

...the explosion checks the northern part first and the Black Gate blocks the explosion. The Tar will be destroyed when the southern squares are processed, but by then it's too late.

The 2nd example is the correct one using the same logic orbs were changed: state changes to obstacles shouldn't occur during the middle of an explosion. As such, I made an attempt to generalise the fix, and make the results of an explosion use its own routine after expansion has been fully calculated.

mrimer
Level: Legendary Smitemaster

Rank Points: 5064
Registered: 02-04-2003
IP: Logged

I've applied your fix.

TFMurphy wrote:
2) Obstacles had to be allowed to be processed as part of an explosion, just like orbs, because even though the obstacle can *stop* an explosion, breakable walls that the obstacle was on top of could still have been destroyed in the first check. If walls were protected by obstacles on top of them, this wouldn't be a problem. Not sure if this should be changed - I mean, it makes a kind of sense that the wall covers more area than the obstacle and as such could be exploded out from under it, even if the obstacle protects everything else on the square.

This is an unintended artifact of the original 2.0 explosion code logic flow -- I wasn't thinking of the possibility of obstacles on walls when I wrote this. Still, since obstacles block *everything* (right?), then it shouldn't really matter whether any crumbly walls underneath them get shattered by an explosion or not. I guess I'm fine with leaving this idiosyncracy as-is.

EDIT 2: Oh, one thing did occur to me. Fegundos setting off bombs have their explosion completely resolved *before* a bomb chain reaction occurs. I wasn't sure whether this was a bug or not, so left that functionality as is. This does mean that a Fegundo explosion can destroy tar (and drop a Black Gate) or toggle an orb, and if it activates a chain reaction on the same turn, the bombs will be able to make use of the changed state (or even, for example, retoggle the orb). It was like this in 3.0, so no changes there.
...

Yeah, I think we should keep this as-is.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.