The reveal scroll cheat is unfortunately only an aid to debugging map problems, rather than a real wand of revealing. It simply runs the eprint command on the entity which it finds. The rules of eprint are that it skips over the 100+ fields on the entitiy which are set to zero, and prints just the ones which have values. This means it's not very good for feature discovery, as you have to turn on the features before you can discover them...

What I will try and do is zip up all my "unit test" maps which are meant to thoroughly test all the quoth entities, to try and catch regressions in new versions. They are a useful reference because if you see something you want to be able to do in one of the maps, you've got a .map that demonstrates how (admittedly polyps with alternate skins are not part of that...yet). The problem is my existing hosting is about to disappear so I'm still working on a new home.

I will share one tip that I don't think made it into the mapping guide, and I forgot about until a few weeks ago so I'm worried I never posted about it. Quoth supports "flags" on the developer command. If you set developer 2 then all triggers in the map will become visible. If you set developer 4 then monsters with the teleport flag will be visible before they spawn (but blink on and off). You can add these flags together to get both effects. Developer messages appear at all levels but 0. 

negke never dreams such things up!!
(except sometimes) 

Is this normal Vermis behaviour?
Yeah, the vermis will shoot at the last spot it saw the player until it sees the player again.

Is there an optimum height for placement so that he can grab me when I try to run past him?
I just winged it every time I added it into a map; moved it up and down until it was in a good position.

Is there enything I can do to ensure that when I can see him, he can see me?
Not really. The vermis can only 'see' from a single point like all other monters.
Unlike all other monsters, it's huge. In ne_ruins, for example, I allowed larger monsters to 'see' from two separate points which helps them keep track of their targets better and reduces the chance of exploiting.
The vermis should probably have been able to 'see' from multiple points along it's vertical axis.
As it is, there is nothing that can be done. 

Oh bugger, another bright idea bites the dust! 

I notice in the released Vermis code:-

//if (trace_ent != targ)
// return FALSE;

Is that why it keeps shooting? 

no I didn't load a saved game, it happens when just loading the map from the console. Even if I quit the game, run qbsp+light from scratch, start the game again, and then load the map, the weird behavior persists.

it happens in every engine too jsyk

:( 

If I quit the game, run qbsp, start the game again, and load the map, it looks and plays terrific. If I quit the game afterwards, run light on THE EXACT SAME MAP, start the game again, and load the map, I get monsters in walls and floating above the floor. 

Apparently your brushwork is so terrible that it even affects something completely unrelated. Perhaps you might want to consider some subtle grid-love after all... 

Yes, for the most part. If those lines were not commented, it would stop shooting when you were out of sight.

Also, the vermis' 'eyes' are actually at '0 0 25' relative to the monster's origin (about where that bulb is near the middle of it).

also, it uses visible() in it's run function to determine is enemy_vis is set but then enemy_vis is never actually used.

Looking back, I was a pretty shitty coder back in the quoth days. :( 

No seriously I was going to do that anyway...
(even though this is AFTER snapping all brushes to the grid) 

Hook a fella up with your unlit and lit .bsp, not just for rubbernecking, I'll see if I can help, honest! 

No can do. Made a few modifications and utterly destroyed it. I *could* theoretically go to the most recent backup but I don't much feel like reconstructing so much work just to recreate the error it inevitably led to.

For your amusement though, here's what it looks like now. Amusingly enough, the number of errors actually GROWS when I remove brushes. wouldn't you expect the other way around?

http://www.suspenlute.com/stuff/raep.jpg 

That looks a bit like what happens when you have 0-volume brushes and they end up stretched to infinity. There's an error checking command in worldcraft/hammer which will find brushes like that. Have you tried using an alternate compiler and see if you get better results from it? 

I just don't understand why or how Light should cause an error like that, because it only generates the lightmaps data and adds it to the bsp, but it doesn't affect any entities or clipping hulls. Normally, anyway. I take it this is BJP's light tool with no additional compile flags? 

that pointfile is also going through a solid wall btw.

negke: for what it's worth it was with -extra -light 37 but that shouldn't make a difference

preach: I tried LordHavoc's kit and got even worse results than before

everybody: this map had over 300 warnings when I finally gave up. I'm just going back and trying to get it under 50 or so and then seeing what happens so trying to help with this problem is now superfluous, thanks though. 

If the pointfile is going trough a solid wall, it means that you have a misaligned poly somewhere around... and certainly by something like a 0.000001 delta: those are the most critical to resolve unfortunately... as almost invisible in the editor (you may have to check all poly coordinate to find it.... QuArK behavior) :(
OTOH, what you can do is to try with aguirRe TxQBSP.exe and add "epsilon -0.01" option, and check what it looks like ingame (without running vis and light)? The -epsilon option change a little bit the way collision detection and poly expansion processing
is performed AFAIK, and sometimes it gives interesting results.. The default epsilon value is 0.05, (like standard BSP compiler), and reducing the value increases the precision, hence helps to detect HOM and misaligned polys..
Let us know whether it helps ;) 

Maybe Radiants Bob-Toolz Brush Cleanup could help too. 

-epsilon 0.01 is default 

Try both bigger and smaller value...

Quotes from txQBSP readme...


.....
TxQBSP 1.11 (Feb 16 2005)

1. Improved handling of complex maps such as terrain. This is done by increasing precision when identifying unique planes (faces) and modifying hull expansion logic. This reduces the risk of clipping errors and creates much smoother clipping hulls which can help player/monster movements.

All maps don't benefit from this, therefore two new options have been introduced; "-oldexpand" which just disables the new expansion logic and "-epsilon x" (default 0.01) which sets the plane identifying tolerance. To revert to previous compiler behaviour, just add options "-oldexpand" and "-epsilon 0.05".

The default settings have been chosen for overall best results. If you have a big map that still doesn't build correctly, you can try lowering the epsilon even more, e.g. 0.001. In most maps the default settings have little effect on # clipnodes, but some maps can see either a significant increase or decrease. Thanks to Tyrann for this one.....



hence my mistake on epsilon default value...

Note I solved some issue in my previous huge maps using this epsilon option (i.e in Gateway to Hell, I had a hard time to fix a leakage onto a stair step, that was misaligned by 0.000001)...

Experiment ;) 

JPL: low epsilon values seem to help with various issues, but light still moves the monsters around.

Preach: I did find a lit/unlit version for your perusal so you've got mail 

txqbsp with epsilon 0.00001 and hmap2 - light makes everything work again. Maybe I can still be lazy with this after all :P 

May I suggest you contact directly aguirRe in order to get direct feedback from him ? I guess he could be of a real help to understand what is exactly the issue, even though he is not involved as he was some years ago. I am pretty sure he would not be reluctant to help you... give it a try and let us know ;) 

Is there an easy way to make trigger_monsterjump trigger once? 

But you can killtarget it after use, maybe even by the monster itself. (*)

(*) Not sure if Quoth fixes this, but normally, unlike other entities, monsters can't just have a killtarget, they also need a dummy target for the former to work. In this case, both could point to the trigger_monsterjump. 

I used a trigger_once killtarget

trigger_hurt, trigger_monsterjump and trigger_push could use more control. Quoth has better control for trigger_hurt. Be cool if they had playeronly/monsteronly, target and count.