Doom-Ed

I AM GOING OUT OF TOWN NEXT WEEK, DON’T SEND ME ANY MAIL!

Odds are that I will get back and just flush the 500
messages in my mailbox.

No, I’m not taking a vacation. Quite the opposite, in fact.

I’m getting a hotel room in a state where I don’t know anyone,
so I can do a bunch of research with no distractions.

I bought a new computer specifically for this purpose — A
Dolch portable pentium-II system. The significant thing is
that it has full length PCI slots, so I was able to put an
Evans & Sutherland OpenGL accelerator in it (not enough room
for an intergraph Realizm, though), and still drive
the internal LCD screen. It works out pretty well, but I’m
sure there will be conventional laptops with good 3D
acceleration available later this year.

This will be an interesting experiment for me. I have always
wondered how much of my time that isn’t at peak productivity
is a necessary rest break, and how much of it is just wasted.

——-

The client’s IP address is now added to the userinfo before
calling ClinetConnect(), so any IP filtering / banning rules
can now be implemented in the game dll. This will also give
some of you crazy types the ability to sync up with multiple
programs on the client computers outside of Q2 itself.

A new API entry point has been added to the game dll that
gets called whenever an “sv” command is issued on the
server console. This is to allow you to create commands
for the server operator to type, as opposed to commands
that a client would type (which are defined in g_cmds.c).

——-

We did a bunch of profiling today, and finaly got the
information I wanted. We weren’t doing anything brain dead
stupid in the server, and all of the time was pretty much
where I expected it to be.

I did found two things we can pursue for optimization.

A moderately expensive catagorization function is called at
both the beginning and end of client movement simulation.
With some care, we should be able to avoid the first one
most of the time. That alone should be good for a >10%
server speedup.

The other major thing is that the client movement
simulation accounted for 60% of the total execution time,
and because it was already compartmentalized for client
side prediction, it would not be much work to make it
thread safe. Unfortunately, it would require MAJOR rework
of the server code (and some of the game dll) to allow
multiple client commands to run in parallel.

The potential is there to double the peak load that a
server can carry if you have multiple processors. Note
that you will definately get more players / system by
just running multiple independent servers, rather than
trying to get them all into a single large server.

We are not going to pursue either of these optimizations
right now, but they will both be looked at again later.

All this optimizing of the single server is pushing the
tail end of a paradigm. I expect trinity to be able to
seamlessly hand off between clustered servers without the
client even knowing it happened.

We got 70 people on a base100 server, and it died after it
wedged at 100% utilization for a while. Tomorrow we will
find exactly what overflowed, and do some profiling.

Base100 is really only good for 50 or so players without
overcrowding, but we have another map being built that
should hold 100 people reasonably well.

I will look into which will be the easier path to more
server performance: scalar optimization of whatever is
critical now, or splitting it off into some more threads
to run on multiple processors. Neither one is trivial.

My goal is to be able to host stable 100 player games in
a single map.

I just added a “players” command that will dump the total
number of players in the game, and as many frags/names as
it can fit in a packet (around 50, I think).

Coop play works now, including coop savegames. I also
fixed the savegame problems when under doors or on lifts.

We still have some game issues we need to hack around to
allow coop to be played all the way through the game
(like needing to pick up multiple power cubes, but still
leave them for other coop players to grab), and the monster
ai needs a bit of work for multiple players, but it will
all be there for the next release.

Version 3.10 patch is now out.

ftp://ftp.idsoftware.com/idstuff/quake2/q2-310.exe

A few more minor fixes since yesterday:

* qhost support
* made qport more random
* fixed map reconnecting
* removed s_sounddir
* print out primary / secondary sound buffer status on init
* abort game after a single net error if not dedicated
* fixed sound loss when changing sound compatability
* removed redundant reliable overflow print on servers
* gl_lockpvs for map development checking
* made s_primary 0 the default

Christian will be updating the bug page tomorrow. So hold
of on all reporting for 24 hours, then check the page to
make sure the bug is not already known.
http://www.idsoftware.com/cgi-win/bugs.exe

All bug reports should go to Christian: xian@idsoftware.com.

