weird glitch on spacetracks-beta3

[JOURNEYMAN]

Just a few minutes ago we had a series of rather weird glitches on spacetracks-beta3.

http://www.mediafire.com/?4tnj65ogs2kmoho

If anyone else made a demo of this particular game, feel free to post it here.

[Pazuzu]

To recap: These aren't just the usual elevator glitches (although there were plenty of those). Towards the end of the game, both of the bases suddenly disappeared. The build log just said the structures were "removed". Everything else was immediately destroyed because of lack of power. This was in sudden death. And then we were all frozen in place. We could attack and chat, and the walking animations showed, but we couldn't go anywhere.

[/dev/humancontroller]

Towards the end of the game, both of the bases suddenly disappeared. The build log just said the structures were "removed". Everything else was immediately destroyed because of lack of power.

so the structures were "removed". immediately after that, what other things (not structures) remain to be destroyed because of lack of power?

And then we were all frozen in place. We could attack and chat, and the walking animations showed, but we couldn't go anywhere.

a case of this was supposedly fixed in ioQuake3, and merged into Tremulous. perhaps there are more cases to consider.

[JOURNEYMAN]

The first "removal" affected all the structures (both humans and aliens).  The game was played for a few more minutes after revert.  Then suddenly everyone was stuck (spectators were able to move around with no clip on).  During this time it appeared that RC was removed but did not show on build log.  No other structures were "removed".  At least from my perspective, human buildings were blowing up due to no power.  I was moving toward the human base so I don't know if OM was removed or not.  

If anyone else was recording demo of this game please upload it so we can see what it was like from your perspective.

[Supertanker]

Blew my mind when I saw it! Would appreciate more demos though.

If it helps any, the actual movers on spacetracks in that part of the map are func_trains set to be crushers. However, the map IS littered with func_doors. I'm not sure how to read that special case mentioned but it sounds like the bounding box becomes infinite for a short time.

Also fwiw, there are a few path_corners really, really, really close to each other for the elevators, but I don't think any of them are moving instantly. They're like 0.125 units apart though. I did that for a reason but I don't remember atm.

EDIT: looking at g_mover.c, I notice that the only function that seems to have that context is:

void Reached_Train( gentity_t *ent )

What do you know. This handles (?) when a train reaches a path_corner. It doesn't appear to have the "protection" against stupid small values.

From what I recall, there are three path_corners in a row about 0.125 units apart for a reason. I was used to half life's trams and they had a nice feature where they could fire an entity's targetname on pass, but in Trem you have to hackishly have another entity with the same targetname as the next path_corner. It also happens to fire that entity BEFORE it gets there with this system. So for example, from the bottom up, it fires the targetname of the top corner before it even leaves. I wanted it fired when it REACHED the top to toggle the doors and didn't want to rely on careful timing if the elevator jammed. So I have one corner at the top, then another one really really close to it that shares a targetname with the door triggers, then one just after that which is where the train actually stops. It's weird and complicated but I'm wondering if this behavior is causing the bug.

Also fwiw, the old elevators were like this too. Never have seen any problems until some dolt built really close to the elevators. :> To fix the problem I've just nobuilded around the doors. Should work. I hope.

[/dev/humancontroller]

the bounding box becomes infinite for a short time.

the position becomes (NaN,NaN,NaN), to be exact.

EDIT: looking at g_mover.c, I notice that the only function that seems to have that context is:

void Reached_Train( gentity_t *ent )

What do you know. This handles (?) when a train reaches a path_corner. It doesn't appear to have the "protection" against stupid small values.

i have no idea what you're talking about. Reached_Train() is the only function to have "protection" against small duration values.

To fix the problem I've just nobuilded around the doors. Should work. I hope.

do not add workarounds for game logic bugs!

[ULTRA Random ViruS]

To recap: These aren't just the usual elevator glitches (although there were plenty of those). Towards the end of the game, both of the bases suddenly disappeared. The build log just said the structures were "removed". Everything else was immediately destroyed because of lack of power. This was in sudden death. And then we were all frozen in place. We could attack and chat, and the walking animations showed, but we couldn't go anywhere.

_______

Adding nobuild in certain areas probably won't work. You know chuck's tremship_b3/4? It had the same bug, caused by i think its the train function from the ships/alien egg killer "bomb" (its happened before the nuke was reach-able so im guessing this could be a cause) and chuck's map is filled with nobuild except the top ship.
You can try doing that, but it probably won't fix the bug.

[Supertanker]

the bounding box becomes infinite for a short time.

the position becomes (NaN,NaN,NaN), to be exact.

EDIT: looking at g_mover.c, I notice that the only function that seems to have that context is:

void Reached_Train( gentity_t *ent )

