Possible for simultaneous Dual Rail Kills?

[[BTF]MangyMutt]

I posted this topic here >> http://tastyspleen.net/quake/forums/index.php?topic=8372.0 ....Pls visit and if you have relevant info or a demo then PLS post. Thanks!

WOOF! 

[ReCycled]

I've been wondering that for years. I've never seen it. Quake must time it to the nanosecond or something.
 

[quadz]

Quake must time it to the nanosecond or something.

It doesn't need to.    Incoming messages from clients arrive as packets at respective UDP ports.  Quake reads the packets one at a time, and processes the messages contained therein one at a time.  A rail shot, including the kill, happens while processing a single message from a single packet.

(That alone doesn't prove mutual rail kills are impossible... but if they are, it will be for a different reason... Timing might still be involved, but more in an accidental way...)


Regards,

quadz

[peewee_RotA]

(That alone doesn't prove mutual rail kills are impossible... but if they are, it will be for a different reason... Timing might still be involved, but more in an accidental way...)

I still am convinced it's not possible. Quake 2 is not programmed to run concurrantly, and entities affect other entities directly, rather than sending messages and waiting for them to respond.

[quadz]

I still am convinced it's not possible. Quake 2 is not programmed to run concurrantly, and entities affect other entities directly, rather than sending messages and waiting for them to respond.

What you are stating is the reason it should not be possible, provided there are no bugs that make it possible.

Quake2 is a complex state machine. Yet, one could make simultaneous rail kills possible by simply changing the first statement in Weapon_Generic, from:

    if(ent->deadflag || ent->s.modelindex != 255)

to:

    if(ent->s.modelindex != 255)

That such a change might introduce undesirable side-effects--such as possibly being able to fire weapons while dead--is not the point.  The point is, look how easy it is to make mutual rail kills possible.  (In theory - I haven't actually tried it.. )

So... would I say that looking at the 3.21 game source, mutual rail kills should not be possible? Yes.  But would I go as far as saying it's impossible that any sort of bug is causing edict_s.deadflag to be overwritten with a zero prematurely? No, I wouldn't go as far as saying it's impossible.  (But I'd say it looks unlikely.)


Regards,

quadz

[peewee_RotA]

Quake2 is a complex state machine. Yet, one could make simultaneous rail kills possible by simply changing the first statement in Weapon_Generic, from:

    if(ent->deadflag || ent->s.modelindex != 255)

to:

    if(ent->s.modelindex != 255)

That such a change might introduce undesirable side-effects--such as possibly being able to fire weapons while dead--is not the point.  The point is, look how easy it is to make mutual rail kills possible.  (In theory - I haven't actually tried it.. )

// clear inventory
// this is kind of ugly, but it's how we want to handle keys in coop
for (n = 0; n < game.num_items; n++)
{
   if (coop->value && itemlist[n].flags & IT_KEY)
      self->client->resp.coop_respawn.inventory[n] = self->client->pers.inventory[n];
   self->client->pers.inventory[n] = 0;
}

You won't have a weapon to fire. Your inventory is cleared right after you toss your current weapon.

[quadz]

You won't have a weapon to fire. Your inventory is cleared right after you toss your current weapon.

I'm not sure that is enough.  player_die() doesn't reset client->pers.weapon or client->weaponstate.  So even though the inventory is clear, it looks like you may still have enough of the "weapon in hand" left to fire.  (I just did some spot checks, not a thorough trace, though.)

I did, however, also notice that Think_Weapon() checks for (ent->health < 1) ... so that check would also have to be removed in addition to the deadflag check above...


Regards,

quadz

[peewee_RotA]

/*
=================
Think_Weapon

Called by ClientBeginServerFrame and ClientThink
=================
*/
void Think_Weapon (edict_t *ent)
{
   // if just died, put the weapon away
   if (ent->health < 1)
   {
      ent->client->newweapon = NULL;
      ChangeWeapon (ent);
   }

   // call active weapon think routine
   if (ent->client->pers.weapon && ent->client->pers.weapon->weaponthink)
   {
      is_quad = (ent->client->quad_framenum > level.framenum);
      if (ent->client->silencer_shots)
         is_silenced = MZ_SILENCED;
      else
         is_silenced = 0;
      ent->client->pers.weapon->weaponthink (ent);
   }
}


also in weapon_generic

if ( ((ent->client->latched_buttons|ent->client->buttons) & BUTTON_ATTACK) )
{
   ent->client->latched_buttons &= ~BUTTON_ATTACK;
   if ((!ent->client->ammo_index) ||
      ( ent->client->pers.inventory[ent->client->ammo_index] >= ent->client->pers.weapon->quantity))
         {


If you clear inventory you dont have ammo to fire. So disabling those checks would ammount to a click sound.

[quadz]

if ( ((ent->client->latched_buttons|ent->client->buttons) & BUTTON_ATTACK) )
{
   ent->client->latched_buttons &= ~BUTTON_ATTACK;
   if ((!ent->client->ammo_index) ||
      ( ent->client->pers.inventory[ent->client->ammo_index] >= ent->client->pers.weapon->quantity))
         {


If you clear inventory you dont have ammo to fire. So disabling those checks would ammount to a click sound.

Good catch...

[QwazyWabbit]

My head hurts. I don't know which thread is better to post in. A couple of thoughts occur to me.

1. Q2 doesn't need microsecond accuracy for the timing to be deterministic, it only deals with one thread examining the state of each game entity once each server frame. A server frame is 1/10 second, by definition.
2. It doesn't matter how many client frames from each client the server receives in each second, it accumulates the state changes for each client and processes only one state per entity per server frame.
3. Since each frame begins with client index 0 it will naturally have a bias (IMO) to see kills by that client before all others regardless of when the shot was fired and the client message received by the server. (As long as the client messages were both received before the server frame was processed.)
4. Q2 tracks the time of arrival of each client frame only so far as to determine which client frame is the newest when using the client information for entity state and prediction. Once the entity state is set for that frame, the server frame doesn't care.

I would expect the following:
If two client frames both arrived "at the same time" well in advance of a server frame event and they were both shots and both on target, the server would pick up and process both frames, modify states, then process the shots, then client 0 will get credit for the kill more often than client 1, all else being equal.

This assumes a rail particle is instantaneous in a Q2 frame, if it takes more than 1 frame for a rail shot to be processed then it is possible for both particles to be "in flight" at the same time and for each player to take the hit.
(I admit I am hedging here.)

What's really happening in HPW vs. LPB rail games is who is getting the accurate shot off prior to the server tick so the client state is in the server que sooner. The LPB wins more often because his state is there sooner. What's happening is tick, shoot, tick, kill, tick, shoot, tick, aw nutz. If it were tick, shoot, shoot, tick, then client 0 wins.

I have encountered the dead shot phenomenon in LOX code too. Both players shoot and both see their shots but one is effective and the other is not. This appears to be the client index preference at work. You would have to log the entity state details each server frame to see it in a debugger, I don't think I would want to try to set that kind of breakpoint. It would only make my head hurt worse.

It would be interesting to create two clients coupled to the same fire button and aimed at each other and let them shoot monte-carlo style and see who wins.

[UUD-40]

I wouldn't know, I just rj the other guy when he pulls out a rail. 

[m0n0LiTh0]

Hnmm , playing on Comp Weapons Server earlier this evening , had Ultra RG opposition had Sniper Gun (takes more skill , much slower) both direct shots simutaneously.  Concole read that  i was sniped then other player was railed , equal pings.
Was almost indistinquisable to the eye, milliseconds. I know i have seen it before..

Yep yes sir i'am sure i have ??

[peewee_RotA]

Hnmm , playing on Comp Weapons Server earlier this evening , had Ultra RG opposition had Sniper Gun (takes more skill , much slower) both direct shots simutaneously.  Concole read that  i was sniped then other player was railed , equal pings.
Was almost indistinquisable to the eye, milliseconds. I know i have seen it before..

Yep yes sir i'am sure i have ??

Doesn't the sniper gun shoot a projectile? The parasite Tip model if I'm not mistaken.


as for shooting then server ticks before dying, the t_damage function calls the killed funtion which then calls the player->die which should kill the target before the next client can get focus and the next round of client think() for the following client can be processed.

From experimenting with the trace function for instant hit, I've noticed that quake 2 will not continue with other processes while it calculates the trace. If for example you change the rail code slightly and cause an issue where there will always be an "ignore" (by playing with content masks or other reasons) then there will be an infinite loop of instant hit traces. The game will freeze as it tries to finish the infinite loop. Same thing for similar mistakes using the findradius function.

I noticed most of this while creating the lighnting spell for quakechi. You fire instant traces at short distances, at the end of every distance, if you do not hit anything, it fires another trace. Also every 4th segment branches off with an additional segment. The trace is pretty resource intensive so the server, as well as clients, will have lag spikes everytime the lightning is fired. Rails servers always used to spike even for normal rail shots. I'm no expert on network code but I think that's due to the server processing the more resource intensive rail loop before moving on to the next message.

[QwazyWabbit]

Your description of the T_damage function calling etc. before moving on is what we mean when we say q2 is single-threaded. The CPU is only in one place in the Quake2 code (engine and mod as a unit) at any point in time. The OS can be preemptively doing other things, including accepting UDP frames from clients, but they are queued in buffers until the engine code comes and gets the data on the next server tick.

The quake2 engine is running a loop, get network data, run the world loop, call think_ functions for entities etc, all based on a timing of 10 server ticks per second. One tick constitutes one pass through all entities and their functions as needed according to their state at that tick. There is no "concurrency" of events in quake2 where more than one thread is executing. If you were to do this there would have to be all kinds of synchronization objects to make sure an "event" on one entity was accounted for for all entities affected by it.

The big loop is G_RunFrame, controlled by the big for statement:
   for (i = 0 ; i < globals.num_edicts ; i++, ent++)

etc.

Once an entity is identified in use and it has physics, the control passes to G_RunEntity for that entity and this big loop is executed for every entitiy in the game before the cycle is complete and the next server tick can execute it all again. You can think of the engine as the dispatcher of the mod and G_RunFrame as running physics across num_edicts number of objects before returning control to the dispatcher. This is why the number of entities in the game is so important because all that state information has to be processed isochronously before the next server tick. When you have too many entities the game can't meet the deadline and you have late frames and lag. Once the loop is called, there is no getting back from it until all the functions it is calling have returned and ClientEndServerFrames() has finished. G_RunFrame returns to the engine and it dispatches whatever else it must do. The whole game can be preempted by the OS to do other things, but the game thread resumes where it left off thinking that no time has passed since it was executing. (The game has no sense of "real time".)

Since a client is an entity and the big loop is taking them in turn according to their spawn sequence, the first client connected will be the first one considered for his targeting information. Thus, the first-connected client will be the preferred one when it comes to registering hits.

Any particle that has physics, like grenades or rockets or player models, will proceed from tick to tick and change position or state accordingly. If the rail slug doesn't have "physics" but registers instant hits within the same frame it has "infinite velocity" in the game and zero time delay. Thus, a hit on a player will kill him and change his state to dead before his entity gets to "think" and register his shot. If in your example a sniper particle is fired and the player gets hit by a rail shot, it means the sniper shot message was received in a server frame BEFORE the rail gun shot message from the other player. If it appears to be simultaneous, that is an artifact of the clients, not the server.

[quadz]

If the rail slug doesn't have "physics" but registers instant hits within the same frame it has "infinite velocity" in the game and zero time delay. Thus, a hit on a player will kill him and change his state to dead before his entity gets to "think" and register his shot. If in your example a sniper particle is fired and the player gets hit by a rail shot, it means the sniper shot message was received in a server frame BEFORE the rail gun shot message from the other player. If it appears to be simultaneous, that is an artifact of the clients, not the server.

Unfortunately this discussion got split up on mutiple threads...

But yeah, we explored this in some detail on the "other thread".   I posted a backtrace from the debugger showing the full call chain from client message processing through rail shot, through player_die() all happening in one uninterrupted sequence:

http://tastyspleen.net/quake/forums/index.php?topic=8372.0

The question in my mind then became, could there be any loophole (bug) that could still allow a mutual rail kill, due to some state getting clobbered that would provide a window of opportunity for mutual kills to sneak through if the timing were just right.  However, in exploring that angle, we've found at least three different variables set by player_die, each of which alone is enough to prevent a dead opponent from firing a weapon:

  deadflag

  health < 1

  ent->client->pers.inventory[ent->client->ammo_index] < ent->client->pers.weapon->quantity

In other words, I've been pursuing a, "yes it should be impossible, but what if..." approach.

But even from a "what if" standpoint, it is seeming increasingly unlikely...


Regards,

quadz