News | Forum | People | FAQ | Links | Search | Register | Log in
Jackhammer 1.1 Public Alpha Is Out!
Jackhammer is a brand new level editor for games with a quake-style BSP architecture. The aim is to develop a convenient cross-platform tool capable of incorporating the best features of existing editors, such as Valve Hammer Editor, Q3Radiant and others. Despite Quake and Half-Life having been released a long time ago, the large community have arisen around, still developing mods and games on their bases. However the existing editors suffer from fundamental disadvantages their users are well familiar with. Jackhammer does aspire to be the universal level design tool for classic games. But not only the classics! The editor shall become a key development tool for the Volatile3D II engine, that is why its second name is Volatile Development Kit.

Jackhammer is being developed since August 2013, that means the editor is quite young. Today our team is ready to present the latest public alpha - new version 1.1.500. Despite not all the ideas being implemented and not all the functions being completely error-free, you are already able to download almost fully functional version of the editor, install and evaluate Jackhammer in action. Please don't forget that alpha may contain some issues. We are interested in a vast testing of the editor and grateful in advance for your comments and suggestions. In addition, you can provide Jackhammer with financial support, donating funds for the further development.

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

Web page
Feature list

DOWNLOAD NOW

Screen #1 Screen #2 Screen #3 Screen #4
First | Previous | Next | Last
 
[ works for me ... that's weird! 
What ... 
works for you? 
Forget The Question 
 
 
@Cocerello

Thank you, I had lots of fun!


about grid-size shortcuts..

[ works, aswell as -/+. But I really appreciate recent additional shortcuts for decrease/increase grid that exist in recent Hammer versions. Something that speeds up workflow, very accessible.


about moving objects that are off-grid:

Rotating something won't snap it to the grid. The only snapping then would be the angle snap. I am not following you fully, how can you have the group being off grid and the brushes making up the group being on grid? Groups don't function that way? Anyway, the way I suggest is how it works in recent Hammer version.

And there is freedom to choose; if you want to move something off-grid, you can toggle off "snap to grid" or move objects using Alt pressed. 
 
A more advanced suggestion:

A lot of the more advanced rotation operations require making a large brush that can be used to fake a pivot point for the rotation of a group of objects.

It would be awesome if, say, you could middle click in the viewport and define a temporary pivot location. Then all scaling/rotation operations happen around that point rather than the center of the selected group of brushes/entities.

Allow for a quick way to clear that temporary pivot and it will revert to the current way of doing things.

Please? :) 
 
Rotational/scaling pivot is very nice idea. I'll think of it. :) 
 
About [, i'll check it more in other computers. Maybe it is an issue of incompatibilities between the languages in keyboards or OS incompatibilities, who knows!


WizardExt

I haven't explained myself well: it is more like sometimes is better to have them off-grid for some calculations when vertex manipulation is used a lot on a rotated brush in a non 45 or 90 angle, even more with some more complex brushes.

Check the brushes around four of the spawn points in my first map submitted for the contest when we had them published to see an example of where i needed that. It has to do with using irregular prisms with quadrangular base for some complex structures.

And there is freedom to choose; if you want to move something off-grid, you can toggle off "snap to grid" or move objects using Alt pressed.

Where can you toggle off it? Haven't seen that, and want to use it.

I haven't explained myself well again: Yeah, right now there is freedom, but if you make it so they snap automatically when moving like i think you were asking for, the mapper loses the freedom to choose. But my words are invalidated if you say there is an option to revert it back aside from Ctrl+Z. 
XaeroX 
TB2 uses a handle that you can freely place by dragging its center point around. It works quite well, people have done some cool (and to me, unexpected) stuff with it:

http://t.co/xVHumtHPyN
http://t.co/Mwd5t26ILQ 
Yeah.. Maybe 
Never saw TB in action. I'm scared of it because it doesn't have 2d viewports, for me it's the same as a car without a steering wheel. Althouth I believe such car can be very handy. :)
Btw, JH has an ability to rotate a brush around a vertex pivot. Just enter Vertex Manipulation mode, select all the vertices, press RMB on some vertex and drag it. 
No 2D Views 
I got convinced by people that 2D views are better for some things, so TB2 will have them, too.

The vertex pivot thing is interesting. Which axis does it rotate about? Maybe this would also be useful for brush edges so that you can easily rotate a brush about one of its edges. I think someone requested that feature for TB a while back. 
Since It Rotates In A 2D View 
The choice of axis is straightforward.
After some tests in JH I've remembered that rotation pivot is arbitrary. ^^ Just click any point in 2D with RMB and rotate the whole thing aroung it.
Scaling relative to an arbitrary pivot is also possible. Hit Alt+E in vertex manipulation mode and drag the blue circle (this is a pivot).
Well, yes, I often forget the things I've coded some time ago.. :( 
 
Are you sure? If I select some brushes and try to right click in the viewport, I get the context menu ...

https://dl.dropboxusercontent.com/u/161473/Misc/2015-03-31%2009_39_27-Jackhammer%20-%20%5BQMapJam.jmf%5D.png 
Yep, I'm Sure 
But first of all, enable Vertex Manipulation mode. :) 
 
Ahhh OK ... now I see it. Thx! 
 
Wow I just tried it. It's a really nice feature! :) 
 
Please make selections part of the undo buffer. It's maddening when you deselect something, hit undo by reflex to get it back, and it undoes something you did earlier instead. 
Well, Maybe As An Option 
Selections and object properties (which are currently also non-undoable) will blow the undo buffer up. 
 
Have a limit. Most apps will give you an option where you can set the number of undos you want. So if someone has a monster machine, they can jack the number up higher.

Also, something I've seen done is clearing the undo buffer whenever the map is saved. ToeTag does that... 
So Does TB 
Also, there really is no need to limit the undo buffer. You can collate subsequent actions into one (for example, you can collate 5 subsequent transforms if they happen within a certain amount of time) and the actual information you have to store is quite small for most operations in a level editor. 
Oh God No! 
>>clearing the undo buffer whenever the map is saved
This is the most evil feature I've ever encounetered.
Once I've lost my work in Excel after occasional Del followed by Ctrl+S instead of Ctrl+Z! 
 
Whether it's more or less evil than only including certain actions in the undo/redo buffer is a debate for another time then. ;) 
 
Well, excluding selections from undo buffer can't be fatal as compared to deleting or modifying objects, you can always select again and you can't break the work with unwanted selection.
As for entity properties, well yes, this is evil. But afaik VHE doesn't undo them too, and I was too lazy to implement it since it doesn't fit well to my undo system. :( 
 
:-/ 
Am I Missing Something Here? 
I have always been able to undo everything I've done with Jackhammer after saving a map with no problem. 
 
Yes, you're missing something. The previous 10 posts or so should clear it up. 
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.