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. 

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! 

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! 

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