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
Quake 3 Support 
Oh wow. 
5 Minutes Of Nosing Around 
Some nice quality of life changes and fixes here. Nice! I'll be making another Quake level with this thing and I will be able to give proper feedback after that. 
 
Donated. Thanks for all the hard work guys, your editor is great! 
Working Great, Slight Niggle 
It installed and worked right away on 64-bit Ubuntu Linux.

Configuring took me some time to figure out on the previous version, so here is a summary of what I did for editing Quake 1 maps.

I created a game Profile for Quake in Tools -> Options -> Game Profiles tab.

I put the included quake.fgd file in the Game Configuration files list. I added the appropriate directories into the Directories subtab.

I added a texture wad file and the palette in the Textures subtab. The Quake palette is in the quake subdir of the Jackhammer distribution, named quake.pal.

I used a pak tool to extract the mdl files from the Quake paks and placed them into a progs directory that was a subdir of the Base Game Directory I set in the Directories subtab. Now I can see the models while editing. (It would be great if Jackhammer could pull them from the pak files directly, but I suppose it's not necessary.)

This is the necessary part of the config setup. I wanted something more, though.

I set up the Build Programs so I could launch the map compiling tools and the Quake engine from the editor. This worked well enough, until I tried to do it the second time.

* Linux gave the error message:
"File exists"

This happened because it tried to copy the newer test.map file and replace the older one. I would like it to replace the older map file and not stop with an error.

I would in fact prefer to be able to run an external build script from the editor instead of the built-in sequence of commands. It's easy enough to just export the map file and run my own scripts from the terminal, though, so this is not a big usability issue.

However, how are you supposed to edit and test a map multiple times if you can't copy a newer version of the map file on top of the old one? Please advise. Or fix :)

Finally, I have no idea how to edit light colors. I could paste the color entry as text via the paste command in the Object Properties dialog, but is there a way to edit the color key and values in the Jackhammer editor at all?

It's looking great despite these small niggles. I'll be eventually working on an actual map with it, as soon as I've sorted my other priorities out. 
Color Values 
"is there a way to edit the color key and values in the Jackhammer editor"

At a guess I'd have to say that just like any other editor that uses FGD files you will need to modify the quake.fgd file by hand and add in the flags there (just once, then it's there forever). Once you do that then it's as simple as changing the light entity's other values. 
Yes, Edited The Fgd 
@Quaketree, yes that works. Thank you.

The Quake.fgd that comes with Jackhammer doesn't have all the light options that are in, for example, the Trenchbroom's one, so I copied some from there. Then, I added the line below by myself in the Light baseclass definition. I don't know if there is a way to specify a triplet of integers, but a string works well enough in practice.

color(string) : "Light color" : "255 255 255"

Nice to see the editor color the light entity icon according to the light color.

I thought that I can probably work around the map file copying restriction by creating a little wrapper script for qbsp that renames the map file after compiling the bsp, for backup purposes. I'll do a little write up about this and other little helper hacks later (after proper testing), in case anyone else might find them useful. 
Be Careful With Custom FGDs 
If some features are missing from quake.fgd, this means that map compilers provided with JH don't support them. But other quake compilers may not support JH's output map format (220). So, to use such features as colored lighting, you need a map compiler that supports mapversion 220. I believe there are some, since many people were already using VHE for Quake.

If your OS can't overwrite a map file, there is probably an issue with access rights. There is also an "Expert" mode similar to VHE's where you can create your own command pipeline, including a delete file command before copying. 
Reasons To Use Over Trenchbroom? 
So I am curious.. What mountain of epicness does this editor have in comparison to TB? Not asking about quake 3 related stuff. That is pretty sweet though. But curious how is the brush editing and mapping.

There any good videos of this editor in action? I was sold instantly with Trenchbroom. Wondering if this one has similar editing wizardry... 
 
You could just grab it and give it a go for 20 minutes. :)

It's basically Worldcraft/Hammer. If you liked those editors, you'll like this. 
I Never Installed And Ran Trenchbroom 
Only saw a couple of screens and videos. Was not impressed, since I personally prefer editing in 2D-views. Jackhammer is a VHE-like editor, for those who got used to its look-n-feel. 
 
