News | Forum | People | FAQ | Links | Search | Register | Log in
Jackhammer 1.1.700 Public Beta Is Out
Hi all!
Yes, now we're in beta status, which means lots of bugfixes and improvements were done. ^^

New version highlights:

* Archive Support: Jackhammer can load models and sprites from game archives (PAK, PK3). This is useful if you open other's map which uses models, and your game resources are not unpacked.
* Compiling in Editor: now it is much more convenient to compile maps in the editor, because the compile process doesn't block it. You can continue editing the map while the long compilation takes place. You can also terminate it at any time simply by closing the Process Window.
* Improved Decal Rendition: you can preview Half-Life decals (colors and transparency) in the 3D-View just the same as in the game.
* New Texture Application Modes: "NULL to Selected" (applying NULL or caulk texture to selection), "NULL to Unselected" (same as the previous mode, but texture is applied to the other brush faces; handy fast removal of backfaces), "Apply (texture + values + axes)" (copying texture axes information, simplifying texture application to complex objects and landscapes, especially when combined with "Align to View" mode).
* Automatic Selection in 3D: you can select multiple objects by pressing mouse button in 3D-View and then dragging a cursor. This mode is convenient for quick selection of lots of nearby objects (e.g. landscape brushes), when clicking can become annoying.
* Model View: you can specify an external model viewer (e.g. HLMV) and open any model simply by a context menu command. Also it is now possible to reload a model from disk without restarting the editor.
* Update Check: the editor can automatically check for new version available and notify you, so you can immediately download and install the update.
* Lots of improvements: the new version traditionally contains lots of bugfixes and improvements in comparison with the previous release. The editor became much more stable and functional, and now it is a beta. Please view a changelog for the details.

This version supports Quake, Quake II, Quake III, Half-Life, Gunman Chronicles and their modifications.
Supported operating systems: Windows, Linux.
Supported architectures: x86 (32-bit), amd64 (64-bit).

Web page
Feature list
Changelog of version 1.1.700


Thanks for the feedback, some features were added because of your requests. Hope you enjoy Jackhammer, I've put much effort to it.
Gonna Download It 
It's the way to put Worldcraft behind with a soft learning curve. Later, I'll get started on Quake 3 as well. Thumbs up! 
and perfect timing with map jam 6 starting this Friday :) 
What's the theme of the jam? 
Theme Will Be Announced Friday Afternoon GMT 
Linux Version Is Buggy For Me 
strangely the windows version runs great through wine. 
What Do You Mean - Buggy? 
Linux version was tested on Debian a lot, it definitely works in Wheezy and Jessie... 
Been A WC 1.6 User For The Last Decade... 
Tried this out today. I'm enjoying it so far. It's too early to tell, but I may be making a permanent switch. Thanks XaeroX. I really enjoy the camera. It took me a few minutes to figure it out, but once I did I enjoyed its ease of use. 
I Mean None Of The Textures Appear. 
Either in the texture browser or in the 3d window shaded or not.

They all appear as white. 
This Is Odd 
What about the previous version, 1.1.500? Is there the same thing? 
Bless You XaeroX 
"Toggle 3D auto selection by mouse dragging"

This button is godlike :D 
I've been using version of the editor to create my map jam 6 map and have a few things:

1) When in face edit mode I should be able to shift+ctrl+left click on a brush and the editor will add all the faces on that brush to the face selection. This works in Hammer but does not in JH :(

2) When placing an entity into the world by clicking inside the 3d view to place it, it will usually be 2-4 units inside the floor/wall you place it on and require you to manually move it afterwards. It would be great if there was some sort of check to make sure the entity wasn't inside anything when placed.

3) With 15 degree rotations box in 2d options ticked, I cannot do free rotations in object rotate mode by holding alt. Holding the ALT key while in object rotate mode should allow completely free rotation on that axis.

