I am happy to announce that I have cracked it! Well, I'm fairly sure I have - since it's not a bug you can reproduce reliably it can be hard to confirm that it can't recur after the fix.

As layman as I can get it: In one place in the ogre's ai, it is instructed to charge at the player, but they forgot to specify how far to charge. The ogre fills in the gap with a value plucked from a previous calculation. Depending on what entity made the last calculation, this value might be a tiny distance (and it appears that in practice nearly all the time it is), or it might be a huge number. "Teleporting" is just the ogre charging a very long way in a single frame.

I would hope the fix is obvious to any QC coders - just specify a charge distance or remove the instruction to charge. The compiler does warn you that this has happened, so the lesson is to fix the compiler warnings... 

Looks like the ogre_smash12 frame function is the one right? It's the only spot I see where there's an ai_charge() with no arguments.

No wonder it's so rare. It would only happen if there was something in the 0.1 seconds between the last frame and that frame and most of the time the move would fail anyway since it would probably be trying to move into a wall or something.

Good catch! 

omg... this is amazing, definitely will help to breathe even more life into this beautiful game! 

I think the largest mitigating factor is that charge movement is all-or-nothing, and so if you've got a large positive movement forward you probably hit the player you were melee-attacking and don't go anywhere. Negative values would likely be better. Maybe charge distances in the millions (1000 times the size of the map) might break the engine as well...

The timing thing is not so much of an issue, because literally ANY function call that takes one or more parameters will change the charge distance, it doesn't need to be ai_charge or anything. Worse - it will reinterpret the first argument to that function as a distance even if it was a string or an entity! These are stored by the engine as integers - recording the offset from the beginning of the string/entity table.

Actually those cases probably aren't so bad, because the integer offsets are likely to be small (compared to a 32 bit integer), and I'm pretty sure small positive integers convert to incredibly small positive floats. If the worst input for exposing the bug is a reasonably large negative value, then I think the most likely trigger would be a function which takes a vector as its first parameter. The ogre would then take the x component of that vector as the charge distance.

One such function call runs every frame in player_pre_think - makevectors(self.v_angle). If nothing else runs that frame then that could trigger it... 

I just had to wiki Oculus Rift. 

http://www.youtube.com/watch?v=89iszJNcKQw

Looks gnarly. 

nitin I would like to try your version of the idgamma pak. I see you posted it. Thanks. I will try deleting the 2nd pak file in backstein and see what happens. Negke yes the idea of the idgamma was to lighten glquake but it works on all maps,engines etc as far as I know. Be careful knocking someones wants. I still play maps from the 90's. I currently use fitzquake 0.85 but it doesn't fix the darkness problem if that's what you mean. If not explain as I can always listen to new ideas. 

nitin is it the pak 2 file? What do I do with it. 

It works! Thanks :) 

and I honestly dont know the technical reasons, just from experience, are Nehahra and killjoy's map Avinpaala Prasaada, the one with the ikwhite textures. 

Thanks, kinda get that. 

Hah, awesome for chasing that down. I bet id didn't expect people to be chasing their bugs 15+ years on! Do you have any idea why it happens more often in, say, gor1, than other maps? 

I have wondered that, here's two possible ideas:

One is the interaction with other entities. We know that the player sets a value in the right place in memory for the ogre to use every single frame, so we can rule out anything from a previous frame affecting the ogre. However, any entities which think between the player and the ogre might change the value the bug depends on.

I'm not sure which way round makes the bug more likely to manifest. It might be that the gor1 has a particular set of entities which frequently act earlier than the ogre on the frame the bug occurs, and they are supplying the value which triggers it. Conversely it could be that the value from the player functions is good at triggering the bug, and gor1 is set up free of any distractions!

The other thing that might make some maps more susceptible is the geometry surrounding the ogre. It needs to be possible for the ogre to move to exactly the right spot when the bug is triggered. I guess that pier in gor1 is just right for ogre teleportation. 

Reminds me of the ogre boss in the Mexx series - the one without a ranged attack that chases you round a pentagrammic circle.

Lightspeed Charge Ogres

The chuck Norris of Quake? 

Someone's should bring him back to Q scene 

 

at least not officially? 

http://www.doomworld.com/vb/wads-mods/62339-doom-2-in-name-only-public-beta-released/

Now I want to see this done for Q1... 

 

I would love to see a similar thing to the fan qad called "doom the way id did" but for quake 

Thinking about good demo file name scheme again. How important would you consider the protocol? People often do not know what protocol they use (including me)... Is the identifier written to the file?

I kinda fancy adding demo hosting to quaddicted, so we could start collecting eg 100% playthroughs for all the skill levels. 

I would try and follow theirs if so.

Otherwise maybe this? Required in <>, optional in ()

<mapname> _ <skill> _ (*m*s) _ (100) _ (playername) _ (engine) .dem

I think the protocol is only important if obscure. I also think it would be smart to have a handy list of all the protocols somewhere. 

Engines change plus they can support multiple protocols. I thought of it too but protocol number is the proper thing to use.

My idea was quite similar:
<zipfile>_<bspfile>_ <skill>_(complete)_ <YYYY-MM-DD>_ <playername>_ (protocol).zip

And inside the zip:
<zipfile>_<bspfile>_ <skill>_(complete)_ <YYYY-MM-DD>_ <playername>_ (protocol)-#.dem
where # would be a number, 0-9 or 01-99.

*m*s is a good addition, on the long run one could find out how long a map is. I'd put it in the zip name (or the dem if it is one single file) before the <YYYY-MM-DD>, so:

<zipfile>_<bspfile>_ <skill>_(complete)_ (*h*m*s)_<YYYY-MM-DD>_ <playername>_ (protocol).zip

Other meta information would be saved in the db:
Is it the first time the player played the map (or skill?)?
Short description/comment
How many deaths (0 to "I lost count")
URL to captured video :)


I thought about writing some simple parser (or rather ask someone to do that) but then I looked at http://quakewiki.org/wiki/Network_Protocols and no, no.

It would not be a random dump but a highly nazi-&stasified system meaning that uploads would be linked to your account and the naming scheme is enforced (if you fail to do it, you just wasted your time uploading :\ ). If I was a smart programmer I would rename files as needed but I am not...