Danget my lazyness has been detected! Then again I was never much a fan of those editors.... Still need to keep an open view for new tools. 
2D Views 
...but I hear Trenchcoat 2 will have 2D as well. 
>Trenchcoat 2 
 
@XaeroX 
Qbsp from tyrutils compiles the 220 map format just fine, and the associated light program handles colored lights. There is one snag with tyrutils, so I thought to write it down here in case anyone else is on Linux and wants to use these tools.

You will have to modify qbsp a bit if invoking it directly, because it misinterprets full paths beginning with a / as options (to be fair, may be that is thing you do on Windows?). This is a one-line change in the tyrutils source, and I should in fact mail a note about it to the author.

Diff for qbsp.c:

457c457
< if (szTok[0] != '-' && szTok[0] != '/') {
---
> if (szTok[0] != '-') {

This shouldn't be an issue on Windows.

I'll set things up to my liking with the expert mode as soon as I find it. Thanks for the response. 
 
"...but I hear Trenchcoat 2 will have 2D as well. "

That might be true, but the Trenchbroom 2 beta hasn't seen a new build dropped since mid-September so ... maybe give this a go while you wait. :) 
Re: Be Careful With Custom FGDs 
I think that the issue is twofold. First that different compilers use different entity spawnflags (especially where light and detail brushes are concerned) and second that the FGD that comes with Hammer is, aside from the parts that add models and sprites, set up for the original Quake compiler parameters. Colored lights, detail brushes, sunlight and so on are not supported in the FGD that ships with this version. As such I wouldn't really call it a custom FGD so much as an updated one.

While not a huge problem (Smart Edit can take care of it with no problems but that can be a lot more work for the mapper if they extensively use the extra features added by more modern compilers) and replacing any modified FGD with the one that Hammer shipped with is dead simple as long as you make a backup of the original FGD before you start to fiddle around with it.

I would save the "Custom FGD" moniker for one that has values other than the defaults rather than adding in features used by most modern compilers. So for, example, lets say that a mapper almost always uses _sunlight (or light from torches for that matter) with a slightly yellow tinge in a map, it's much easier to tweak the light parameter(s) in the FGD once instead of doing it for every instance of that entity. 
@XaeroX 
>If your OS can't overwrite a map file, there is probably an issue with access rights.

It can do it in the other directory...

The problem is specifically these flags that end up being passed to open(2) system call when the program is about to copy the map file to the target ($bspdir) directory.

O_WRONLY|O_CREAT|O_EXCL

O_EXCL means the syscall to open will fail if the file exits already, which is exactly the problem here.

I used strace to find this out, as one does. While I can use Expert mode from now on, I'd appreciate if you looked at this some time, and figured out why specifically when copying the map file to the $bspdir this flag appears. You see, all the other straced open calls (such as when backing up and overwriting the jmf and map files in the $path directory) don't have it, but use the much more sensible O_TRUNC. 
Oh Shi~ 
Thank you for O_EXCL! This is my fault.
Will fix it in the next Linux update. 
 
Awesome news ) Congrats! 
Jackhammer/WC1.6 Issue Or Wally1.55b Issue? 
* First of all, congratulations and thx for the release, i believe i'll be using this marvel a lot.


* Second, i have a problem with textures in both Jackhammer and WC1.6 and haven't seen a single thing similar to this on their FAQs and manuals:
I was checking out mapping in JH for all the videogames it supports, but when i got to Quake 2 i had a problem, the textures that i exported to .wal from Quake wads look weird (and only those), with lots of white points. I checked them on Wally, and used them on maps compiled with JH and WC 1.6 and loaded on vanilla Quake 2, and look perfect on the three of them. They only have those white points were looked on those two editors.
Investigated further and discovered that the Quake 2's palette that comes with Wally 1.55 is different to the one that comes with JH/WC 1.6: according to Wally, 8 brown/ochre, 1 green and one fullbright colors are missing from the palette that comes with the editors, the same that were showed as white on the editors. Also, when loaded in a text editor, editors palette's files are unreadable, while Wally ones are ordered and readable in RGB data columns, so i can't use Wally's palette for the editors (all the textures change colors a lot (brown to purple/blue for example) when viewed in the editors) or use the one from the editors on Wally (the missing colors are shown as white on any program). Tried also to find more palette files in other editors to substitute them, but they seem to not have any, at least visible as a separated .lmp or .pal file.
Now i am trying to find an older Wally that can save the palettes in the same format as the editor's but had no luck for now, and also i don't think this idea is going to work.


* Third and last, this is just me being curious, why isn't a CSG compiler provided with the editor? Not that i worry about, as i just copied one from another editor. 
CSG Compiler Is Half-Life Specific 
And you should leave its field blank for other games.

The reference Q2 palette is the one shipped with WC 1.6 and JH. If you use another palette (e.g. in you mod) then convert it to pal format (it's actually a binary set of rgb codes). But note that Q2 keeps a palette not in pal format, but within a specific pcx image (can't remember its name actually). 
 
Q2's palette is generally considered to be stored as the palette inside pics/colormap.pcx

although of course all of quake2's pcx files should have the same palette in order to display correctly in software rendering, so it shouldn't really matter which you pick - assuming your tools support reading palettes directly from pcx anyway. 
I Know That But ... 
... what you are saying is that textures made with Wally's palette won't be loaded well by those two editors and i should make a palette out of Quake 2 original colormap.pcx, even though textures in Wally's palette works perfectly in the game itself? Then, which program should i use to convert that colormap.pcx to a .pal format those two editors can understand? 
 
I don't know. I grabbed the pal file from WC 1.6 distribution. :)
I'll add support for JASC ASCII pal format (exported by Wally) in the next release. 
Various Things 
OK, while you do that, i'll search all over the net, as it is impossible no one has reported that about WC 1.6 after more than one decade, and tell you the results.


Now, about new things.


* First, a suggestion: how about adding a list of hot keys, not so the user can know them, that could be done just by investigating a bit, more like so the user can know if he knows all of them. I know there is a list already in commands lists..., but that one is missing quite a number of hot keys.
Also, would be good to be able to change the keys related to each hotkey's shortcut, if it isn't too much work.


* Second, a question: which compilers for Quake and Quake 2 are those that come with the program?
That's an important question, as to know how good they are, but most importantly, what they can do. By knowing which ones they are, the mapper can use the documentation he or she has for them already, know what they can do and a s a result, use them to their full uses.


* Third, i am using JackHammer more and more, and discovered more uses, and more issues, which i am here to report to you to help you improve the editor:

- A general one: i found one thing that can make JackHammer crash when loading, and its only fixed by uninstalling and reinstalling. After many uninstall/reinstall, i found out that it only crashes just by moving the windows 'new objects', 'textures' and 'filter control' as individuals, separating them from the side they begin in. It works fine, till i close and open the program again.

- In Quake: when using the compilers the editor provides, it gives an error even when compiling the basic room the editor makes on new maps. The error doesn't happen with other compilers, except with WC1.6 ones, but those give a different error.
The error is that qbsp freezes completely, so when vis and rad try to do their work, they can't. When looking at the compiling window, it says something about ''parsing error in line 8'', which is the first time i heard about it, and it isn't even in the compiler error lists out there on the net. With WC 1.6 compilers it says ''parsing brush in line 6''. Both errors are similar to some seen in Quake 2 compilers, but as i said before, they are unheard of in Quake, as far as i know.

- In Quake 2: in this game, textures are usually stored inside the packs in /textures/texturesetname/, which this editor knows well, but only for those textures that come with Quake 2, for the rest, when the editor saves the .map file, it points them to /baseq2/textures/ instead of /baseq2/textures/texturesetname/ (which is the standard for custom maps as far as i know) or any other place the mapper points to, so the mapper is forced to store all of them in the same directory, which is chaotic for both the mapper and the player, or manually edit the .map file in a text editor, brush by brush. It also doesn't let you use textures from a subfolder in the folder you selected.
Maybe you should do it like WC 1.6, that gives freedom to the user to put the textures wherever he wants, by for example, if the player want the .map and .bsp to use textures from /baseq2/textures/texturesetname/aaa, he can put them in for example c:/program files/wc/textures/aaa/ and by selecting that /textures/ folder, WC and Quake2 will use those from both /baseq2/textures/texturesetname/ and its /aaa/ subfolder, and in the map the textures' location will be write as /textures/texturesetname/a.wal and /textures/texturesetname/aaa/b.wal


* Fourth: By the way i use Windows XP SP2 and a nVidia 8600 graphics card, if that helps you.


* Fifth, in which websites frequented by Quake and Quake2 mappers have you advertised your editor? It's in case i find more issues i can check if they have been reported already or not. So far i know of this one and apart, some others where it was advertised by others (QuakeOne and some blogs and personal websites (nothing big)), and of course those Half-Life related ones that are pointed out in your website and in the editor itself, and some Doom related websites, and your own ModDB part. 
Coce 
someone said fifth? 
Thanks! 
I'll check the issues.

>>in which websites frequented by Quake and Quake2 mappers have you advertised your editor?
Only this one. The editor is advertised mostly in Half-Life websites. 
About Compilers 
>>parsing error in line 8
>>parsing brush in line 6
This usually happen when you try to compile "new" map format 220 with "old" compilers, and vice versa.
JH's output map format is NOT compatible with ANY map compilers, except 1) Half-Life compilers, and 2) compilers that come with JH (they are actually original compilers with slightly increased limits and map220 support).
But. You can add map220 support to any opensource compilers you like, the source code of their modifications is available. I hope one day developers of all compilers will add map220 support for JH needs, but until that there will be problems. And there is no way to support old map format, because most of JH texturing caps (seamless texturing, UV lock, align to view, etc.) will be lost. 
Bugs With Current Latest Alpha 
I've been updating the level I made for map jam 3 over the last few days using the latest update of JH and have come across a few things :

1) Cordon tool does not work :) You can set the boundary but when you turn it on it does nothing!

