intermission mode. As far as I can tell, it's pure luck wether the
svc_intermission comes before or after the first pass through the prediction
code, and if it comes before, the prediction code will never run and thus
never realise that it's ok to start rendering, so force the issue if in
intermission mode.
physics and progs, that's what sv.time is for. Things seem to work nicely,
including map changing, and this /should/ make long uptime servers work so
long as the map gets changes occasionally.
realtime back caused the problems with clients not reconnect on map change
and after my preliminary mucking around with time, I'm convinced there's a
better way.
server bug anyway), broke qizmo (not that I really care: that's still qizmo's
bug) and (most importantly) broke recording demos across map changes.
(Closes: #14)
directly calling sys_doubletime () - managed to remove six calls. Proboably I
should look through the code some more and find more ways to remove more calls
... The server works fine with them on my system as is, but I've gotten the
impression from people in the know that spamming the clock this often is bound
to cause non x86 arches to have problems.
Tim McGrath (Misty)
Also of note, I found a line I missed for logging from the last checkin. Doh.
Did not test heartbeats, although the code is so dead simple it ought to
function.
I did not test logging, although the code is rather simple so unless I missed
something, it ought to work this time. ;)
Tim McGrath (Misty)
not. Your choice.
if sv_frametime is less than or equal to zero, progs does not enjoy life.
Don't make progs suicide, join the > 0 club today!
Tim McGrath (Misty)
done every maxtic instead of every *mintic* which is what it was supposed
to be doing. Ooops.
Also minor whitespace cleaning in sv_init.c
Tim McGrath (Misty)
and also prevents old_time in sv_main.c from getting screwed up in the head
and pausing the physics indefinitely (check and see if there is a faster way
to do it :)
What does this let us do? LEAVE THE SERVER RUNNING! Imprecision due to the
server being on for long periods of time should now no longer be a problem,
so long as you have a map rotation going at least once a day. :)
I plan on committing updated versions of my glspeed cfgs next, and then
looking at timeleft - just to make sure when sys_dead_sleep is 1 it can't
overflow accidentally.
Tim McGrath (Misty)
With any luck it should actually work this time. Added the getimpulse
command so that GIB scripts can check if an impulse command is pending
before sending their own. Fixed all the memory leaks I could find.
QuakeC and GIB seem to be clean except for maybe one or two sneaky leaks
I can't track down.
unbounded frame rate (you can still set it to clamp your fps to, for example,
your monitor's refresh rate), and cl_maxnetfps 0 is now based on your network
rate.
The NetQuake-compatible targets now also have an unbounded framerate. This is
OK, because the built-in server uses its own tick rate.
building the render entity lists directly) so they get vis-clipped. The
benefits of this to newer gl cards/drivers or sw is negligable, but is a
pretty serious boost for the voodoo2 (~24%).
to GIB. Fixed a bug in dstring_replace that was causing too much data to
be copied when the incoming string was larger than what was being replaced.
Very minor reorganization in cmd.c (1 function moved around I think).
cmd.c should probably get broken up into separate files soon.
add dstring_replace. this replaces a string of lenth rlen at position
pos with data of lenth len, growing, shrinking and shuffling data as
appropriate. At this rate, the dstring `class' will get buffer gap
editing capabilities :)
cmd.c:
Cmd_TokenizeString builds cmd_active_buffer->line again.
Cmd_Process bails out instantly if cmd_active_buffer is a legacy buffer
and uses dstring_replace to modify the parameters in
cmd_active_buffer->line. This last change results in drastic
simplification (and accuracy) of the commandline reconstruction code,
both in Cmd_TokenizeString and Cmd_Process.
it's not needed. This should speed things up fractionally for well behaved
mods/servers that send atomic svc_stufftext packets (ie, always ending in
\n).
found at the end of the string. This works around a stupidity in some
servers where stufftext commands are sent in pieces and might not reach
the client before execution occurs, resulting in parse errors.
Useful on multi-homed machines where either you want qw-master to listen on
only one address or your operating system is lame.
While (currently) ugly, compiles for win32 again.
