I don't see how z-aware ogres are an enhancement to Quake's simple and pattern-based gameplay

- more caution/challenge/skill/planning etc., which some players might enjoy (after 12 years...)

- it's 2008, nearly everyone uses mouselook, why not grant the same to them poor Ogres ? I find it always silly to see an Ogre frantically throwing grenades above my head.

Easy to learn and handy to use.

always the same pattern - boring / unpredictable monsters - surprise, excitement

Why not also add "headshots"

nice try to generalise, coming soon to the slipgate near you though 

I'm not sure, but i think the non-z-awareness of ogres actually helps them being more dangerous - i can ALWAYS dodge their apples (if there's room), but it's v. hard to keep track of the ones you didn't dodge... 

the mapper placed them right, so they're above me and behind me is wall so them apples bounce back to me and hit me from behind. 

would be nice.

And to blast all of them with a bfg and a rail gun :) 

Is stupid. What I meant before is that monsters should know what liquid is from a purely mechanical POV - drown in water, burn in slime or lava, etc. Depending on the monster type - so fiends would be immune to lava damage but drown if completely submerged in any liquid for long enough. Fiends do have eyes, and I think they need to breathe as well.

Enforcers immune to slime damage?

Z-aware fiends is an interesting idea, so they can leap up onto a 64 unit high ledge, for example.

Look at Zelda, those Octorok monsters can only shoot in 90� angles. Would you see it as an enhancement if they would shoot in all angles?

No, because the player can only move in 90% angles. You can spaz it a bit to get nearly diagonal movement, but that's about it. Quake on the other hand has a fully three-dimensional environment with 360 degree movement in all three axis. It's true that the Ogre can now fire much further than before, so a cap to his maximum distance is probably a good idea. 

shouldn't it be Y-aware instead?

I like the idea of enforcers being immune to slime damage, but then again one rarely sees them (or any enemy period) submerged in slime, if ever.

Death Knights should be lava immune, though, knowing fire magic et al. 

RE: monsters affected by liquids.