4) When shift-dragging brushes to duplicate I sometimes get corrupted texture coordinates on a face that can lead to a compiler crash with "bad texture axes on face" or something similar (Quake 1, EricW's compiler suite). I can't remember if I had texture lock on or off when I duplicated, and it's only happened once or twice. I will try and investigate and get a working repro.

And some things on my wish list for the future... :D

1) Hammer style auto-visgroups when? :D
2) 3 point clipping like in gtk radiant!
3) robust vertex editing like in TrenchBroom
4) vmf instances like in latest Hammer

This latest version has been very stable for me, I think I had one crash (without error msg) during this entire map jam, luckily with the autosave system nothing was lost! 
Thanks For The Feedback! 
1) ctrl+shift+click is actually an alias to alt+click. This is a workaround for stupid Ubuntu desktop environment behaviour that reserves alt key to its own needs. Shift+click works, but there is actually no way to select multiple brushes in texture application mode. However you can exit it, select brushes and enter again.
2) Such checks are complicated because the editor itself does not define an "inside anything" term. This is a game-related term actually. E.g. func_illusionary is not solid and therefore there is no problem that some entities are inside, the same applies to triggers. JH has a workaround for "players in floors" offseting their origins using a fgd keyword "offset", but this is the only thing. As for 2-4 unit offsets while placing entities far from the camera, this is actually a precision problem.
3) Well, it should not. :) Hold shift instead of alt. This is the same behavior as VHE's.
4) Make sure you've disabled "UV Lock" before ANY operation that doesn't explicitly require it. And don't forget to use Alt+p sometimes.

About suggestions:
1) VHE doesn't have auto-visgroups. Please mind that my reference editor is VHE 3.5.
2) Very complicated due to current clipping tool architecture, operating only in one 2d-canvas.
3) I've never seen TrenchBroom in action, and actually do everything in 2d views since my first map. :) I keep saying that JH is a 2d-oriented level editor.
4) Do you mean prefabs? Or what?

Anyway, thanks for suggestions and for using Jackhammer! ^^ 
Moving Images! 
Hammer auto-visgroups - very useful for quickly removing all the stuff you don't need to see!

TrenchBroom vertex editing - As you can see, Trenchbroom will slice faces to keep brushes convex when you vertex manipulate them. It also refuses to move a vertex into a position where an invalid brush shape will be formed.

Thx for the reply. Looks like I have some new shortcut keys to learn :) 
Setting Up Jackhammer For The First Time 
Is there a beginner's guide somewhere that tells you how to configure Jackhammer correctly for Quake? I've looked at the online documentation, but I can't see anything along those lines ... and there are quite a lot of things to configure. I think I've got it more or less figured out, but I'm not sure, and I've left a lot of fields blank as I simply didn't know what they were. 
I know that Hammer 4+ has auto visgroups. But again, my reference hammer is 3.5.
I see, TB performs automatic triangulation on non convex objects. JH does not, so such vertex editing is quite useless. It would be nice feature though, but I'm not sure I'm ready to implement it. :)

The installer can automatically configure everything, just specify a path to quake executable during the install process. After the installation you can immediately create a simple room, compile it and run in a few clicks.
Hovewer this is possible only under Windows (Linux installer is much simpler). 
Like Daz, I'm also using JH 1.1.700 for a Jam 6 map, and I really love what you've done with the program, great work! I do have some feedback, though. I've taken a few dozen notes about Jackhammer; between feature requests and bug reports it's about 70 items so far. Is there a better way to provide that much feedback than posting the whole thing here? My posts tend to be long enough, and I'd hate to clutter the board with an even bigger mass of text.

As for instances, when Daz mentions them, I trust he means these: They work sort of like prefabs, but they're easy to keep editing after you've put them in position, even rotated or translated off of the grid.

