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. 

Has a lot of potential - ONLY_MELEE for example.

Count is a good idea, and I always liked the Drole Rage thing as well. 

And just being able to toggle monsterjumps on and off would be cool.

Taking the melee only thingone step further this would allow for climbing fiends.

Just sayin :) 

I could have sworn I saw an animated texture of burning coals but I can't remember what map or .wad it was in and cba to check every one right now. Anybody know off the top of their head what I'm talking about? 

you're not talking about the doom texture with the kind of veiny glowing hardened lava? 

but I don't think so