I have had several cases of people with lockup problems
and decompression overreads having their problems fixed
after they mentioned that they were overclocking either
their CPU, their system bus (to 75mhz), or their 3DFX.

It doesn’t matter if “it works for everything else”, it
still may be the source of the problem.

I know that some people are still having problems with
vanilla systems, though. I have tried everything I can
think of remotely, but if someone from the Dallas area wants
to bring a system by our office, I can try some more serious
investigations.

Something that has shown to help with some 3dfx problems is
to set “cl_maxfps 31″, which will keep the console between
level changes from rendering too fast, which has caused some
cards to hang the system.

New stuff fixed:

* timeout based non-active packet streams
* FS_Read with CD off checks
* dedicated server not allocate client ports
* qport proxy checking stuff
* fixed mouse wheel control
* forced newlines on several Cbuf_AddText ()
* if no nextmap on a level, just stay on same one
* chat maximums to prevent user forced overflows
* limit stringcmds per frame to prevent malicious use
* helped jumping down slopes
* checksum client move messages to prevent proxy bots
* challenge / response connection process
* fixed rcon
* made muzzle flash lights single frame, rather than 0.1 sec

I still don’t have an answer to the WAADRNOTAVAILABLE problem.
I have made the packet stream as friendly as possible, but some
computers are still choking.

I managed to get fixes for address translating routers done
without costing any bandwidth from the server, just a couple
bytes from the client, which isn’t usually a critical path.

I have spent a fair amount of time trying to protect against
“bad” users in this release. I’m sure there will be more things
that come up, but I know I got a few of the ones that are
currently being exploited.

We will address any attack that can make a server crash. Other
attacks will have to have the damage and prevelence weighed
against the cost of defending against it.

Client message overflows. The maximum number of commands that
can be issued in a user packet has been limited. This prevents
a client from doing enough “says” or “kills” to overflow the
message buffers of other clients.

Challenge on connection. A connection request to a server is
now a two stage process of requesting a challenge, then using
it to connect. This prevents denial of service attacks where
connection packets with forged IPs are flooded at a server,
preventing any other users from connecting until they timeout.

Client packet checksumming. The packets are encoded in a way
that will prevent proxies that muck with the packet contents,
like the stoogebot, from working.

Are there any quake fans working with the tera MTA prototype
at UCSD? I am real curious to see how some of my threaded codes
(qvis3, qrad3) would run on the MTA.

Wired magazine does something that almost no other print magazine
we have dealt with does.

They check the statements they are going to print.

I just got a “fact check” questionair email from wired about
an upcoming article, and I recall that they did this last
time the did an article about us.

Most of the time when we talk with the press, we try to get
them to send us a proof of the article for fact checking. They
usually roll their eyes, and grudgingly agree, then don’t send
us anything, or send it to us after it has gone to press.

Wired had a few errors in their statements, but it won’t get
printed that way because they checked with us.

How refreshing.

—-

A small public announcement:

The Linux Expo is looking for:

1. People that develop games or game servers in *nix, and
2. People interested in learning how to develop games in *nix.

Either one should give a write to ddt@crack.com.

Some of the things I have changed recently:

* fixed the cinematics
* don’t clear config after dedicated server
* don’t reallocate sockets unless needed
* don’t process channel packets while connecting
* rate variable for modem bandwidth choking
* delta compress client usercmds
* fixed sound quality changing after intermissions
* fixed PVS problem when head was directly under solid in GL
* added r_drawflat and cl_testlights to cheats

There are a few problems that I am still trying to track down:

WSAEADDRNOTAVAIL errors
Map versions differ error
Sometimes connecting and seeing messages but not getting in
Decompression read overrun.

Of course, we don’t actually get any of those errors on any
of our systems here, so I am having to work remotely with
other users to try and fix them, which is a bit tougher.

My new years resolution is to improve my coding style by
bracing all single line statements and consistantly using
following caps on multi word varaible names.

Actually, I am currently trying on the full sun coding style,
but I’m not so sure about some of the commant conventions: don’t
use multiple lines of // comments, and don’t use rows of
seperating characters in comments. I’m not convinced those
are good guidelines.