Skip to content

Improve Lua Wall Detection

You've probably heard me, or other people, complain about this before. Detecting walls in Lua for things such as wall jumps sucks. The currently provided hooks and functions are just not up to snuff for doing anything besides bouncing off or sliding into them. I have three propositions on how somebody could possibly levitate this problem.

  1. PostMobjLineCollide A Lua hook that runs after MobjLineCollide and SRB2's own line collision checks. This hook has four parameters: mobj, line, collided, and texture. The first two are pretty self explanatory, being the same mobj and line used for MobjLineCollide. The collided parameter returns true if the mobj had collided with the line, false if not. Now, this is the main reason for this hook existing. Currently, there's no way to use SRB2's default collision checks and have Lua code run immediately afterwards. Instead, using MobjLineCollide often has you guessing whether or not the mobj actually collided with the line, since the hooks runs even when you're simply passing from one sector to the next with no interference. This can lead to unintended behavior, such as wall jumping in midair. The final parameter is texture. This returns a number from 0 to 2. 0 means the mobj has touched the line's toptexture. 1 means the mobj has touched the line's midtexture. And 2 means the mobj has touched the line's bottomtexture. Why is this useful you may ask? Well, SRB2 has many invisible walls, most being on the edge of thok barriers. However, these invisible walls sometimes do not cover the entirety of a line, such as in Green Flower Zone, instead only occupying the toptexture portion of a line. This is done by simply not setting the toptexture, leaving it at 0. Being able to access what texture of the line the mobj collided with would allow you to figure out extremely easily whether or not the part of the line you've collided with is invisible or not. This would prevent any wall scaling abilities from climbing walls in midair, similar to how Knuckles already does in vanilla. This parameter could also be used for code that only executes upon colliding with a specific wall texture, even if doing so would likely be rare. Although, thinking about it, this parameter could be turned into a function that can be used separate from this hook, which may have more uses in the long run.

  2. Give MobjMoveBlocked More Parameters MobjMoveBlocked is a pretty nice function. It allows you to execute code the moment you collide with a solid object or wall. Problem is, there's no way to know what actually blocked your movement. This is an absolutely baffling decision, and making working with this function for doing anything other than P_BounceMove or P_SlideMove an absolute pain in the butt. While it is possible to store the line collided with in MobjLineCollide, there's no actual way to know for sure if said line was the one that blocked your movement, which often it isn't, considering this hook runs for objects as well as lines, and MobjLineCollide can run for lines that you never would've been blocked by in the first place. So, if we're going to add more parameters to MobjMoveBlocked, what do we add? It's possible for an object to collide with more than one line/object in a single frame, so adding just one or two parameters won't cut it. Actually, just kidding, it will. My proposition is that the two new parameters be collidelines and collidemobjs. Now what exactly are these parameters? Well, they're tables that contain every line and object that you've collided with that frame, respectively. This allows you to iterate through all the lines and objects you've collided with, find the one that's closest, and let you attach to it, among other things. While it might be a pain in the butt to have to work through all the collision code to add this functionality, I feel it could be extremely worth it in the end.

  3. P_FindCollisionLine Now, what is this function? Well, simply it's P_BounceMove or P_SlideMove but with the bouncing and sliding completely removed, only leaving the "finding the wall you collided with" part. This function would return whatever line it thinks you just collided with, and would be used in MobjMoveBlocked much like how P_BounceMove and P_SlideMove usually are. Not much to say with this one, it's pretty self explanatory...hopefully.

Anyways, those are my ideas for how Lua wall detection could be improved. I will probably end up trying to implement some of these myself down the line (heh) if nobody else does, but I just mostly wanted to get my ideas out there. Sorry if it's seems like I'm trying to get one of you to do my bidding or something.