[SUGGESTION] What are your thoughts on wallclipping?

Wallclipping in Quake 3 is a nifty feature that works as follows: Every time your character jumps there's a 250ms time window during which your speed won't be stopped by solid objects, which in regular circumstances means you can slide by small edges of walls/ceilings or player hitboxes without losing your speed. In contrast, without it you will be coming to near full stop every time as soon as even 1 unit thin solid makes contact with your hitbox. This has the effect of making the movement feel rigid and clunky.

Here's some extreme condition examples of it in Reflex, the faster you move the longer slides of wall you can clip through:

Here's an example of the same thing happening with ceilings, which I could imagine being beneficial for Xonotic's blaster heavy gameplay:


Wall clipping opens up a variety of options for route access as well as trickjumps. It can be used to prevent overshooting platforms without sacrificing speed or effectively making sharper turns through cramped corridors.

What are your thoughts on it? Would this be implementable in Xonotic? As an experiment at the very least. If anything, this would be a fantastic inclusion and a key element to the custom defrag/Q3 physics for anybody interested in making those mods in the future. Here's mechanical concepts in what would be needed to engineer it:

• A time window (250ms for example) after every jump, during which your momentum is unstoppable. 250ms is roughly half the time it takes for a player to jump and land again.
  
• Cancel the unstoppable behavior if your head (top part of your hitbox) collides with a solid.
  
• ^Unless your jump velocity is higher than normal, ie with ramp/blaster jumps. These latter two parts are to prevent "ceiling magnetization" effect. I'd imagine ceiling clipping to realistically happen only during blaster jumps, so this is kind of a way to prevent intervention with regular movement.
  

  hoothoot.JPG (Size: 28.61 KB / Downloads: 317)

If every jump triggered the wallclip behavior, your character would get glued to ceilings like magnets. Komier's concern is related to Q3's method of getting rid of this, which means you have to have jumped before hand - which makes it difficult to get magneted anywhere. In Reflex same kink is prevented by having wallclip behavior cancelled if your head touches something, which means in Reflex you CAN wallclip straight out of a single jump the way I think Komier wants to.

What Reflex's implementation however does is disable ceiling clips (see video #2) and I think some jump velocity related solution would be a better direction.

I don't quite understand wall clipping that much nor do I know what kind of impact it would have on gameplay. I'm open to seeing what happens.

Basically what I'm proposing is to add a time window for each jump, during which your speed wont be stopped by anything. If during this time window you come in contact with an obstacle and manage to slip by the obstacle in time, you'll carry on as if the obstacle never hit you. The engine would essentially remember what your speed was and would expire after 250 milliseconds.

You'd be less likely to bump into enemies/team mates and lose all your speed when running around.

Some jumps like RA in hub would become slightly easier.

Some ramp jumps in Fuse would become easier and ways you can use them more flexible.

This might also partially fix high ping players losing their speed in teleporters. At least would give high pingers a way to manage them consistently.

The main issue for this would be prediction... We can't predict timed actions, so it would be a nightmare for anyone above 50 ping.

That said, if someone wants to try implementing this, they're welcome to it.

While I can see the appeal of this and have heard many defraggers coming from Q3 vocally plead for this feature I'm not sure it's a good idea to copy Q3 in every aspect. Then we'd also have to reimplement overbounce, etc.And then there's the issue Mario mentioned.

How about doing something inspired by this weird Q-mechanics, but somewhat different?

