Either in the texture browser or in the 3d window shaded or not.

They all appear as white. 

What about the previous version, 1.1.500? Is there the same thing? 

"Toggle 3D auto selection by mouse dragging"

This button is godlike :D 

I've been using version of the editor to create my map jam 6 map and have a few things:

1) When in face edit mode I should be able to shift+ctrl+left click on a brush and the editor will add all the faces on that brush to the face selection. This works in Hammer but does not in JH :(

2) When placing an entity into the world by clicking inside the 3d view to place it, it will usually be 2-4 units inside the floor/wall you place it on and require you to manually move it afterwards. It would be great if there was some sort of check to make sure the entity wasn't inside anything when placed.

3) With 15 degree rotations box in 2d options ticked, I cannot do free rotations in object rotate mode by holding alt. Holding the ALT key while in object rotate mode should allow completely free rotation on that axis.

4) When shift-dragging brushes to duplicate I sometimes get corrupted texture coordinates on a face that can lead to a compiler crash with "bad texture axes on face" or something similar (Quake 1, EricW's compiler suite). I can't remember if I had texture lock on or off when I duplicated, and it's only happened once or twice. I will try and investigate and get a working repro.

And some things on my wish list for the future... :D

1) Hammer style auto-visgroups when? :D
2) 3 point clipping like in gtk radiant!
3) robust vertex editing like in TrenchBroom
4) vmf instances like in latest Hammer

This latest version has been very stable for me, I think I had one crash (without error msg) during this entire map jam, luckily with the autosave system nothing was lost! 

1) ctrl+shift+click is actually an alias to alt+click. This is a workaround for stupid Ubuntu desktop environment behaviour that reserves alt key to its own needs. Shift+click works, but there is actually no way to select multiple brushes in texture application mode. However you can exit it, select brushes and enter again.
2) Such checks are complicated because the editor itself does not define an "inside anything" term. This is a game-related term actually. E.g. func_illusionary is not solid and therefore there is no problem that some entities are inside, the same applies to triggers. JH has a workaround for "players in floors" offseting their origins using a fgd keyword "offset", but this is the only thing. As for 2-4 unit offsets while placing entities far from the camera, this is actually a precision problem.
3) Well, it should not. :) Hold shift instead of alt. This is the same behavior as VHE's.
4) Make sure you've disabled "UV Lock" before ANY operation that doesn't explicitly require it. And don't forget to use Alt+p sometimes.

About suggestions:
1) VHE doesn't have auto-visgroups. Please mind that my reference editor is VHE 3.5.
2) Very complicated due to current clipping tool architecture, operating only in one 2d-canvas.
3) I've never seen TrenchBroom in action, and actually do everything in 2d views since my first map. :) I keep saying that JH is a 2d-oriented level editor.
4) Do you mean prefabs? Or what?

Anyway, thanks for suggestions and for using Jackhammer! ^^ 

Hammer auto-visgroups - https://dl.dropboxusercontent.com/u/33279452/autovisgroups.gif very useful for quickly removing all the stuff you don't need to see!

TrenchBroom vertex editing - https://dl.dropboxusercontent.com/u/33279452/tbvertexedit.gif As you can see, Trenchbroom will slice faces to keep brushes convex when you vertex manipulate them. It also refuses to move a vertex into a position where an invalid brush shape will be formed.

Thx for the reply. Looks like I have some new shortcut keys to learn :) 

Is there a beginner's guide somewhere that tells you how to configure Jackhammer correctly for Quake? I've looked at the online documentation, but I can't see anything along those lines ... and there are quite a lot of things to configure. I think I've got it more or less figured out, but I'm not sure, and I've left a lot of fields blank as I simply didn't know what they were. 

2DaZ:
I know that Hammer 4+ has auto visgroups. But again, my reference hammer is 3.5.
I see, TB performs automatic triangulation on non convex objects. JH does not, so such vertex editing is quite useless. It would be nice feature though, but I'm not sure I'm ready to implement it. :)

