The default camera location in Netradiant is at the info_player_start position. That works pretty well because you can easily orient yourself from there. 

mankrip

I understand the request. I just can't fathom a reason for it. 

It's for more accurate "Align to view" results.

Currently I have to switch to wireframe mode to try and get more accurate angles before applying "Align to view", and that takes significantly more time than if I could just trust that the camera is pointing in the exact direction I want. 

wouldn't you want the angles you get from 'align to view' snapped to 15 then?

instead of, you know

the whole camera all the time 

An ideal solution would be to implement a separated "Align to projection" option that let us define the position and direction as if we were moving & rotating a point entity. But that would probably be harder to implement, so I decided to suggest a simpler alternative. 

(the views, camera position, tools state, even the loaded files) would be great. 

It would be nice to have a hotkey for switching between 15 degree rotation and free rotation, so I don't have to open options every time I need to switch it. 

Just hold down shift whilst rotating and it'll do the opposite of what you have in your settings. 

that's a magic! 

following on from a question posed by DeeDoubleU in the Mapping Help thread, it would be super cool if you could edit the FGD from the Object Properties window in JackHammer. I'm imagining a simple "Add to FGD" button at the bottom (usually grayed out) that becomes clickable as soon as you type in a class or add something with SmartEdit that doesn't already exist in the FGD.

If it's not possible to change the FGD dynamically in this way, maybe it could work more like a prefab, so the class name and keyvalues get saved in to a separate file or the JMF, just for easy re-use later. This latter option would probably exclude saving changes to pre-existing classes, but it would be a very useful feature all the same. 

... or a rather unintuitive behavior:

When I shift+drag a brush, if I release the shift while draggin, the "clone" operation becomes a "move".

In my opinion the "shift is pressed" test should be done when dragging starts, not when you drop the brush, or you force me to keep shift pressed unnecessarily. I also end up moving the brush by mistake, instead of cloning it, quite often. 

This is the same behavior like in Worldcraft/VHE.
Many people, including me, got used to this, e.g. when we want to cancel clone-dragging, we simply release shift button and return the selection to its original place.
If you want to guarantee the cloning, you can use ctrl+c, ctrl+v. 

It would be nice to be able to press Esc to cancel the dragging before releasing the mouse button. Specially in manual vertex editing, where sometimes it's impossible to move vertices back to the same place. 

Fixing the undo/redo system within vertex editing would be awesome. Having only 1 undo and having to exit vertex mode and lose everything you did, kind of sucks. 

Why do you say "fixing" instead of e.g. "extending"? Of course English it not my native language, but as far as I understand, fixing means repairing something broken. :) But this is not broken, this is exactly the same behavior as in VHE. 

Whatever you want to call it. I'm requesting that you make it more useful. :)

And "VHE does it that way" isn't really a valid excuse. This behavior has always been awful. 

I agree, this is not an excuse. But this was my aim actually - to recreate VHE's behavior. Simply because many people already got used to it. :)
But certainly inconvenient features should be reworked in future. I'll think of a way to make vertex manipulation more undo-friendly, thanks for giving me a hint. 

Besides, Hammer was never a usability gem. When you rework the inconvenience, please, consider this one I pointed :) 

I wonder at what point do we admit that you're working from some version of the actual Hammer source code? I mean ... I suppose you can't, really. But I find the dance and silent group agreement that we don't mention it amusing at times. :)

But rock on, I love this project... 

You certainly understand that I'll never admit that, don't you? :) 

brb, phoning valve lol. 

Valve knows everything (simply because they gave me a permission to post JH to Greenlight). But they will never tell you the truth! :)) 

Any chance to test the texture rotation problem described in post #147? I've switched back to Hammer for the meantime as that had given me some trouble. 

Afair, this problem is fixed, please wait for the next public release. 

just started tinkering with this... vis groups are acting weird for me. They render the selected brushes invisible but then I am unable to access them in the 'VisGroups' window, to render them visible again etc. If I select 'show all visgroups' it is re-established however.

Is this standard VHE/Jack behaviour?
Is there robust documentation in english for using Jackhammer or VHE that I should use?