While on the note of weird bugs, here's one I got a short while ago: link (Fitzquake Mark V)

Was dicking around with cheats (god + impulse 9/255) on E3M1 when, as the demo shows, another "dog" spawned at the same location as the previous one, except the model was replaced with the dog head-gib model, which proceeded to attack me, while seemingly moving at about half the speed of the normal dog. And after taking a jump, it sort of dies? Very weird, reminds me of a bug I've gotten before where I restarted a map with a different mod (or something like that, can't quite remember) and suddenly all the models would be switched around, but this was just normal id1. Happened once before too with the exact same dog, tried to record with Fraps then, which crashed itself and the game - probably because the bug was too weird to handle. 

I can clarify a bit why that might happen, but I can't explain it fully. First thing to know is that unlike the rest of the gibs that are given off, the head gib is actually the same entity as the original model, just with a new appearance and very slightly modified behaviour. All the original ai is still part of this entity. If anything failed to notice it was dead and requested that it run an ai routine, it would carry on from where it left off.

So the difficulty is trying to work out what unusual circumstance led to that first post-mortem ai request. One special ai request for the dog is in the leap function Dog_JumpTouch, where dogs who are stuck trigger a second jump via an ai request. I thought perhaps gibbing a dog mid-leap might cause this to occur - but Dog_JumpTouch checks that the dog has hp left before running. So unless it was some kind of mod that creates shootable corpses, something else must be at play here... 

 

I was making a new type of zombie when this turned up. The heads of the gibbed chasing me around and nipping at my shins.

It was funny so I included it as part of the creature behavior, with a few modifications. The Flayn will be included in something one day :) 

I am humbled. I have installed this game 20-30 times starting when it first came out. I have the idgamma patch and the gl 1.13b whatever and I have the game in c:\quake. When I run the idgamma patch it can't find the location. Hence the prick is dark and acting funny. I am using fitzquake 85 and have the bright turned way up so it is playable but not right. I loaded that backstein map and although the resolution is 800x600 it looks like about 320. The glquake plays ok other than dark. Plus in order to have mouse look I always made a copy of my cfg file,deleted everything and put +mlook and saved it as Autoexec.cfg and it worked. I use notepad as my editor and I get a notepad instead of a cfg file that opens in notepad. Just on the copy. The original cfg is ok.Wtf? Some genius straighten me out.
windows xp sp3 nvidia geforce fx 5200 

with backstein, sock is forcing some graphical settings via the pak file. Not sure if that is also interfering but try deleting the second pak file to see if it changes anything. With idgamma, I dont know the issue about the installation error but I would be happy to email you my idgamma pak file if you want. No idea re cfg file issue. 

Wasn't the whole point of Idgamma to make the game brighter on old GLQuake with its nonfunctional gamma/brightness slider? All modern source ports have this fixed - no one has to play or should be playing with this old piece of junk these days. 

I cant get the same look (which I like) with modern engine settings.

Frib has posted about this in better detail in the past. 

Can you post your idgamma pak? I think I have lost mine and would like to try it out again since gamma support is currently broken in QuakeSpasm on OS X. 

here you go:

http://www.sendspace.com/file/58s4a5 

 

http://phoboslab.org/log/2013/07/quake-for-oculus-rift

uses Quakespasm as a base. Have fun! 

I remember this happening a few times when I was trying a Zerstorer (M3? M5?) speedrun, and was quite interested at the time. I'll be interested to hear the explanation, in laymans terms :) 

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.