Outstanding:
------------
* 12/16/2004: multicastLists constructed in object_deserialize sometimes are
              leaked (see valgrind). Not very often, but it happens.
* 12/16/2004: Sometimes the owner of a missile becomes NULL and causes quake
              to crash when it hits and kills something...
              -- never seen this again
* 12/16/2004: Assertion (m_Entity->owner->guid != GUID_NONE) 
              failed at dg/DG_Edict.cpp:AttachedTo:267
              (saw this once in valgrind...)
              The owner is free'd by Quake. My guess is that the owner of
              the missile is a replica which is deleted because of lack of
              interest. We require someway to keep interest in pointers
              (See Merc/BUGS for generalization of this bug) -- never seen
              this again...
* 12/16/2004: when objects are migrated (or when a replica is recreated) the
              entity index in the client frame packet changes. This means the
              client thinks the entity is new and the old one was deleted...
              this doesn't seem to affect much from a visual standpoint, but
              it is somewhat inefficient since it will cause the object to be
              serialized to the client from the baseline object instead of
              delta encoded. For replica recreation, there is probably nothing
              we can do, since a re-creation means it went out of scope and
              then came back in, but for migrated objects, we should see if
              we can make the server maintain guid-level equality between
              old and new client frames sent. [This is very low priority]
* 12/14/2004: Iterating through g_edicts and clients array is too expensive
              to do for every little thing! should be more intelligent about
              this since we will need to up maxentities and stuff for real
              large maps.
* 09/17/2004: dropped items don't disappear if picked up by a remote dude?
              i.e., try it with quad_damage on rooms.bsp. Sometimes they
              flicker? -- does this still happen? (might be fixed with the
              dmflags option changed mentioned in the items bug below)
* 10/05/2004: Assertion failure in DG_RecordDeleteObject -- 'prevent' is
              no longer there in the object store. Changed it for now to 
	      return instead of assertion failure.
* 06/29/2004: make other edicts distributed...

Semi-Resolved:
--------------

* 09/05/2005: fix the bodyque -- right now it is disabled.
* 08/24/2004: with triggers enabled, sometimes we keep getting pubs for 
              objects which have been deleted. I see where this is occurring 
              for some objects (such as item drops, which are destroyed when 
              they are picked up, but since they are items they have a pub 
              lifetime of 30 sec), but it also appears to be happening for 
              transient objects like bolts. MercRouter holding onto pubs for 
              too long? -- does this have to do with MercRouter not being able 
              to keep up with the send rate?
              -- haven't seen this in a while, maybe fixed?
* 06/30/2004: sometimes the sprite-frames (graphics) for bots gets messed up?
              happened once when player joined, left, joined another server.
	      HAPPENS a lot now with delta encoding... ??? Seems to happen
	      sometimes when sometime splatters into gibs and then they
	      turn into a "gib head".  
>>>
the edict.s.modelindex and edict.s.modelindex2 are the IDs for the
graphics model to use for the entity and its weapon,
respectively. However, for players (and bots), these are both set to
255, indicating that the model is actually set by
edict.s.skinnum. Usually this is the skin to apply to the modelindex
model, however, in the case of players, it is an index into a client
array that is present on each client. Hence, quake always sets it to
"ent - g_edicts -1" to get the "player number" in the array. Actually,
it uses the low order byte for this. The 2nd low order byte is used to
store the weapon model index for the player.

Of course, this makes no sense for replicas, since they are in the
"normal" area of the edict array and are beyond max_clients. Hence
their models get totally screwed up sometimes (usually the client is
just confused and gives them a "baseline" model, which is
ok). Moreover, this actually seems to screw up the bot AI -- if the
model gets screwed up, the bot stops shooting. I think this is because
the weapon model is missing / incorrect.
<<<
              -- we hacked in a fix for now that forces all models to be the same.
              there is still a bug with the missiles in that some of the sprites
              look like boxes...
* 06/26/2004: bot AI for attacking players/bots in "normal" edict area?
              sometimes they stop shooting bolts... maybe a replica bug?
	      not an AI bug. Problem is that when a bot is killed by a
	      remote update, somehow the state is screwed up and the
	      ent->client->pers.weapon remains NULL so the bot doesn't
	      have a weapon. The bot also does not seem to want to change
	      its weapon even if we explicitly stop it from pressing
	      the FIRE button (which prevents the weapon from changing).
	      For now, I just put a hack that forces the bot to
	      call ChangeWeapon() in its AI code explicitly when this
	      happens. This is symtomatic of a larger remote-update bug,
	      so this is not fully resolved...
