nq's SV_CheckVelocity will be a little different (spherical rather than
cubical), but sv_maxvelocity defaults high enough for it to not matter to
most players. It might even improve play.
The remaining differences need some careful thought before the physics
merge is done.
This allows the pvs to be used on an antity no matter how many leafs the
entity is touching. Seems to work nicely, but it will leak memory every
time a map is loaded.
MOD_TraceLine now behaves the same as id's SV_RecursiveHullCheck (from
WinQuake). This means that even if the trace would escape from solid space
into non-solid space, the trace is treated as allsolid if it crosses from
one solid space to another before hitting the empty space.
trace-id.c is used only for establishing the behaviour of id's code.
This reverts commit 10232acdfe.
The problem was really in the trace code, but it got fixed by "accident"
when I had similar problems in hipnotic a couple of years later. Now to
figure out just what the trace could really should be doing.
I've been experiencing funny trace issues while playing Soul of Evil. While
I think the boxclip dregs shouldn't be causing problems, it's probably best
to clean them out properly before trying to fix anything.
This reverts commit ad7e7e45fe.
The cleanup broke entity linking, but fixing it would just duplicate the
previous tests, so might as well revert. Cleaning up the interpolation code
is probably a better approach.
The efrags system's usage of ent->visframe clashes with that of
CL_LinkPacketEntities. As the latter is rather bogus, and potentially
visible entities are always inserted into the map (causing ent->efrag to be
non-null), a null ent->efrag is a good indication that the entity is newly
visible.
When R_AddEfrags is used (as is the case in nq), this function is
redundant. Brush models in qw are currently broken (invisible), but that's
just a matter of getting qw to use R_AddEfrags instead of R_NewEntity.
This removal should speed up the software renderers a little bit.
While reading the code, I noticed the comment stating that qw projectiles
(nails) are really temp entities, so I decided to make that true. The
client now supports unlimited projectiles.
Trying to cover very long times will probably cause more problems than it
fixes, so limit the length of time. Two seconds aught to be enough for
now. Need to look into proper handling of prevtime.
I got tired of seeing the noise about XMMS' config script not being
installed making it seem like XMMS is important to QF. It might be useful,
but it's certainly not important enoug for a scary looking message.
This is a weird little diff. We're doing a lot of gymnastics here so that
we don't have to crash (killing any loaded unsaved work!) when we find a
wadfile we don't know how to deal with.
