Hey guys!

I just started using Trenchbroom and I'm having some problems when I'm cooking/baking the map. Just for testing I created this one room with just an enemy some lighting and pickups as well as a player spawn. It cookes/bakes well and when I load it in-game the bsps seem to be invisible, so I can look out in the infinity. Yet I can still see the enemy and the pickups.

Anyone know how to solve this?

Cheers,

/ Stefan 

1) post a link to the .map because it could be a number of things

2) you don't need to sign your posts 

It's to do with navigation - they won't cross a gap they think they can't.

In order to make it invisible to the player you can put a func_illusionary in the gap. 

 

That linked image confuses me a little. Wouldn't monsters try to cross using that thin bridges?
Maybe there is minimum floor size they can use for navigation?

The way monsters navigate is mostly by blindly moving towards their enemy, turning randomly whenever they hit a wall or cliff. So technically they could cross those narrow beams but it's very unlikely . So if you want 100% impassible you probably need an unbroken gap with a func illusionary to fill in if desired. 

I wrote an article on how to program monster clip here:

https://tomeofpreach.wordpress.com/2015/11/18/selective-clipping/ 

If you don't care that it won't work in COOP mode, you can hack monster clip by making a func_wall with clip brushes as described in the blog post above. Then add to that func_wall the key

"owner" "1" 

I don't think monsters could path over those thin beams as the monster would be considered partially in the air due to some corners of its bbox being off the floor. AI won't willingly move to this state. 

Ah, so it tests all 4 corners for ground contact? Then I agree 

My current map exceeds safe limit and I have HOM effect starting at 4096 (only size warnings in log, no leaks).

In this case I'll move few rooms to fit, but was wondering is it possible at all to make a map which is larger than 4096?
Why editor shows grid up to 65536 if I can't use it? 

It's a network protocol limit. You can make maps larger than +-4096 but they will only work in engines with a protocol that supports it, like darkplaces. 

It might be explained a thousands times, but every time it breaks me up.
Why does a map start leaking while there is no common explain for it?
A kinky brush, a wrecked up detail, an unusual corner.
All I see is a red line that leads me to a *.prt file making me guess there will be a bad brush.
When I deteckt the bad brush and delete it another one shrimps up like a balloon pressure.

I can block them off with a cube and precise the dilemma, but I just don't understand the meaning of it.
Give me a looking box and I can tell when there's no hole to look in but.., aargh! 

Because math. 

me for alladin. 

Is it because id wanted accuracy of geometry over usability? Or was this a limitation of the tech at the time?

Out of interest would less leaks occur with relative coords rather than a static grid? 

coordinates relative to what? 

to each other, or the first brush placed. 

Is there any way to create invisible clipping volumes in Trenchbroom? There's a lot of stairs in my map and I'd like to cover them in a ramp to smooth out movement if that's at all possible? 

create a normal brush with the texture "clip" on it, that will do what you want.

However, ramps for stairs are kind of bad in quake because player will slide down the ramp, unlike stairs where you can stand on them properly. Also grenade bounce behavior on ramps is weird and different from stairs, and players will expect stair behavior if it looks like stairs. 

I'll probably just have to reimagine this section, the buffeting down the stairs caused by always run is too annoying to leave in IMO. Thanks for the help anyway. 

What editor are you using? 

Working in TrenchBroom atm but I think I wanna move to something more robust. I'm more comfortable working in orthographic views. 

My bad spud, still getting used to the format of this forum.