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. 

...I would totally agree with fixing. Because it's a game-breaking insta-death bug. Unlike, say, Ogres who can't aim right, the Fiend bug really fucks your gameplay experience up on the occasions when it happens. That is probably the best reason for fixing anything... 

just let the finds run a bit more than they do now and make them climb up stairs while running? 

Fiends:

1. Don't have eyes.

2. Are an awesomely cool monster. 

Yeah megaman, this would be another good way to prevent stairs from blocking fiends. You could add an self.attack_finished time to the jump which is a bit longer than the length of a full jump, all frames included. Then make sure that DemonCheckAttack checks for it before making a jump(although it should be ignored for melee attacks as usual).

Alternatively you could just extend the jump sequence by adding

void() demon1_jump12 =[ $leap12, demon1_jump13 ] {};
void() demon1_jump13 =[ $run1, demon1_jump14 ] {};
void() demon1_jump14 =[ $run2, demon1_run3 ] {};

You'd also want to actual put some ai_face(); movetogoal(n) stuff to make it move during those last two frames without calling ai_run. I don't think this would be the best way to do it though.

This would make the fiend slightly slower to rejump in all situations though. You could make it a bit smarter about this by calculating at the start of the jump the rough endpoint of the jump under the assumption the fiend isn't obstructed, and store that in self.pos1. Also store the current position, or somewhere a little behind the fiend in self.pos2.

Then in demom1_jump11 (the first landing frame) decide if the fiend's origin is nearer pos1 or pos2. If the former, then the jump went well and continue as normal. If you're still nearer pos2 then put an attack_finished time on of half a second or so, making sure you won't jump for a while. The reason you might want to put pos2 some way behind the fiend is so that the jump doesn't have to get more than half way to count as a "good jump". Just make sure that if the fiend goes nowhere/essentially nowhere, pos2 is going to be nearer.

The attack_finished trick is already used for the pyro in quoth, to make sure that after each shot he tries to close the distance with you. It's pretty neat, but you do have to be careful when thinking about nightmare skill. If you use SUB_AttackFinished to set your attack_finished value then you won't get the behaviour in nightmare mode. So you should only use that subroutine if the attack_finished time is intended to make the monster less dangerous. 

unless luns_mom_jumptouch is triggered previously and in sequence.

sorry dunno what's got into me :E 

So I had a go at implementing the first fiend stair fix, and ran into a snag pretty quick. Almost instantly after the fiend jumps into a set of stairs the touch function decides the fiend is on ground and jumps to demon1_jump11, thereby bypassing the velocity boost added to demon1_jump5.

(to avoid confusion, in the rest of the post "frame" means a server frame, animation frame functions should just be called by name)

As far as I can tell, in the first frame after the jump starts, the function checkbottom returns true even though the fiend is off the ground, and has just banged into a wall. I suppose that this might be a consequence of the order things run in the physics engine, that touch functions occur before the information that checkbottom relies on is updated.

In any case, if you set
self.t_length = framecount;
in demon1_jump4, and then add

if(framecount == self.t_length + 1)
return;

in DemonJumpTouch just before

self.touch = SUB_Null;
self.think = demon1_jump11;
self.nextthink = time + 0.1;

Then the jump actually reaches demon1_jump5 so the physics trick can go ahead. And then it does in fact work. It's good enough that the fiends in e1m3 only get stuck once or twice before leaping up to you, even if you try and glitch them in place.

Stay tuned for part II where I see what the other fix does for the fiend. 

So, armed with this knowledge, I decided to try the other way. The basic method is to add

if (self.attack_finished > time)
return FALSE;

to CheckDemonJump.

The trick is knowing when to apply the waiting time. In the last post we had to work around the problem of the jump cancelling at the first available opportunity, but here we can use this to our advantage. It turns out that if that happens, it's very likely that the fiend is stuck on some stairs. So we put the same line into demon1_jump4:
self.t_length = framecount;

Then in the same place in DemonJumpTouch we add

if(framecount == self.t_length + 1)
self.attack_finished = time + 1;


And just like that fiends will walk a way up stairs if they jump into them, it actually looks quite natural. I went for a 1 second gap, because it takes about half a second for the fiend to actually land again and begin to run. If you wanted to get more sophisticated you might vary the time based on how much higher the player way, but you would have to ask if the sophisticated way would actually perform better.

The source I came up for each of these methods can be found at
http://www.btinternet.com/~chapterhonour/demon_variantsl.zip
[warning: the insta-kill fix has not been applied to these files, and in the case of the first one it's really worth doing, as the extra velocity boosts could make it inflict multiple hits]

If you notice a strange alteration to one of the jump functions, you may want to read the next post, which gets really nitpicky about it.

Some food for thought to finish with. The second method only alters the way in which a fiend chooses to use it's abilities, rather than adding a new dimension to it. So it might sound like a fairly faithful and "safe" alteration. However, remember that all that differentiates the majority of nightmare monsters from their regular skill counterparts is when they decide to use their attack and pain sequences...so the decision process matters too.