Closed Koopa1018 closed 11 months ago
That's already known. It happens when the pipe comes after Mario in the hierarchy--since execution flows from top to bottom, some part of Mario's code somehow interferes with the pipe's activation. It happens with doors too.
Pre-4.1, I had this fixed by setting pipes' execution order to -1 (so they always ran before Mario), but since the upgrade, it doesn't let me set it lower than 0 anymore...even via code. I have no idea how else to go about this...any thoughts?
Either way, putting the pipe before Mario is an effective workaround.
(And I'd say this bug definitely fits in this PR. Different root causes, but the effect is the same: pipes don't activate when they should.)
If the root issue is the execution flow, could we not invoke the pipe logic from Mario? Or would that over-complicate the code? I haven't had a good look at the Mario logic code.
But to me, the best solution would be to check for pipes within Mario before the flag gets cleared. However this would make Mario implement logic technically meant for pipes.
Alternatively we could have like an array of all flags which have been enabled within this frame for Mario, then the pipe could simply read from that array. But this could be very bad practice as well as other code would more quickly pull from this array rather than doing it 'properly'.
I'd suggest trying to invoke pipe logic inside of the Mario, that seems like the best solution.
Hmmmm. I can actually see that working.
Pipes and doors are a special case of Interactable
. Would we want all Interactable
s handled by the player? Or would we want to make pipes and doors a separate class? (They kind of already are--they inherit InteractableWarp
, which inherits from Interactable
.)
Either way, it's big enough that we really should make a whole separate PR for it.
Merging this now - we'll fix the overall issue later.
Description of changes
Somewhere along the line, pipes were set to no longer monitor the player's layer. This PR simply fixes that, allowing pipes to work again.
Issue(s)
N/A