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. 

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.