There were a few problems with the 1.07 patch:
Bodies stuck under doors caused a repeated explosion effect.
Timedemo was broken.
The servers crash about once an hour under full load.
I have the first two fixed, and I hope the third. The four
servers at Id are running a new executable.
If the servers don’t crash in the next couple hour or two,
I’ll put another release out.
The 1.07 patch is out:
ftp://ftp.idsoftware.com/idstuff/quake2/patch_07.zip
Please mirror and distribute this.
When submitting bugs, make sure you say that you already have the
3.07 patch.
Christian will go through and update the bug page when he gets back
from vacation next week.
This release does not fix all known problems. We intend to have
another release in a few weeks.
We are going to release a new quake 2 executable that fixes the
malicious server crashing problems Real Soon Now. It also fixes a
ton of other problems that have been reported, so we are going to
have to give it some good testing before releasing it.
John Cash has two kids that would lynch him if he came in and worked
on christmas, so we certainly won’t be able to get a release candidate
together before the weekend. I am fairly confidant we will have it
released to the public on sunday.
I have been spending most of my time on trinity research but I have
still made quite a few fixes to Q2. John Cash has made many more (he
is just finishing up the IPX coding, among other things).
I have been doing a lot of testing over a proxy that gives me a very
bad ping (400 - 800), so I was able to find and fix two significant
errors with the prediction code.
The reason why you get a jerk when running forward and firing rockets,
blasters, or grenades is that the client side prediction code was
blocking you on your own missiles.
The jerky behavior on plats was due to a subtle error in the prediction
error interpolation. A prediction error was causing oscillations as long
as your latency, instead of smoothing out over just 100 ms. The plats
are now smooth as long as you aren’t dropping packets, and other
mispredictions are also handled much better.
There are still a lot of other things that will be fixed in an upcoming
release, but this will definately be an executable worth grabbing.
My fixes:
* zombies aren’t being removed properly
* joystick not in menu
* classname for rockets and bolts
* no screaming when invulnerable and in lava
* lowered water blend values
* clear powerups when dead (no more breather sounds)
* only play “computer updated” three times max
* mapname serverinfo now updated properly
* changed “rejected a connection” to “Server is full”
* made console “rejected a connection” a developer only message
* made WSAWOULDBLOCK warning silent
* max 10 packets/second during connection process
* set cl_maxfps to 90
* increased loading plaque timeout value to 120 seconds
* paused not default to 1
* no savegame in deathmatch
* fixed ; binding from menu
* no crouch when airborne
* removed half-baked $ macro expansion
* pause on landing before re-jump (fixes no fall damage bug)
* public server framework
* no ; comment in config files
* teleporter events
* lower hyperblaster damage
* don’t use PORT_ANY for clients!
* fix the entity number thing here
* don’t re-check CD after the first time
* auto cddir from cd scan
* dissallow kill from intermissions
* faster rockets
* less bfg effect damage
* remove packet command from client
* strip trailing spaces on cmd_args
* added protocol to serverinfo
* used CMD_BACKUP instead of UPDATE_BACKUP for phone jack
* don’t predict clip into your own missiles
* good netgraph
* validate userinfo for semicolons and quotes
* don’t copy savegames on dedicated servers
* also check current directory for game dll loading
* changed connect packet on client to differ from server
* bump protocol version
* fixed error interpolation on plats
* only respawn with attack or jump
* fov as a userinfo
* show weapon icon if fov > 90
The DOOM source is up.
Merry christmas!
ftp://ftp.idsoftware.com/idstuff/source/doomsrc.zip
———- contents of README.TXT ————–
Here it is, at long last. The DOOM source code is released for your
non-profit use. You still need real DOOM data to work with this code.
If you don’t actually own a real copy of one of the DOOMs, you should
still be able to find them at software stores.
Many thanks to Bernd Kreimeier for taking the time to clean up the
project and make sure that it actually works. Projects tends to rot if
you leave it alone for a few years, and it takes effort for someone to
deal with it again.
The bad news: this code only compiles and runs on linux. We couldn’t
release the dos code because of a copyrighted sound library we used
(wow, was that a mistake — I write my own sound code now), and I
honestly don’t even know what happened to the port that microsoft did
to windows.
Still, the code is quite portable, and it should be straightforward to
bring it up on just about any platform.
I wrote this code a long, long time ago, and there are plenty of things
that seem downright silly in retrospect (using polar coordinates for
clipping comes to mind), but overall it should still be a usefull base
to experiment and build on.
The basic rendering concept — horizontal and vertical lines of constant
Z with fixed light shading per band was dead-on, but the implementation
could be improved dramatically from the original code if it were
revisited. The way the rendering proceded from walls to floors to
sprites could be collapsed into a single front-to-back walk of the bsp
tree to collect information, then draw all the contents of a subsector
on the way back up the tree. It requires treating floors and ceilings
as polygons, rather than just the gaps between walls, and it requires
clipping sprite billboards into subsector fragments, but it would be
The Right Thing.
The movement and line of sight checking against the lines is one of the
bigger misses that I look back on. It is messy code that had some
failure cases, and there was a vastly simpler (and faster) solution
sitting in front of my face. I used the BSP tree for rendering things,
but I didn’t realize at the time that it could also be used for
environment testing. Replacing the line of sight test with a bsp line
clip would be pretty easy. Sweeping volumes for movement gets a bit
tougher, and touches on many of the challenges faced in quake / quake2
with edge bevels on polyhedrons.
Some project ideas:
Port it to your favorite operating system.
Add some rendering features — transparency, look up / down, slopes,
etc.
Add some game features — weapons, jumping, ducking, flying, etc.
Create a packet server based internet game.
Create a client / server based internet game.
Do a 3D accelerated version. On modern hardware (fast pentium + 3DFX)
you probably wouldn’t even need to be clever — you could just draw the
entire level and get reasonable speed. With a touch of effort, it should
easily lock at 60 fps (well, there are some issues with DOOM’s 35 hz
timebase…). The biggest issues would probably be the non-power of two
texture sizes and the walls composed of multiple textures.
I don’t have a real good guess at how many people are going to be
playing with this, but if significant projects are undertaken, it would
be cool to see a level of community cooperation. I know that most early
projects are going to be rough hacks done in isolation, but I would be
very pleased to see a coordinated ‘net release of an improved, backwards
compatable version of DOOM on multiple platforms next year.
Have fun.
John Carmack
12-23-97
The Quake 2 public code release is up at:
ftp://ftp.idsoftware.com/idstuff/quake2/source/q2source_12_11.zip
This source code distribution is only for hard-core people that are going to
spend a lot of time pouring over it. This is NOT a how-to-make-levels-for-q2
type dsitribution!
This should keep a bunch of you busy for a while. 
BIG BUG IN Q2 NETWORKING!
If you run multiplayer servers, download:
ftp://ftp.idsoftware.com/idstuff/quake2/q2_306.zip
A serious bug got through… I thought the QuakeWorld master server
code was completely disabled, because I was planning on putting a
modified architecture in place in the point release. It turns out
that the code is still in there, sending heartbeats to a unix
machine here at id that isn’t even running a master server.
That wouldn’t normally be an issue — a packet every five minutes
from all the servers.
Except….
Cyrix has a new processor that is significantly faster at single
precision floating point calculations if you don’t do any double
precision calculations anywhere.
Quake had always kept its timebase as a double precision seconds value,
but I agreed to change it over to an integer millisecond timer to
allow the global setting of single precision mode.
We went through and changed all the uses of it that we found, but
the routine that sends heartbeats to the master servers was missed.
So, instead of sending a packet every 300 seconds, it is sending one
every 300 MILLISECONDS.
Oops.
To a server, it won’t really make a difference. A tiny extra packet
three times a second is a fraction of the bandwidth of a player.
However, if there are thousands of network games in progress, that is
a LOT of packets flooding idsoftware.com.
So, please download the new executable if you are going to run any
servers (even servers started through the menus).
ftp://ftp.idsoftware.com/idstuff/quake2/q2_306.zip
This isn’t the real point release — there are no new features or
bugfixes. I just went back to the release codebase and recompiled
with one function commented out so we wouldn’t have to worry about
introducing new bugs with our current untested code.
Btw, all bug reports should go to Christian (xian@idsoftware.com),
NOT to me, Brian, or Cash! We need a central point to funnel
things through. Hopefully we can set up a web page or something
to make public what we know about, so we can cut down on email
traffic.
A couple things I forgot to mention:
DOOM source. Still planned to be released Real Soon Now, but there is some work that needs to be done on it first to remove the sound engine, which was written by someone else.
Our Quake editor. It will be released with the tools, but it really isn’t going to be all that usefull to many people. Most people will be better off with one of the actively supported editors designed for normal machines.
There is no documentation (Steve Tietze at Rogue has talked about writing something, though). It is designed to run at 1280*1024 resolution on a fast, fully-compliant OpenGL driver. It was designed for high-end boards like intergraph realizm, 3DPro, and Glint boards, but it also runs ok on 8 mb consumer boards like the permedia II and rendition V2200. It will NOT work with voodoo or powerVR. It is unlikely to work with voodoo rush, because of framebuffer size limits, but it might work at a low screen resolution. It might be workable on RIVA cards if they do some fancy work disposing buffers between window renderings (they are a 4mb card, but the textures can stay in AGP memory, so it will almost be enough). I’ll work with them if they want to give it a try.
Right now, only 3Dlabs has a full opengl driver on win-95 (and it is a little flaky). All the other cards would require you to run NT. Over the next several months, most of the major vendors should be releasing full OpenGL drivers that work in ‘95, but there are no firm release dates.
A comment to the people complaining about the release not having Their-Favorite-Feature:
A software project is never, ever completely finished. If you wait until EVERYTHING is done, you won’t ship at all.
Would it have been the right thing to delay releasing Quake 1 until I had written the glquake code and the QuakeWorld code? Or we had gotten Paul to build us all new models? Or we had made all new maps that hang together thematically?
If we had, we would be releasing Quake right about now. It would be a much better game (it would be Quake 2), but all of the enjoyment that everyone has gotten from Quake would have been lost. It would have been the wrong decision.
Quake 2 is great, and it will get better yet after its release.
A reminder about “John Carmacks”:
Anyone claiming to be me on IRC is lying. I have never been on IRC, and if I ever choose to, I will mention it here first.
If you get an unsolicited email from “John Carmack”, the odds are high that it was spoofed. Every couple days, I get a mail bounce from someone who messed up on a spoofed mail, and I often get confused responses from people that I have never mailed.
Quake 2 has mastered.
Where we go from here:
Point release.
We should have a Quake 2 point release out shortly after the game gets in your hands. We intend to fix any bugs that turn up, improve the speed somewhat, and optimize for internet play in various ways. We will also be making several deathmatch only maps.
Deathmatch in Q2 has gotten a lot of lan testing (Thresh, Redwood, and Vik Long helped quite a bit the last week with tuning), but not much internet testing. There are probably gaping holes in it, but we will address them soon.
The deathmatch code in the shipping Q2 is also not designed to hold up against malicious users — there is no protection against clients being obnoxious and constantly changing skins, chat flooding, client-side cheating, or whatever.
Q2 does checksum maps on the client side right now, so cheater maps won’t work like they do in Q1, but cheater models and skins are still possible. I have some plans to combat that in the point release, but there are a lot of forms of cheating that can be implemented in proxies that are fundamentally not detectable. I can make it very painfully difficult for people to implement such things, but a very clever person with a dissasembler just can’t be stopped completely.
The server code and network protocol should be able to support ultra-large player counts, but I know I need to do some low-level work to get around operating system buffer limits before it will actually work. We will test at least a hundred players in a giant map for the point release, but we won’t actually address the issues of making a rational game at that level (chat hierarchies, team spawning, etc). I am very much looking forward to seeing what the user community creates on that foundation.
It is likely that the point release may have incompatable network protocols and savegames. Fair warning.
Q2 Demo.
After the point release, we will be making a new demo release. If you experienced compatability problems with q2test, or were unsatisfied with the quality in some way, you should look at the demo. The final product is much improved.
Q2 Ports.
We are commited to Win32 Alpha, Linux, irix, and rhapsody in that order. It is likely that a bunch of other ports will come later, but no promises. The presence of hardware-accelerated OpenGL on a platform will improve it’s odds a lot. Zoid will probably prioritize Q2 CTF over other ports, so hold off on bugging him about ports for a while.
Development tool release.
I will basically be making publicly available a subset of the directory tree that we will deliver to our licensees. All the utility source code, the game dll source code, and probably some example source media — .map files, artwork, model source, etc.
Q2 mission pack.
Most of the company will be working on a mission pack while Brian and I write tools and technology for trinity.
Trinity.
I am going to rapidly wean myself off of working with quake so I can concentrate fully on new directions. The evolution of the Q2 codebase will be left to John Cash (until the mission pack ships) and Zoid.
Everyone should keep in mind that any next-generation game that we produce is a LONG way off, so don’t start getting all worked up over it, ok?
For the curious, it does look like java is going to start playing a significant role in our future projects. All of the lightweight utilities will be java applications (some requiring OpenGL bindings). The heavy duty number crunching utilities will probably stay in C. It is still unclear how much of the game framework and the level editor we can get away with doing in java.