Careful here. I always considered quake's monsters as unearthly entities that aren't bound by the normal rules. I think it adds to their appeal. I can't remember who said it, but the best example i heard was someone's description of a deathknight (and i can't remember the exact words) as "waiting behind the door motionless for thousands of years, but ever ready to spring instantly into action with his sword, should anyone disturb him".

I think it makes them a lot creepier to know that they are somehow immune to drowning, lava etc. 

http://celephais.net/board/view_thread.php?id=60049&start=10&end=10

What you say is very true, but some monsters are more unearthly than certain others. Shamblers burning in lava may be wrong, but Ogres and Knights taking the fire damage is something I'd find appropiate. 

And I agree that a Deathknight being immune to lava damage makes perfect (twisted, arcane) sense.

But the current behaviour in liquids has two things that prompt me to mess with it.

1. Monsters treat liquid exactly the same as air in terms of gravity / whatever. This just looks dumb.

2. They don't die if they fall in, and if the player can't reach them (eg. lava) then they get lost from the killcount, apart from grenade spamming. 

Obvious solution is 'build the map better' eg. put a trigger_hurt at the bottom of pools the player can't enter. But its a waste of an entity and won't affect other maps running under the mod in question - the original maps for example. 

good call, that's the one :) 

If i recall (it's been a long time since I looked) SoA's gremlins had an ugly bodge which did a check for lava at a certain point in their run cycle, and gibbed them if it returned true. 

Would be damaging the monsters a bit, and hurling them out of the liquid (most likely back into the player) to make them appear scalded.

It would be pretty annoying to code and the effect would end up somewhat cartoony, but what the hell :p 

of monsters being able to drown and be burnt

hvent gotten round to figuing it out

somthing with limiting there aair like the player and wutnot 

Re: ijed

Number 1 is fixed by Gyrofying them. Liquids have movement resistance. You can even give them buoyancy.

Number two, I agree, they should drown or burn. This shouldn't be so hard to do. Monsters should just remove self when inh2o= lava.

// Gollum :-P 

http://shub-hub.com/files/images/ogreb.gif

Maybe in the crowd for Madfox' band ;) 

I'd love to see such an ogre in Quake :D 

 

z-aware monsters, monsters taking liquid damage etc can be found in the DarkPlacesMod. Monsters also do a bit more damage, do some leading... but not perfectly. However LordHavoc also made one-hit kills from monsters deadly. They can only bring you down to 1 in a single hit, after that, its your priority to get the hell out of Dodge (for which he provided health regen and offhand grapple). I enjoy DPmod, its a good way to replay any map due to the presence of the grapple with the more aggressive monsters. 

Here's a bug that needs to be fixed:
fiends getting stuck. I know it's part of the "gamePLAY" to use stairs or little doorways as a way of defusing fiends so you can plug away at them safely, but it just seems like an exploit.

I wonder if the lookspring code could be adapted to alter fiend jump velocity to get them up stairs? Or maybe just lift them 16 units off the ground when they jump so that they clear whatever stair they're butting against - wonder how obvious that would look. 

Just make them hull1. Doesn't sort out the stairs thing, but it solves nearly everything else... 

I'd be wary of doing something like bumping them up 16 units, in places with low ceilings you'd run the risk of them getting stuck in the ceiling, and then they're a worse sitting duck.

What might work better is giving a little extra horizontal velocity to the fiend at the apex of its jump. This would be a bit like the air control the player has, just nudge them forwards by 10-20 units/second. That should be low enough that you wouldn't notice the extra speed if they're making a full leap. Ordinarily the fiend gets stuck because all the horizontal velocity is zeroed when he hits the step at the start of the jump. If you give it him when he's already high enough to clear the step, then it should work.

Of course, that little velocity won't get him up more than one step per jump. Perhaps if you started him off a little slower in the horizontal direction and gave him multiple small boosts during the jump you'd get better results. I'd recommend storing the initial jump direction for all of these calculations, you shouldn't be letting the fiend correct its course mid-flight. 

To get rid of the fiend instakill leap bug, add some code just after the damage code in the touch function. Check to see if the "other" entity is still alive after the touch. If so, then prevent the fiend from doing any more damage in this leap by setting a flag, for example setting self.worldtype to 1. Then you need to check for this flag before the damage is inflicted. Also be sure to reset this flag each time the fiend launches a new jump. 

The demon_jumptouch function is supposed to reset its self's touch func when it's called so it only does damage once, and that doesn't seem to happen (so if you're running at a fiend as it's leaping it's like being under a crush door). why is that? 

Because the flag would be recorded per fiend, you'd still take damage from multiple fiends hitting you. The reason it doesn't cancel after one hit can be found in the if(!checkbottom(self) block. This checks if the fiend is properly onground, basically if it's on flat navigable ground. If this is not the case then it's still in the air, or stuck on a steep slope. The inner if statement checks for FL_ONGROUND, which would mean it's on a steep slope. In that case it resets the touch function and goes for another jump.

However, most commonly if checkbottom is false, the fiend is off the ground with no FL_ONGROUND, so it just goes to the return at the bottom of the block without changing the touch function.

Normally when two entities collide side to side and stay in contact they don't get repeat touches called, so even if you run at the fiend which is leaping, you only take one ping of damage. In theory if you could hit it, back off and hit it again you could take damage twice but it's not easy to do that.

When a fiend lands on your head it's a bit different. For some reason quake registers a touch every frame for vertical collisions like this, possibly the gravity code, I couldn't say. But isn't the fiend at rest as soon as it comes to rest on your head? Sadly, standing on an entity doesn't count for checkbottom, and even worse, the sliding bbox effect is caused because you don't get FL_ONGROUND on top of such an entity. So the fiend decides it's in the air the whole time, and you keep getting hit.