You place a point entity called a func_instance which serves as a reference to, or "instance of", an external map file. This map file can contain basically anything you want. A common light fixture, for example, or a pillar, or maybe a complex entity configuration that you want to use in several locations. Instances let you set everything up once, then instantiate your work multiple times. Something called "name fixup" keeps entity names unique, if a mapper wants to, by adding a prefix or suffix (either one the mapper specifies or an automatically generated name). You can even do material replacements, swapping out one material for another in some instances but not in others.

There's also the benefit of being able to build neat geometry on the grid in an external file, but then rotate the func_instance point entity which references that external file to whatever angles you'd like. The transformations don't get applied to the instanced geometry in the map file stored on disk, they get applied only immediately before compiling, so concerns of slowly accumulating floating point rounding errors are dramatically reduced, if not eliminated. On top of that, the func_instance entity exists only at compile time, and the top level map along with all instances can be easily collapsed into one .map file by an external tool (I'll get to this in a moment), so there's no need to modify the compile tools themselves. By the time CSG or BSP see the map, the instances have been collapsed and it's an ordinary .map file.

The good news is that the external tool I mentioned already exists:

It's built for the Source engine, but I have my own personal version of the project that I've modified to support Quake maps (at least, the Valve 220 format). A custom Jackhammer build configuration runs this tool after exporting the .map but before passing the result to CSG. The tool does all the work of rotating/translating objects, fixing up variable names, replacing materials, etc. All you would need to do is allow the func_instance point entity to display the contents of the external file it's loading. That's not to say it's a trivial project, but a lot of the work is already done.

Some examples of the results: The glowing blue-green thing with the teeth exists in three places in my map. Its geometry, and the entities that allow it to light up when players approach, is only built once, in its own file. I place the three func_instance entities and specify a fixup name for each, and when players approach one of them, they hit a trigger that targets the fixup name, so only the one they're near activates. This is a more recent example. Each section of bridge there is an instance, built in another file neatly on the grid, allowing me to get a nice uniform curve to the center section. I place the func_instances, then rotate them into their final positions as seen in the picture. I can then continue to edit the section if I need to, without having to copy and paste the updated geometry all over again. 
Thanks for the response, but yeah, I'm on Linux... 
Game Config Info 
Where is JH's game config information stored? I tried making one for Quoth but JH won't keep the whole path to the pallette file. I was hoping that I could edit the source info and force it to do so.

