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. 

Are you using arbitrary face alignment.* You might want to try world instead of arvitrary or face alignment.

*Please note that I don't know Trenchbroom handles arbitrary alignment feature of ALT+RightClick that other editors have so talking out of experience with other editors here. 

(I sent email) I went through my map file, and tried to put replace integer values in some cases where some numbers really wanted to be "close to" integer value 0.5.. values like 0.499999999 = 0.5 etc. I have no idea about those values, are those really suppose to be not like set in editor or does it have to do something with coding language and how Math works in the end.

Though that didn't fixed my issue, hopefully this will be solved some way (even idiotic way).. maybe I need to create new map, and start copying same brushes from this map or something. 

I have no idea what you mean by that (have no experience), but in TB I select brush's faces and just rotate them.. so is that called 'arbitrary face alignment'?. 

https://developer.valvesoftware.com/wiki/Texture_alignment 

Thx, sometimes I wish I could have born in USA or Britain, so I couldn't need to use dictionary all the time. But that article seems like, it has some important information. 

Did you look into whether or not you supply the -oldaxis argument to qbsp? 

Error unkown option 'oldaxis', I tried to put it on Qbsp : Txqbsp.exe -> command line arguments -> -oldaxis

Am I doing something wrong in here? 

Nevermind.. wrong place.. I have to look into it, I try to compile it now. 

Nothing seems to be changed after adding -oldaxis, texture is still off. 

I didn't get the email, mind sending it again?

Also you mentioned tyruttils 0.15.5 which is my compiler pack (tyrutils-ericw), but you also mentioned txqbsp which is a different compiler. Are you sure you tried my qbsp too? 

Thank you, it fixed it* I have to continue mapping to see, did it actually fix all of the texture related problems I had.. this Txqbsp.exe, was it recommended in some website because I ended up using it? Ealier qbsps gave me errors or something like that.. but now it went flawlessly, you been doing a lot of updates recently I assume*

Thank you again. 

I couldn't reproduce the problem in either tyrutils-ericw or txqbsp-xt; maybe you had an old txqbsp.exe 

It must be the case* 

Quaddicted recommends Txqbsp here, which I think is a large part of why people are using that older compiler. It's the reason I was still using it when I sent you that email a ~month ago ericw (I was too lazy to change my .bat files to use the 0.15.5 qbsp before then...). Someone should really ask Spirit to update the page, I suppose. 

I must be equally as lazy not yet lazier, oh well - there is many updates to keep eye on. Some cases updates has been many so easy and automatic that we don't actually need to even thing about it. 

has been made* too easy and automatic.. 

First of all, thanks for the recent updates, SleepwalkR!

Secondly, sorry for having been absent and not having contributed bug reports for ages. Real life issues keep getting in the way of mapping/testing.

Thirdly, I'm having trouble installing the latest Beta on Linux -- can anyone help? I've downloaded the .deb package and GDebi opens it, but then gives me the following error message:

Error: Dependency is not satisfiable: libstdc++6 (>=5.2)

Not sure what this means, and couldn't find answers on the web that I could understand. I thought maybe it meant that I don't have the right version of libstdc++ installed, but according to Synaptic I do have libstdc++6 installed ...