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. 

For Windows there is no un-zip and run version, only an installer? 

I second that. I would love if there was a portable version. 

is there a way to paste a copied brush to the location where I right click and paste on the 2d window? 

No, it pastes to the center of the viewport. It doesn't do pasting as well as more modern Hammer iterations. 

It's not so much for portability, but to keep more unnecessary stuff from cluttering up the registry. Windows takes care of that well enough on its own.

I usually run a system restore afterwards if an installer has to be used but it would be nice to avoid that hassle, and even then a lot of software will continue to write trivial configuration data there instead of to a separate config file as it should. 

Most stuff you install, if not all, should really not need to write stuff to the registry. 

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.

This sums up to: hovering the mouse over a viewport window activates it. That would improve productivity a ton. I'm using a two window setup, and the need to click to activate one is driving me crazy. 

This sums up to: hovering the mouse over a viewport window activates it. That would improve productivity a ton.

so true 

>>hovering the mouse over a viewport window activates it.
It actually does, from the first versions of the editor. O_o
>> For Windows there is no un-zip and run version, only an installer?
No, the installer does a lot of configuration job so I recommend to use it.
>> The program crashes every time for me.
This bug exists only in 64-bit version and will be fixed in the next release. 

>>hovering the mouse over a viewport window activates it.
It actually does, from the first versions of the editor. O_o

It does if no other windows are open. If I open texture application an its window is currently active then I need to click on the window behind it to make Z work.