2total_newbie:
The installer can automatically configure everything, just specify a path to quake executable during the install process. After the installation you can immediately create a simple room, compile it and run in a few clicks.
Hovewer this is possible only under Windows (Linux installer is much simpler). 

Like Daz, I'm also using JH 1.1.700 for a Jam 6 map, and I really love what you've done with the program, great work! I do have some feedback, though. I've taken a few dozen notes about Jackhammer; between feature requests and bug reports it's about 70 items so far. Is there a better way to provide that much feedback than posting the whole thing here? My posts tend to be long enough, and I'd hate to clutter the board with an even bigger mass of text.

As for instances, when Daz mentions them, I trust he means these: https://developer.valvesoftware.com/wiki/Func_instance They work sort of like prefabs, but they're easy to keep editing after you've put them in position, even rotated or translated off of the grid.

You place a point entity called a func_instance which serves as a reference to, or "instance of", an external map file. This map file can contain basically anything you want. A common light fixture, for example, or a pillar, or maybe a complex entity configuration that you want to use in several locations. Instances let you set everything up once, then instantiate your work multiple times. Something called "name fixup" keeps entity names unique, if a mapper wants to, by adding a prefix or suffix (either one the mapper specifies or an automatically generated name). You can even do material replacements, swapping out one material for another in some instances but not in others.

There's also the benefit of being able to build neat geometry on the grid in an external file, but then rotate the func_instance point entity which references that external file to whatever angles you'd like. The transformations don't get applied to the instanced geometry in the map file stored on disk, they get applied only immediately before compiling, so concerns of slowly accumulating floating point rounding errors are dramatically reduced, if not eliminated. On top of that, the func_instance entity exists only at compile time, and the top level map along with all instances can be easily collapsed into one .map file by an external tool (I'll get to this in a moment), so there's no need to modify the compile tools themselves. By the time CSG or BSP see the map, the instances have been collapsed and it's an ordinary .map file.

The good news is that the external tool I mentioned already exists: https://github.com/Metapyziks/VMFInstanceInserter

It's built for the Source engine, but I have my own personal version of the project that I've modified to support Quake maps (at least, the Valve 220 format). A custom Jackhammer build configuration runs this tool after exporting the .map but before passing the result to CSG. The tool does all the work of rotating/translating objects, fixing up variable names, replacing materials, etc. All you would need to do is allow the func_instance point entity to display the contents of the external file it's loading. That's not to say it's a trivial project, but a lot of the work is already done.

Some examples of the results:

http://imgur.com/a/D30Cx The glowing blue-green thing with the teeth exists in three places in my map. Its geometry, and the entities that allow it to light up when players approach, is only built once, in its own file. I place the three func_instance entities and specify a fixup name for each, and when players approach one of them, they hit a trigger that targets the fixup name, so only the one they're near activates.

http://imgur.com/LmrtTWl This is a more recent example. Each section of bridge there is an instance, built in another file neatly on the grid, allowing me to get a nice uniform curve to the center section. I place the func_instances, then rotate them into their final positions as seen in the picture. I can then continue to edit the section if I need to, without having to copy and paste the updated geometry all over again. 

Thanks for the response, but yeah, I'm on Linux... 

Where is JH's game config information stored? I tried making one for Quoth but JH won't keep the whole path to the pallette file. I was hoping that I could edit the source info and force it to do so.

Thanks! 

Please read the FAQ:
http://jackhammer.hlfx.ru/en/articles/1/faq.html 

 

Hey XaeroX would it be possible to support Enemy Territory in a future release (seen as you already support Q3) I am part of the team working on the new engine for the game and would love to have some good mapping tools available.. 

I'm not sure it is quite easy to add support for modern games. I still can't support HL2 because of such things as displacements, input-output system and stuff.
Q3 support was an intent since the first days of the development, and JH's renderer is actually optimized for Q3 shaders (Q1/Q2 and HL textures actually have in-memory representation as Q3 shaders). 

