You do realise you can just maintain a "prefabs" map file and just copy n paste bits over into your working map as required, right? 

Oh just read your post where you say the same actually. 

You can submit your ideas as feature requests for TrenchBroom on github and I'll consider them. I'm always open for ideas on how to make it easier to use as long as they don't get in the way of power users. 

Kinn,

Yes, I've thought of doing that, but I don't have such a file. I've thought of asking around if somebody has one or could make one for me. Also, I've had a lot or problems with TrenchBroom crashing when I try to open two map files. I think TrenchBroom is great though because it supports MacOS and lets you manipulate things in the 3D view window. 

SleepwalkR,

That is very kind, thank you. I have some ideas. I also suspect I could come up with a better understanding of what is possible by talking with an advanced mapper to generate more ideas. 

"Jackhammer has been renamed to J.A.C.K. because of copyright issues"
Seriously? Isn't jackhammer a common noun, like car or refrigerator? And isn't J.A.C.K. trademarked by Monolith, you know, as in Contract J.A.C.K., the game set in the No One Lives Forever universe? 

Jack Hammer aka J.A.C.K. was greenlit on Steam. I guess they asked XaeroX politely to rename it, to avoid misunderstanding what is Valve's Hammer and what is Jack Hammer. 

So to avoid copyright issues they're creating a new one? Boy, that's rich! While they're at it, why don't Valve ask the world politely to find new words for hammers, valves and steam altogether? 

 

...but the saddest thing about it is that you're most probably right. 

Anyway it would be a trademark thing, not a copyright thing 

Copyright, trademark... it's basically the same thing under a different guise. 

Suggestion: In camera mode you can use pgup/pgdn to cycle between multiple cameras. I can't see any reason for why the same keys shouldn't cycle through cameras outside camera mode as well. I don't think they're bound to anything else. 

I've been having issue with precisely placing enemies when the 3D model is visible. The selection box wraps to the size of the model rather than the defined bbox in the fgd. This makes placement difficult as I can't tell whether the enemy is partially inside a brush or not, especially for non-symetrical enemies like the ogre. I find that its better to turn the 3D models off so I can see the bbox for proper placement. Would be nice to have the selection box match the bbox. 

Brush Selection Not Recalculating After Clipping: After clipping a brush, when switching back to the selection tool, the outline box and handles are still at the pre-clipped size in the 2D views.

Undo Shift-Right Click Texture Apply Does Not Undo in One Step: After applying texture to all faces of a brush with Shift+RightClick, it requires an Undo action for each of the faces instead of only one undo.

Not sure if this is one:
Alt+RightClick to apply texture along same angle as selected face causes face to have neither Face or World check box ticked but only if the face is greater than 90 degrees rotated away...example, select bottom face of a pyramid then Alt+RightClick onto one of the upper faces of the pyramid then select that face to see that it is not using either alignment. Texture is also stretched weirdly. 

I've finally figured out why it's been nearly impossible for me to get most of the GPL vanilla maps to compile.

If I simply open up one of those .MAP files in Jack and try to compile it, Jack will generate and export a different .MAP file in the same place of the original .MAP file, overwriting it.

These different .MAP files seems to be in Valve's 220 format, and for some reason this makes them generate many leaks when compiling.

Compiling the unmodified GPL vanilla maps manually works perfectly, all I have to do is edit them manually with a text editor to update the "wad" field. This way, the latest TyrUtils can compile even E2M2, which the old compilers from Worldcraft couldn't compile.

I don't know if the problem is with the compiler treating the 220 format differently, or if Jack actually modifies some of the values when converting the GPL maps. But I've also tried using the BJP compilers and the Worldcraft compilers, and all of them had the same problems when compiling the versions of the GPL maps exported by Jack.

The fact that Jack was overwriting the original GPL .MAP files made me think that the problem was in them, but it isn't. 

Why not actually identify a single brush that was right BEFORE opening in Jack and a brush that was wrong AFTER saving it. The .map and .map 220 formats are nearly identical.

Posting the text for that brush (BEFORE) and the text for that brush (AFTER).

