Onground Calculation

[Cobalt]

[Spike]

You don't free calc. And certainly spawning an ent for use within a single function is not good karma.
Tracebox is a 'pure' function and won't harm anything but the trace globals, so spawning an extra ent is pointless.
droptofloor uses tracebox internally, so that is redundant.
checkbottom uses pointcontents and is thus buggy with clip brushes.
your tracebox will start -targ.mins_z units above the bottom of targ.

If you just want to check if an ent is stuck in something, you can just call tracebox(self.origin, self.mins, self.maxs, self.origin, FALSE, self); and then test trace_startsolid as you already do. False means that its free to move around, true means its stuck within something.

[frag.machine]

[Spike]

no
the engine/qcc never remove()s any entities ever, except when the qc explicitly calls remove().

and even if it did, there's a 2 second grace period before the entity can be reused. call it once per frame, run it on a machine with a good cpu + small res (2000fps), and you'll crash the (vanilla) server in a quater of a second. if you're calling it once per frame per monster then oh boy!
if you really need such a temporary entity, you can always spawn one in worldspawn and just reuse it each time. I just don't think you really need an entity.

[Cobalt]

yea, forgot to remove the ent, but this was just an idea / concept.

I thought I recalled testing droptofloor with vanilla quake years ago , whenever called, will actually drop the (self) entity its called down in to the floor no matter what. So that was why I decided to spawn an ent at the object we are testing's origin, and drop a test marker. No sense dropping the object itself to the floor.

For the most part I am trying to detect a condition where for example a player is moved off a ledge via a rocket blast, and hits a wall and is still
technicly not standing or laying on the ground below. I figure the collision to the wall will definatley set FL_ONGROUND to TRUE, and I guess the tracebox code would also start in a solid at some point, but I figure if we did that droptofloor with the entity it had some way to detect if really we are on the ground of the map, but I guess it would not matter if droptofloor moved side to side when ' dropping'? It would still be TRUE as long at it hit a solid, so the only thing that would work with is if the playwr was over a liquid I guess.

Another idea is the .jumpflag float.....however I believe that is utilized with the negative value of self.velocity_z ?

[Spike]

droptofloor will not move sideways, like I said its just a tracebox, one vertically down. But you are right in that its also a setorigin, but that is bypassed by using tracebox only, thus removing the need for a temp ent.

The general rule is that if the player is within 1 quake unit of the ground, then they're sufficiently onground to be, urm, onground. So tracebox from self.origin to self.origin-'0 0 1', and if trace_fraction is < 1, they're standing on something. If you use traceline at the same time, you can check if at least half the bbox is over a ledge and thus give different amounts of friction or something.

When tracebox-testing a player's origin, startsolid==true indicates a bug. It should not happen during normal play (if an NQ engine sees it, it'll move the player back to self.oldorigin) - it can happen due to precision issues, but is pretty rare and won't last more than a frame.

Quake considers ground planes with a trace_plane_normal_z < 0.7 to be walls. It must be >0.7 for it to be considered ground, by the engine.

[Baker]

[Spike]

actually, one exception to that - makestatic contains an implicit remove. A copy of the ent lives on as a static entity, but the original qc entity is indeed removed in that case.
Even with csqc, the engine expects the csqc to call the final remove() on entities that left pvs (this allows entities to live on as explosions or corpses or whatever, which is handy with the pvsf_noremove flag, which is really handy with allowing longer-lived event entities).

[Cobalt]

[r00k]

A dirty solution for ents getting stuck over an edge would be to randomly rotate the object ever so minutely until it is removed or drops.

[Spike]

.blocked is exclusively for movetype_push entities, and is called by the engine to say 'pusher can't keep moving, something is blocking it'. Its not useful for players at all.

Go google for planes or plane equations, etc. An infinitely large surfaces with no edges ever can have its position and orientation expressed with just 4 values - a normal and a distance (ie: how many units along that normal you'll find the surface). Being a normal and all, its normalized, thus a value of at least 0.7 ensures that its pointing more upwards than any other axial direction. You can access the properties of the plane the traceline hit via trace_plane_normal and trace_plane_dist. The dist generally isn't useful (the engine calculates trace_endpos for you with it so qc and most of the engine code doesn't need it).


Logically, makestatic does freeze the entity...
But back in reality, the engine copies the visible attributes of the entity out into an svc_spawnstatic message which it puts into the MSG_INIT buffer. Then remove()s the original entity. From then on, the entity has been destroyed as far as QC is concerned. The client will receive the contents of the MSG_INIT buffer when it connects (after the map is spawned), and will read that copy of the entity's visible attributes. The client doesn't know anything about the entity other than what it looks like and where it is.
Send too many static entities to a client and you'll fill some client-side list, resulting in the client ignoring any more.
If makestatic didn't remove() the original QC entity, you would have two separate entities visible on the same spot.
Calling makestatic will not affect the size of the MSG_INIT (aka: sign-on) message - you are basically trading an svc_spawnbaseline for an svc_spawnstatic. The real gain is that the server is no longer doing pvs/physics/etc for the now-static entity (because it got remove()d and doesn't technically exist any more), and is no longer sending the entity over the network (beyond the MSG_INIT) message.

[Cobalt]

[frag.machine]