Or maybe it works better for you, but I'm afraid that I'm not inclined to change it again.
That's OK, I'm used to it by now. I was speaking from the perspective of the total n00b who tackles TB for the first time (which I was just a few weeks ago).

unfortunately there's nothing I can do about it.Damn. Oh well, fly mode can serve as a workaround, but it would've been nice to be able to do that. 

Sat down to record and I can't open the map I was working on. I tried other maps from AD and the base maps and they all through the same error:

"Cannot load compilation configuration 'Quake\CompilationProfiles.cfg': Unexpected character: $ [line 7, column 22]"

I'm guessing this was caused when I tried setting up a compile process, but I can't launch any maps because of it and I can't find the file. 

*threw 

Please create a report on github and attach the file located at

C:\Users\<username>\AppData\Roaming\TrenchBroom\games\Quake\CompilationProfiles.cfg 

C:\Users\username>\AppData\Roaming\TrenchBroom\games\Quake\CompilationProfiles.cfg 

C:\Users\USERNAME\AppData\Roaming\TrenchBroom\games\Quake\CompilationProfiles.cfg

Where USERNAME is your, well, user name. 

I don't know of any alternative libraries apart from Qt, but how bound to WxWidgets is TB anyway? It kind of feels like it's limiting the application in a few ways these days, like with that dragging issue I opened on Github and the inability to lock the cursor to the window.

I can't imagine UI development is much fun, so I don't blame you for not wanting to move away from what you already have, but it is getting a bit painful to see such annoyances. 

Done. 

the better choice, but it's too late now. 

blank origin key followed by entirely blank key

It's pretty annoying; brushes seem to develop this seemingly at random without even being interacted with half of the time, and will either begin to appear slightly displaced in a compiled map or will completely dissappear and instead show up at the bottom of the level in-game.

I'd open an issue on github, but I wanted to check here first since there are a few factors to consider, and like a similar blank property issue I haven't been able to reproduce it on demand.
The main issue is that I'm developing for AD, and so my thinking is that this could somehow be an issue with the .fgd i'm using, which is the one included with the mod. Has anyone else had this happen in other editors? Or had it happen in TB, but with different mods?
Getting this part figured out would be great, I'd feel a lot more confident opening a github issue if I knew it was a TB problem and not an AD problem. 

I use TB, and I have never seen this happen.

I am also creating a map using AD so it could be the .fgd you are using? (I am using the one that comes with the official download, just modified to my needs) 

I'm using the AD .fgd that I have from my download as well, and I haven't modified it at all. (I actually looked inside to see if there was some clear issue with it, but then I realised I have no idea how .fgd files work so I gave up) 

You seem to be the only one with this issue. Are you using another editor together with TB? Or it might be that you are using the entity property grid in an unexpected way, maybe you are trying to use keyboard shortcuts there, or you are using keyboard shortcuts with the intention of doing something in the 3D view, but the focus is on the entity property grid? 

I have same kind of issues. Items aren't in same place after compiling, than what they were in TB's editor view. In fact If I open my map in older version of TB versions 1. something, it clearly shows that in fact those are in different place than what it was in TB2.. that is why I place items in TB1 only. 

Or maybe I'm missing again something:
https://drive.google.com/file/d/0BwxYkKdSD855UVptNmQ4TmZ6em8/view?usp=sharing 

I mean.. the one in TB1 screenshot represent real actual position where it actually lands in game. Would it be possible that there is something wrong in AD.fgd?... but to be honest, this same happened during base jam. So either both has something wrong in fgds or something is different in TB2 than what was in TB1 when it comes to item placing. (x,y,z position). 

I've seen that issue as well, all the items in my AD map have to be off center by about 16 units or so. It's like the center is actually one of the corners in TB, it's pretty easy to compensate for once you realize.

For some reason, I thought there was already an issue for this, but I can't find it... I might take some screenshots when I get home and create one. 

Can you create an issue with a minimal example? Does it affect all entities of a certain type, or only specific ones? 

I'm not sure it's an issue with TB right now, rather the .fgd provided by AD. It's pretty easy to see on my end if you simply switch your entity definition; you can actually see the entities moving in the map as you do so.

video

In the compiled level, the entity appears in the place where it was at the start of the video, rather than the one shown when using the ad .fgd

Also, TB freezes really hard when you switch to an entity file and don't have the appropriate mod directory selected, when it starts working again the console is spammed with missing model errors. Not a big deal, except when you're switching a bunch as I was just doing...

I tested with a few types of entity, and at least for this fgd it only seems to appear with health and ammo entities: image

If you like, I can open an issue on github with this evidence attached. Not sure how much of this is TB's problem, though... Building special cases to handle problems in 3rd-party files is a dangerous path to tread. 

One thing to note from the AD readme:

Mappers : The editor .def and .fgd files supplied with this MOD require
: the worldspawn entity to have "no_item_offset" set to 1

float no_item_offset; // All ammo/heal items use central point rotation


My understanding is, the AD fgd/def are designed with the origin for health boxes to be in the center of the model, and you're supposed to set "no_item_offset" "1" in the worldspawn of custom maps.

The idea is AD can also run vanilla id1 maps which use the origin of health pack entities as the corner of the model. 

I dislike creating github issues for things until I'm more certain. I've been consulting the AD readme a fair bit lately as I toil, but I didn't find that part in the places I looked! I set the key, and now... all my items are in the wrong place. Well, they're where the editor says they are, but that's wrong in the map since I'd been compensating for my idiocy this entire time. Time to unset it and remember for next time... 

I think that explains NewHouse's issue as well 

my worldspawn's no_item_offset was set to -1... that must be the reason in here? 

Whenever I move a selection that contains a func_detail, the detail doesnt follow properly. it progressively gets more off grid as the further I move it.

Is it a problem on my end or trenchbroom? do other users experience this? Its a pretty glaring problem that seemingly hasnt been reported, or otherwise im missing it on github.

This happens in the most 2 recent betas, Ive yet to build from source as its something I've never done. Ill tackle the intimidation factor soon enough, I'm sure. 

Yeah - I had that as well. If it's the same thing you're experiencing, it should only happen when you use the "select touching" command: https://github.com/kduske/TrenchBroom/issues/1409

It was fixed a few days after the latest beta came out (spet 6), so you'll have to avoid using "Select touching" until the next beta is released.