No problem :) 

That is still kinda bad practise though, right? Plopping worldspawn brushes together like that. Esp. since you do not want to keep track of which brushes were placed earlier.

So in most cases like that you should still cut one of the brushes up into smaller parts, right? 

yeah, it's best to avoid - messy map file. But if it's hard to avoid overlapping world brushes, the compiler will deal with it. 

Thanks for the extensive responses, ericw and ptoing. 

That's what this place is here for :D 

I've noticed that on some angled brush-faces, the brick texture I'm using is warped -- as in, the vertical lines on the texture (the short part of the bricks) are diagonal instead of vertical. No amount of changing the texture angle/size/X/Y-offset seems to help...

Is there any way of fixing/avoiding this? I'm using TrenchBroom 2 on Linux. 

I dunno about TB2, but Jackhammer has very good texture alignment tools and there is a Linux build, so maybe worth looking into that. 

I *think* that's something the "Valve 220" texture alignment fixes. And I *think* TrenchBroom supports it.

At the moment I use Netradiant, but I seem to remember somebody here sending me a map a year or so ago when I was trying TB1 that showed how it looked, and I remember being surprised how much better it was at aligning textures on angled and rotated surfaces.

Make a backup copy of your map if you try something like that, it may not be reversible. 

I can't believe I've been mapping all this time and just discovered this. Makes positioning info_intermission easy.

Turn on noclip and find a good view. Open the console and enter the "viewpos" command (no quotes). Write down the numbers:

(origin) mangle

Enter these in your map for an info_intermission - Done. 

That's a result of the way textures are projected onto faces in Quake. Your only option is to use the Valve 220 map format, which TB2 supports. However there's no conversion function yet, but I could implement one. 

Thanks very much, ptoing, Rick and SleepwalkR, for your responses.

SleepwalkR, how does one go about using the Valve 220 format? I can't see any option for enabling it. Is it enabled by default? Or is it something one specifies when compiling? 

when you create a new map. In the game selection dialog, when you select Quake, you see a dropdown list below the game list where you can choose between Standard and Valve 220 map formats. 

Does that mean I'm now stuck with standard format in the current map I'm working on, at least until you implement conversion? D'oh.

I tried opening a new .map in Valve format and copy&paste-ing my current map into the new file, but it doesn't work -- it says
Unable to parse clipboard contents: (line 2, column 1)Expected '(' or ')', but got 'classname'
I'm guessing that's because you can't (currently) copy&paste between the two formats in TB2? 

First, I need to write a converter. Maybe I can squeeze one in tonight, because converting from Standard to Valve 220 is easy. The converse isn't, though. 

 

You'll be happy to know that the old way to draw brushes is coming back in TB2. You will have to enable the brush tool to do it, but then you can just bang out the brushes by dragging as usual. The new mode is only activated if you hold shift while clicking or dragging. 

that does indeed make me happy. Getting the brush mode to work has been a bug-bear of mine though. I've struggled to make brushes in TB2 in 3d view. Also, it would be nice to see a return of the 64x64 unit brush as a starting point when you start working on a new map. 

I was under the impression that BSP2 removed the original +/- 4096 loop boundary but this still happens to me in BSP2 compiled maps. Does it require engine support too? I'm using QS 0.90.1 

BSP2 does not remove the 4096^3 boundaries. 

ohh whoops, i thought those two were kind the same thing. :S 

Caught me by surprise too when I found about it. 

No, the 4096 is tied into the networking protocol and other things I believe. Would be hard to remove. :-/ 

map format already supports larger map sizes, it's the network protocol that is the limiting factor.

I didn't add this feature to protocol 666 because I couldn't think of a good way that wouldn't make packet sizes bigger for normal-size maps. This means you'd get a packet overflow on some older maps that wouldn't overflow on protocol 15. 

The empty map will contain an initial room at some point in the future. If you want to testdrive the new / old create brush tool, I can upload a new build that contains it. 

Mankrip, da man behind Makaku and Retroquad engines, runned my jam 6 level and reported two bugs that pop in software render.

The mipmaps of my fixed rock_brown texture were wrong. I used Wally to edit the wads. Apparently the default settings for Remip Deluxe doesn't work well with Quake software render. I had to go to View / Options / Remip and click the "Use Quake Lookalike Settings" button.

Also, liquid textures bigger than 64x64 get distorted by software render. I was using *lava4a. For full compatibility, I'm changing to *lava1.

DLC will have both fixes.