Quick bug report! Another thread just reminded me I never mentioned this here, my apologies.

For my entry in Map Jam 6 I used a custom executable as part of my compile chain, running once before CSG and again after BSP. It did what it needed to do, but I found that custom build steps in Jackhammer seem to treat the first parameter you specify as a literal string even if you're using JH variables.

In my case the "Parameters:" field of my custom step was set to something like this:

$path/$file $path/$file.temp.$ext --parameter "argument"

Althought the second item was replaced successfully, the first one ($path/$file) was sent along to the executable as a literal string, leaving me needing to hardcode the path to the current map in every build configuration I had. 

Yes, there was a problem with parameters' replacement: actually only one occurence was replaced. It will be fixed in the next version. 

Connect entities
Skybox rendition 

Connect Entities ... nice!! 

I must remember to post some suggestions here� Jackhammer is fascinating, and it's great to see that it's being actively developed. 

Good news for those Radiant users who betrayed their favorite editor and migrated to Jackhammer. (Well, if there are none, at least that's about me. ^^)
Finally the famous Radiant feature is added: preservation of entities' internal connections on cloning/copy-pasting. It is optional, of course.
watch video 

Should be a consideration 

https://bitbucket.org/FreeSlave/def2fgd 

Alphamasked textures support. Detect them by scanning for the color 255, rather than relying on the character "{" in the filename, so alphamasked animated textures can also be supported. I can give you some code for this.

Sort animated/switchable textures by frame in the texture browser, rather than by name.

Don't filter the textures in the texture browser.

Parse the compilers' output for error messages, and add a way for the user to (right) click on them to focus the editor's Windows in the indicated coordinates (possibly with auto-selection of the problematic object/entity). 

Alphamasked textures support. Detect them by scanning for the color 255, rather than relying on the character "{" in the filename, so alphamasked animated textures can also be supported. I can give you some code for this.

Sort animated/switchable textures by frame in the texture browser, rather than by name.

Don't filter the textures in the texture browser.

Parse the compilers' output for error messages, and add a way for the user to (right) click on them to focus the editor's Windows in the indicated coordinates (possibly with auto-selection of the problematic object/entity). 

i wish there's some sort of controllable paste, for example, if i'm in the top view, paste goes on the same Z height, same applies for other windows.
cuz now it's nightmare, i have to move paste every time to the previous Z height... 

This would be lovely.

Also, a similar thing, and it *sort of* works right now but pasting something to where your cursor is on the 3d view. 

In Radiant, default paste data includes the exact coordinates of the copied item(s). Anything pasted into a different map will be in the same location it was in the original map. There is also the option "Paste to camera" if you want. 

Is it a known bug in version 1.1.700 that duplicated compile configurations are synchronized? I'd like to be able to make a new configuration by using Run Map->Edit->Copy and then just changing a few things, but any changes I make to that copy are being applied to the original as well. 

ItEndsWithTens: thank you, it was a silly bug with shallow copying of QList. Now it performs a deep copy, and everything is ok. :)

Rick: the same behavior can be achieved in JH, use "Paste Special" and tick "Paste at center of original" checkbox.

I'll fix the annoying problem with messing up depth coordinate of pasted object, thanks for the suggestion. 

To avoid synchronization of duplicated compile configurations in 1.1.700, simply restart JH after the copy, to allow saving/reloading them from disk. 

It would be awesome if, when resizing a brush in the 2d view, there was a live preview in the 3d view, or even just a wireframe that live updates (like the clip tool - the 3d live preview there is really nice.)

The use case for this is resizing or creating a brush so that the size lines up with some borders or features in the texture. I'm new to hammer-style editors so maybe I'm missing something too :-) 

Resizing, or manipulating a brush in vertex mode shows a 3d live preview. 

Finally taking the chance to jump in and try out Jackhammer. :)

One question I have is how to set up textures with their directory paths. I'm using a Quake2 gametype, and have a set of texture directories I'm adding. In Jackhammer however, the directory name isn't showing, and loading a level I've started shows only the checkerboard texture. (A surface might be assigned 'bricks/brick1', but Jackhammers texture browser is only showing me 'brick1'.)

Any tips would be appreciated! 

I didn't have problems when making test maps for Quake 2. Jackhammer should use a directory name also for a texture name. Would you mind give a screenshot of game configuration window ("Textures" tab)? 

Thanks for the quick reply, pretty sure it's something I'm not setting up properly that's throwing me off here!

Here's how I have the textures specified in the options dialog. I'm wondering if it's because the 'textures' directory should be selected rather than the individual directories within, but when I do that Jackhammer finds 0 textures:
http://www.ogier-editor.com/files_dod/Jackhammer_Options.jpg

And the texture browser:
http://www.ogier-editor.com/files_dod/Jackhammer_Browser.jpg 

It is probably a problem with game directores. Your texture folders' names should appear as "textures/bricks", not "C:/Users/...etc". Are you sure your game directory is set to "DoD Editing"? Please make a screenshot of "Directories" tab also. 

I was unsure if that could be part of it, so I moved the texture files into the base game folder.

Here are the options set under configuration. The textures are inside the base games directory.
http://www.ogier-editor.com/files_dod/Jackhammer_TextureOptions.jpg

This is what the texture browser looks like with the above configuration loaded. I notice that Jackhammer displays the textures by their specified name rather than path/filename.
http://www.ogier-editor.com/files_dod/Jackhammer_TextureBrowser.jpg

Here's a surface that should have the above texture (selected in the texture browser) applied to it. It instead displays as missing.
http://www.ogier-editor.com/files_dod/Jackhammer_TextureSurface.jpg

If I save this map, this is what is in the resulting file:
{
"classname" "worldspawn"
"gravity" "800"
"sounds" "1"
"mapversion" "220"
"_generator" "Jackhammer 1.1.700 (vpQuake2)"
{
( 512 0 256 ) ( 512 0 0 ) ( 512 -32 256 ) The Bricks [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 256 -32 256 ) ( 256 -32 0 ) ( 256 0 256 ) The Bricks [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 512 -32 256 ) ( 512 -32 0 ) ( 256 -32 256 ) The Bricks [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 256 0 256 ) ( 256 0 0 ) ( 512 0 256 ) The Bricks [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 1 1
( 256 0 0 ) ( 256 -32 0 ) ( 512 0 0 ) The Bricks [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
( 512 -32 256 ) ( 256 -32 256 ) ( 512 0 256 ) The Bricks [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 1 1
}
}

It seems to also be saving using the texture name rather than the file path/name. Would this be part of the issue? 

I should make the correction that the third image with the surface properties window open is a map I had saved from another editor, while the map file contents which follows is a different one made and saved with Jackhammer. 

It seems that I've figured it out. Jackhammer takes mip name from WAL file directly. Mip name is likely to be specified as "The Bricks", instead of correct "textures/bricks/thebricks" (or something).
JH works around empty WAL mipnames, but if they are set, it uses them. Sorry, it is impossible to use these textures in JH unless you edit them in a certain way.