2) when in face select mode for texture alignment etc it should be possible to ctrl+shift+click to select all sides of multiple brushes. Currently in JH you can only select a single brush in this way and then have to ctrl+click individual faces on any other brushes you want.

3) I am getting a worrying amount of "point off grid" warnings in the qbsp compiler after building geometry with this editor. I will paste it below:

------ GrowRegions ------
WARNING: CheckFace: Healing point (-1965 -173 107) off plane by -0.014
WARNING: CheckFace: Healing point (-1958 -173 80) off plane by -0.0139
WARNING: CheckFace: Healing point (-1960 -181 79) off plane by -0.0141
WARNING: CheckFace: Healing point (-1967 -181 107) off plane by -0.0142
WARNING: CheckFace: ^-- Face Verts : 4 Tex : mmetal1_2
WARNING: CheckFace: ^-- Brush 3761, Line 30623 ( Ent 617 SubBrush 3 )
Processing hull 1...
------ MergeAll ------
11164 mergefaces
WARNING: CheckFace: Healing point (-1965 -173 107) off plane by -0.014
WARNING: CheckFace: Healing point (-1958 -173 80) off plane by -0.0139
WARNING: CheckFace: Healing point (-1960 -181 79) off plane by -0.0141
WARNING: CheckFace: Healing point (-1967 -181 107) off plane by -0.0142
WARNING: CheckFace: ^-- Face Verts : 4 Tex : mmetal1_2
WARNING: CheckFace: ^-- Brush 3672, Line 30623 ( Ent 617 SubBrush 3 )
WARNING: CheckFace: Healing point (-1942 -189 104) off plane by -0.0139
WARNING: CheckFace: Healing point (-1942 -189 104) off plane by -0.0139
WARNING: CheckFace: Healing point (-1944 -197 103) off plane by -0.0141
WARNING: CheckFace: Healing point (-1951 -197 131) off plane by -0.0142
WARNING: CheckFace: Healing point (-1949 -189 131) off plane by -0.014
WARNING: CheckFace: Healing point (-1949 -189 131) off plane by -0.014
WARNING: CheckFace: ^-- Face Verts : 6 Tex : mmetal1_2
WARNING: CheckFace: ^-- Brush 3672, Line 30623 ( Ent 617 SubBrush 3 )
WARNING: CheckFace: Healing point (-1944 -197 47) off plane by -0.0137
WARNING: CheckFace: Healing point (-1952 -228 45) off plane by -0.0142
WARNING: CheckFace: Healing point (-1952 -228 101) off plane by -0.0142
WARNING: CheckFace: Healing point (-1944 -197 103) off plane by -0.0137
WARNING: CheckFace: ^-- Face Verts : 4 Tex : wmet4_8
WARNING: CheckFace: ^-- Brush 3676, Line 30593 ( Ent 617 SubBrush 7 )
Processing hull 2...
------ MergeAll ------
9061 mergefaces
WARNING: CheckFace: Healing point (-1965 -173 107) off plane by -0.014
WARNING: CheckFace: Healing point (-1958 -173 80) off plane by -0.0139
WARNING: CheckFace: Healing point (-1960 -181 79) off plane by -0.0141
WARNING: CheckFace: Healing point (-1967 -181 107) off plane by -0.0142
WARNING: CheckFace: ^-- Face Verts : 4 Tex : mmetal1_2
WARNING: CheckFace: ^-- Brush 3672, Line 30623 ( Ent 617 SubBrush 3 )
WARNING: CheckFace: Healing point (-1926 -205 104) off plane by -0.0139
WARNING: CheckFace: Healing point (-1926 -205 104) off plane by -0.0139
WARNING: CheckFace: Healing point (-1928 -213 103) off plane by -0.0141
WARNING: CheckFace: Healing point (-1935 -213 131) off plane by -0.0142
WARNING: CheckFace: Healing point (-1933 -205 131) off plane by -0.014
WARNING: CheckFace: Healing point (-1933 -205 131) off plane by -0.014
WARNING: CheckFace: ^-- Face Verts : 6 Tex : mmetal1_2
WARNING: CheckFace: ^-- Brush 3672, Line 30623 ( Ent 617 SubBrush 3 )
WARNING: CheckFace: Healing point (-1928 -213 15) off plane by -0.0137
WARNING: CheckFace: Healing point (-1936 -244 13) off plane by -0.0142
WARNING: CheckFace: Healing point (-1936 -244 101) off plane by -0.0142
WARNING: CheckFace: Healing point (-1928 -213 103) off plane by -0.0137
WARNING: CheckFace: ^-- Face Verts : 4 Tex : wmet4_8
WARNING: CheckFace: ^-- Brush 3676, Line 30593 ( Ent 617 SubBrush 7 )


