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.
First | Previous | Next | Last
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? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.