Enemy Territory Support 
Hey XaeroX would it be possible to support Enemy Territory in a future release (seen as you already support Q3) I am part of the team working on the new engine for the game and would love to have some good mapping tools available.. 
I'm not sure it is quite easy to add support for modern games. I still can't support HL2 because of such things as displacements, input-output system and stuff.
Q3 support was an intent since the first days of the development, and JH's renderer is actually optimized for Q3 shaders (Q1/Q2 and HL textures actually have in-memory representation as Q3 shaders). 
Enemy Territory Support 
Sorry I mean Wolfenstein: Enemy Territory. Its idtech 3 (like Q3) and uses the same shaders (mostly) and also uses q3map2 to compile maps to bsp. 
Re: Enemy Territory Support 
Ah, ok.
Adding new game support generally consists of the following tasks:
1) Compiler(s) that supports mapformat 220 and is compatible with JH (q3map2 must be modified, unless you use the one shipped with JH; its sources are available in "quake3/", so you can diff changes and add them to any your custom q3map2 build).
2) Texture and model format specifications, to implement them within a plugin. The same applies to texture scripts (known as "shaders" in id tech 3) - new keywords, etc etc.
3) Entity definition file (FGD). Can be created as a modification of the existing quake3.fgd.
4) Game-specific editing features that can be implemented in plugins (e.g. "WAD extraction" tool for Quake).
5) Game-specific editing features that CANNOT be implemented in plugins and require modifications of the editor itself (e.g. q3's bezier curves).

So, please give me a detailed explaination of your needs according to the list, and I'll figure out whether is it possible to support your game, and how easy it will be. 
Heretic 2 Support 
would be really nice too. I know Quark supports it, though I do not know which format the compiler uses. 
Enemy Territory Support 
1) I created a custom q3map2 version for legacy to better support deluxe mapping (i also removed all the gtk dependencies since they were really just dead weight and the compiler is not a lot lighter and only a single binary)
2) Textures work the same way as in q3, in ET there's another model format mdc which is essentially a packed md3 ( the float values are packed ), but also md3 is used and both work the same way. There are some new shader keys for the new renderer which adds support for normal/displacement/etc effects but that is not really in use yet.
3) Theres an existing radiant definition for ET for that could be used?
4-5) Tank/Car route editor which is used to create the paths for the tanks and or cars (

I might be totally forgetting something, but essentially the editing is very similar to Q3. 
Few Requests 
First one is very simple: I'd love to order my visgroups properly. Just add up/down buttons to the
"Object Groups" window, or maybe make the items in "Groups" list draggable, so I can reorder the groups by hand. An option to order them alphabetically would be nice as well.

Second, I don't know why these dialog windows have fixed sizes. Having them resizable would be great.

Third: in Worldcraft, when I pressed Z over the 3D window, it "captured" the mouse and entered in "mouselook" mode, no matter what window was active at the moment. Now I have to activate the main window and then press Z. It has less usability.

Last: it would be nice to save windows state when the program exits. The load and save current window state buttons are not enough because I use two independent windows: one 3D and one splitted into top and front 2D views. I have to reorganize them every time I load the program. 
I think the color picker that gets invoked from various places is showing web colors instead of the standard Windows set. 
Looks like it, though it's not like it really matters as you can still choose whatever colour as well as add custom ones. 
One Thing 
Please make individual vertex manipulation steps undoable. The thing where you have to exit vertex mode and then undo the whole manip session is unsustainable. 
^^ X1000 
Please :) 
On the subject of undo transactions, I'd personally really like to see selection and deselection added to the list of possibilities. I'm constantly deselecting large groups of objects accidentally, but where Source Hammer lets me just hit Ctrl+Z to get the selection back, Jackhammer doesn't. I know your feature list is defined primarily by Hammer 3.5, but this is one thing I'd make extensive use of.

There's a similar situation with texture application. If I Shift+Right click a brush to apply the current texture to the whole brush, but then change my mind and hit Ctrl+Z, it only undoes one face at a time, even though the last action I took as a user was changing all the faces at once.

One final note, unrelated to Undo: I just found out that Rick Lipsey's map source, from the recently released func_mapjam 6, will crash JH if you try to go to the nailgun.

In the mod's "source" directory, load into Jackhammer 1.1.700. Go to Map|Entity report..., tick the "By class" checkbox, choose weapon_nailgun, and click Go to. The program crashes every time for me. I just sent an error report about this (though I'm not exactly comfortable sending desktop screenshots to strangers), but figured I should document it here as well. 
Installer Only? 
For Windows there is no un-zip and run version, only an installer? 
I second that. I would love if there was a portable version. 
Am I Missing A Setting? 
is there a way to paste a copied brush to the location where I right click and paste on the 2d window? 
No, it pastes to the center of the viewport. It doesn't do pasting as well as more modern Hammer iterations. 
No Install Version 
It's not so much for portability, but to keep more unnecessary stuff from cluttering up the registry. Windows takes care of that well enough on its own.

I usually run a system restore afterwards if an installer has to be used but it would be nice to avoid that hassle, and even then a lot of software will continue to write trivial configuration data there instead of to a separate config file as it should. 
Yeah, Totally. 
Most stuff you install, if not all, should really not need to write stuff to the registry. 
Third: in Worldcraft, when I pressed Z over the 3D window, it "captured" the mouse and entered in "mouselook" mode, no matter what window was active at the moment. Now I have to activate the main window and then press Z. It has less usability.

This sums up to: hovering the mouse over a viewport window activates it. That would improve productivity a ton. I'm using a two window setup, and the need to click to activate one is driving me crazy. 
This sums up to: hovering the mouse over a viewport window activates it. That would improve productivity a ton.