* 08/19/2004: subscription computation is way too expensive. on emulab it takes several
              msec to do (up to 10?) -- precomputed now

Resolved:
---------

* 12/14/2004: missle sprite graphics are still messed up. They seem to be
              taken from the first client index (like the sprite bug
              mentioned below). They are "boxes" until the first player
              shoots something, then they become that player's missile type.
              -- not sure when but this seems to be fixed
* 07/16/2004: Something broke the death animations... only 1 frame plays now 
              and the dead dude just sticks to that "falling down" frame...
              probably has to do with the sprite bug mentioned below...
              -- bots tried to change weapon after dead
* 12/15/2004: non-health items still don't disappear when you pick them up
              -- this was a dmflags option
* 12/15/2004: when bots are migrated, it seems like their old bodies stick
              around somewhere in the system. or at least they are still
              visible to the client. may be related to the next bug
              -- didn't set modelindex to 0
* 07/09/2004: EdictRef::ResolveRef(GObject *obj):
              Jeff: This is HORRIBLY BROKEN for 2 reasons:
              (1) The use of absolute pointer addresses is WRONG because the
                  scatchEnt changes over time.
              (2) The edict pointer could be overwritten by a subsequent
                  update in which case this edict ref should be removed, but
                  it is NOT.
              I've disabled all remote pointers because it appears replicas
              (at least for bots and missiles) don't need to follow them
              -- need to get this to work with migration. need to get this
              to work; Suggestion: total rewrite of this code.
              -- rewrote the interface
* 07/18/2004: replica items are still visible even if they are not "there"
              (i.e., have been picked up...). -- I believe this was a delta 
              encoding bug. 2 fields got encoded to the same bit in the mask.
              Nope, still a bug. Seems to occur for items that are supposed
              to be invisible but are newly created replicas.
              -- was stupid migration bug + nextthink field serialized
* 12/13/2004: Sometimes "blood" multicast events (and possibly others) don't
              show up on replicas. This happens a lot when in close quarters...
              my guess is when missiles are created and deleted in the same
              frame, we aren't handling it properly...
              -- problem was new missiles being counted as "non-distributed" if they
              never made it to the DG code.
* 06/30/2004: broadcast effects should actually be marked within the 
              object doing the broadcasting, not the objects that it broadcasts
              to, because the broadcaster might not be interested in the
              broadcastees. However, we also need a general mechanism for
              handling these events and state changes for objects that are
              deleted (could be broadcast + delete in same message, the 
              broadcast still needs to be carried out before the delete).
              -- fixed, except for bug mentioned on 12/12/2004
* 06/26/2004: "conflict resolution" for when replicas occupy same space
              see KillBox function for detection... -- whoo whoo. finally
	      made an initial hack at doing something correct when there are
              dudes stuck together -- try to move them apart! :)
* 07/10/2004: Sometimes when you kill someone (and are sure you killed them
              since it announces they are dead), they don't actually die?
	      (may have been fixed by the item bug below...)
              -- don't see this anymore. must have been fixed. :)
* 07/17/2004: On big_map.bsp, after sometime (or after something happens?)
              the DG stuff gets really really slow. This happens very suddenly
	      This was happening because of MercALOG and the disk filling up.
* 07/10/2004: Often, guys you are looking at will disappear for a split
	      second (replica disappears). Also guys that are far away
	      don't show up. Why? Bounding box messed up?
              ARGH! This was a stupid bug: operator+(timeval, int) was
              incorrect so ALL softstate timers were off by an order of
              magnitude! Can't believe nothing broke horribly. :)
* 07/09/2004: Sometimes when you grab remote items, they don't go away?
              (resolution was to move the client packet receiving code after
              the checkpoint, because that calls client think code, which
              picks up items)
* 06/26/2004: !!! actual delta encoding: full replicas are too large
              can we just transmit entity and player state?
* 07/06/2004: delta encoding: secondary delta mask is not preserved in case of
              packet drops!
* 06/30/2004: one time player turned into a replica after disconnecting and
              being destroyed by DG_HandleObjectChanges, then crashed the
              next time because wasn't in object store...
* 06/30/2004: *severe bug* for replicas, the difference should be calculated
              from the copy just before G_RunFrame and just after, and NOT
              with a Recv() call in the middle, because those will incorporate
              remote updates and will then almost *always* be true!
* 06/29/2004: broadcast effects should be broadcast to all interested parties
* 06/26/2004: bad FOV on client