Now, I cannot be certain that it is the editor causing these off plane points but I am 99% sure they were not occuring in the old alpha of JH!

4) I was having trouble with the "Go to brush number" function in the editor. Again I am not sure if this is an editor bug or just some weirdness with how brush numbers are stored in the map file but I couldn't go to certain brush numbers above a certain point. Brush 1 - 2000 or so worked fine but 3000 plus did nothing. 
#28 
Yeah, i know the issues with Half-life's map format, but ''parsing error in line 8'' happened when using JackHammer's provided compilers, so from what you have written i have to think that the compilers you added to JackHammer are old. 
 
2 DaZ:
Cordon tool works ONLY if you compile with editor. It doesn't affect regular map export. It will be fixed in the next releases.
As for the errors, I never heard of the "point off plane" error. What compiler do you use? Please give me the map file also.
I'll check "Go to brush number" function also.

2 Cocerello:
Yes, JH compilers are old. But they definitely support JH's exported map format. Could you please give me a map file that produces such errors? 
Files 
Here you go, map file, compile tools and the batch files I use https://www.dropbox.com/s/l52xzk35tz79vv1/jam3_daz_files.zip?dl=0

About the cordon tool. I am not trying to compile maps while the cordon tool is active. I simply use cordon tool to hide all geometry outside of the cordon cube so that I can see what I am working on. This does not work currently as the cordon box doesn't hide any geo! :) 
 