Let's take a similar time interval, let's say 200ms. If you hit a solid, the component of the velocity vector that is orthogonal to the wall "survives" (this is just an inner product and I reckon collisions are handled somewhat similar to this anyways, as when you hit a wall at a shallow angle you keep most of your velocity orthogonal to the wall and when you hit a wall face on you're pretty much stopped dead in your tracks. Now what to do about the component of velocity perpendicular to the wall? How about not remembering the original velocity and restoring it upon clearing the obstacle but rather decelerating it over a time interval? So if you clear the obstacle very quickly you keep almost all of it. But if you clear it later you keep less. If you exponentially decay it with a time constant of 200 ms you keep half of your speed if you clear it after 200 ms, a quarter of it after 400 ms, etc.. This has the advantage of being a one-frame computation.

That said, if someone wants to try implementing this, they're welcome to it.

Speaking of which, wanna give it a go?

Then we'd also have to reimplement overbounce, etc.

Would we then also have to add vQ3 movement, would we then also have to remove ramp jumps, would we then also have to remove alt fire modes from all of the weapons? Because that's not my angle.

I'm not sure it's a good idea to copy Q3 in every aspect.... ...How about doing something inspired by this weird Q-mechanics, but somewhat different?

What I proposed was already different to Q3 and is more similar to how Reflex implemented it. Imo Reflex feels better other than for the fact that you can't clip ceilings, because they didn't want headbump-double jumps to fuck up. Headbumping is not really common in Xonotic so I'm not sure there would even be any need for head-collision related restrictions that I proposed in OP.

Let's take a similar time interval, let's say 200ms. If you hit a solid, the component of the velocity vector that is orthogonal to the wall "survives" (this is just an inner product and I reckon collisions are handled somewhat similar to this anyways, as when you hit a wall at a shallow angle you keep most of your velocity orthogonal to the wall and when you hit a wall face on you're pretty much stopped dead in your tracks.

Not sure if I understood correctly: Instead of just the expected orthogonal velocity surviving, you'd have some extra perpendicular velocity added to the orthogonal direction? So are you talking about redirecting velocity? How would that then resume the correct direction after slipping by a solid? How do you even determine the right direction? Same direction it was (time window) ago? Or the direction you're looking at? Sounds like you're dealing with more mechanics than is necessary here.

Now what to do about the component of velocity perpendicular to the wall? How about not remembering the original velocity and restoring it upon clearing the obstacle but rather decelerating it over a time interval? So if you clear the obstacle very quickly you keep almost all of it. But if you clear it later you keep less. If you exponentially decay it with a time constant of 200 ms you keep half of your speed if you clear it after 200 ms, a quarter of it after 400 ms, etc.. This has the advantage of being a one-frame computation.

I'd imagine it would just slow you down similar to what nonwallclip-movement does. We'd then have a wallclip feature which nobody would be compelled to use. Also, 250ms is not quite a lot of time. But I agree, it should not be 250ms for the sake of it being 250ms. It should be a time interval that is approximately the time it takes for your character to start falling after a jump, because then you have a reference for it besides an atom watch. If 250ms happens to be the exact time or that, then it should be 250ms imo.

I looked into this a little while ago when the Quake 3 defraggers were at full force. It would require modifying engine code, which is a bit outside my capabilities.
That said, after 0.8.2 we will have the possibility of using the game code for all physics, so this kind of thing might be a bit easier to implement in the near future.

As for how it should work; The only way I can see it working with prediction would be to slow down the player gradually when they collide with a wall, maintaining speed for a set time simply won't work for our physics.

The only way I can see it working with prediction would be to slow down the player gradually when they collide with a wall

Does gradually mean it could be inconceivably slow? Because if you lose near to zero speed, but still slightly slowing down then it would work just as fine.

After thinking a while: I think one problem might be identifying what's a "penetrable solid" and what's a ramp where a collision right after a jump is desirable. If nothing stops you for a time window then would you then perhaps glide through ramps without gaining the height from jumping off of them?

What I wonder is what would actually be the benefit of this? It looks to me like another physics element that, due to its absurdity, causes bewilderment among players that are not used to this kind of feature from other games - similar to strafe jumping - and that would require yet another whole chapter in the Newbie Corner to explain it. Would it actually add more desired features (keeping speed despite accidental bumps) than undesired ones (getting glued to walls for a short time)? Also, isn't it part of the skill to be gained NOT to bump into walls when jumping so you don't lose speed?

I think I have not yet fully understood why this is desireable in the first place.

   

In the picture, substitute ceiling for wall in the case of vertical skimming. I'm wondering if the calculation is done at impact, can you choose to only magnet when you're going to skim and then choose to not magnet if you're not going to make it?

I think I have not yet fully understood why this is desireable in the first place.

Wallclipping is a simple mechanic that prevents crashing into tiny objects. It complicates nothing in the gameplay, just makes movement smoother for players of any skill. It's desired, because it makes no sense for a 200kg erebus speeding at 900 qu/s to come into a full stop when it bumps into a hair. Think of this feature as a way to make the characters feel like they actually have some mass in them.

Would it actually add more desired features (keeping speed despite accidental bumps) than undesired ones (getting glued to walls for a short time)?

The gluing action is simply the means to get the desired effect for this. If you didn't glue, then you would bounce off of the walls and get redirected. If the speed resumed to the original location from that kind of state, then it would defy all logic. So I can't think of anything smarter than getting glued.

Keep in mind that the first video demonstrates the mechanics under extreme circumstances - to give an idea what's actually happening in bigger scale. That's not how it happens normally. Players usually only clip through corners roughly the size of their own hitbox, most of the time not even that much and you're lucky if you see it actually take place in full speed. You might see huge clipping like that in Defrag/Freestyle, but by comparison it's rather uncommon in regular gameplay.

Also, isn't it part of It looks to me like another physics element that, due to its absurdity, causes bewilderment among players that are not used to this kind of feature from other games

I remember countless times where I ran alongside a friendly in TDM, then came to a full stop suddenly because I ran into my team mate from behind who was moving a couple qu/s slower than me. There are many instances in general where I've bumped into other players because they wiggle around unpredictably + ping. Yes, players are walls too.

What causes more bewilderment than wallclipping is the unintuitive size of your hitbox, invisible playerclipped walls and things that you simply can't dodge with your own terms.

I'm wondering if the calculation is done at impact, can you choose to only magnet when you're going to skim and then choose to not magnet if you're not going to make it?

Are you asking hypothetically or how it works in Q3/Reflex?

As far as I know there's no calculation of any kind, you simply can't be stopped by anything for (duration of time) after each jump. In Q3 you have to land before you do the magnet jump. In Reflex, you don't magnet at all any which way if your head (top part of your hitbox) hits a ceiling.

What happens with fall damage/ damage if you bump into a wall with high enough speed? Would that damage also be delayed by 250ms?

Also, especially in the second jump of your CPMA video, it is extremely noticable that you hit the wall, but suddenly (and without a explainable reason) you accelerate upwards. If this feature gets implemented, I think the time window should be smaller.

Also, especially in the second jump of your CPMA video, it is extremely noticable that you hit the wall, but suddenly (and without a explainable reason) you accelerate upwards. If this feature gets implemented, I think the time window should be smaller.

It doesn't accelerate, I never lost the speed there in first place. I'm technically in a "glue limbo" there. There's the time window of 250ms after every jump, during which you can't be stopped. This means the time between my rocket jump and slipping past the walls is less than 250ms. What I do however lose there during the gluing is vertical height of the rocket jump. It's basically like a regular rocket jump except the wall readjusts the max height of that jump.

What happens with fall damage/ damage if you bump into a wall with high enough speed? Would that damage also be delayed by 250ms?

Technically yeah, you could avoid falling damage from walls assuming you get away from them during the time window. It would not be delayed in itself, it would take place as soon as player loses his velocity, which in turn is the one being delayed.

"Falling damage" in Xonotic happens when your speed drops drastically or when there's a huge shift in Gs right? So it should still work as soon as the speed loss, albeit not instantly on contact with a wall happens eventually anyway. Only instances it happens currently is if you bump into a wall head on. If people were to wallclip, they would hit the walls at an angled directions. You don't usually gain falling damage if you hit walls at an angle in Xonotic, you'd have to be going so much faster for that.

On another side note, I think the falling damage in Xonotic is crap. It doesn't seem to be working consistently, specifically because you can avoid drastic G/speed loss by swinging yourself at walls at diagonal angles. And vertically, I don't know why but sometimes even that doesn't always work.

Also, especially in the second jump of your CPMA video, it is extremely noticable that you hit the wall, but suddenly (and without a explainable reason) you accelerate upwards. If this feature gets implemented, I think the time window should be smaller.

It doesn't accelerate, I never lost the speed there in first place. I'm technically in a "glue limbo" there. There's the time window of 250ms after every jump, during which you can't be stopped. This means the time between my rocket jump and slipping past the walls is less than 250ms. What I do however lose there during the gluing is vertical height of the rocket jump. It's basically like a regular rocket jump except the wall readjusts the max height of that jump.

Well, technically you never lost the velocity, however, since you can't go through the ceiling, your upwards movement came to a stop and suddenly was back. That's what I meant with "acceleration" (acceleration in the meaning of second derivative of the position, not in the meaning of first derivative of the [artificially] constant velocity, mathematically speaking).

What happens with fall damage/ damage if you bump into a wall with high enough speed? Would that damage also be delayed by 250ms?

Technically yeah, you could avoid falling damage from walls assuming you get away from them during the time window. It would not be delayed in itself, it would take place as soon as player loses his velocity, which in turn is the one being delayed.

It's not the possibility to avoid that damage that I am concerned with. It's the delay from hitting the wall to getting the damage. Imo, there already is a noticable delay between the two.

An alternative way to resolve the problem of being stopped by "tiny" collisions might be the use of "hitcylinders" with eliptic base areas instead of hitboxes. It's logically more correct, but might also have a bigger impact on the gameplay since it would also affect aiming. (I'm also not sure how good the engine can handle cylinder collision)

Well, technically you never lost the velocity, however, since you can't go through the ceiling, your upwards movement came to a stop and suddenly was back.

No, no. It did not return back to what wasn't lost in first place. It only looks that way. In Q3 and Reflex if you stared at your speedometer only, you wouldn't even notice that you got glued. You're merely suspended in one spot doing the same exact things which you would've otherwise done further away unobstructed by the wall.

It's not the possibility to avoid that damage that I am concerned with. It's the delay from hitting the wall to getting the damage. Imo, there already is a noticable delay between the two.

250ms is really not that long time though and this time window activates after each jump. So if you're roughly half way through your jump (already falling) then you're gonna get falling damage'd by a wall like normal.

An alternative way to resolve the problem of being stopped by "tiny" collisions might be the use of "hitcylinders" with eliptic base areas instead of hitboxes. It's logically more correct, but might also have a bigger impact on the gameplay since it would also affect aiming. (I'm also not sure how good the engine can handle cylinder collision)

