model collision

[m0dhippY]

Another quick question. I'm not sure if the quake series is exposed to this kind of exploit\glitch but with the use of the antiwallhack fix running obviously it only draws what needs to be drawn, but what if a player body is clipping through walls and exposed? That's the issue we're running into. MOHAA has a bad issue with model collision\clipping and now when a player is leaning into a wall, the entire body is rendered through that wall. Is there anything you can suggest to fix this model collision issue?

Any help is appreciated.

[Spike]

The potential is there in quake, in that tracelines that start in solid have their endpoint set to the attempted end point.
However, without tags or anything, the start point of any such traces are always inside the owner's bounding box, and thus never in solid. So while the potential is there, it'll never happen.

[Downsider]

The potential is there in quake, in that tracelines that start in solid have their endpoint set to the attempted end point.
However, without tags or anything, the start point of any such traces are always inside the owner's bounding box, and thus never in solid. So while the potential is there, it'll never happen.

Mhmm, lol, isn't he talking about fixing clipping errors in MOHAA, not in Quake?

[Spike]

can't be... we already had that topic. if that's what he wanted he'd have found that other topic just fine...

and even if he did want that, my opinion on what the problem is is included in what I said. a simple wrapper in the gamecode would work around the issue that I mentioned in passing (or rather, one for each trace trap). it shouldn't break anything.

[m0dhippY]

I may have missed that other thread, unless you are referring to the original thread I made regarding MOHAA's wallhack fix.

Spike, I'm not too good with understanding the model system very well (I do have to apologize in advance), you said that the potential is there but it will never happen. If it's possible, then why can't it be done?

Certainly can't you calculate the fraction of the body to the wall? Or maybe it would be possible by editing the animations for leaning?

without tags or anything

What tags are you referring to? Are you talking about the player bones? Couldn't you have a switch statement of some sort that loops to check the fraction of that body part to see if it "collides" with a wall and if it does, force the body to be pushed away?

I appreciate the replys.

[scar3crow]

Spike certainly knows his stuff, so I hesitate to suggest it may be other wise, but it seems to me like its a relatively trivial thing for in the lean code, to check if there is enough space to that side of the player, and if there isn't, preventing the lean (perhaps with a "Lean Blocked" message a la CoD4's "Prone Blocked" message when you try to lay down in a space not long enough) and not following through on the frameset.

Basically, leaning player is... 4 units of whatever wider than normal, so if a player inputs the command to lean to the left, the game says "is there more than 4 units of whatever between player as he stands now and the world? if so, lean, if there isnt enough room, dont lean".

Of course, I'm not a coder, but I can't think of a limitation that would prevent such a check from happening. I've read Spike's reason, but I don't fully get it (it sounds like it would only apply if the code didn't know the difference between "self" and "other"...)

Just my rambling two cents, as hacky and uninformed as it may be =)

[Spike]

tbh I'm just misreading everything entirely (or not reading anything at all, it seems).

as scar3crow says, yeah, do a tracebox.
you want to make said tracebox slide along walls to an extent, so they can still lean if they're angled awkwardly.

you can't lean in quake, so this doesn't otherwise affect us. The player is a fixed size, always, and never changes his size.

if you lean, you need to keep the eye origin more than 4 units away from any walls. 4 is the 'standard' minimum distance.

but yeah, if you want to stop the player from leading into walls, you need to cancel the lean if a tracebox ends up in solid. You can't just increase player sizes at will.
If you do add traceboxes to stop the player from leaning, you could make it so that leaning actually moves the player away from the wall that their lean hit if its blocked, thus stopping it from being annoying if they lean slightly forward while leaning around a corner.

Anything that can make the player bigger than their previous bbox size _has_ to be able to fail if there is not enough space. This includes things that are outside the model, including weapon positions or eye positions. (Although the trace thing will make weapon positions irrelevent for the most part, but you can't do that with eyes). But you can attempt to push the player back so it doesn't fail as often, but it still has to be able to fail.

trace = traceboxslide(self.origin, self.mins, self.maxs, self.origin + right*leandist);
if (trace.fraction != 1 || trace.startsolid || trace.slid)
{
t2 = tracebox(trace.endpos, self.mins, self.maxs, trace.endpos - right*leandist);
if (t2.fraction == 1 && !t2.startsolid)
self.origin = t2; //no space, push the player away from where they would lean to, so they don't notice there wasn't space
else
sprint(self, "not enough space to lean\n");
}

sort of thing. obviously traceboxslide would be a wrapper which does two traces, first as normal, second bounces off the plane that it hit, to slide along the wall. you could make the fraction be that of the original move to avoid the trace.slid part.
but yeah, you'll need to fix it up lots in order to make it match the mohaa api.