(Right now you have identified symptoms, but have not drilled down to identify a specific problem --- which would make it easier for them. IF -- in fact -- it is a JACK problem, but I think you've shown evidence that it is). 

Baker: Leaks doesn't belong to brushes. Leaks happens between two or more brushes, so it would actually be a matter of finding all brushes related to a leak.

Plus, Jack reorganizes the brush data upon exporting, which makes it even harder to identify the corresponding brushes.

This is the beginning of the original E1M1.MAP:
{
"message" "the Slipgate Complex"
"wad" "gfx/base.wad"
"classname" "worldspawn"
"sounds" "6"
"worldtype" "2"
{
( 448 -320 64 ) ( 448 -384 64 ) ( 448 -384 0 ) SLIPBOTSD 0 0 90 -1.000000 1.000000
( 512 -320 64 ) ( 448 -320 64 ) ( 448 -320 0 ) SLIPBOTSD 0 0 90 -1.000000 1.000000
( 512 -384 64 ) ( 512 -320 64 ) ( 512 -320 0 ) SLIPBOTSD 0 0 90 -1.000000 1.000000
( 448 -384 64 ) ( 512 -384 64 ) ( 512 -384 0 ) SLIPBOTSD 0 0 90 -1.000000 1.000000
( 448 -384 64 ) ( 448 -320 64 ) ( 512 -320 64 ) +0SLIPBOT 0 0 0 1.000000 1.000000
( 512 -320 48 ) ( 448 -320 48 ) ( 448 -384 48 ) SLIPBOTSD 0 0 90 -1.000000 1.000000
}

This is the E1M1.MAP exported by Jack:
{
"classname" "worldspawn"
"message" "the Slipgate Complex"
"sounds" "6"
"worldtype" "2"
"mapversion" "220"
"wad" "C:\Dev\Tools\WADs\quake_shareware.wad;C:\Dev\Tools\WADs\quake_registered.wad;C:\Dev\Tools\Jackhammer\adib.wad;C:\Dev\Tools\WADs\mankrip_original.wad;C:\Dev\Tools\WADs\mankrip_id1_colorkey.wad;C:\Dev\Tools\WADs\mankrip_pak0_colorkey.wad;C:\Dev\Tools\WADs\ironbase.wad;C:\Dev\Tools\WADs\dopa.wad"
"_generator" "J.A.C.K. 1.1.1064 (vpQuake)"
{
( 512 -320 64 ) ( 512 -320 48 ) ( 512 -384 64 ) SLIPBOTSD [ 0 0 1 0 ] [ 0 1 -0 0 ] 270 -1 1
( 448 -384 64 ) ( 448 -384 48 ) ( 448 -320 64 ) SLIPBOTSD [ 0 0 1 0 ] [ 0 1 -0 0 ] 270 -1 1
( 512 -384 64 ) ( 512 -384 48 ) ( 448 -384 64 ) SLIPBOTSD [ 0 0 1 0 ] [ 1 0 -0 0 ] 270 -1 1
( 448 -320 64 ) ( 448 -320 48 ) ( 512 -320 64 ) SLIPBOTSD [ 0 0 1 0 ] [ 1 0 -0 0 ] 270 -1 1
( 448 -320 48 ) ( 448 -384 48 ) ( 512 -320 48 ) SLIPBOTSD [ 0 1 0 0 ] [ 1 -0 0 0 ] 270 -1 1
( 448 -384 64 ) ( 448 -320 64 ) ( 512 -384 64 ) +0SLIPBOT [ 1 0 0 0 ] [ 0 -1 0 0 ] -0 1 1
}

See how the order of the data was completely changed in the first brush.

Also, the order of the brushes may have also changed. This is a brush from the original file:
{
( 304 192 16 ) ( 304 136 16 ) ( 304 136 0 ) TECH08_1 0 0 0 1.000000 1.000000
( 320 384 16 ) ( 304 384 16 ) ( 304 384 0 ) TECH08_1 0 0 0 1.000000 1.000000
( 320 136 16 ) ( 320 192 16 ) ( 320 192 0 ) TECH08_1 0 0 0 1.000000 1.000000
( 320 192 0 ) ( 304 192 0 ) ( 304 136 0 ) TECH08_1 0 0 0 1.000000 1.000000
( 288 336 16 ) ( 320 336 16 ) ( 320 336 0 ) TECH08_1 0 0 0 1.000000 1.000000
( 288 336 16 ) ( 288 384 16 ) ( 320 384 16 ) TECH08_1 0 0 0 1.000000 1.000000
}

And this is a brush from the same position in the exported file:
{
( 320 384 -0 ) ( 320 336 0 ) ( 320 384 16 ) TECH08_1 [ 0 1 0 0 ] [ 0 0 -1 0 ] -0 1 1
( 304 384 -0 ) ( 304 384 16 ) ( 304 336 0 ) TECH08_1 [ 0 1 0 0 ] [ 0 0 -1 0 ] -0 1 1
( 320 336 16 ) ( 320 336 -0 ) ( 304 336 16 ) TECH08_1 [ 1 0 0 0 ] [ 0 0 -1 0 ] -0 1 1
( 304 384 16 ) ( 304 384 -0 ) ( 320 384 16 ) TECH08_1 [ 1 0 0 0 ] [ 0 0 -1 0 ] -0 1 1
( 304 336 16 ) ( 304 384 16 ) ( 320 336 16 ) TECH08_1 [ 1 0 0 0 ] [ 0 -1 0 0 ] -0 1 1
( 304 384 0 ) ( 304 336 0 ) ( 320 384 0 ) TECH08_1 [ 1 0 0 0 ] [ 0 -1 0 0 ] -0 1 1
}

There's very different values between both versions. I'm not an expert on .MAP files, but this doesn't seem to be a straightforward task. 

Between the maps from all 4 episodes plus end.map, only E1M4, E3M7, E4M4 and E4M8 had leaks when compiling the original GPL sources directly. E1M2, E2M3 & E3M4 have missing textures, but compiled fine along with the rest. 

I've compiled the DM maps directly now, and only DM2 had leaks. DM7 has missing textures, but compiled fine. 

I'd like to suggest some features that I think would be a great for jack to have.

If these already exist and I'm derpy, then I apologise.

Three things that I think would help immeasurably are:

1. being able to select an objects center of rotation, specifically the vertex you want to rotate it around.

2. allowing me to snap a vertex to another vertex location (rather than to grid).

and

3. create a shape by extrusion along a path.

thanks

:) 

best (english) HL1 editing resources? 

http://twhl.info 

thats about the only one I've found... 

Something I noticed is that if an entry in the FGD inherits spawn flags from more than one other class, only flags from one appear to be shown in JACKs properties window.

e.g.
@BaseClass base(SpawnFlags1, SpawnFlags2) = Test
(Only SpawnFlags1 will be shown in JACK.)