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. 

someone said fifth? 

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. 

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

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. 

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? 

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. 

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

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. 

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. 

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. 

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. 

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.