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. 

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?