All I said was that use of CrashRpt should be disclosed at the time of installation and I suggested that it be made optional. Before posting, I looked all through the Jackhammer web site for a privacy policy, checking all links, and could not find one. If it's there, it is very hard to find.

I find your reply to my comments pretty bizarre and reactionary actually. 

IMO it is very hard to miss.
I personally respect privacy concerns in general and don't suppose them being ridiculous; I mean that CrashRpt library is quite clear and well designed, it asks for user permission before sending anything, contains a link to company's privacy policy, allows to examine the files about to be send, and so on.
I don't understand why the use of CrashRpt should be disclosured at any time except before sending the report, when it is *actully* used. If you don't press the "Send" button - nothing is sent, and what do you demand to disclose at the time of installation?
If there were any report sent without user's permission, I'd certainly make it clear and optional. But that's not the case.
And the last but not the least, CrashRpt is opensource and you can easily check it for any backdoors or whatever.

I'm sorry that you find my reply reactionary, but then I'd rather recommend not to use proprietary and closed source software, since you never can be sure of your privacy, unless you block program's network activity using a firewall. Just wait until JH becomes open source (it eventually will be).
The only thing I can do is to mention the use of CrashRpt in readme/installer as a part of "license agreement", without any options, however this is the first time during these 2 years when I get such a complaint... 

But I'm not sure of schedule. 

"Just wait until JH becomes open source (it eventually will be)."

=) 

I've slightly modified privacy policy text to be more clear. Now it explicitly mentions both the engine and VDK (which is actually Jackhammer). In the "Information we collect" section the statement "(etc)" is replaced with "Crash Minidump", so now it can't be voluntarily interpreted.
I've also put a link to the policy to the JH's website, at the bottom of each page. 

An option in the primitives to set what gridsize you want them to snap to. 

2 ptoing:
What do you mean? Snapping on dragging or on creation? 

I mean on creation. Everything is on grid, but it is the 1 unit grid. So if I want to make an arch or cylinder that is on say the 4 unit grid I have to do it by hand. 

Ok, but snapping cylinders and spheres to large grids may result in coplanar faces and overall bad looking geometry. There is even an option to turn grid snapping for created primitives off at all ("Don't snap primitive points to integer grid").
However you can create a cylinder one quarter of its original size (with snapping to integer grid turned on) and then scale it by four (using "Transform" dialog or manually resizing). After that its vertices will lie on 4 unit grid. 

Don't see how it would cause problems with cylinders. Spheres, yeah, those can be a mess already without being on a bigger grid.

Making a smaller piece and then scaling up is a decent workaround. 

Here is an example of problems with 256x256 cylinder when snapping to 4 unit grid: image. The larger is grid, the less subdivisions will cause problems. 

That makes sense, thanks for clarifying. 

I wanna stop asking things the UI wasn't meant to do.

So, I found a comfortable way to use Jackhammer: one maximized window, split in two views: one 3D and one toggled between top/front/side.

But since TAB toggles between 2D layouts, SHIFT+TAB could toggle backwards, don't you think? So far, SHIFT+TAB just gives focus to something else. Isn't it inconsistent? 

Added Shift+Tab to toggle backwards, thanks for suggestion.
Also added Tab and Shift+Tab shortcuts for 3D views, to change rendermodes. 

So I tried using the JH 'extract textures' feature, but where does JH deposit the created wads?

Oh, and for some reason JH won't recognize Zerstorer.wad. Any idea why this could be happening? 

Just not why zerstorer.wad won't work. 

I take it your wad is actually named zerst�rer.wad with the o-umlaut. If you rename that to o or something it will work. I reckon it is a unicode or otherwise text encoding issue. 

Thanks! MFX also pointed me in the right direction. 

We need your "yes" votes:
Jackhammer on Steam Greenlight 

I was working with a Quake mod the last few weeks that has no fgd file for it and contains a shit load of new and important spawn flags for most entities, this made JH essentially impossible to use for this project as I can't access the spawnflags for entities to set it manually :(

Pleeeeeeease? :) 

Spawnflags should always work at "Flags" tab even if unnamed/not defined in FGD. First checkbox in a first column sets spawnflag 1, second checkbox in a first column - 2, third - 4, then 8, 16 and so on. 

 

Voted, although I'm not clear on whether this means that Jackhammer is going behind a price wall? 

Steam version can get some useful Steam-specific features such as cloud backup storage and automatic update system, which helps to deliver hotfixes ASAP.
I'm not sure of pricing policy yet, but I promise there will ALWAYS be a FREE version of Jackhammer (and opensource in future) outside Steam. Just like now. 

http://i.imgur.com/60ipi3H.png
Brush A is created, rotated without texture lock, then the texture is manually rotated to fit. This seems to do the rotation with world projection as expected.

Brush B is the same brush moved a bit without texture lock, behavior as expected, nothing weird here.



Brush 1 is created unrotated, then with texture lock on, rotated 45 degrees. This seems to do the rotation in the face projection rather than the actual texture rotation parameters. As expected, as that's the easiest way to get it right.

Brush 2 is the same brush moved a bit without texture lock. The face projection data seems to be lost as soon as it moves. This is highly undesirable! I don't know how you store your projection plane per face, but it looks like it's simply lost somewhere here.