It COULD given the right meta data ... Plats, doors, etc are all just simple linear moving entities. 

I remember from my very early attempts at Quake 3 editing that at least one version of Qeradiant (2.02 maybe) could animate func_train entities.

I don't recall whether it was a built in capability or a plugin of some kind and I don't remember if it was limited to func_trains or if it could animate other moving entities also.

So at least it's possible. 

But you're talking about a Quake-specific (at least iD dedicated) editor. Jackhammer is not. 

What game does it support that isn't derived from Quake?

Anyway, it's easy enough to just disable something that's not available for the game currently being edited. 

Make the camera start near the player's spawnpoint, when available.

Also, XaeroX, can you add an option to limit camera rotation to multiples of 15 degree angles? 

"Make the camera start near the player's spawnpoint, when available."

I'd rather it remember where the camera was the last time I had that map open.

"Also, XaeroX, can you add an option to limit camera rotation to multiples of 15 degree angles?"

Wat? 

An option similar to the "Default to 15 degree rotation", but for the camera.

Also, it would be nice to be able to drag the camera in the 2D views.

And good idea about storing the camera position in the .jmf file. 

An option similar to the "Default to 15 degree rotation", but for the camera.

https://www.youtube.com/watch?v=PEZWYXPvmS8 

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.