so true 
>>hovering the mouse over a viewport window activates it.
It actually does, from the first versions of the editor. O_o
>> For Windows there is no un-zip and run version, only an installer?
No, the installer does a lot of configuration job so I recommend to use it.
>> The program crashes every time for me.
This bug exists only in 64-bit version and will be fixed in the next release. 
>>hovering the mouse over a viewport window activates it.
It actually does, from the first versions of the editor. O_o

It does if no other windows are open. If I open texture application an its window is currently active then I need to click on the window behind it to make Z work. 
Not Really 
I have two viewport windows: one 3D view only; the other split between 2D top and front views. I have to click to activate the 3D windows to navigate thru it. When I want to edit something on 2D I have to click-activate it first. PITA.

Also, if a dialog is active I have to click on the viewport window behind to Z navigate it. 
"I have two viewport windows: one 3D view only; the other split between 2D top and front views."

You do? How? And does it save between sessions somehow? 
Based on my tests Jackhammer could easily be supplied in an unzip and run configuration. The installation saves some uninstall information in the registry and offers to associate Jackhammer.exe with certain file extensions, it also attempts to set up various game configurations. None of that is really necessary.

Simply running Jackhammer.exe does not appear to create any program specific registry keys.

Windows itself will of course automatically make certain keys which refer to Jackhammer.exe, as far as I know this is unavoidable.

The Qt toolkit however, does create registry keys. So a true "portable" installation appears to be impossible in this case. 
Window / New window

You can have as many windows as you like for a single map. And no, it doesn't save between sessions, it's another request I did. The editor should save its state when it exits. 
Not Real Thrilled About This... 
Continuing to test Jackhammer, I noticed an unexpected executable, CrashSender.exe, in the Jackhammer folder.

This is apparently due to inclusion of something called CrashRpt (in the form of crashrpt.dll). According to the CrashRpt documentation, CrashSender.exe is capable of sending various data over the internet including desktop screen shots.

This is just my opinion, but it seems that use of CrashRpt and what it does should be disclosed during installation of the software and preferably be made optional. I couldn't actually make the software crash, so it's unknown to me if the user is prompted or not before any data is sent, what that data might be, or if data is even sent at all.

The current Jackhammer.exe will not run if the crashrpt.dll is missing. However, it will run without CrashSender.exe (though this will cause a message window to pop up when it starts). Rather than take any chances, I erased the CrashSender.exe, just because it's better to be safe than sorry these days. 
This Is Ridiculous 
If you do not accept our privacy policy, please do not use Jackhammer (this link is displayed in a crash report window).
Crash report is sent if and only if you press the "Send" button in crash report window. This is not an option and never will be one in Windows versions, unless JH becomes very, very stable. If you doubt the way we use crash report, why don't you doubt the JH at all? Nothing can stop me to collect your passwords, nuclear missile activation codes and stuff from the JH's code itself. So, be sure you erase both CrashSender.exe and jackhammer.exe to ensure your privacy. ^_^ 
Are There Plans For Prefab Support? 
Privacy Concerns Are Not Ridiculous. 
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. 
Privacy Policy Link Is Located Directly At The Crash Report Window 
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... 
Prefabs Are Planned 
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. 
Something That Might Be Nice. 
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. 
TAB, But No Shift+TAB 
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? 
Request Accepted 
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? 
Figured Out The Extract Textures Thing... 
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. 
And It Is! 
Thanks! MFX also pointed me in the right direction. 
Please Support Jackhammer On Steam Greenlight! 
We need your "yes" votes:
Jackhammer on Steam Greenlight 
Spawnflags Request (again) :D 
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. 
Greenlight Voted 
Voted, although I'm not clear on whether this means that Jackhammer is going behind a price wall? 
There Will Be No Walls 
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. 
Odd Behavior With Texture Rotation.
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. 
2czg: yes, there is a bug. Thank you, I'll figure it out. 
czg map incoming.

