As part of the work on getting nq to work on multi-homed nodes, I used the
existing recvmsg code in qw-master to check how things work. I figured it
might be worth keeping.
Since we clip the world properly even with skyboxes active, and the
'skybox' serverinfo doesn't do anything in any other engine I know of,
nuke the 'skybox' serverinfo entirely and use a nice short semi-standard
name ("sky") for the serverinfo containing the map's preferred skybox
(as potentially modified by the .ent file on the server).
This ensures that the map's sky is always used unless the client itself has
set its r_skyname cvar. The server's r_skyname cvar is now the default
name for the skybox for when the map does not specify one. The map's sky
worldspawn field overrides this. The r_skyname cvar is no longer a
serverinfo cvar.
in_dga -> 0 (until X is fixed)
gl_multitexture -> 1 (why was this 0? not enough support back then?)
cl_usleep -> 1 (seems to be ok)
host_mem_size -> 40 (even 32 isn't enough these days)
rate -> 10000 (we're not in the modem era any more)
cl_mem_size -> 32 (16 is not enough, 32 sounds better than 24)
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.
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.
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.
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.
Bill Currie
Jeff Teunissen