sorry for the double post.

i've got a map with 32unit thick bars every 32 units, so there are gaps in between these bars of 32 units. on the floor.

monsters won't cross over these gaps when running/walking. even if there is a clip brush which overlaps these bars and gaps.

what gives? i thought the clip brush basically added the collision data to hull1 and hull2... so why do the monsters still treat the area as if there were gaps in them? 

Yes! I've been meaning to ask this very same question - I noticed it in Bastion, and other maps and it has always bothered me. 

it must be something to do with tracelines in the movetogoal code only using hull0 or something. 

Part of the code that monsters use to do pathfinding uses hull0, i think. 

Could anyone point me to some basic tutorials on D3 mapping preferably non video ones as my poor 56kb wouldn't like it. 

Could someone tell me how to open the texture window with actual textures in. 

Scrap that, got it all working, yes I suck. 

I've seen some really good tutorials on map scripting (like how to get custom machines to animate properly) at doom3world.org.

Also, http://www.splashdamage.com/index.php?name=pnPHPbb2&file=index , has a forum to help level designers specifically on multiplayer matters. 

Have a dig around this site/forums, you should find some useful stuff.

http://www.doom3world.org/index.php 

sorry, didn't see it already above in HT's post 

I like being able to load wads into the editor without all the fuss. However in 1.5 i am unable to select a single face to change the textures. Is this a bug? Or is it me.
Thanks in advance.
-water 

It is you. http://zerowing.idsoftware.com/radiant-files/nightly/1.5.0/docs/ 

i hacky way to get monsters to cross gaps in the floor is to make an invisible func_wall entity (like hipnotic's func_togglewall)
that way, you still can't see it, but tracelines *will* impact on it's surface.

the downside is that you can't shoot through the gaps anymore, and gibs will land on them as well...

i suppose it could be possible to make an entity somehow toggle on and off depending on if a rocket was touching it or not, but i doubt that would work well... 

i get allocblock: Full.

now, i know this has to do with lightmaps and sealing the map usuall helps, but this is a little different than normal.

the map is still very small, only 1000 brushes or so. i've had maps that were 3000 or so brushes, unsealed with tons of lights without bothering quake a bit.
this map only has half a dozen or so lights.

also, i noticed the light compile time took much longer than normal. a few versions ago, it was lighting in about 1 sec while on this attempt it took 10 seconds.

aguire: this might be some issue with the actual light utility (or something i did which made an issue with the light utility) so i'm going to be messing around with stuff a bit to see what i can do.

thought you'd like to know or you might know what to do? 

got a Gl_buildlightmaps error: excessive lightmaps 67 (normal max = 64) 

edit2: that error appeared even when i *didn't* light the map at all. how can there be lightmaps when i didn't even have them calculated? 

figured out what was wrong... had one of those huge/infinite brushes, so the face count went crazy. never mind... :P 

Is a brush error. Try to load the .map file in a few different editors to see if some brushes don't load.

If that doesn't work, try to delete any brushes you added recently that have weird manipulations.

Also, look for microscopic OR gigantic brushes in the .map file. (in a text editor) 

Is it possible for you to try to reduce the chance of appearing of HOMs in the next version of your QBSP tools?

Or at least explain me why HOMs appear in places where they haven't been before after I place some more brushes in the room. Or does it have no explanation? 

When a HOM is on the surface of a brush and is not affected by VIS, I've found that it will usually fix the problem if I make sure all the edges and vertices meet perfectly where the HOM occurs. 

This may (or maynot) help you. Have a read of the "tooltips.txt" on AguirRe's site, scroll down to "Portal Problems"
Direct Link to ToolTips
http://user.tninet.se/~xir870k/tooltips.txt

AguirRe's Site
http://user.tninet.se/~xir870k/ 

I assume the first error message was when you were not using any of my engines, the warning you got when using one of my engines, is that right?

The AllocBlock: full error has no relation to whether the map is lit or not or how many lights or brushes there are.

It's only related to having very large visible brush faces (planes) in the map that the GL engines need to allocate space for. Too large and too many of these faces will sooner or later exceed the lightmap array (normal size 64, in my GLQuake it's 512).

Software engines Win/TyrQuake don't have this problem at all. 

what RPG and VoreLord said; check out brush alignment in the area and my ToolTips doc (Portal Problems section).

If you still can't fix the HOMs, please send me the zipped map+wad and I'll take a look at it. 

hehe, should have specified. :P

i was using fitzquake when it crashed with the error, so i loaded it up with your [aguire's] quake engine. man, i love that engine. ^_^

.
i didn't know that about the lightmaps. i just assumed if there wasn't any lighting, that the lightmap would be zero (making quake default to fullbright)

also, is it possible to make your vis and light start with different priorities like your qbsp does? it'd be nice to make light and vis always use 'belownormal' priority. :) 

I only added that possibility to qbsp since it's normally so fast that you don't have time to manually use Task Manager to change the priority of the process.

I have a small utility that you can use to start any Win32 console program with a specified priority and optionally with a timeout to wait for completion. After the timeout expires, it will kill the child process (useful when it might get stuck).

I'll email you this small utility.