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? 

I opened good.map in TB2 a few times and it looks OK. Also when I load and save good.map in TB2, the saved file is the same as the original (ignoring the order of the faces) which is good. 

Well, I ran TB1 in Valgrind and it reported that while loading my test map, Face::Face(worldBounds, forceIntegerFacePoints, point1, point, point2, textureName) was using an uninitialized value, m_forceIntegerFacePoints. If I stick in a m_forceIntegerFacePoints = false/true; there, my map reliably loads correctly/drifted, and the valgrind warning disappears. Will post a PR on github.

I think that can explain the weirdness a lot of people had, since it would mean every time a map loads, each face had a chance of being snapped to have integer face points. 

How did you get it to ignore all the warnings from within wxwidgets? When I tried it, I got so many that I couldn't find those which originated in my own code. 

I didn't do anything special; there were only 10 or so from wxWidgets as the application started, but none after that. I was using wx 2.9.5 and followed your instructions in Linux/Build.txt. 

Maybe it's worse on wxWidgets-Cocoa.