I make textures while I map.

Everytime I update a wad I have to exit/enter the editor again. Or maybe close the project, remove the wad, add the wad again, open the project.

The "Tools/Options/Game Profiles/Textures" tab have buttons do Add, Add a directory and Remove a wad.

Could it have a Refresh button as well, to reload the selected wad?

Jackhammer prevents the user from removing a wad that's already in use. I think it should be just a warning. After all, it's possible to load a level without loading its required wads.

So, the same warning would be given when a refreshed wad lack a used texture.

Is it possible? 
Voted For It 
I voted for Jackhammer on Steam. Since I couldn't find it on Greenlight at first, I'll share what I needed to do to bring it up in my Steam client. If you can use the above link instead, this doesn't matter.

From Greenlight front page, select Browse and Software. The Customize your queue with the tags Animation & Modeling and Utilities. It should appear in the list.

For some strange reason, simply searching for Jackhammer did not bring it up. Perhaps it's not indexed yet? 
Refreshing Textures In Runtime Is Quite Tricky 
Unfortunately I won't add this feature to the upcoming releases. It requires a lot of changes in texture managing module and is also potentially dangerous: texture coordinates depend on texture size, and changing its size may result in offset textures.
Only models can be refreshed so far (using "Reload model" command in a context menu).

2 all: Thanks for your votes! And we need more! ;) 
Support For Quake Mods 
I'm trying to get JH to read other .fgd files so I can make levels for other mods but it doesn't seem to be populating with anything other than the standard quake entities etc?

For example, if you try and use the quoth .fgd it wont show any of the entities for this.

Is this hardcoded? is there something I am missing other than adding the .fgd file and selecting it? I have set up folders and stuff, nothing! 
What Editor Is This FGD For? 
Jackhammer doesn't support such features as model(":progs/player.mdl"), therefore it can't properly load the FGD. 
There was a Quoth FGD previously posted, created specifically for JH: 
These Are TB Specific Attributes 
Some Minor Things 
In the surface properties panel, the tab order between the various fields is odd.
Pressing tab from the x-scale field moves focus to the justify right button. Should go to y-scale field.
From the y-scale field it goes to the fit button, which might be alright but would be better to go to x-offset in my opinion.
x-offset goes to y-offset as expected, but y-offset goes to justify left, expected rotation.

Another thing is that giving focus to a field by clicking on it should do a select-all on the text in it.

A minor thing, but the world/face projection checkboxes are very confusing, as it seems that faces that happen to have the same world space projection as the default face projection get both boxes checked. (I.E., faces that point toward positive X/Y/Z)
In my opinion the difference between world space and face projection should be explicit, but I have no idea how you're handling this internally. 
I'll Check The Tab Order, Thanks 
The difference between world and face projection can't be explicit, simply because there are cases when they coincide. In other words, they are NOT mutually exclusive. And that is why there are checkboxes, not radio buttons. 
Yeah that's kinda what I guessed was going on.
It's still a bit confusing, but it's alright I guess :-) 
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. 
Thanks For The Bug Report 
Yes, there was a problem with parameters' replacement: actually only one occurence was replaced. It will be fixed in the next version. 
A Couple Of New Features Of The Upcoming Version 
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. 
New Feature 
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 
Supporting. Def Files 
Should be a consideration 
Why Not Use 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. 
Thanks For Reports! 
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. 
Noob Question / Feature Request 
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:

And the texture browser: 
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.

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.

Here's a surface that should have the above texture (selected in the texture browser) applied to it. It instead displays as missing.

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. 
WAL Files Incorrect? 
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. 
Another Suggestion 
Texture filtering option for the 3D view. This would make it easier to prevent and adjust against bad color bleeding when two different textures are used on neighbouring surfaces. 
What's the different between the suggested feature and already existing option "Filter Textures"? 
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).

