seems to load vertex points correctly nothing is off grid in 1.0 

running trenchbroom.exe with compatibility mode for any OS fixes it idk why but it does 

But do make sure that you use the latest version, which is 1.1.1 

You do tend to see vertices wander off grid over time. I think a fix was suggested but not sure if it was implemented 

But if you keep your plane points on the grid and don't build too complex brushes, the errors will be small enough to ignore. 

i wasnt even making anything complex just some raised or inverted brushes and they were going off grid until i set compatibility mode

and the problem doesnt occur on my win 8.1 x64-bit computer if i dont set compatibility mode only on this computer which is win 7 x64-bit so maybe its OS based 

https://www.dropbox.com/s/01zqjoe1komd5nn/good.map?dl=0

In Mac OS, if I double-click this map in the Finder to open it in TB (latest 1.1 build), look at the brushes, then quit the TB application and repeat, the map will look different each time: sometimes there's vertex drift (with different amounts/directions), sometimes not.

https://www.dropbox.com/s/d6ue7uurj84882n/good1.png?dl=0
https://www.dropbox.com/s/326ujizx92fqq1k/good2.png?dl=0
https://www.dropbox.com/s/27ud4h7527qkcyc/good3.png?dl=0
https://www.dropbox.com/s/ivcl33lewk0w4kg/good4.png?dl=0

On the latest Windows TB1.1 build, it seems to always open with no vertex drift; but if I open the map, go to File -> New, then open it again, it has vertex drift then.

https://www.dropbox.com/s/w5dur8zisoj3wlm/windows_not_drifted.png?dl=0
https://www.dropbox.com/s/npor518z96rh3lz/windows_drifted.png?dl=0

Here is what I got when saving the drifted version in Windows:
https://www.dropbox.com/s/nc9x7iwznrbyo2j/windows_drifted.map?dl=0

It's pretty weird, I might see if I can debug what's going on. Maybe memory corruption somewhere? 

But it doesn't happen in TB2? 

I opened good.map in TB2 a few times and it looks OK. Also when I load and save good.map in TB2, the saved file is the same as the original (ignoring the order of the faces) which is good. 

Well, I ran TB1 in Valgrind and it reported that while loading my test map, Face::Face(worldBounds, forceIntegerFacePoints, point1, point, point2, textureName) was using an uninitialized value, m_forceIntegerFacePoints. If I stick in a m_forceIntegerFacePoints = false/true; there, my map reliably loads correctly/drifted, and the valgrind warning disappears. Will post a PR on github.

I think that can explain the weirdness a lot of people had, since it would mean every time a map loads, each face had a chance of being snapped to have integer face points. 

How did you get it to ignore all the warnings from within wxwidgets? When I tried it, I got so many that I couldn't find those which originated in my own code. 

I didn't do anything special; there were only 10 or so from wxWidgets as the application started, but none after that. I was using wx 2.9.5 and followed your instructions in Linux/Build.txt. 

Maybe it's worse on wxWidgets-Cocoa. 

Changes
- Enable texture names starting with '{' (ericw)
- Fix hang when adding multiple updating entity targets (ericw, necros)
- Simplify build instructions (ericw)
- Fix vertex drift on map load (ericw)
- Fix crash with colors in byte format (ericw)
- Add option to invert zoom direction when using Alt+MMB (kduske)

Download: http://kristianduske.com/trenchbroom/downloads.php

Thanks to ericw for the fixes! 

 

 

Danget Trenchbroom 1 needs the vertex snap to grid option from 2 :)

Right now I bounce between the 2 for map diagnostic bug hunting. So easy to find brushes that have verts not snapped to the grid.

But this is a nice fix! 

it seems when i try to copy paste somewhat complex geometry mostly arches by ctrl+c then ctrl+v the vertex points go off grid with a result like this http://i.imgur.com/jnIWPlv.png when it should look like this http://i.imgur.com/uYS3vGX.png

this issue happens on both my computers win 8.1 x64-bit and win 7 x64-bit

it doesnt happen when ctrl+d cloning

the issue is made worse if i turn the grid off

the issue doesnt happen in the previous version of trenchbroom being 1.1.1_368 

I can reproduce that, will look into it. Seems that copy/paste rounds to integer plane points. 

Thewaz154... what mod is that? I see a bunch of additional corpse deco meshes :)

Which makes me ask the question... where are the wall corpses as place able objects for quake1? 

@thewaz154, thanks for the report, I think I fixed the copy/paste bug. I need to check with SleepwalkR but there will be an updated build at some point.

@Skiffy, The corpses in id1 are monster_zombie with 'spawnflags' '1'. In TB you can just enable the "Crucified" checkbox to set the spawnflag.

For a wider variety, check out Quoth. in TB1, go to Edit -> Map Properties, then select the Quoth2.fgd in the first popup and the 'quoth' directory in the second (you'll need quoth installed.) Then you should see all the corpses in the TB entity palette. 

re-creation

#1. load trenchbroom and open a map with a decent amount of stuff in it and dont do anything yet

#2. go to face texture browser, pick a texture, and then create a brush

#3. re-size, clone, or copypaste that brush

#4. watch as trenchbroom crashes :c

this issue can be bypassed by moving, re-sizing, or cloning and already existing world brush and it wont happen for the rest of the session but its a bit annoying to have to do that every time i open my map up again

moving, cloning, or editing non brush entities doesnt bypass this 

Changes
- Fix vertex precision problems when copy/pasting brushes (ericw)

Download: http://kristianduske.com/trenchbroom/downloads.php 

Ah awesome. Yea was having some trouble with this lately