Take a look at this shot:
http://www.btinternet.com/~chapterhonour/fiendbug.jpg
How did the fiend end up through the wall, so high up in Gloom Keep?

The eagle-eyed might have spotted the alteration I alluded to above, it was a setorigin call in demon1_jump4. Nobody saw that? Fair enough...

You might be thinking that I was trying to sneak Lunaran's 16 unit lifting fix into the mix as well. Actually, the code that lifts the fiend 1 unit off the ground is in the original ID source, but they do it as:
self.origin_z = self.origin_z + 1;
This is bad practice, as you aren't meant to set the origin of an object without calling setorigin(but you can get away with it if the object isn't solid yet). So I thought I was fixing a bug.

It turns out I was fixing a bug after a fashion, but only in the sense that the original line is a bug, and the fixed line is a bug with the proper function call. Because there's no checking for low ceilings when the line is called, the fiend can be bumped up into a stuck position.

It's not easy to do this, as quake monsters won't walk into a place where there's no clearance between the top of their bbox and the ceiling above them. Due to grid snapping, you need to use sloping surfaces to make the gap smaller than 1 unit. The small doorway below the fiend in the screenshot offers one such place, as the doorway has 45 degree bevels at the top. If you jam the fiend into the doorway and make it leap into the door frame enough times, eventually it'll do it close enough to get stuck. The 1 unit bump just moves its bounding box into the sloped roof of the doorway.

Then once the fiend is stuck, it tries to jump its way free. Each jump it tries to make begins with the 1 unit bump, so it gets stuck further. If you go away and do the crossword for a bit, the end result is what you see in the screenshot.

Now, I believe I'm right in saying that the line should just be commented out, because lifting the fiend off the ground like that is unnecessary. From trial runs, the fiend certainly jumps just like before. Unless someone can suggest a more unusual case when the height bump is needed, I think the line only causes the occasional bug. 

Do the other monsters that use leaping attacks (dog, spawn, that's it, isn't it?) have these issues as well? 

Both of them have the same line that increases their height by 1 unit each time they jump, so if you're fixing that for one, fix it for all of them. I've not checked if they have the same problem jumping into stairs, so it could go either way. The best way to verify that would be experimentally. The same kind of approaches to fixing them should work, if they are problems. 

(gee, I just love this thread)

Spawn don't have the same problem with stairs because they become MOVETYPE_BOUNCE when they start jumping. This means when they collide with a stair, they bounce back off it, and so they launch their next jump with enough of a run up to clear the obstacle.

If you look in the dog.qc file, there's a comment
// if close enough for slashing, go for it
which suggests the whole thing is a big copy-paste from the fiend file. Technically you can get dogs stuck jumping in the same way, but it's harder to do, as dogs will only leap at you under very specific circumstances. You have to be between 80 and 150 units away, which isn't easy to judge.

Still, if it bothers you enough you can fix it by copy-pasting the lines of code from demon.qc. Hell, it's what iD did... 

can make them jump too you if u r using some cranked stuff 

why is:
self.origin_z = self.origin_z + 1; // raise off floor a bit
in walkmonster_start_go?

i'm guessing it has to do with either droptofloor or the somewhat hacky use of walkmove to print out the debug message?

and what exactly is the difference between setting origin directly anyway? what does that mean 'messes up entity links' or whatever. i've always used setorigin but never really understood why. 

I think droptofloor requires it. Similarly, the items need it as well. 

why is FL_FLY broken?

a walking monster without FL_FLY will fail on a walkmove(0,0), but a flying monster (with FL_FLY) will pass, even if it is inside a wall. this is probably why scrags can sometimes 'noclip' through walls.

some cool shit could be done if the walkmove check functioned properly with FL_FLY. :( 

Yeah, I agree with Lardarse, it's so that the monsters actually have a distance to fall with droptofloor, even if the mapper placed them flat on the ground. I've never checked what happens if you omit it, it might be that the monster gives off the warning message for being stuck. I don't think it's such a bug risk though, because mappers have to account for it in monster placement.


setorigin does a lot of behind the scenes work which is hard to understand. One of the most transparent things you can see it do is update the absmin and absmax of the entity(including the extra size for FL_ITEM entities). The next step is to link to the PVS leafs, which I think determines where the entity is visible from(but I don't know the engine source well).

The next thing the function does is recurse down the tree of areanodes to find the first node which crosses the bounding box of the entity. It then adds the entity to the linked list of all other entities which cross that areanode. This is the important physics thing which you break if you don't use this function. When you change the origin directly, your entity will be in the wrong list of areanodes, which may mean it misses collisions.


The idea behind the walkmove(0,0) is that it returns FALSE if the monster couldn't move the entire distance in the desired direction, and TRUE if it did, which is meant to be used for detecting when a monster has just walked into a wall. If you look at the engine code which governs it, you see that actually flying and swimming monsters have almost no walkmove code in common with walking monsters. By contrast, the only difference between FL_FLY and FL_SWIM is that if the endpoint for a FL_SWIM monster would leave the water, then the fish doesn't move and FALSE is returned.

The other thing that's important to note is that other than that for FL_SWIM, the only reason the move can fail for a flyer/swimmer is if the trace_fraction from the attempted move is not equal to 1. If you're moving 0 distance, then this cannot fail. In the walking case, there's a lot more going on to check for stairs, including checking whether the trace is allsolid. The check ties into deciding whether the monster needs to step up/down, specifically whether the trace is "startsolid". Because some degree of solid tracing can occur even in a sucessful move, it's important that the case of the whole trace being solid is dealt with by returning FALSE straight off. As a side effect it spots when the monster is stuck. 

Those links don't work for me :/ Can you put the fix on shub-hub or something? 

Any love for a small Quake monster art event? Something just as simple as "Draw/sketch an original quake-themed monster" or something? 

 

if it's in the next couple weeks, or in august 

but its not going to be spectacular

do u want creature spec's also? 

Anyone have any guidelines they'd like? Like ... have a piece of art in by a certain deadline (say like next Friday?) Any theme we're going after, "New Ogre Boss" or something, or just whatever we feel like coming up with? Ideas! 

Be a pretty good reference. I've got a few Quake artwork images that have surfaced on the net over time and by various artists - good for inspiration. 

Well I'll just post this as tentative right now:

When: Due by Saturday, June 20th, 2009
What: "Original Quake Monster" art - come up with a monster that you feel fits in the Quake universe!
Who: I suppose right now send them to me, but I'll have to find some place to upload them, unless anyone wants to volunteer to host magnificent, original Quake art.
Where: Wherever you can.
How: Pens, pencils, paper, 3d models, clay models, 2d digital art, whatever. 

I need to get a scanner :-/ 

Quaketastic loves you. 

Count me in for sure! 

I havent drawn anything for years.... 

http://www.youtube.com/watch?v=XOXvdfcct8g 

That everyone submits a piece of art - can I expect something like 4-5 drawrings by Saturday?

As a side note, I will probably be gone 20th, but will be back late on Sunday. So unless Spirit wants you to send them directly to him, my email is ZwiffleOwnsU@gmail.com. Use something like "this here is quake art" for the subject so I don't just delete it (which I might just do anyway.) 

Here's my take on a variant Quake bad guy: http://biff.quaddicted.com/art/scrag_ass.jpg
Isn't he precious?