Oh wow. 

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! 

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. 

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

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

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. 

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. 

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. 

...but I hear Trenchcoat 2 will have 2D as well. 

 

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

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. 

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

Thank you for O_EXCL! This is my fault.
Will fix it in the next Linux update. 

Awesome news ) Congrats! 

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

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. 

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

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.