That's why I told NewHouse to do so. I'll file a bug report for this help issue, I just wanted to know beforehand if there was a full text version available so as not to pester you with such a n00b request and detract you from more important work. 

I think it's a browser issue. Which one are you viewing the manual with? 

The one bundled with XP, i.e. IE (ayeee ayeee, that's funny!). Not by choice though: my main computer isn't connected to the internet so I can't install Firefox. 

I'm not going to start supporting a web browser from 15 years ago. Sorry. 

Trenchbroom tries to remember where you dragged those elements, but for me at least it forgets from time to time and I'm stuck with a view that's far too small to work in comfortably or really do anything.

This is now fixed: https://github.com/kduske/TrenchBroom/issues/1434

Please submit these problems on github. I can't fix what I don't know about. 

Yeah, I figured as much, hence my question about a full text file. Oh well, I guess I can still figure out the keys with help from the keyboard shortcut chart, but it won't be nearly as handy as a simple help file. 

If you could install TB on that computer, you can install FF on that computer too... 

 

I don't need a connection to install TB. I download my stuff elsewhere. The only connection I currently have is through my phone (yeah I know, I sound a bit like a caveman - with a phone). TBH I haven't checked about FF but usually, modern programs that use internet also need a connection to install. 

There should be a hotkey to cycle between alternate clip planes when making a clip with only 2 control points. For example, if I select 2 points on opposite sides of a vertical cylinder (like a barrel) Trenchbroom will assume I want to slice it horizontally to make 2 stacked barrels. There should be an option slice in vertically (like splitting a log). 

If you are talking about placing clip points in the 3D view, TrenchBroom already allows you to control how the clip plane is extrapolated from two points. It depends on where you place the two points; specifically, it depends on the normals of the faces on which you have placed the points. For example, if you place two clip points on a face whose normal points upwards, then the clip plane with be vertical. If you place the points on a plane whose normal points sideways, the clip plane will be horizontal. This should be enough in most situations.

In 2D views, the clip plane is always "top down", that is, the normal of the clip plane points sideways. There's no way around that. 

https://www.mozilla.org/en-US/firefox/all/

Offline installers for firefox. Download and transfer to you PC with your phone as you did with TrenchBroom. 

 

Thanks xaGe. I wasn't aware of offline installers for FF. Also, it seemed pointless to me to install a web browser on an offline computer, so I never checked. 

TrenchBroom lit a massive fire under my ass to take mapping seriously. Ive dabbled with BSP mapping for years...probably close to 10 but never took it seriously enough to care about releasing a full map. For the most part I just used it as a "sktechpad" of sorts. When I tried out TrenchBroom it answered a lot of prayers I had while working with Hammer and QuARK.

Thanks a million Sleepwalkr.

Lately Ive learned a lot about the creative process and how to manage progression of my creativity. Hoping to get a Q1SP done in the next few...months. 

 

I'm feeling stupid, because I can't figure out how to fix this : https://drive.google.com/file/d/0BwxYkKdSD855a0RHbUFpcDlacFE/view?usp=sharing

I have removed, remade, working on values (trying positive, no floating "float" values etc.). I haven't have this kind of problem ever before, even when working degrees that are more precise than 26.5. Normally something like this I was able to fix, just removing it and remaking it from scratch.. but not in this case. 

with tyrutils 0.15 you could get issues like that if you didn't use the -oldaxis flag. 

I was using tyrutils 0.15.5 it seems..
There seems to be new version available. 

220 or standard? 

 

SleepwalkR - I was using the latest stable release without the 2D views. I get what you're saying about the pre-selected clip plane orientation with 2 points. I'm just saying it would be nice to have a hotkey to cycle between alternate (horizontal/vertical) planes. Also if you select 2 clip points on different faces as in my barrel example, the default orientation isn't always logical.

I suppose an even nicer feature would be to have a rotation control around the clipping axis so that you can do the clip at any angle. This would be a lot quicker and more convenient in many cases than placing a 3rd point, I imagine. I havn't seen this feature in any other editor so it would be quite innovative. 

I've just looked into the issue again and realized that it might not be so bad as I originally thought.

Yes, the way the D3 editor represents brushes in a map file is inherently numerically unstable, because if for instance you translate a sloped surface represented like that, the little error adds up.

I've saved a map with a slope and cut off a few digits of its normal vector in a text editor. Resaved the map, the numbers after the decimal points changed a bit, as was to be expected because there is the binary representation in memory vs. the textual decimal representation.

Now... I've moved the brush slightly, and back into position, and poof, the numbers were exactly again as if I had just cut this slope freshly. I suspect the editor renormalizes all brushes that are manipulated in any way (an untouched brush wasn't changed like that). It's possible that internally, at runtime, they are represented as vertex meshes or with spanning vectors for the planes, and when saving, it's trimmed down to that simple but unstable plane equation representation.

Without looking into the code, I guess when loading, the editor derives a more stable representation by looking at the computed corner vertices, and calculates spanning vectors aligned to a really fine grid from vertices it picks as it best sees fit, to work with while it's running.

This math is more precise and less error-prone the closer the architecture is to the world origin. It's an interesting approach... and it solves a bit of the uncertainty when spanning vectors get too extreme, and being faced with the problem of checking for that and calculating better vectors.