Looks like removing the texture names from the WAL files corrects this issue, I'll just make an alternate version of the files for use with Jackhammer then. Thanks for the help! 
Filter Textures? 
I didn't know; where's this option? When clicking on the "Camera" caption in the 3D view, the only options available are wireframe, filled shaded polygons, textured polygons, and textured shaded polygons.

I'm at my job right now, I'll search for it when I get home. 
In the menu go to Tools->Options, then in the "3D Views" tab there's a "Filter textures" checkbox. 
:D Thanks 
Well, if that's what you need, I would rather make a hotkey to toggle "Filter textures" at any time. :) 
I'd like to advocate again for art tablet support. It's -right there-. :) The only thing it does wrong is if I try to use my Wacom tablet to rotate the camera in the 3D view, it's WAY too sensitive and flies all over the place. But it seems usable for everything else.

PLEASE give me the ability to use my tablet for Quake mapping. My shoulder would thank you!

I don't know specifically what needs to be done but it seems like damping the input into the 3D window would just about do it ... everything else, as I said, seems fine. 
Have you tried to change mouse sensitivity setting in the preferences? 
I did. Even dropping it as low as it can go is still way too fast. 
Would you mind estimating the acceptable sensitivity, as a percentage of JH's sensitivity value = 1 (the lowest)? 
Actually, in playing with it ... you know what? I think the main problem may be in the way the viewport handles the mouse.

When using the mouse to rotate the view, it looks like you're re-centering the mouse with each change in rotation. That works fine for the mouse but I think it's wrong for the tablet.

If I confine my initial clicks to the center of the viewport, it feels pretty normal.

If I click to the extremes of the viewport, it goes CRAZY which I imagine is because it's seeing a huge delta from the center of the viewport to mouse cursor.

You don't do that in the 2D viewports and they work perfect ... maybe relevant? 
But to answer your question ... currently I'd estimate you'd need 20% of the current lowest speed to feel OK on the tablet. So instead of 1, it would be 0.2 or something. :)

But, as I said above, I think tablet input may require some special handling as it's not exactly the same as a mouse. 
Ok, thanks, I'll think of correct mouse handling. Fortunately I have a Wacom tablet to test it. :) 
Having a tablet definitely helps. I remember bugging the coders on UE4 to properly support tablets and they kept borrowing my spare tablet whenever problems came up. :P

So Sleepwalkr 
When are you going to convert Trenchbroom to UE4?? 
Fuck, wrong thread! Damn you func_ and your lack of an edit button 
So Xaerox 
When are you going to convert Trenchbroom to UE4?? 
This is confusing. 
You're posting such things right at the moment when I'm downloading UE4. Is this the sign?

Jackhammer to UE4 tool would be nice. 
it's been discussed elsewhere on this board in the past, and warren-willem can surely elaborate, but making bsp architecture in UnrealEd isn't frustrating because the people who wrote it suck, it's because bsp is just about the single worst thing you can use Unreal3/4 for. it's simply enforced at the tool level.

jackhammer or trenchbroom for UE4 would only allow you to quickly and easily create levels that are still relatively plain and boring compared to what UE4 can do with meshes, at a big performance cost. 
Being able to quickly iterate then export would be a huge boon.
That doesn't excuse the piss poor tools. Also heavy reliance on 3Rd party programs kind of misses the point of an all in one game Dev environment.

I guess I really disagree with your views 
I Try To Keep My Mouth Shut Most Of The Time 
With all due respect, Lunaran, I could not disagree more. A while back I posted a comment with some thoughts about this on Joe Wintergreen's video regarding the topic: But I'd like to elaborate.

There's a difference between "building BSP architecture" and "using BSP-style tools to build mesh architecture". HammUEr does the latter, from the sound of things. No one is advocating a return to BSP brush based engines, only that simple, intuitive, accessible tools like those found in Hammer be made available in modern editors. Hardly a non-trivial development task, but with million-instance foliage rendering and hundred-square-mile procedural terrain handled so well, I'd think this is comparatively straightforward.

