That would be a use case for filtering, but groups are different. I think there are other reasons to make groups:

1. You want to be able to quickly select objects that belong together because they form an architectural feature, such as a door incl. its frame. The goal is to edit them as a group.
2. You want to be able to quickly hide stuff that forms an entire part of the level, such as a bunch of rooms with the interconnecting corridors. The goal is to unclutter the view.

I want to implement both functions using func_groups because then I can get by without extending the map format. As for additional controls, I think this could be nicely integrated with the planned map browser (tree of all objects in the map). Not sure yet. In any case, groups would have additional checkboxes for hiding and locking them individually. 

Nice! That would be very cool! 

I've done a bit of debian packaging (and know people who have done a _lot_), I'll try to take a look at some point. It probably won't be until April though. so if someone beats me... 

Hello again. I have one question about rotation. Do you think you could add the option to use local object space for brush rotation? It would be nice to rotate the object and have the gizmo update with it instead of the default world space rotation axis.

I use this a lot in normal 3d modeling when placing decoration bits. It sure would make things like fallen over pillars easier to place with the ability to adjust their spin on their local z axis after you rotate them at odd angles. 

That would only work for one session with the rotation tool as brushes don't have local coordinate systems. And since you can achieve the same result be reordering your rotations, I don't think it's necessary? 

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.