search

GTcreyon / SM63Redux

Code base for Super Mario 63 Redux
https://sm63redux.com
Mozilla Public License 2.0
195 stars 27 forks source link

Make pipes usable again #235

Closed Koopa1018 closed 11 months ago

Koopa1018 commented 1 year ago

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

Koopa1018 commented 1 year 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.)

jaschutte commented 1 year ago

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.

Koopa1018 commented 1 year ago

Hmmmm. I can actually see that working.

Pipes and doors are a special case of Interactable. Would we want all Interactables 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.

GTcreyon commented 11 months ago

Merging this now - we'll fix the overall issue later.