Announcement: Be excellent to each other.


Caravel Forum : DROD Boards : Bugs : Processing order of aumtlich beams
New Topic New Poll Post Reply
Poster Message
Dragon Fogel
Level: Smitemaster
Rank Points: 1634
Registered: 06-21-2014
IP: Logged
icon Processing order of aumtlich beams (+2)  
This is some extremely weird behavior. Basically, when multiple aumtlich beams are pointing at cracked orbs, weird things happen.

This hint thread covers a room that was meant to be based around this behavior, and includes what I was able to figure out about how it works:

-Aumtlich beams are processed in the move order of the aumtlich.
-When a new beam is processed, first it checks if that beam destroys any orbs. If it did, and another beam was blocked by that orb, that beam will effectively "fire again", destroying any broken orbs in its path and turning cracked orbs into broken orbs.
-However, if the unblocked beam destroys any orbs and unblocks any other beams, those beams' effects (at least on orbs) will NOT be checked.

This last point, in particular, has weird consequences.

(The room in the linked hint thread has an unintended solution which should still work if the behavior is changed in a way which results in full chain reactions happening. I don't think any other rooms were made relying on the behavior, but I'm not entirely certain on that.)
10-16-2020 at 12:00 AM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 4720
Registered: 02-04-2003
IP: Logged
icon Re: Processing order of aumtlich beams (0)  
I agree this seems weird, but from my cursory read of your description, this seems an ordering issue and not necessarily a bug.

What do you think the behavior should be?

____________________________
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.
10-16-2020 at 12:08 AM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
Dragon Fogel
Level: Smitemaster
Rank Points: 1634
Registered: 06-21-2014
IP: Logged
icon Re: Processing order of aumtlich beams (0)  
It's the third point that leads to weird behavior: namely, the player can see an aumtlich beam pointing at a cracked orb without damaging it.

I see two ways of making it more consistent:

Option 1: Destroying an orb does not result in any other beams passing through that orb being processed at all. This would still result in weird behavior but it would be easier to understand - basically, each beam is processed exactly once. The room in the linked hint thread would become impossible, but allowing the aumtlichs two turns of gazing instead of one would make it possible again. However, this might have an impact on other rooms that don't use the behavior to the same ridiculous degree, but incidentally involve multiple aumtlich looking at cracked/broken orbs.

Option 2: Any time an orb is destroyed, check the effect of beams passing through that orb. I'm not sure how difficult this would be to implement, or what this would do to processing times in rooms with a lot of beams and orbs, but HAs could say "don't do that" if the latter is a problem.
This would not affect solvability of the room in the linked hint thread, though it would break demos.
10-16-2020 at 12:20 AM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 4720
Registered: 02-04-2003
IP: Logged
icon Re: Processing order of aumtlich beams (0)  
Dragon Fogel wrote:
It's the third point that leads to weird behavior: namely, the player can see an aumtlich beam pointing at a cracked orb without damaging it.
Thanks for the suggestions. I agree this scenario looks weird visually, but I don't consider it a bug. It is a movement order issue, which I agree we don't want too many of, but that doesn't mean we should try to stamp them all out at this point.

Edit:
-When a new beam is processed, first it checks if that beam destroys any orbs. If it did, and another beam was blocked by that orb, that beam will effectively "fire again", destroying any broken orbs in its path and turning cracked orbs into broken orbs.
Actually, I don't believe the game logic works like this. (Please set me straight on this point if I'm missing something.) My understanding is that in CDbRoom::ProcessAumtlichGaze(), each beam is processed in sequence, fully applying any effect it has on the room, and that's it.

Maybe there's another issue here...

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

[Last edited by mrimer at 10-16-2020 01:06 AM]
10-16-2020 at 12:42 AM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 4720
Registered: 02-04-2003
IP: Logged
icon Re: Processing order of aumtlich beams (0)  
After a quick debugging session, I think there is some other kind of bug in the engine.

In `CCurrentGame::ProcessReactionToPlayerMove`:
1) this->pRoom->ProcessTurn is called, which in turn calls PostProcessTurn at the end,
2) then PostProcessTurn is called a second time at the end of the method.

The aumtlich gaze effect is performed in each call to PostProcessTurn. This makes it happen twice, which doesn't seem right. I'd expect it to be performed only once each turn.

Skell, I believe you added the additional call to PostProcessTurn in (1) because the method call has "this->" prepended. Can you trace back what the rationale for that addition was? It might have been in a recent PR, but I can't recall and don't have time to look atm, but I can check the commit history later if you don't get to it before I do.

It seems we need to refine this logic, either calling PostProcessTurn in only one spot, or invoking the aumtlich gaze logic in only one of these two places, or something like that. I'm confident you'll probably know exactly what's going on here.

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

[Last edited by mrimer at 10-16-2020 01:08 AM]
10-16-2020 at 01:03 AM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
Dragon Fogel
Level: Smitemaster
Rank Points: 1634
Registered: 06-21-2014
IP: Logged
icon Re: Processing order of aumtlich beams (+1)  
I vaguely remember that the second check was added in order to account for situations where an aumtlich beam is blocked by a door that opens late in the turn.

In one of the test builds, it was causing an issue where cracked orbs were being hit twice in the same turn and therefore being destroyed. Maybe this is something similar?
10-16-2020 at 01:25 AM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
Chaco
Level: Smitemaster
Rank Points: 3416
Registered: 10-06-2005
IP: Logged
icon Re: Processing order of aumtlich beams (+1)  
I'm not skell, but it may have something to do with these earlier fixes to cases where an Aumtlich gaze needed to go through a black door that was opened at the end of a turn, and hit the player and freeze them:

