Some automated way to set up pathing networks would be awesome too.

That's basically what I was saying. I'm certain there was a version of Radiant that did this. It didn't automatically name everything, but once you had it set up it would animate it in the editor and you could see the stuff move in the 3D view the same as it would in game.

It's possible it was a plug-in of some kind. I remember using it when I was working on a Quake 2 map, maybe 10 years ago. 

I will try to make entity "scripting" easier, that is, provider some way for quickly setting up paths and logic gates. I don't think I'll be doing in-editor animation though because that would be very specific for every game, and TB2 is not going to be limited to Quake. 

I've been having some fun messing around with Trenchbroom on my poor old laptop here, and I've found a way to reduce the complexity of the face shader (at a small cost to quality). If you've previously hit an error when launching Trenchbroom and would like to try tweaking it to see if reduced graphics settings help, then open up Face.fragsh in the Resources folder in a text editor, and change the getSoftStripes function as follows:

float getSoftStripes(float value, float gridSize, float stripeSize) {
��float mainVal = value * gridSize;
��float triangle = abs(2.0 * fract(mainVal) - 1.0);

��float sSize = stripeSize;

��return step(sSize, triangle);
}

This gets rid of the anti-aliasing on the lines and the bolder lines every 64 units, so you wouldn't want to apply it generally, but if your graphics card is as weak as mine it might just get things running! 

IIRC, AFAIK, BBQ, ( TB1 at least ) didn't do an Early Z Prepass or similar, so shaders are potentially invoked quite a lot, even if the fragments don't end up visible.

Whats your laptop's hardware like ?
Do you know which OpenGL Version it runs ? 

I put this in the issue tracker and I'll add it when I get around to it. Maybe there are a few other places where I could disable some stuff to get better performance. 

Unless you're gonna put a low-graphics fallback or option in don't go adding it in blindly. You lose features, I only wanted it to be there for people who can't use Trenchbroom otherwise. Loving the editor btw, really is quick and intuitive to use. 

I would only add this together with other features which would make the editor usable for people with low end hardware, basically like a "safe mode" option.

And thanks for the nice words, happy that you like it! 

yeah, went back to radiant for a bit and while the 2d views are useful, it felt awkward and slow working in radiant's 3d view. 

Yeah, I caved. Some things are easier to do in 2D than in 3D. TB2 will have two layouts, a Hammer-like 4-pane view for incest enthusiasts and a full size layout where you toggle between 3D and XY, XZ and YZ views with the tab key. 

With 3D view and 2D view side by side, using tab to cycle through the 2D views. 

2d view is good for making accurate measurements, something I really found difficult when I first started with trenchbroom. I don't feel like I need it much now, infact it may have been a bit of a crutch.

I'm looking forward to 2 things from next versions of TB, making maps for other games and making quake maps with 220 format texture accuracy. 

a Hammer-like 4-pane view for incest enthusiasts

lmao, but yeah, thanks for this. I love 4 views. I find the single view at a time way too limiting; having access to all 3 axes at onces helps me keep a better overview of what's going on. A nice toggle to go straight to full screen 3d (maybe camera centered on current or last selected brush/entity?) would be fantastic. The more fluid 2d <-> 3d, the better!

I don't feel like I need it much now, infact it may have been a bit of a crutch.
I often have to make 'measurement' brushes to get the precision I want which slows things down for me. But even with that, I still prefer TB to anything else right now. 

how do I enable that feature? 

I think TB currently limits you to -8192 to +8192, if you need to raise those limits, then this is currently not supported. 

But those areas aren't playable.

To enable the feature:

Step 1: Build a huge map 

 

As SleepWalkR says, there is the +/- 8192 limit, but this is only visible in engine.

In many editors (WC is an exception) this limit is not even visible and you can just keep building forever.

Trenchbroom is like this, at least in current release version; without anything delineated to say 'won't work beyond this point'.

In any case this is an engine limitation; I don't think it'd be good to retrofit TB to impose it as well since that'd affect development for other games.

I think FTE allows for gameplay outside the 8192 limit in Q1 as well. 

Its +/- 4k, 8k range.

And its a protocol limit rather than a random engine limit (read: makes stuff incompatible).
Some engines always use more wasteful/precise coords(DP). Some engines guess at map startup and probably get it wrong half the time(FTE). Some engines hack the protocol and probably crash. Others just crash outright. And others will just wrap coords in a really buggy sort of way because noone hacked them to do weird stuff yet (the inevitable fate of all quake engines - doing weird stuff).

BSP format limit is +/- 32k, due to the use of shorts in the node+leaf structs. This can be worked around, but its not pretty.

QBSP has an expectation that all geometry will be within +/- 99k.


Anyway, geometry outside the +/- 4k limit is fine (distant details or whatever) in any engine, so long as entity/effects don't leave the boundary.
Maybe generate a clip brush on the boundary the first time something gets put beyond it, just to make a point, or a popup message warning them or something. Otherwise, let the mapper shoot themselves in the foot if they really want to.

Limiting yourself to 18-year-old limits is stupid. 

Rocks and stuff beyond fences and out of windows, plus a train arriving from 'far away'.

Also some walls and stuff that if I moved 32 units would send the player to an alternate dimension, if they stepped up close. 

Limiting yourself to 18-year-old limits is stupid.

0/10 flamebait, try harder. 

@onetruepurple:
An editor that intentionally cripples its users is never a good thing. This is the TrenchBroom thread after all, not the 'I hate everything that wasnt made by id' thread.

oh noes! people might use it for things that are not cripply faithful! we can't have that! get the pitchfork!

its stupid, and its not helpful. 

A train moving in from "Far away" is an entity as are any lights and so on, and entities outside the +/-4k limit can cause bad things to happen. This is Quake, not Far Cry or something like that that may seem unlimited.

You can try the huge clipping brush barrier to keep the player inside the limits or make a detail brush with a skip texture that will also effect entities unlike a clipping brush. 

bsp entities tend to have an origin of '0 0 0'. they can start outside and move 4k qu in any direction without a problem - so long as the player, other pointentities (lights are okay), or projectiles/shotguns can't enter that region. 

It's already in and working - func_trains don't cause any problems as far as I can tell. 

The path_corners are outside - I assume this isn't causing trouble because they don't do anything.

I did have the train teleporting to the world 0,0 (and being invisible) at one point but this was bad qc / configuration of the path corners.