Thanks for the map file. It seems that everything is ok. Regarding the compiler messages, you'd rather contact the author of the compiler. I can explain only messages spit by compilers that comes with JH.
Cordon tool is historically a tool to hide parts of the map during compilation process to speed it up. It does not affect editor visibility. Sorry. 
 
It does affect visibility in the editor. That's half the point.

Se here : https://developer.valvesoftware.com/wiki/Hammer_Cordon_Usage

Only things touching the cordon bounds are drawn in the editor viewport. 
It Does Not! 
In Hammer 3.5 which is my reference editor.
Maybe future versions of Hammer do, well, good for them. 
 
OK, instead of getting defensive can you add it as a feature request? 
 
I am not defensive, just explain why some things work so and not otherwise. Feature requests are always welcome, but the phrase "Cordon tool doesn't work" doesn't sound like one. ^^ 
Pew Pew 
I assumed that the cordon tool always had this behaviour (hiding all geometry outside the cordon cube) as this seemed like its most useful function. Clearly I was wrong :)

It IS a super useful feature however, it would be nice if it could be added. 
 
I very much enjoy using JackHammer, thank you very much for your work!

Some things I would like to comment on:

* It would be nice if name/target keys would be kept unique when copy&pasting entities. NetRadiant will just add a numeric suffix so that the entity name is unique (when cloning via <space> this step will be omitted, IIRC).

