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. 

Exactly whats happening. 

Is there any way to "deselect" the current texture, so that TB will create untextured brushes again, like it does before you select your first texture? I've been putting up with it for months because it's really just a pet peeve, but I prefer to build the foundation of my map without texturing and then texture and add detail later. Having to either deal with crappy, distracting textures/colours (I know you can disable texture rendering, but the textures still show up when you actually load the map) or restarting the application when I want to work on a new area is kinda lame.

One advantage of using the default texture to me is that it helps to spot untextured spots; they show up very well since in QS at least they're always fullbright, so it can help me find areas i've missed. 

Currently no.

Ive been meaning to suggest it along with some other texture based ideas/issues.

currently, you can select a face with shift+LMB and then apply that texture to another face with alt+LMB (you can also apply it to a whole brush by alt+double LMB). Id like to be able to "paint" by dragging the brush similar to how youre able to ctrl+LMB and select multiple brushes.

also, while a texture is selected itd be nice to either paint or apply that texture with its current coordinates or default. 

also, while a texture is selected itd be nice to either paint or apply that texture with its current coordinates or default.

Try holding ctrl+alt, it should not copy the attributes in that case. 

currently, you can select a face with shift+LMB and then apply that texture to another face with alt+LMB (you can also apply it to a whole brush by alt+double LMB). Id like to be able to "paint" by dragging the brush similar to how youre able to ctrl+LMB and select multiple brushes.

That's a good idea. Submit a feature request please. 

Also submit a feature request for deselecting the default texture. 

Nevermind, I've already changed it. Deselect everything, then click on the selected texture in the browser and it will deselect. Will be in the next beta.