Ahh ... Ok, will try that! 

Ha, nice ... that fixed it AND it seemed to resolve the weird lighting problems I was getting in-game. Yay! 

 

That gave me quite a few headaches. 

I remembered it being submitted as a feature request but what's the status on adding a 2dview and grid? 

Progress is currently slow due to real life obligations. That is all ;-) 

This may be useful to users of the editor;

http://www.quaketastic.com/files/helper.mdl

It's just a scaled up and reskinned version of Sock's voreball, colour coded to match the various entity types.

This means you can turn off 'bounds' in the model view to make your screen less cluttered. You will need to add this;

model(":progs/helper.mdl" 0)

To the various entries in your .fgd (not sure if its the same format for .def) replacing the 0 for the corresponding skin - each skin is correctly named inside the file.

I'd share my fgd but its got modded entities inside and I can't be arsed cleaning them out. 

Updates have been slow recently, so before people get worried I thought I'd give a small status update. TrenchBroom 2 has been progressing nicely in the past months until the point where I started to integrate a new feature for layers and groups into the editor.

It turns out that the internal structure I had for representing maps did not lend itself well to this particular extension, so I had to change it significantly. This of course rippled into basically every other part of the editor, and I'm working on adapting all other parts of it to these changes.

Progress on this has been a bit slower in the past two weeks as I am quite busy with real life stuff, too. But I'm still working on it, and it's going forward. I'll start pushing new builds as soon as the editor is back in a usable state. 

Great to hear it's still moving forward. I'm just grateful that people find any time to work on projects like this.

I think we all understand that real-life gets in the way a lot more than for example 13 years ago... when I was living at home, playing Q1SPs while mum makes me din dins.

The cool thing about Trenchbroom though, is that it's making mapping so much easier, it seems to be combatting lot of mappers real-life time constraints, and therefore caused a resurgence in Q1SP releases! So keep up the good work, it's very much appreciated. 

I wish I had started with TB a couple of years earlier when I was still a student. Oh, the time I could have sunk into it then. Now, it's just the odd couple of hours here and there.

Thanks for the encouraging words! 

Haha, seriously ... I wish I could take everything I know now, and rewind a few decades. Single, all the free time in the world to work on projects ... I didn't realize what I had. :P 

Not really touched the editor for longer than 5 mins while I got a new girlfriend. I have a crazy mapping itch needing to be scratched 

Didn't realize there was a newer thread for TB and posted in another, but here is my issue compiling on Linux. I have finally gotten to the point where it almost compiles, but now craps out with 4 g++ errors ; http://pastie.org/9726329

It might be a simple error on my part or obvious to someone more knowledgeable than I. Any help appreciated. 

When I attempted using latest wx src 3.0.2 its still failed, but a whole different way. http://forums.inside3d.com/viewtopic.php?f=6&t=5142&start=75#p55021 

Pet peeve:

"wad" "C:\new\new.wad"
or worse:
"wad" "C:\new\"
(found in at least one map)

C:<NEW LINE>ew<NEW LINE>ew.wad
makes no sense, and the other one:
C:<NEW LINE>ew"<UNTERMINATED STRING CONSTANT>
will just corrupt the world entity and everything that comes after it.

Seeing as most tools take significant shortcuts and don't parse things properly, can you at least ensure that wad paths are written out with / instead of \ or \\, so as to ensure maximum compatibility with existing tools, without outputting unsupportable gibberish please?
The alternative is to ban \n and \" etc, but this issue interacts with saved games, but making special cases for parsing wad values, or special cases for saved games vs initial load is annoying and clumsy. 

So / is preferable to \\ ? 

/ works fine in the core windows api, but may be rejected by microsoft's commandline tools.
\\ will generally work, but might cause problems with things that do try sanitising things (poorly).
/ is a single char
\\ isn't usable at the start of a relative path (unc shares), and is thus potentially dangerous in windows (if poorly sanitised, // is identically dangerous).
/ is portable
\\ is not (poorly sanitised, // is equivelent to /../ on amiga and thus unsafe).

so yeah, / is preferable to \\ or \
but hey, \\ is at least a correct C string, and acceptable as-is for most of the windows api. 

But not for absolute paths. TB supports both. So I think I'll use the escaped version with \\ on Windows. 

as far as windows and the C api is concerned, / is as portable as \
leading \\ (or //) will be interpreted as a unc path if the tool doesn't de-markup the string (hurrah for lazy parsing), so be sure to use / instead of \\ if its the first char of a drive-relative path, even in windows. 

Thanks. 

So are there any plans/chance for Hexen 2 support?

I have a couple of mapping ideas I want to try out for it but I'm sick of the editors I used to use 

Hexen 2 is supported in TB 2.0... You need to speak to SleepwalkR about access as a beta tester 

How would I go about that? Should i just ask about it here? 

Send me an email: kristian.duske@gmail.com 

so i go and make some terrain looks fine in the editor and compile it looks fine in game

then i load my map back up in the editor and some of the terrain vertex points are off by one unit or more which is impossible to fix sometimes without making the terrain again and hoping it will be trenchbroom valid

yet when i load the map up in hammer those vertex points arent messed up