Oh, that would be great. I plan to change the dependencies so that you don't have to make your own build of wxWidgets on Linux anymore, maybe it will be easier then. 

Worldcraft only has it because it uses its own map format that is not compatible with the compilers. Because of this, I can happily work away in my .rmf map and export to .map when I want to compile without disrupting anything. It also has an option that allows me to export visible objects only, which is handy for debugging the map.

Maybe I can support it in my batch file, though the problem is that the working map file name changes based on map and version (e.g. map1_01, map1_02...) and detecting that in the batch file is fiddly perhaps, though I've never looked into it.

Adding the feature to the editor would require an export option adding to the file menu and potentially an export location adding to the preferences (always export to the same place so that exporting is a single click away).

As you said though, it might be an obscure feature, and I'm not really sure how everyone else tends to build. Since building isn't handled from TrenchBroom, and probably shouldn't be anyway, it seems like a simple feature that would be handly for streamlining the build process, that's all.

Anyway, if you think some kind of export feature would be ok but don't want to spend time implementing it, I could try perhaps? Currently I'm just getting the project set up. It might be worth getting a code::blocks project set up for windows for those who don't have VS and want to fiddle with the code. I had to install 2012 to test a friend's game, but the install process is insane and it eats up 13gb of disk space. I'm going to look into that if there isn't one already. 

I've been calling this editor Trenchboom since I first saw it... 

"Export" implies a different map file format, which this is not. Maybe a "Save copy..." menu item could be added to the file menu though.

Regarding Code::Blocks, yeah, that would be cool. Not sure how easy it will be to set up the dependencies (wxWidgets mostly), though. 

Seems quantal only has packages of wxwidgets 2.8, I presume 2.9 is a hard requirement? Some dude has a PPA with 2.9 in:

https://launchpad.net/~sven-eckelmann/+archive/ppa-wxwidgets2.9

Does that look new enough? 

That's why I suggested a kind of on/off system, searching by entity fields - it wouldn't invalidate the .map format.

Haven't thought through the ramifcations properly though, so no idea how difficult it would be to code. 

seems that code::blocks can import the sln file without any problems. I have to get wxwidgets properly installed before I can compile, but this is a good start. Once I get it compiling I'll post a little set up guide for anyone else that wants to look at the code and fiddle with it. 

Yes, 2.9 is a hard requirement because I use components which are not present in 2.8. I wanted to try these:

http://www.codelite.org/LiteEditor/WxWidgets29Binaries#toc1

I have no idea how up to date they are, though. I'll try the ones you found as well. 

Look at Windows/Build.txt for exact instructions on which files to get for wxWidgets and where to put them. 

After I clicked build twice? I got some error about SIZEOF_LONG the first time... now I disappear for a month :) 

It should build without warnings, much less errors. 

I would be fine with it being once a session. Or maybe add another file that sits external from the map format for this type of addition? That way you don't need to break the map format but can store info in an accompanying file. It would be lovely stuff.

Either way still cant say enough how much I love this editor. Rocks my socks off! 

I have added a feature request for session-wise local coordinate systems, but I won't make them persistent. That would add too many new problems. 

This code in Include/freetype/config/ftconfig.h:

#if defined SIZEOF_LONG
#undef SIZEOF_LONG
#endif
#define SIZEOF_LONG 4

looks a bit suspicious on my 64 bit system :) 

fucking wxwidgets!

This again! I can't figure out how to get wxWidgets to work with code blocks. It's such a horrible fucking nightmare to get it working correctly. 

still no luck. I got rid of the wxwidgets simply by copying setup.h from the wxwidgets lib/gcc/msw/wx folder to the include/wx folder, but now I am getting an error saying va_list has not been declared (String.h 97)

No idea what I'm doing wrong, but this is the kind of thing that always puts me off doing c++ programming. Environment setup is fucking shit and makes me very annoyed :/ 

Let us schedule a Skype meeting so that we can sort this out. 

More random, non-rtf, feature ideas:
- display the size of the selected texture in the tex window
- always show the current grid size somewhere (as a number)
- specific filter option for skills + deathmatch (may be something for the fgd to allow similar filters with different games)
- possibly status bar?
- minigame to pass the compiling time (tetris) 

Another idea I'm throwing out there. What if upon starting a new map, there is always a single 4x4x4 brush at 0,0,0? This might prevent some disorientation when placing your first brush since there's already one there for reference.

Excuse me if this had already been suggested, kinda skimmed through the recent posts. 

Maybe even provide a whole little textured room with a light source (like Quark ;) ;) ). Then one has a way to test the compiling pipeline easily. 

- A tablet version is a very interesting idea that I have thought about a lot, but I decided it's not within my means for the time being.
- Texture size, grid size, specific filter options for skills + DM; noted.
- Status bar is a no, but I will add something similar (but better).
- Minigame, cool idea actually. ;-)

Quakis, excellent idea! 

I like that idea so much that it's going to be in 1.0.5. 

Tablet version - every time I pick up my iPad I think, "Man, it'd be neat if TrenchBroom worked on this thing". :P 

I can imagine two use cases for a tablet.

First, of course, as a standalone editing tool. It would surely be cool to be able to directly touch and manipulate the objects in the map. There is only one problem with it: Your fat fingers. Yes, yours. Because they obstruct your view of what you're actually doing. One idea to overcome this would be to automatically move / rotate the camera when you touch something so that it becomes visible again, yet reacts to your gestures.

Second, it would be cool as an additional input device for TrenchBroom on a desktop PC, because I guess somethings are still easier to do with a pointing device that's not your fat finger, and somethings are much more intuitive to do with the fingers (rotation!). 

Oh yeah, there are a ton of interface challenges with it ... I just think it would be neat. :P