"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 

I've not tried TrenchBroom yet, so I don't know. But, I would like to say:

I used the Quest level editor for many years, instead of QERadiant and GTKRadiant. Why? Because I was able to make a map 10x faster, using Quest's controls.

I take an interest in TrenchBroom because of the single 3D view, because that is how I did it in Quest.

In Quest, I always fullscreen one of the views, and I would use the keys to navigate, and a key to switch from 3d to grid view. The key for switching to grid view was very powerful for me, because I often used the grid to line things up better and visually measure stuff better.

The view in Quest was restricted to 90-degree angles only. I loved this. You could also turn off restrictive view and then rotate the camera to any angle you wish. But, I was always in restrictive view mode, 90-degree camera angles only.

To move around, I used "A" and "Z" which is Zoom In and Zoom Out in grid view, or Forward and Backward in 3d view. The arrow keys "UP" and "DOWN" were for Panning up and down in grid view, and flying up or down in 3d view. Same goes for the "LEFT" and "RIGHT" arrow keys.

The keys to turn the camera 90-degrees to any direction, my favourite keys and these were critical to my 10x speed of mapping, were the key combinations of "ALT+LEFT_ARROW" to rotate camera 90-degrees to left. Same goes for any "ALT+{ARROW_KEY}" combination to rotate the camera 90-degrees towards that direction arrow key you pressed. Same goes in grid view, the view would rotate as well.

I'd like to keep this in mind, and see what you can do about having your editor provide the same type of usability controls as what I've described.

Thanks! 

I'm sorry if this will sound harsh, but the last thing I want to do with TrenchBroom is make it work like another editor that clearly follows a different UI approach.

I suggest that you try TrenchBroom and forget about how Quest works. Use it with an open mind. If it doesn't work for you, then there are plenty other editors out there. 

So, you didn't think about what I said.

You didn't even give it a thought--nevermind the particular keys being used--but no thought of having an option to restrict the view to 90-degree angles-only and using key combinations to rotate the camera 90-degrees to any direction, and keys to move and pan around at high speeds.

Keys, keys, keys.

Instead, you closed your mind, and immediately responded with a generic and vague "im not changing my editor." liner. Okay.