I think the way Xonotic implemented falling damage is dumb to begin with. I think getting wall damaged is dumb, because most of the time it happens because someone Vortexed your back, in which case it's also dumb luck because you hit the next wall just the right way. It's inconsistent beyond words, vertically it doesn't even always work. I think it should aim to stick to vertical damage and determine it with some more consistent values like falling height for example.

No, no. It did not return back to what wasn't lost in first place. It only looks that way. In Q3 and Reflex if you stared at your speedometer only, you wouldn't even notice that you got glued. You're merely suspended in one spot doing the same exact things which you would've otherwise done further away unobstructed by the wall.

It's not the (again artificial) velocity that gets stopped but your movement normal to that wall and that is my point here. Again, do not think of velocity as the value that your speedometer shows but as the first derivative of your movement.

I think the way Xonotic implemented falling damage is dumb to begin with. I think getting wall damaged is dumb, because most of the time it happens because someone Vortexed your back, in which case it's also dumb luck because you hit the next wall just the right way. It's inconsistent beyond words, vertically it doesn't even always work. I think it should aim to stick to vertical damage and determine it with some more consistent values like falling height for example.

This way you could get fall damage when landing on slopes where your velocity normal to that slope would be neglegtable. I don't think that this would be more consistent.

I think the way Xonotic implemented falling damage is dumb to begin with. I think getting wall damaged is dumb, because most of the time it happens because someone Vortexed your back, in which case it's also dumb luck because you hit the next wall just the right way. It's inconsistent beyond words, vertically it doesn't even always work. I think it should aim to stick to vertical damage and determine it with some more consistent values like falling height for example.

Falldamage sometimes not applying after a vertical fall is a bug. It's not meant to behave like that. I agree that walls are a bit inconsistent but it's because if you don't hit perpendicularly, you only get redirected instead of stopped so the velocity difference isn't large enough. One thing that could be done is having a lower damage threshold for horizontal velocity changes.

About wallclipping: I'd like something like stepheight for walls to avoid getting stuck every time i hit a minor irregularity on the surface. I like Freddy's idea of cylindrical hitboxes, if it's not feasible, something like wallclipping could do the trick although i see no reason it should apply only after jumping. I'd like it to apply all the time - like turning slightly sideways to avoid an obstacle when walking irl.

What if there was separate hitboxes for wall collision and projectile/hitscan collision? In other words, one hitbox that interacts with walls (cylinder) and the one that interacts with your opponent's pellets (could be the old hitbox). This way we could for instance make collision experiments without it having effect on aiming/other gameplay.

That kind of thing is virtually impossible in this old engine of ours, unfortunately.

One way that may work (and indeed, worked quite well in my broken test) would be to make stepping up stairs work sideways, so you effectively step past corners and stuff. We can easily predict that, as it has no timing issues.