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 

 

seems to load vertex points correctly nothing is off grid in 1.0 

running trenchbroom.exe with compatibility mode for any OS fixes it idk why but it does 

But do make sure that you use the latest version, which is 1.1.1 

You do tend to see vertices wander off grid over time. I think a fix was suggested but not sure if it was implemented 

But if you keep your plane points on the grid and don't build too complex brushes, the errors will be small enough to ignore. 

i wasnt even making anything complex just some raised or inverted brushes and they were going off grid until i set compatibility mode

and the problem doesnt occur on my win 8.1 x64-bit computer if i dont set compatibility mode only on this computer which is win 7 x64-bit so maybe its OS based 

https://www.dropbox.com/s/01zqjoe1komd5nn/good.map?dl=0

In Mac OS, if I double-click this map in the Finder to open it in TB (latest 1.1 build), look at the brushes, then quit the TB application and repeat, the map will look different each time: sometimes there's vertex drift (with different amounts/directions), sometimes not.

https://www.dropbox.com/s/d6ue7uurj84882n/good1.png?dl=0
https://www.dropbox.com/s/326ujizx92fqq1k/good2.png?dl=0
https://www.dropbox.com/s/27ud4h7527qkcyc/good3.png?dl=0
https://www.dropbox.com/s/ivcl33lewk0w4kg/good4.png?dl=0

On the latest Windows TB1.1 build, it seems to always open with no vertex drift; but if I open the map, go to File -> New, then open it again, it has vertex drift then.

https://www.dropbox.com/s/w5dur8zisoj3wlm/windows_not_drifted.png?dl=0
https://www.dropbox.com/s/npor518z96rh3lz/windows_drifted.png?dl=0

Here is what I got when saving the drifted version in Windows:
https://www.dropbox.com/s/nc9x7iwznrbyo2j/windows_drifted.map?dl=0

It's pretty weird, I might see if I can debug what's going on. Maybe memory corruption somewhere? 

But it doesn't happen in TB2?