Sorry I mean Wolfenstein: Enemy Territory. Its idtech 3 (like Q3) and uses the same shaders (mostly) and also uses q3map2 to compile maps to bsp.

https://en.wikipedia.org/wiki/Wolfenstein:_Enemy_Territory
http://www.etlegacy.com 

Ah, ok.
Adding new game support generally consists of the following tasks:
1) Compiler(s) that supports mapformat 220 and is compatible with JH (q3map2 must be modified, unless you use the one shipped with JH; its sources are available in "quake3/src.zip", so you can diff changes and add them to any your custom q3map2 build).
2) Texture and model format specifications, to implement them within a plugin. The same applies to texture scripts (known as "shaders" in id tech 3) - new keywords, etc etc.
3) Entity definition file (FGD). Can be created as a modification of the existing quake3.fgd.
4) Game-specific editing features that can be implemented in plugins (e.g. "WAD extraction" tool for Quake).
5) Game-specific editing features that CANNOT be implemented in plugins and require modifications of the editor itself (e.g. q3's bezier curves).

So, please give me a detailed explaination of your needs according to the list, and I'll figure out whether is it possible to support your game, and how easy it will be. 

would be really nice too. I know Quark supports it, though I do not know which format the compiler uses. 

1) I created a custom q3map2 version for legacy to better support deluxe mapping (i also removed all the gtk dependencies since they were really just dead weight and the compiler is not a lot lighter and only a single binary)
2) Textures work the same way as in q3, in ET there's another model format mdc which is essentially a packed md3 ( the float values are packed ), but also md3 is used and both work the same way. There are some new shader keys for the new renderer which adds support for normal/displacement/etc effects but that is not really in use yet.
3) Theres an existing radiant definition for ET for that could be used?
4-5) Tank/Car route editor which is used to create the paths for the tanks and or cars (http://www.pythononline.co.uk/et/tutorial38.htm)

I might be totally forgetting something, but essentially the editing is very similar to Q3. 

First one is very simple: I'd love to order my visgroups properly. Just add up/down buttons to the
"Object Groups" window, or maybe make the items in "Groups" list draggable, so I can reorder the groups by hand. An option to order them alphabetically would be nice as well.

Second, I don't know why these dialog windows have fixed sizes. Having them resizable would be great.

Third: in Worldcraft, when I pressed Z over the 3D window, it "captured" the mouse and entered in "mouselook" mode, no matter what window was active at the moment. Now I have to activate the main window and then press Z. It has less usability.

Last: it would be nice to save windows state when the program exits. The load and save current window state buttons are not enough because I use two independent windows: one 3D and one splitted into top and front 2D views. I have to reorganize them every time I load the program. 

I think the color picker that gets invoked from various places is showing web colors instead of the standard Windows set. 

Looks like it, though it's not like it really matters as you can still choose whatever colour as well as add custom ones. 

Please make individual vertex manipulation steps undoable. The thing where you have to exit vertex mode and then undo the whole manip session is unsustainable. 

Please :) 

On the subject of undo transactions, I'd personally really like to see selection and deselection added to the list of possibilities. I'm constantly deselecting large groups of objects accidentally, but where Source Hammer lets me just hit Ctrl+Z to get the selection back, Jackhammer doesn't. I know your feature list is defined primarily by Hammer 3.5, but this is one thing I'd make extensive use of.

There's a similar situation with texture application. If I Shift+Right click a brush to apply the current texture to the whole brush, but then change my mind and hit Ctrl+Z, it only undoes one face at a time, even though the last action I took as a user was changing all the faces at once.

One final note, unrelated to Undo: I just found out that Rick Lipsey's map source, from the recently released func_mapjam 6, will crash JH if you try to go to the nailgun.

In the mod's "source" directory, load jam6_rick.map into Jackhammer 1.1.700. Go to Map|Entity report..., tick the "By class" checkbox, choose weapon_nailgun, and click Go to. The program crashes every time for me. I just sent an error report about this (though I'm not exactly comfortable sending desktop screenshots to strangers), but figured I should document it here as well.