vasyyshakov / zombiereloaded

Automatically exported from code.google.com/p/zombiereloaded
0 stars 0 forks source link

Antistick triggering bouncing props #16

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Well, this is not really our fault. The antistick system itself works fine 
now.

But the engine freaks out when players get stuck into eachother - or when 
collision groups are changed frequently. It's one of those events that 
trigger it. Maps with teleports may increase the risk player getting stuck.

We might need to add that old antistick stuff too, that pushes player away 
on infection.

On a second thought, this may eliminate the first cause, players getting 
stuck, since the old pushaway worked fine before and didn't trigger 
bouncing props.

Actually I don't think both players need to have collisions disabled, only 
one of them. This might fix or reduce bouncing props.

Thread to watch for possible solutions or workarounds:
http://forums.alliedmods.net/showthread.php?t=99819

Instead of changing collision group just use a simple pushaway like the 
old zstuck, but not manually triggered this time.

Use the existing functions that check if people are colliding and 
automatically apply a small push if stuck.

Original issue reported on code.google.com by richard.helgeby@gmail.com on 4 Jan 2010 at 6:50

GoogleCodeExporter commented 8 years ago

Original comment by andrewbo...@gmail.com on 4 Jan 2010 at 7:02

GoogleCodeExporter commented 8 years ago
Added milestone label.

Original comment by richard.helgeby@gmail.com on 16 Jan 2010 at 10:06

GoogleCodeExporter commented 8 years ago
I played HL2 again lately and noticed that in scripted scenes, I or the 
characters 
have simplified collision groups if I stand in their way when they're walking 
to a 
place.

Like when Dog throw a van and I stand where it's going to hit I were pushed 
away, 
just like with those non-solid props. Or if I stand somewhere Alyx is going I'm 
pushed away there too.

So changing collision groups live and in-game IS supported, but we might do it 
the 
wrong way or use the wrong collision groups. That new touch hook you mentioned 
in 
SDK Hooks might help.

A quote I didn't notice from that thread:
"It's caused when one of two (or more) overlapping objects in different 
collision 
groups is destroyed"

So, if a player dies AND they touch other players at the same time we could 
just 
make sure they have the same collision group at the moment the entity (player) 
is 
destroyed, and restore when it's gone. Then you can keep the awesome anti-stick 
and 
avoid the engine bug.

Original comment by richard.helgeby@gmail.com on 7 Feb 2010 at 12:47

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
ShouldCollied hook might help

Original comment by mr.ex...@gmail.com on 7 Feb 2010 at 1:47

GoogleCodeExporter commented 8 years ago
exvel, I thought so too except that hook actually appears to be useless.

rhelgeby:  I thought I know what your talking about with HL2 pushing you away, 
but that 
doesn't really mean much.  I thought the bug was caused randomly.  How often 
does a 
player die while clipping through someone else?  That's extremely rare.

Original comment by andrewbo...@gmail.com on 7 Feb 2010 at 7:42

GoogleCodeExporter commented 8 years ago
Well, for example this code worked for me. It is not very smooth for players 
but 
does no matter when you just need it temporary for players to unstuck them.
[code]public OnClientPutInServer(client) 
{ 
   SDKHook(client, SDKHook_ShouldCollide, Hook_ShouldCollide); 
}

public Action:Hook_ShouldCollide(entity, &collisiongroup, &contentsmask, 
&bool:result)
{
    result = false;
    return Plugin_Changed;
}[/code]
The only think that is problem is that I don't know how to get client index if 
player you collied with in the hook. Maybe &contentsmask?

Original comment by mr.ex...@gmail.com on 8 Feb 2010 at 4:53

GoogleCodeExporter commented 8 years ago
&contentsmask is a bitstring.  That code above does not work on my server.

Original comment by andrewbo...@gmail.com on 8 Feb 2010 at 5:48

GoogleCodeExporter commented 8 years ago
By the way, I noticed a flag that's set in m_fFlags that is titled 
FL_UNBLOCKABLE_BY_PLAYER.  So that's not changing collisions mid-game, although 
I can't imagine collisions NOT being changed on live entities at some point in 
HL2.

Original comment by andrewbo...@gmail.com on 22 Mar 2011 at 3:42

GoogleCodeExporter commented 8 years ago
There have been several updates to CS lately, so I wonder if something is 
silently fixed. I haven't checked this in a while.

Original comment by richard.helgeby@gmail.com on 23 Mar 2011 at 5:40

GoogleCodeExporter commented 8 years ago
A thread in donor section about setting the bounds on the collision box of 
players.

"Let me clarify what i need.
m_vecMins and m_vecMaxs form a box which represent when you colide with other 
players and walls. I want to alter that box (make it smaller) so that, for 
example, someone could walk normally in a ventillation without having to crouch 
and other such uses.

I am open to any suggestions for this purpose. I would like to make the box 
even smaller than the one of a crouching player but otherwise, as high as a 
crouching player would still be better than nothing.

I have tried modifing the property directly during a SDKHook_PostThink with 
this,
SetEntPropVector(victim, Prop_Send, "m_vecMaxs", arr);
i will probably attempt with a PreThink when i have time.

Thank you"

"smlib provides a function Entity_SetMinMaxSize which is basically a rewrite of 
CBaseEntity::SetCollisionBounds in SourcePawn.

I think you also have to set the player's box model to SOLID_BBOX so it takes 
the box instead of the model for collision detection ?"

"We tried this and it works to a degree. It does change the bounds but only for 
player-player collision. 

We are trying to find a way to change the bounds so you can for example make it 
so a player doesn't need to crouch to pass through a vent, etc. In essence 
setting their bounds so they are always crouched would be a better way to say 
it I think."

Promising.

Original comment by andrewbo...@gmail.com on 1 Jun 2011 at 5:07

GoogleCodeExporter commented 8 years ago
Yes, this sounds useful. We just have to remember to give credits then.

Original comment by richard.helgeby@gmail.com on 1 Jun 2011 at 6:29