On SDA there's mention in a few speedruns of the "Houdini Ogre" bug, where ogres teleport spontaneously under unusual circumstances. The 40 second speedrun of E3M7 benefits from it where a blocking ogre teleports away. Does anyone know why it happens? I've found the solution to the other obscure bug on there (why monsters occasionally spawn frozen and unkillable), but this one has me stumped...
Which Hemisphere Was The Demo Recorded In?
Could be important!
i have never heard of that before. o_O
There's a fairly reliable way to reproduce it at:
Look for the "gor1" map entry.
I believe that it is actually a bug with monster_ogre_marksman, and in particular how they use CheckAttack instead of OgreCheckAttack. Still not got it nailed down...
Another Strange Bug
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 :)
Quake 1 To Dark
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.
Its Not The Same
I cant get the same look (which I like) with modern engine settings.
Frib has posted about this in better detail in the past.
Nitin Or Frib
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.
Quake In Occulus Rift
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 :)
Ogres For Shambler
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.
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...
Jesus I Am Behind The Times
I just had to wiki Oculus Rift.
Brutal Doom V19?!?!
Re Quake To Dark...thanks
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.
Nitin's Pak File
It works! Thanks :)
The Only Maps/mods Idgamma Doesnt Work Properly With
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?
What Happened To Aguirre?
Someone's should bring him back to Q scene
He Hasnt Released Anything For Q2 Though
at least not officially?
Doom 2 In Name Only
Thats A Neat Idea :)
A Plan Forms..
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.
Does SDA Have Naming Standards?
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?)?
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...