InsideQC Forums

Posted: **Sat Jun 11, 2011 11:06 am**

you could set fl_onground regardless of the solidity. really the only reason to not do so is to ensure that tne entity on top is able to clear the onground flag again next frame if the entity below movetogoals away or such.
movetype_walk entities generally fully reevaluate anyway, so if the ent above has that movetype, you can set its onground flag safely even if the ent below is not movetype_push.

movetype_push is safe because that code does an explicit check for the things sitting on top of it.
the issue comes when you have health/ammo boxes/etc sitting on top of an explobox - you don't want the movetype_toss item above getting the onground flag, because if nothing clears it once set, the item will never drop to the actual ground.

solid_bsp is not really relevent for anything in this regard. if anything, you'd be best changing the check to not be able to gain traction when standing on a solid_slidebox than to only gain traction on solid_bsp, that is if you wanted to continue to not gain traction on the heads of monsters.

Posted: **Sun Jun 12, 2011 12:31 am**

movetype_push is safe because that code does an explicit check for the things sitting on top of it.
the issue comes when you have health/ammo boxes/etc sitting on top of an explobox - you don't want the movetype_toss item above getting the onground flag, because if nothing clears it once set, the item will never drop to the actual ground.

That sounds like the code that sets FL_ONGROUND should not be executed at all if the entity type cannot accept it. In fact, it sounds like a bug in the design or implementation of MOVETYPE_TOSS.

solid_bsp is not really relevent for anything in this regard. if anything, you'd be best changing the check to not be able to gain traction when standing on a solid_slidebox than to only gain traction on solid_bsp, that is if you wanted to continue to not gain traction on the heads of monsters.

Actually, I did change the check to not allow jumping on slidebox (I followed my own advice

):

Code: Select all

int
SV_EntCanSupportJump (edict_t *ent)
{
    int         solid = SVfloat (ent, solid);
    if (solid == SOLID_BSP)
        return 1;
    if (!sv_jump_any->int_val)
        return 0;
    if (solid == SOLID_NOT || solid == SOLID_SLIDEBOX)
        return 0;
    return 1;
}

Code: Select all

        if (trace.plane.normal[2] > 0.7) {
            blocked |= 1;               // floor
            if (SV_EntCanSupportJump (trace.ent)) {
                SVfloat (ent, flags) = (int) SVfloat (ent, flags) |
                    FL_ONGROUND;
                SVentity (ent, groundentity) = EDICT_TO_PROG (&sv_pr_state,
                                                              trace.ent);
            }
        }

While I missed some important information about move types (and I thank you for pointing it out), the thought of the server manipulating an entity's type behind the progs' back feels deeply wrong. Even though my approach will require extra tests to avoid issues with MOVETYPE_TOSS (and others?), at least the server will still be respecting the settings of the progs code.

InsideQC Forums

Jumping on Exploboxes