* In NetRadiant, copy&pasting or cloning via <space> will have the copy in exactly the same position as the original, which is usually what I want. In JH, when copy&pasting the copy will be "somewhere", depending on where the 2D views are positioned. When only working in one 2D view (and switching this 2D view around) it is basically impossible to say where the copy will end up being. Even when using the standard layout of 2D views the copies end up being in unexpected places, unless I'm very careful with the position of the 2D views.

* If the <space> key is still unbound: It would be nice if a "in-place cloning" could be bound there (like in NetRadiant), especially if you don't want to change the current positioning behavior of copy&paste. 
Thank You For Comments! 
In-place cloning in JH is done via Shift+drag.
Convenient unique naming of objects is a challenging task (because sometimes mappers want to clone with the same name, e.g. when it is a multi-target entity such as env_beam). Maybe it will be implemented via a special checkbox in "paste special dialog". 
 
Oh, completely wasn't aware of the <shift>+drag cloning - thanks for pointing that out and sorry for the noise! 
 
Request: Would like to be able to still create groups when when I have "ignore groups" turned on. It's super annoying to be hitting CTRL+G a bunch of times and then realize I'm not in groups mode so none of that was saved. 
+1 For That! 
Also, when you turn on "ignore groups" your selecting is cancelled :( 
 
OH GOD YES, please stop that. :) 
 
As long as I'm in here making requests, being able to nudge stuff with the cursor keys in the 3D viewport would be SUPER useful.

As it is now, I have to select what I want and then hover over a 2D viewport and start hitting the keys to move stuff. If you add page up/down for moving vertically, it would be a super handy way of nudging things into place. 
IG-mode Requests Are Accepted 
PgUp/PgDn 3D nudging along Z axis is also clear.
But arrow key nudge is not so simple. Should user rotate the camera, the meaning of "right"/"forward" will change dramatically. Should I implement nudging in relative X/Y axes or stick to world-space X/Y? In the latter case, with camera rotated around Z to 180 deg, left becomes right and vice versa.
On the contrary, the problem with relative axes is that user generally can't position the camera to nudge in exactly axial directions which are often intent. 
 
Nice!

Well, I personally prefer the relative axes solution. If I hit LEFT, the editor determines and uses whichever axis direction most resembles left based on my current camera rotation ...

It's more intuitive than my constantly having to guess which way +X current runs in the viewport. 
I Have Experimented A Lot With Both 
And in the end, relative won out in TB. It's just a lot more intuitive, even though in some cases it might be unclear which direction is actually selected for the cursor keys.

This is where TB's camera orbit mode (don't know if Jackhammer has this) comes in quite handy, as you can quickly rotate the camera about the selected objects to ensure that the correct axes are chosen. 
 
As long as we're talking about features, is there any chance of making it tablet friendly? If I try to navigate the viewports with my wacom tablet, it goes a little crazy and is basically unusable. I would LOVE to kick back and make Quake levels with my tablet but ... alas! 
Feedback, Requests, Thoughts.. 
I have been using Worldcraft/Hammer editor for the past 15 years. It's a big part of me and I just love working in that environment; whether it's Quake 2 editing or Source-based games.

Now I have been using Jackhammer daily for the last 2 months thanks to a Quake 2 mapping competition. I think it's a great tool and I want to give some feedback. Here goes:


