Thanks @kobus-v-schoor , I figured initially it was something like that.
But, then how do we reach the inconsistency between Round 7 and Round 34?
I would expect both to end up as HIT_WALL (if status is decided based on some precedence as it seems from above).
But instead, one is HIT_MUD (round 7) and the other is HIT_WALL (round 34), even though both hit the same obstacle types, in the same order (ignoring the boost hit going to round 34).
Think I’ve found it, the last block that the player lands on and the “middle blocks” are processed separately:
In your first example the last block the player landed on was mud, so that was the final state since that got processed after the other blocks. In the second example only the middle blocks are special, so then the precedence kicks in. I think this separate last block logic is probably for the “lizarding”, but not entirely sure.
I feel like I’m missing something. Why does this state matter ? Shouldn’t your only concern be the speed you lost ? (or does this state affect score ?)
For me - it’s my pedantic paranoid side.
My state representation is not matching what the current engine is doing. That makes me worried, because then I start questioning what else am I missing?
As explained by @kobus-v-schoor, indeed there is an implicit precedence in the code, being MUD/OIL/WALL. The state will reflect the hit item in that priority.
An inconsistency arises from updating the engine to handle the final block separately to the middle path.
It’s unfortunately one of those problems where we are trying to simulate continuous moment discretely, where every solution has it’s own pros and cons
There is no stacking effect that i’m aware of, so I believe the previous explanation about precedence will still be valid. So yes the mud effects will be applied