SV_Physics_Toss: no validation check on groundentity

[dystopm]

https://github.com/dreamstalker/rehlds/blob/6a916d766b2f766ed9a45f9f008b3f7b737e3c89/rehlds/engine/sv_phys.cpp#L1050

Consider the next scenario:

1. Create an entity (ent1), movetype=MOVETYPE_TOSS, solid=SOLID_BBOX, takedamage=DAMAGE_YES, health > 0, mins and maxs to some random box size (15x15x15)
2. Call PF_droptofloor_I (AMXX's drop_to_floor) on ent1 to drop it to the floor, FL_ONGROUND flag is set and groundentity is updated after this: https://github.com/dreamstalker/rehlds/blob/478f338e376e2872a2f62a5235f3ff15d1110b07/rehlds/engine/pr_cmds.cpp#L1689-L1690
3. Create another entity (ent2) with the same properties of ent1, and use PF_droptofloor_I on ent2 trying to place it above ent1. ent2's groundentity will link to ent1.
4. Shoot ent1 until disappears because of health going down zero. ent2 will still link groundentity to the freed ent1, causing ent2 to be stuck on air because of the condition written on the first linked line in sv_phys.cpp. Both entities have velocity zero for obvious reasons: https://github.com/dreamstalker/rehlds/blob/6a916d766b2f766ed9a45f9f008b3f7b737e3c89/rehlds/engine/sv_phys.cpp#L1050-L1052 There's no checking if groundentity is valid or freed on that condition, leaving the entity to not update it's current status and leaving it on the air

In another scenario, using the same properties of ent1 or ent2 but WITHOUT using PF_droptofloor_I you are going to notice ent2 is not linking its groundentity to ent1 and no FL_ONGROUND flag set. In fact, the engine thinks ent2 is still flying (with velocity zero) because it thinks there are above of no entity, when in fact it's above of ent1.

For the first scenario, I suggest to just add if groundentity is not freed on the cited statement to clear the FL_ONGROUND flag and leave the physics flow to update it's status.

For the second scenario, I wasn't able to get the right statement to update his groundentity when landing above another solid entity. I don't know if this is a expected behaviour of the engine or if it's going to break something internally, but I'm leaving this to the modders who may know better the related physics workflow.

If there's anything else you need me to provide I will do. Thanks for reading

[UnrealKaraulov]

Need create ReReHLDS, because this repository is dead :(

[StevenKal]

Need create ReReHLDS, because this repository is dead :(

Haha! Yeah, but for me this is more the "approvers" behind who no longer have motivation to work on this, or/and are busy with others things in life, etc.. Besides the 2 last years really fucked up the people's motivation for a bunch of things, I constated it in other things, like some people working on some interesting HL1 mods or other cars games, suddently all of this became "stagnant/abandonned" by developers.

Probably the best for those Re* projects should be to have new approvers active & who do not wait months to push PRs & cie (& also give their opinion if they are for or against, & suggestions, unlike silentq who is... silent & refuses to communicate 99% of the time), and, having good & similar knowledge compared to the original maintainers, in order to also be able to maintain a few things "themselves", rather than only relying to contributors's PRs. But as wopox said, the question of trust is around, besides it might be hard to find such people.

There are contributors, and I am pretty sure a few more people will be glad to contribute more, but "activity & efforts" should be done & in adequation from both sides, if contributors submits PRs but devs do not care, contributors leave, because it is disappointing & a waste of time to focus on a code if devs do not care, as simple as this. And at the end, some people is gonna be a bit "selfish" & make their own version (like I started for RGCS) with some modifications based on their wishes, for their needs or not, or do other public forks.

[dystopm]

I appreciate your answers, and I would like to follow the line of this thread and also reply something related to itself. @s1lentq hope you had sometime to see this and tell us what do you think about it, hoping that everything is to contribute and improve.

[RauliTop]

Don't forget this @wopox1337

[dystopm]

@justgo97 @s1lentq @wopox1337 sorry to bother you, can you take a look at this one day? I will be very appreciated

[justgo97]

@justgo97 @s1lentq @wopox1337 sorry to bother you, can you take a look at this one day? I will be very appreciated

I haven't tested it but adding ent->v.groundentity->free to the validation check in SV_Physics_Toss will probably solve the issue you are describing.

if (ent->v.velocity[2] > 0.0f || !ent->v.groundentity || (ent->v.groundentity->v.flags & (FL_MONSTER | FL_CLIENT)) || ent->v.groundentity->free)