What do you know. This handles (?) when a train reaches a path_corner. It doesn't appear to have the "protection" against stupid small values.

i have no idea what you're talking about. Reached_Train() is the only function to have "protection" against small duration values.

To fix the problem I've just nobuilded around the doors. Should work. I hope.

do not add workarounds for game logic bugs!

You're right--I looked at an old version of that file.

Soooo...what am I supposed to do then? Wait? Is it going to get fixed? (I don't have the expertise to figure out what's going on, much less fix it.) The nobuild seemed to fix it for now (haven't witnessed the bug since), but I don't know if it'll be permanent or not. People probably shouldn't be making elevators move constantly anyway...

[/dev/humancontroller]

The nobuild seemed to fix it for now (haven't witnessed the bug since)

you haven't even witnessed the bug before.

Soooo...what am I supposed to do then? Wait? Is it going to get fixed? (I don't have the expertise to figure out what's going on, much less fix it.)

Well, I actually personally don't care too much, but let's start analyzing by adding some debug output. apply the following patch, and then try to reproduce the bug.

Code: [Select]

--- src/game/g_mover.c Wed Feb 15 10:57:16 2012
+++ src/game/g_mover.c Wed Feb 15 11:05:40 2012
@@ -461,6 +461,36 @@
 ============================================================================
 */
 
+static int TrDuration( const gentity_t *ent, qboolean rot )
+{
+  int trDuration = ( rot ? ent->s.apos : ent->s.pos ).trDuration;
+
+  if( trDuration <= 0 )
+  {
+    static unsigned count = 0;
+    if( count < 50 )
+    {
+      Com_Printf( "^3ZOMFG !\n"
+                  "^3  %s.trDuration: %i\n"
+                  "^3  position: %f %f %f\n"
+                  "^3  entity number: %i\n"
+                  "^3  classname: %s\n"
+                  "^3  target: %s\n"
+                  "^3  targetname: %s\n",
+                  rot ? "apos" : "pos", trDuration,
+                  ent->s.pos.trBase[0], ent->s.pos.trBase[1], ent->s.pos.trBase[2],
+                  ent->s.number,
+                  ent->classname ? ent->classname : "(null)",
+                  ent->target ? ent->target : "(null)",
+                  ent->targetname ? ent->targetname : "(null)" );
+      ++count;
+    }
+    trDuration = 1;
+  }
+
+  return trDuration;
+}
+
 /*
 ===============
 SetMoverState
@@ -491,7 +521,7 @@
     case MOVER_1TO2:
       VectorCopy( ent->pos1, ent->s.pos.trBase );
       VectorSubtract( ent->pos2, ent->pos1, delta );
-      f = 1000.0 / ent->s.pos.trDuration;
+      f = 1000.0 / TrDuration( ent, qfalse );
       VectorScale( delta, f, ent->s.pos.trDelta );
       ent->s.pos.trType = TR_LINEAR_STOP;
       break;
@@ -499,7 +529,7 @@
     case MOVER_2TO1:
       VectorCopy( ent->pos2, ent->s.pos.trBase );
       VectorSubtract( ent->pos1, ent->pos2, delta );
-      f = 1000.0 / ent->s.pos.trDuration;
+      f = 1000.0 / TrDuration( ent, qfalse );
       VectorScale( delta, f, ent->s.pos.trDelta );
       ent->s.pos.trType = TR_LINEAR_STOP;
       break;
@@ -517,7 +547,7 @@
     case ROTATOR_1TO2:
       VectorCopy( ent->pos1, ent->s.apos.trBase );
       VectorSubtract( ent->pos2, ent->pos1, delta );
-      f = 1000.0 / ent->s.apos.trDuration;
+      f = 1000.0 / TrDuration( ent, qtrue );
       VectorScale( delta, f, ent->s.apos.trDelta );
       ent->s.apos.trType = TR_LINEAR_STOP;
       break;
@@ -525,7 +555,7 @@
     case ROTATOR_2TO1:
       VectorCopy( ent->pos2, ent->s.apos.trBase );
       VectorSubtract( ent->pos1, ent->pos2, delta );
-      f = 1000.0 / ent->s.apos.trDuration;
+      f = 1000.0 / TrDuration( ent, qtrue );
       VectorScale( delta, f, ent->s.apos.trDelta );
       ent->s.apos.trType = TR_LINEAR_STOP;
       break;
this patch protects against division-by-a-duration-of-zero, and prints notifications if it catches anything. if the said bug's symptoms occur even with this patch, then the bug's source is something even less known; if, during attemps to reproduce the bug, the notifications get printed, but no notable symptoms occur, then we'll know that we're surely on the right track. the patch isn't tested at all.

[Supertanker]

Thanks! I'll see if I can get the bug to reappear.