Sorry. Use the betas. They are more stable than the older versions. 

Sorry for not responding earlier..

Do you mean build TB2 from source, as opposed to using the deb package? Would that bypass the libstdc++6 issue? It'd be great if that would mean not having to do a fresh OS install.

Yes, I meant building from source as opposed to the deb package. I *think* it would bypass the libstdc++6 issue. However, if you did upgrade Linux mint, isn't there an "upgrade" feature in the OS that would avoid having to do a fresh install? Ubuntu has that.

Building TB from source on Linux is a bit involved because you need to patch and compile wxWidgets yourself. TB's instructions are good though.

Re: git flow, the current branch is "release/v2.0.0". So if you are building from source, you would do a fresh git clone, then "git checkout release/v2.0.0", then follow the build instrutions in Build.txt

If you're not really comfortable with building from source, upgrading the OS is probably the way to go, but I'm not sure what to suggest really. 

Sorry for not responding earlier..
No worries; thanks for responding -- I really appreciate it!

This clears up a lot. I have built TB2 from source before, back before the release of the first beta, and I seem to recall having to compile wxWidgets back then too. As long as I have good and clear instructions I should manage ... I think. I'll probably screw a few things up along the way and I might ask a few more stupid questions here as a result, but should get it in the end.

Speaking of stupid questions, I have a couple already:

TB's instructions are good though.

Are these the instructions you mean?

do a fresh git clone
Errr, how do I do that again? This is the part where you basically download all the files you then later use to build the programme, right? I remember having done it, but I can't remember how one does it, and Build.txt doesn't seem to say. 

Are these the instructions you mean?
No, those are the ones from the "master" branch which is outdated. here is the current build.txt.

Errr, how do I do that again? This is the part where you basically download all the files you then later use to build the programme, right?

Run these commands in a terminal: (this assumes you don't currently have a TrenchBroom subdirectory in the current directory)
git clone https://github.com/kduske/TrenchBroom
cd TrenchBroom
git checkout release/v2.0.0

The "git clone" is more than just downloading the source code, it downloads every branch and change made to the TB source code. It initially gives you the "master" branch in the TrenchBroom directory, which is outdated code, which is why the "git checkout" command is needed to switch to the latest code (release/v2.0.0). 

That's very clear.

I'm afraid I'm about to post a response to your offer for help in the Mapping Help thread that might make you lose your faith in humanity... 

OK, so I've finally installed Firefox on my computer and the help file now displays properly. It mentions a [CMD] key that I believe is found on Macs. The Windows equivalent is [CTRL], correct?
SleepwalkR, is it feasible to make it so that the help file automatically displays the right key depending on the user's OS 

Please file it on github. 

 

When I double click on a group of brushes, I am able to select and edit the individual brushes within that group (e.g. by holding shift and extruding contiguous selected faces).

If I double click on a group and press Ctrl+A then it selects all of the brushes in the group, which is the behaviour I would expect. But then I don't seem to be able to edit the brushes in the same was if I had selected them manually. Is this intended behaviour? 

Sounds like a bug. 

When placing clip points in 3D view, could you add an option to trace/glue the points onto the selected brushes only (i.e. the ones about to be clipped). Currently, if there are any obstructing, non-selected brushes the clip points will instead glue to their surfaces, which is usually not desirable. 

Im working on reproducing some vert manipulation errors and I'll add it to Pritchards issue report.

Basically, theres times I move verts with arrow keys and the verts deselect. I then have to select them again and can continue moving in my intended direction.

Additonally, "snap to integer" appear broken. Any attempt to "snap to integer" crashes.

This is all on 2f3c498. 

...to the conversation on the "best editor" thread:

SleepwalkR said: "You can select the axis yourself, it's the one you have moved the farthest distance on. Why is that difficult to handle? I'm asking out of genuine interest - maybe I can improve it?"

Maybe a better way would be to select either x or y axis beforehand with a simple toggle key like [ALT] does with the z axis? 

iirc you can hold shift to lock the axis you're moving the brush. 

That was mentioned in the best editor thread. That only applies once you've already begun moving the vert. 

Maybe instead of holding [SHIFT] AFTER you've started dragging a vertex, it would be best to have two different keys to select the axis BEFOREHAND, like for example [SHIFT] for the x axis and the >/< key next to it for the y axis. Or maybe even simplier and more intuitively, [X] and [Y] keys. The latter would imply using the [Z] key for z axis lock, freeing [ALT] for other context-sensitive manipulations. Sleep, does that sound good to you? 

How about having a separate right-click functionality. You can keep free movement of vertices/edges on the left-click, but have right-click draw some axis arrows on the vert so you can click and drag on the axis you want to use. 

Maybe a better way would be to select either x or y axis beforehand with a simple toggle key like [ALT] does with the z axis?

The problem is that it's very hard to select the correct axis that way. Either you make it relative to the camera, i.e., left/right and forward/backward, but then it becomes guesswork if the camera angle is close to a multiple of 45 degrees. Or you make it so that the keys are hard wired to a specific axis, (i.e., X locks to X axis always), but then you still have to take a moment and think about which axis you wanted to lock to. We already had that system in an earlier revision, and it did not work very well.

The current system allows you to select the lock axis by moving the mouse into the direction in which you want to go anyway. It's simply the best option IMO and I don't see why it shouldn't work.

You can keep free movement of vertices/edges on the left-click, but have right-click draw some axis arrows on the vert so you can click and drag on the axis you want to use.

Right click is already used for other purposes. What you're suggesting boils down to using a handle like many professional modeling tools do:

https://phoenixanimation.files.wordpress.com/2010/08/translate_handle1.png

We have toyed with this idea a couple of years ago, and it has its merits. But in the end I decided against it because it requires you to click into precise areas to select the axis of movement.

The system we have now is essentially liftet from SketchUp, and I think it is far superior to all of the above ideas. So far you guys have made suggestions how axis lock could be done, but you haven't mentioned any particular scenarios where the current system doesn't work, or I have missed it. What is the problem, apart from that you may be used to doing things differently from other programs? 

But in the end I decided against it because it requires you to click into precise areas to select the axis of movement and I wanted the user to be able to just click and drag on objects to move them. That was the main reason for the current system, and it's a big part of why TB is regarded as intuitive by many users. 

Having basically only used TB and TB2 for my Quake editing needs, I can say I find the navigation, commands, and everything else work great! I actually only use the 3D view! (So far) 

I mentioned my problems in the other thread and I think you responded to it. When I try shaping brushes to match the curvature of, say, an arch texture, I have a lot of troubling getting an edge to slide along only the x-axis. In the current system, to reliably move an edge/vertex in the direction you want you must position the camera above the vertex so your viewing angle is large. But if you do that, then you usually can't see the texture you're trying to match in the first place. If I want to see the texture, I have to make the camera coplanar with the x-axis, which makes dragging something on the x-axis almost impossible. That's why we need lock functions. I think a bind to enable handles on a vertex/edge would be very useful.