Possible for simultaneous Dual Rail Kills?

[quadz]

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.

As we discovered awhile back, it turns out even with unmodified rail code, these infinite loops still occur occasionally.  If I recall correctly, r1q2 adds a "loop breaker" kludge that says, if trace has been called a huge number of times this game frame, just bail out with a longjmp() ...

My recollection is that unkillable entities with overlapping bboxes cause the problem.... 'cause trace can only ignore one entity at a time.

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.

Aside from the rare infinite loop problem, a typical rail shot should generally cause about an order of magnitude less work for the server than a shotgun or SSG shot.  Right?


Regards,

quadz

[R1CH]

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.

Actually, client index has no affect on it at all, client weapon firing is done in between game frames in ClientThink. So it depends which packet arrives first as to who fires first. Players actually die in between game frames, but of course they don't notice until a game frame ticks by and new packets are sent. The only instance client index would affect is if the client sends no packets (<= 10 fps) between game frames, in which case the game runs the weapon code for them one at a time.

[QwazyWabbit]

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.

Actually, client index has no affect on it at all, client weapon firing is done in between game frames in ClientThink. So it depends which packet arrives first as to who fires first. Players actually die in between game frames, but of course they don't notice until a game frame ticks by and new packets are sent. The only instance client index would affect is if the client sends no packets (<= 10 fps) between game frames, in which case the game runs the weapon code for them one at a time.

Yes. I see that now. I tried the shot in the debugger and got a similar stack trace to the one quadz posted. The entity is modified between world ticks so his entity state is dead before his attack command arrives. Damn LPB's anyway.

[Jay Dolan]

As we discovered awhile back, it turns out even with unmodified rail code, these infinite loops still occur occasionally.  If I recall correctly, r1q2 adds a "loop breaker" kludge that says, if trace has been called a huge number of times this game frame, just bail out with a longjmp() ...

My recollection is that unkillable entities with overlapping bboxes cause the problem.... 'cause trace can only ignore one entity at a time.

That is correct (the cause of the infinite loop).  A jump doesn't seem like the easiest way to break from it, tho.  Are you sure it's not just a break/return/goto?

Aside from the rare infinite loop problem, a typical rail shot should generally cause about an order of magnitude less work for the server than a shotgun or SSG shot.  Right?

Correct again.  Super shotgun blasts are extremely expensive (wrt CPU time), especially when they cross into or out of water.  They're also not shy on bandwidth, either.

[quadz]

A jump doesn't seem like the easiest way to break from it, tho.  Are you sure it's not just a break/return/goto?

Ah, yeah, it's not a longjmp.  I recalled it doing something "drastic", but I guess it was just the overwriting of the caller's 'start' coordinate:

        //r1: server-side hax for bad looping traces
        if (++sv_tracecount >= sv_max_traces_per_frame->intvalue)
        {
                Com_Printf ("GAME ERROR: Bad SV_Trace: %lu calls in a single frame, aborting!\n", LOG_SERVER|LOG_GAMEDEBUG|LOG_ERROR, sv_tracecount);
                if (sv_gamedebug->intvalue >= 2)
                        Q_DEBUGBREAKPOINT;

                clip.trace.fraction = 1.0;
                clip.trace.ent = ge->edicts;
                VectorCopy (end, clip.trace.endpos);
                //this is really nasty, attempts to overwite source in Game DLL. may result in flying players and ents if it uses an origin
                //directly!! we may even crash here if we are given a write protected start.
                VectorCopy (end, start);
                sv_tracecount = 0;
                return clip.trace;
        }


Regards,

quadz

[AustinPowers]

Groovy baby. 

[UUD-40]

I've seen tie scores of 40 frags in the railz server. Maybe theres a slight delay from when the fraglimit is hit to the game actually ending...

[|iR|Focalor]

LOL!!! NO WAY!!! That would suck!

"I WON!!!..... no I didn't.... FUCK!!!"

[UUD-40]

Earlier tonight:

[21:22] <uvula> (railz) -------------name---fph---minutes---frags---
[21:22] <uvula> (railz)            Geezer   393      1.37       9
[21:23] <uvula> (railz)      tumblin~dice   305      7.86      40
[21:23] <uvula> (railz)     :iR:GOATKILLA   304      7.89      40
[21:23] <uvula> (railz)      Q2 BULL[DOG]   297      7.88      39
[21:23] <uvula> (railz)     Arnold Ziffle   145      7.85      19

[21:23] <uvula> (railz) :iR:GOATKILLA: lolo what
[21:23] <uvula> (railz) :iR:GOATKILLA: never seen a tie before
[21:23] <uvula> (railz) :iR:GOATKILLA: a tie win lol
[21:23] <uvula> (railz) tumblin~dice: Mom and son tied
[21:23] <uvula> (railz) :iR:GOATKILLA: noble tie
[21:23] <uvula> (railz) :iR:GOATKILLA: geezee u ever seen that befaore
[21:23] <uvula> (railz) :iR:GOATKILLA: before
[21:23] <uvula> (railz) tumblin~dice: once
[21:23] <uvula> (railz) Geezer: i seen tie happen twice is all

...


 

[console]

I've seen tie scores of 40 frags in the railz server.

Just to clarify, ties do indeed happen - but that's a different scenario from "simultaneous mutual" rail kills.


Regards,

[UUD-40]

no! thats just a cover up!     

[X'tyfe]

damn man, i would love to see this sort of thing caught on demo