- Add shortcut Alt+a/s to decrease/increase grid size. (my biggest annoyance at the moment, because there is no quick way to change grid size)

- Ctrl+Shift+E should focus on selected object/s in 3d-view. Same as Ctrl+E for the orthographic views, but for the 3d-view.

- Texture application mode: Ctrl+Shift+LMB should apply selected texture to all sides

- Texture application mode: Ctrl+Shift+RMD should select all sides of brush

- Pasting something in the 3d-view should paste it from where the cursor is at, onto the surface it hits. If you are in freefly-mode (shortcut z), the cursor is in the center and should then paste from the center.

- Pasting objects/entities in 3d-view should put the objects on the surface, not into.

- Moving an object that is off-grid, should snap it on to the grid once you start moving it.

- Texture browser to display a number in the bottom right corner of the texture, of how many times it's being used. Awesome feature in Hammer, super useful.

- Replace texture feature is not working, when.. you go to your texture browser and select a texture and click replace. Then in the pop-up window, the "..."-buttons are greyed out.

- Clipping tool ungroups objects that it is touching. It doesn't ungroup all objects of the group, only the touched objects are ungrouped from the group. I think groups should remain when using clipping tool, just as in recent Hammer versions.

- Being able to work in group- or objects-mode. Group-mode will work/select groups, Object-mode will give you access to objects/entities within groups, but not destroy the groups.

- F1 for help. Maybe a page where you link to useful sites that could be of help for the user? Right now there is hint-display at the bottom-left saying "For Help, press F1", but doing that gives you nothing.


There you go. Thanks for great work and keep it up! 
More 
- When you delete a brush or group of brushes that is part or all of a visgroup and get it back with Ctrl+Z, the brush or group of brushes is no longer part of the visgroup.

- ] works fine to rise the size of the grid, but [ isn't working to make it smaller.

Yeah, i know the issues with Half-life's map format, but ''parsing error in line 8'' happened when using JackHammer's provided compilers

Couldn't get to make this show again. Found another error where it insisted on using the textures from quake/id1/quake.wad which is non-existent, but comes as an entry by default. Deleted the entry on the textures window and worked fine, so it isn't important.


* On the suggestions side, i have three.

- Please add an option to block the up-down-left-right keys from moving the selected brushes. It is an useful feature indeed being able to move them that way, but half of the time you are moving them without noticing, when using those keys to move the camera around or when doing other things.
I never had to check so many brushes that where causing leaks or other compiling problems in a map since WC 1.1.2, and those aren't exactly good old memories.

- Isn't there a way to make it so the compiling window doesn't freeze while compiling when you go to another window?
I know that the compiling is still going on and that it is an issue that has been happening since WC1.0, but it would be useful to check other things that don't ask much for the processor (looking at tutorials for example) while it is compiling and still being able to check how it is going or if an error that doesn't stop the compiling happens, when doing long (many hours long) visings.
The other option would be using Necro's compiling GUI which hasn't this problem, but it is an external program.

- Also related to compiling, and an old WC issue too: clicking on the extra option for compiling and adding -extra in the expert mode doesn't do exactly the same. I don't know what happens, but some features of some compilers don't work (colored lighting for example).
I know that this should be directed to the person who made the compilers i use, but it is a strange thing that there is a difference in something like that, and think it could be easy to fix.

I hope one day developers of all compilers will add map220 support for JH needs

At least all Quake compilers that have been around for 10-15 years or less do that already. Quake 2 ones don't as far as i know. Don't know about Quake 3 ones.


* WizardExt:

- Add shortcut Alt+a/s to decrease/increase grid size. (my biggest annoyance at the moment, because there is no quick way to change grid size)

There is one already. ] and [, but [ doesn't seem to work at the moment.

- Moving an object that is off-grid, should snap it on to the grid once you start moving it.

Better not, there is some times when you want the brushes to stay off grid, for example after rotating a group of brushes (the box where the group is can be off grid, but the points of the brushes themselves are are still on grid. Better give the mapper the freedom to choose, as there is already a ''snap on grid'' option with its hotkey that works fine for that.

Good luck with the contest. In three days we will get to see the maps and how they went. 
 
[ 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. 
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.