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.
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)
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.
now recycled, not freed. Fixed some bugs in exp.c. Ready to add embeded
functions (read: function calls with return values) and for loops.
Probably some other misc. fixes, I tend to go on debugging streaks.
Changed Cmd_TokenizeString to accept a flag that controls the application
of filters (tags, variables, escape characters) to the tokens and modified
a few places in the source that called it. Added a secondary command
buffer that is parsed without filters for legacy command support.
Currently, it is only used for commands stuffed into the console from the
server. It is hacky, and I hope to eventually generalize the console
interface to support any number of buffers and audit the rest of the code
to recognize it. For now, the legacy buffer at least keeps escape
character parsing from destroying info strings.
code cleanups and general performance work to be developed in relative peace.
While cleaning up the networking code /is/ important, fixing QF's perfomance
issues is of much higher priority.
This required changes to the api (info_t instead of char *) but should be
a net gain in speed (not a lot, admittedly: it was pretty fast to begin
with, but this paves the way for some other changes I have in mind).
svc_serverinfo, and svc_download
I havn't tested svc_download, since I don't want to play with having
seperate dirs for the client vs server on one computer.
- link net_svc.c to the server
- add a NET_SVC_Print_Emit function
- make the server use the above instead of svc_print manually
It's actually kind of ugly, because of how backbuffers are
implimented. Hopefully I'll be able to clean that up later.
