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 

It�s pretty easy to get the colours right with photoshop and the curves set that Kinn did, not sure where to find that though.

Wasn�t there a glowing coals tex in one of Tronyn�s older projects? 

It was called. Not sure about the texture though. Just remember that the last level was a no monsters credits thing with some rocks in glowing lava for the player to clamber around on.

Might have to play that one again...

Here�s the link to the curves as well, courtesy of Quaddicted: http://www.quaddicted.com/files/tools/photoshop%20curves.rar 

thank you 

http://www.cgtextures.com/

Site has some good textures. Not Quake ready 

Ehhhhhh Blow Me :P
#12189 posted by Fern [63.231.65.70] on 2012/10/28 00:29:22
No seriously I was going to do that anyway... 

I see that with GTKRadiant 1.6, the developers have dropped support for any and all games except for Q3/QL/ET and Urban Terror. What version of Radiant are the Q1 mappers using these days, GTKR 1.5? NetRadiant? Something else? 

works perfectly fine