I'm curious, but does Jackhammer have the ability to also save maps in the old format, or only in the v220 format? 

Sorry, it is not possible. JH operates with texture axes, and there is no way to save them in the old, very limited format. 

Unity has Probuilder. Here is nice overview:
https://www.youtube.com/watch?v=Xgt-a6-1Y3c

...and Here is newer demo
https://www.youtube.com/watch?v=Kjqx6cKUepc

I have heard Unreal will get it too!

To not OT too much, i wanna say i love Jackhammer <3
I would love to see some brush boolean operations :) 

Thought I'd ask again, good to know. I hadn't realized that the compilers included with the Jackhammer install had been updated to handle the 220 format.

As Jackhammer already supports texture paths and surface flags, I've updated MapConv to be able to convert maps created with it back into the old format as well.


One thing I have noticed while using Jackhammer is some strange texture alignment issues. After applying a rotation to a texture, moving or copying the brush causes the rotation to flip (this is without texture lock enabled). Changing the textures rotation again causes further issues.

I've attached a sample below:
http://www.ogier-editor.com/files_dod/Jackhammer_Rotations.jpg

1 - A texture on a brush surface is given a rotation of 20'.

2 - If the brush is moved (in this case I nudged it one unit to the side) the rotation then appears to be flipped to -20', although the surface properties still list the original 20'.

3 - If the rotation is changed again (in this case setting it back to 0'), it then looks as if the texture has been rotated -40'. 

Loving Jackhammer so far. Finally got around to setting it up yesterday after worldcraft wiped all my _color light settings.

Question: How do you create new cameras in JH? The default one always starts out in the middle of nowhere (probably the world origin or something sensible like that but whatever...) for me and so I have to navigate it to a sensible spot before I start mapping.

Idea: How about a button to switch doors/lifts/etc. to their "open" position, not only to preview what they'll look like in-game but to allow easier texturing access to faces that they may be covering? When "open" they could be faintly grayed out, and selecting them in the 3D view could switch them back to "closed" for the duration of the selection to avoid weird situations where people try to edit them in the wrong position. The more I think about that the more complex it gets in my head so probably not such a fab idea, but it would be pretty cool if it was doable! 

The editor cannot possibly know about the code that lies behind entities, and has no way of knowing what a "door" is. Just either temporary move the door to the open position yourself or just hide it? 

That's a cool idea, actually. 

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.