http://forum.caravelgames.com/viewtopic.php?TopicID=39350
https://forum.caravelgames.com/viewtopic.php?TopicID=40659

____________________________
Quick links to my stuff (in case you forgot where it was):
Click here to view the secret text

10-16-2020 at 01:25 AM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
skell
Level: Legendary Smitemaster
Avatar
Rank Points: 3500
Registered: 12-28-2004
IP: Logged
icon Re: Processing order of aumtlich beams (+1)  
I remember that issue. So to let me put it in my words and restate the problem, the original issue was that aumtlich beams unblocked by a very specific late-room processing caused a situation where the aumtlich beam was drawn to hit the player but would not actually stun them.

My reasoning to change this was to maintain the illusion of simultaneousness, by making their beams fire once more at the very very end of everything.

Thinking about this, given how edge case it was it might've been a better solution to store in Aumtlich monster the location where the gaze ended and just draw the gaze only up to that position.

Now though? I'd modify it so that the additional beam-pass has no capability to destroy or interact with anything other than freezing doubles/player.

____________________________
My website | Facebook | Twitter
10-16-2020 at 08:34 AM
View Profile Send Private Message to User Send Email to User Visit Homepage Show all user's posts High Scores This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 4720
Registered: 02-04-2003
IP: Logged
icon Re: Processing order of aumtlich beams (0)  
Okay, I think this all makes sense to me. Thanks for getting me up to speed. That all sounds accurate.

I like your idea.

More brainstorming (for completeness; not necessarily suggesting we implement this approach, because it probably won't give anything more than in your proposal): Each turn, maintain the set of room tiles processed for an aumtlich beam on the first pass, then skip over (re)applying any effect on these tiles in the second pass (while seeing where the beams can continue on beyond them and applying the effect further on). Logic may end up somewhat complicated.

____________________________
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.
10-16-2020 at 03:58 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
mauvebutterfly
Level: Smitemaster
Rank Points: 542
Registered: 05-03-2015
IP: Logged
icon Re: Processing order of aumtlich beams (+1)  
Since you just mentioned doubles/player I wanted to ask if that would include stalwarts and soldiers, because it probably should.

____________________________
106th Skywatcher
10-16-2020 at 05:03 PM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
skell
Level: Legendary Smitemaster
Avatar
Rank Points: 3500
Registered: 12-28-2004
IP: Logged

File: Aumtlich beam repeat.hold (1.3 KB)
Downloaded 2 times.
License: Public Domain
icon Re: Processing order of aumtlich beams (+3)  
PR

Second pass of aumtlich gazes will no longer break orbs, only light fuses and freeze doubles/player.

____________________________
My website | Facebook | Twitter
10-19-2020 at 08:25 AM
View Profile Send Private Message to User Send Email to User Visit Homepage Show all user's posts High Scores This architect's holds Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 4720
Registered: 02-04-2003
IP: Logged
icon Re: Processing order of aumtlich beams (0)  
mauvebutterfly wrote:
Since you just mentioned doubles/player I wanted to ask if that would include stalwarts and soldiers, because it probably should.
Right. The scope of entity impact will remain the same as it is now.

____________________________
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.
10-19-2020 at 05:42 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
kieranmillar
Level: Smitemaster
Rank Points: 2272
Registered: 07-11-2014
IP: Logged
icon Re: Processing order of aumtlich beams (+1)  
Can confirm in 5.1.1.alpha.2020-10-29 that in skell's example hold everything works according to how the scrolls say they should.

[Last edited by kieranmillar at 10-31-2020 07:54 PM]
10-31-2020 at 07:54 PM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
Kalin
Level: Delver
Avatar
Rank Points: 64
Registered: 01-25-2016
IP: Logged
icon Re: Processing order of aumtlich beams (0)  
skell wrote:
PR

Second pass of aumtlich gazes will no longer break orbs, only light fuses and freeze doubles/player.
What about freezing the aumtlich itself?

Scenario:
Mirror, Beethro, Sword, and Aumtlich in a line, Beethro moves to the side.

Current behavior has the aumtlich also sidestepping instead of getting frozen by the mirror. Is this what we want?

I noticed this in Under the Mountains: Training Grounds: 1E.


[Last edited by Kalin at 12-26-2020 03:15 PM]
12-26-2020 at 03:14 PM
View Profile Send Private Message to User Show all user's posts Quote Reply
Dragon Fogel
Level: Smitemaster
Rank Points: 1634
Registered: 06-21-2014
IP: Logged
icon Re: Processing order of aumtlich beams (+1)  
What specifically happens is that the order of processing is:
-Aumtlich makes its move
-Game checks if the aumtlich gets frozen

I believe this was done to make it harder to freeze aumtlich, though it's only slightly trickier in most cases. Intentional or not, changing it would break a lot of demos. I'm not sure if there are rooms which depend on it - maybe something in Advanced Concepts 2 does.

This has nothing to do with the second beam pass, which is the main issue in this thread. Although I guess I don't know off the top of my head if the second beam pass can freeze aumtlich, since I haven't done much testing in the beta.
12-26-2020 at 03:49 PM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
New Topic New Poll Post Reply
Caravel Forum : DROD Boards : Bugs : Processing order of aumtlich beams
Surf To:


Forum Rules:
Can I post a new topic? No
Can I reply? No
Can I read? Yes
HTML Enabled? No
UBBC Enabled? Yes
Words Filter Enable? No

Contact Us | CaravelGames.com

Powered by: tForum tForumHacks Edition b0.98.8
Originally created by Toan Huynh (Copyright © 2000)
Enhanced by the tForumHacks team and the Caravel team.