For more than a decade I've heard your arguments thrown in my face with an eye roll and exasperated sigh every time this comes up, and they're just as insulting now as they were ten years ago. Working with 3D applications is as sluggish as ever when you have simple, low end needs like mine.

It's like a tractor trailer: When you're a professional driver, delivering tens of thousands of pounds of food to a supermarket from a distribution center, the vehicle makes sense. You have extensive training, and the trucking company handles operating costs and maintenance. But when you're an individual who just wants to take his family to the grocery store to pick up a few things for dinner, a minivan is the better choice. The commercial truck holds much more cargo, much more weight, is engineered to a higher standard, and will go for literally millions of miles when properly cared for. But the thousands of dollars a week in fuel, the vehicle height, weight and turn radius limiting the roads one can travel, noise and idling ordinances, and difficulty of parking make the vehicle wildly impractical if you don't need its power. You're not simply ABLE to use its capabilities, you're OBLIGATED to.

A more fitting analogy, though, might be "Why do you need Blueprint? Do all your game logic prototyping in Visual Studio! In fact, forget high level languages like C++ and do everything in Assembly, that gives far more power."

We're not earning crane operator licenses, we're not joining the military, this isn't some delicate responsibility you risk handing over to people who might get someone killed through lack of professionalism. Exclusivity of game development as a whole, or even just mapping as a part of that, to only the handful of elites who can work in The One True Way is not something I'm comfortable with. I don't care if Bob Ross' students only paint "motel art", they are and should be able to create simply because it makes them happy, without having to get an art degree before being granted that privilege.

I understand how the tools came to be the way they are, and if they're only ever going to be targeted at professionals, or aspiring professionals, there's no problem. But with engines like UE4, Unity, and Source 2 (which I might add seems to do things the way I want, see the Dota 2 Workshop Tools Alpha version of Hammer for reference) being lowered in cost and opened to a wider audience, I don't think it's unreasonable to suggest less professional people could have a bone tossed our way with regard to polyhedron editing interfaces. 
BSP is invaluable for prototyping and white boxing levels before going into the meshing stage. That's been the standard for years ... so anything that helps with the building of BSP is still useful! 
Another Suggestion� :/ 
When selecting a object and then opening the texture application tool in "Align to view" mode, make the alignment be applied to the whole selection at one.

Currently, Jackhammer ignores the selection and only aligns a single surface. 
"at one" = at once. Autocorrect fail. 
Multi Align To View 
Select as many faces as you wish, and then hit Ctrl+Shift+A.

I'm not going to convert either Trenchbroom or Jackhammer to UE4. :) Although I appreciate the quality of Unreal engines, I'm still developing my own, and the primary goal of JH is to support it. That is why it now supports lots of wysiwyg features, like animating effects, skybox rendition, etc. Support of these features in Quake/Half-Life/Quake3 is, well, a kind of side effect. :) 
When will you create the Volatile Engine thread here at Func_? I wanna try it. 
Well, at least when there is a playable demo version/ :)
However I think most people here are not interested in amateur engines, since it is a Quake-related website. JH itself is another matter because it supports Quake. 
I am all interested in amateur works (or else I wouldn't be doing some of my own) and hope to hear from your engine soon. I'm sure there is room for a Volatile II thread here (how about an "other engines' thread). 
yeah not sure how you got that impression. if it's vaguely quake-like, i'm sure someone here wants to read about it.. 
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:

...and Here is newer demo

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:

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. 
Idea About #148 
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?"

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. 
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. 

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. 
A Persistent State Of The Editor 
(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. 
There's Already A Hotkey. 
Just hold down shift whilst rotating and it'll do the opposite of what you have in your settings. 
that's a magic! 
FGD Editor 
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. 
Bug Report 
... 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. 
An Again... 
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? :) 
Well The Cat's Out The Bag Now 
brb, phoning valve lol. 
The Conspiracy Of Silence 
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? 
Post A Reply:
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.