News | Forum | People | FAQ | Links | Search | Register | Log in
J.A.C.K. 1.1.1058 Public Beta Is Out!
Hi all!

Jackhammer has been renamed to J.A.C.K. because of copyright issues, but there is also good news: we've finally passed Greenlight. This means that J.A.C.K. will be eventually released on Steam (Q4 2016). Thanks everybody for support! Today we are presenting the last pre-Steam version with more bugfixes and improvements. Further, there will be two versions of the editor: the Steam one, commercial, with SteamWorks features and automatic updates, and non-Steam, completely free, although updated not very often.

New version highlights:

* Hexen II Support: now the editor supports Hexen II, the game based on Quake engine. There are compilers, FGD file and palette in the install package. Game configuration of the editor is identical to Quake's.
* VMF Format: now one can import and export maps in VMF format; this is a Source engine format. Although the support is still in beta mode, and not all the features are supported (e.g. the editor can't process Displacements), you can use the feature to transfer your projects between VHE4 and J.A.C.K., and also to include other utilities to the development pipeline (e.g. HammUEr - an UE4 plugin).
* User Cameras: now it is possible to place, move and delete user cameras, like in VHE. There is also an ability to load and save such cameras to JMF, RMF and VMF formats.
* Triangulation: a special command enables triangulation of non-planar faces that frequently arise during vertex manipulation. This helps to get rid of many "Invalid Solid Structure" errors, and to facilitate creation of curved columns and other complex geometry using vertex rotation tool. Simply triangulate your complex stuff after you're done. This command, along with others, is added to a new context menu in Vertex Manipulation mode.
* Incremental Save: a new version saving command automatically adds version number to the file name. Such behaviour is familiar to 3DSMax users; it enables easy creation of checkpoints during prolonged project development.
* Improved Entity Report: now hidden entities in "Include Hidden Objects" mode are marked in italic; also there are Hide and Unhide buttons added, to hide and show selected entities. Besides the dialog remembers last parameters entered, even between sessions.
* Advanced Patch Texturing: Naturalize and Set patch texturing functions now account not only for scale, but also for shift and 90-fold rotation (i.e. 0, 90, 180 and 270 degrees). Along with that, Set function now performs in "naturalized" mode, i.e. taking into account segment lengths. These features greatly facilitate texturing of curves in Quake 3.
* Other Useful Stuff: tabs in Texture Browser, ability to hide triggers and unknown entities, ability to "lock" texture axes in Scale Vertices operation during vertex manipulation, display of selection center in status bar, tear-off mode for submenus, support for deformVertexes autosprite and autosprite2 in Quake 3 shaders, and many more.
* Lots of Improvements: the new version traditionally contains lots of bugfixes and improvements in comparison with the previous release. The editor became much more stable and functional. Please view a changelog for the details.

This version supports Quake, Hexen II, Quake II, Quake III, Half-Life, Gunman Chronicles and their modifications.
Supported operating systems: Windows, Linux.
Supported architectures: x86 (32-bit), amd64 (64-bit).

Web page
Feature list
Changelog of version 1.1.1058


Again, thanks for suggestions and bug reports, some features were added because of your requests.
Excited to try this! The download does give me a false positive in the win10 virus scanner just for your information. Not sure if there's anything you can do about that?

The new vertex manipulation tools are fantastic and are something I have desperately wanted in JH for a long time. Thank you very much for adding them :)

I'll most likely be doing some level design with this editor soon-ish and can comment further once I've used it for more than 10 minutes :) 
I'll most likely be doing some level design with this editor soon-ish and can comment further once I've used it for more than 10 minutes :)
QExpo 2016 Jam confirmed, guys. 
This Is A Level Editor 
for everybody who doesn't know.

For a radiant only mapper, it looks exactly like wc from the screenshots. 
j.a.c.k. = jackhammer = worldcraft

I believe that worldcraft source was given to the community by valve when it transitioned worldcraft into hammer.

I think it was about version 1.6 or 1.8, and they had decided to remove classic bsp support? Others know the history better than me though. 
This is cool but what does the acronym stand for? 
Just Another Cute Kinn 
Just Another Craft K 
But seriously this editor is great! 
<quote>User Cameras: now it is possible to place, move and delete user cameras, like in VHE. There is also an ability to load and save such cameras to JMF, RMF and VMF formats.</quote>

Thank you man 
Did Valve pressure for the change? 
Please Take Note That Pre-220 Q1/2/3 Maps Can Be Imported Incorrectly 
Non-zero texture rotation becomes flipped.
This does not apply to latest RMF, JMF and VMF files, and map format 220.
I'll make a hotfix once the problem is fixed. 
just opened up and messing around with editing for the first time in probably a year

Is it possible to create two brushes along a clip plane rather than removing the part on the red side of the line?

also how does one create a new vertice? I could click two vertices and then right click to get an option in WC 3.3 but I don't see this option in JACK.

Either way looks awesome right now thanks for the hard work 
1) What do you mean by "creating along a clip plane"? You can create arbitrary brushes and then clip all of them by a clip plane.
2) AFAIR in WC3.3 there is no such option... Can you please explain more thoroughly how to invoke it? To create a new vertex in Jack, simply select two adjacent edges (yellow bullets) and press Ctrl+F. the face will be split between the edges and new vertices appear. 
Drew, for clipping, I think you want to keep pressing Shift+X to cycle through the modes, one of the modes keeps both sides of the clip plane. 
Hotfix Released: 1.1.1064 
Fixes bug with bad texture alignment after loading old-format RMFs and MAPs (non-220), and with disappearing of selection size info after copying and/or pasting. Please update. 
Is there any way to un-triangulate? I did triangulation but it made my brush concave... Now I can't rotate or delete this edge to make it convex again...

Is there any way to snap all vertices to grid or integer, like TB2 does? 
The triangulation tool is awesome, it's perfect for getting "phong" shading to work properly. Thanks. 
Plugins => Half-Life => Round Coordinates 
Seems to work fine for snapping to integer.
Still don't know how to un-triangulate (or un-split face)

Is there any way to write custom plugin for JACK? :) 
I've just been playing around in J.A.C.K. 1.1.1064 for a bit during Map Jam 7, and have noticed a few things:

1.) Is there any chance we could have an option to revert to the old Ctrl+Scroll wheel behavior? I can understand why easy grid size changes are helpful, but I've always found Ctrl+Scroll wheel to zoom all the 2D views incredibly helpful, and I find the bracket keys fast enough for changing the grid. I don't expect my personal preference to override everyone else's, but maybe we could have a checkbox somewhere?

2.) Also on the subject of options, would it be reasonable to request the ability to have entities' yellow bounding boxes, and entities' rotations, based on the size(minX, minY, minZ, maxX, maxY, maxZ) defined in the FGD? Currently the boxes are displayed, and the object sizes are reported, based on the bounds of the model, not the bounds of collision (even with "Draw models" disabled in the 2D views preferences), and rotation happens about that box's center, which I don't find as useful as I would the alternative. Snapping to grid already uses the FGD-defined center, which is good, but rotations don't.

I've also got a few notes regarding FGDs, if I may. Map Jam 7 is using the Quoth mod, version 2.2, and like many others I want to use both it and EricW's updated tyrutils compilers. Preach has an FGD for the former available on his website, and Daz has put together an FGD for the latter. Unfortunately, there are conflicts (leading me to combine them myself), and I have a few questions:

3.) Would you be willing to add sharing violations with regard to PAK files to the message window? In testing all of this FGD stuff I found sometimes PAK0.PAK from Quoth wasn't being loaded, but the message window didn't show any errors. In my stupidity I had opened the file in PakExplorer, forgotten about it, and proceeded to spend twenty minutes wondering why the file sometimes loaded and sometimes didn't. An error in the log might be helpful for dopes like me.

4.) Multiple FGDs can be loaded for a game configuration, and they're combined with conflicts resolved by having files farther down in the list override ones farther up in the list. This is sensible, but there doesn't seem to be a way to easily rearrange things. Arrow buttons, or clicking and dragging, something like that. I know removing and re-adding the FGDs isn't the end of the world, this is just a bit of polish that would be nice to have.

5.) As I mentioned, conflicts between FGDs which define the same entity are resolved by replacing earlier versions of an entity with later definitions, but this only happens with entire classes. Would it be feasible to have this happen at a more granular level? That is to say, if first.fgd has info_example_entity, and its only content is a key called "targetname", while second.fgd also has info_example_entity, and its only content is a key called "delay", I'd expect the result to be a version of info_example_entity that has both "targetname" and "delay". Currently the version with "delay" completely replaces the other one. In cases where the same key exists, you could do what you do now and just let the later version of the key override the first.

Finally, in assembling my own FGD for Quoth 2.2, I've come across some difficulties I'd appreciate some help with.

6.) Quoth has something called mapobject_grill, and two variations that use specific sprites. These sprites provide alpha-masked grate objects. I'm able to use sprite("progs/grill128.spr") to make the sprite display in Jack's 3D view, but it rapidly cycles through all the sprite's frames instead of sticking with the one chosen by the 'frame' key, even when "Animate models" is disabled. Is there a way to display only one frame, and synchronize what's displayed with what users have chosen? I see TrenchBroom has accommodations for that in its model() definitions, does Jack have anything like that?

7.) A similar question applies to the corpse_crucified entities, which use different frames of the same model as static props for level designers to place. Is there any way to dictate which frame of the model is shown in Jack? I can choose a skin with skin(X), alongside studio("progs/model.mdl"), but I can't figure out how to choose a frame, if it's possible.

None of this is critical for anything I'm doing, and I'm sorry to be such a pest with requests and dumb questions, but I wanted to get this out there in case there actually are answers I'm simply missing. 
I Second The Frame Specific Fgd Poses 
AD also has different frames for their candle for short, fat, tall, etc. 
TB2 Has Support For This 
Using an extended syntax for the model specifiers in the FGD. XaeroX, I think we talked about this before, but I'm not sure. Either way, if you decide to support this, let's talk and find a common format so that the FGDs can be used in both editors without changes. 
A Couple More Things... 
In addition to the "frame specific" options, I forgot to mention the desire to tie separate bmodels to certain keys' values or spawnflags. In particular, the health kits, which use separate .bsp models for the normal health, rotten health, and Megahealth settings inside of the item_health entity. I don't see a way to do that, currently.

I've also just stumbled over what I think is a bug: when an entity has multiple copies of the same key, but with different data types, the two keys are presented to the user in the Object Properties dialog as separate options, but have their values tied together.

In my case, the light entity used by Quoth is proving troublesome. The FGD I've been working on, as well as just the basic Quoth 2 FGD from Preach's site, have the base class Target defining a key called 'delay' that's of type "string", which allows Quoth entities to offer a delay before triggering their target entity. The Light class, which derives from Target (among others), defines another 'delay' that's of type "choices". Both show up in the Object Properties, which seems sensible since they're different data types and I imagine there should be no conflict (Quoth supports them both, if I understand correctly), but changing the value of one changes the value of the other. This behavior also prevents the "choices" version of delay, which is used to select lighting attenuation, from providing the dropdown list of options with user-friendly names.

I'd suspect it was my messing around with the FGDs that caused this, but since the standard quoth2.fgd shows the same behavior I'm led to believe it's a bug. Is this something that's possible to fix? 
Tricky To Fix 
I don't have a strong opinion on where to go with this but I can share some thoughts. First is why delay is a string in the Quoth fgd - which seems strange when you realise that it's actually a numerical field in-game. The reason is that you might want to set a non-integer delay like "0.5" or "2.3". In some map editors, your options for field types are "integer", "pick-list" or "string", and only one of those lets you put the decimal place in.

The other is who "owns" the delay field. It's actually a standard field in vanilla Quake which just got inherited into Quoth - although I might have added it to the Target class for consistency. It's best practice for fields which mean something to a compiler tool to be prefixed with an underscore (which avoids conflicts with QuakeC), but the use of delay like this does date back a long time. So tough call.

Perhaps a good fix would be to remove the Target class from lights, and just add the "target" field to the Light class instead? Lights don't actually have fully fledged targeting, they only use the field at compile time for directional lighting with an info_null, so the Target class is overkill and perhaps not appropriate. Yeah, that sounds alright actually... 
The Naming Convention Of Light Ents 
is very unfortunate.

I believe they were named that way because of compiler restrictions. If only people knew that prefixing with an "_" back in the day would have solved this little problem. delay, wait etc are daft names for the functions they carry out. 
Well In That Case 
Your idea sounds alright to me! I can't offer any intelligent commentary here, frankly, but if it works for you it works for me.

I only assumed the current class hierarchy was explicitly meant to work as is, and Jack was expected to provide users with both versions of the key. If the Target class is in fact overkill, removing it from Light and simply adding the target field by hand is easy enough, and would solve the problem in this case.

I'd still wonder if it's something Jack should allow in case of future conflicts, but I suppose now it's more of an academic question. If you decide to go with stripping the Target class from Light, I'll follow along with my own FGD and the point will be moot. 
Ya The Classes Are For Fgd Editing Convenience Only 
I went ahead and tried out your idea, Preach, and after testing it a little it seems to work just fine. Target works to let people define their spotlight target, and Attenuation has the nice dropdown menu.

Thanks for the advice! I'd never have figured out how to handle this otherwise. 
JACK Feature Request 
Export wad file pathnames to .map using forward slashes only, e.g. C:/QUAKE/wads instead of C:\QUAKE\wads to prevent compiler mistaking for escape characters. 
Quake Maker Project 
I've been wanting there to be a more user friendly way to make Quake levels closer to the spirit of Mario Maker. Something that includes the standard assets, models, like base doors that are hard to make, selectable attributes instead of using complicated integer flags while keeping the ability to manipulate, adding the compilers, places custom music and graphics and creates folders for you etc. Then, maybe an updated and more simple guide. Basically just try to think how easy Mario Maker is, but allow people to go further than that and do advanced brushwork. There may even be some basic low hanging fruit in QuakeC settings that could be built into the Quake Maker.

We could create a much bigger community of level makers if we could make things easier to understand and a tool that integrates the features. I'd like to focus more on level design instead of trying to break through the technical hurdles.

I don't know everything that is possible because I'm not an expert builder familiar with everything, but I think talking to some of those people, creating a list and then outlining a project would be the solution. I would then want it to get done and maybe we would have to create a fund to pay some open source developers to make it happen.

I see J.A.C.K supports windows and linux, but not MacOS, so I hope that MacOS is added and maybe the creator will be interested in pursuing the sort of vision I describe here. Trenchbroom is also an option, but I don't know who may be interested in doing this. I like the option to manipulate in 3D with Trenchbroom. 
And your evidence that there is a ton of people chomping at the bit to make quake levels, but put off because existing level editors are too difficult to use is.... 

I'm thinking of myself first and I'm already using the current editors and see a lot opportunity to add features to make the program more user friendly. So, even people of my interest and knowledge level it would help me a lot. I imagine that it would also open Quake up to a lot more people if such a program already exists and it introduced to them. 
So, you are basically asking to turn the editor into SnapMap/Deathmatch maker for the target audience of you. 

No, I don't think that would describe my vision.

I actually haven't used the SnapMap editor, but I did use Deathmatch Maker 2 for Quake 2 a long time ago and I have a good idea of what SnapMap is probably like.

The only Quake editor I have been able to get to work is TrenchBroom. It is possible that some of the features I would like are in other editors.

I would like drag and drop assets of the objects that are standard in the game though. It is possible a file could accomplish this if somebody has a map file with lots of these in there that could be copied and pasted out. Examples like base doors which I find hard to make because the way they split down the middle and line up with the texture and other common assets.

Some of the low hanging fruit is with the flags on objects, descriptions and compilers. It would be much easier to have drop down options instead of having to look up integers and set values and some prefabs to get people started that don't have the objects from previous projects would be helpful. Having EricW's light program linked along with the compiler would make the workflow much easier. Perhaps even getting people setup with creating pak files and game folders for custom sounds and graphics would be helpful so all that can be done behind the scenes and create a final distribution.

I don't want to have any limitations to edit brushes and do anything advanced, I just want to use a more user friendly program.

I might have to use J.A.C.K, so I hope J.A.C.K will release a MacOS version soon. 
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. 

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. 

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. 
Uhh... What? 
"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. 
This World Is Crazy... 
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? 
I'm Just Guessing, It's Not Official Explanation 
Yeah I Figured... 
...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. 
I Like Mapping With Jack 
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. 
Enemy/Model Placement Issue 
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. 
Couple Bugs 
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. 
Buggy GPL ID1 Maps Conversion 
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. 
@mk -- While The Iron Is Hot .. 
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, 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. 
Hello XaeroX 
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).


3. create a shape by extrusion along a path.


best (english) HL1 editing resources? 
One Is 
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.

@BaseClass base(SpawnFlags1, SpawnFlags2) = Test
(Only SpawnFlags1 will be shown in JACK.) 
Another Bug 
Flipping brushes (CTRL+L or +I) who have angled surfaces causes the texture to become stretched.

Adjusting a vertex on an angled triangular surface also causes the same effect, texture is stretched and no longer world aligned. 
FGD Source Compatibility 
The studio("progs/somemodel.mdl") format used by the fgd should be changed from studio to studioprop in order to provide compatibility with Source engine games. This will break any custom fgd's but I believe it should be done now so that going forward the same format can be shared across all games that J.A.C.K aspires to support. 
Feature Request 
Support for string data type in choices lists when parsing the fgd. Example format:
noise(choices) : "noise1" = [
"ambient/drone6.wav" : "Drone"
"ambient/riftpower.wav : "Hipnotic - Riftpower"
"ambient/rain.wav" : "Rain"

Currently only integer is supported. String would allow for any data to be entered. 
I have been chipping away at a tiny experiment in HL using JACK. I recently closed the file without saving. Now when I try to open it it tells me the file is corrupt.
I have no idea what caused this or how to potentially recover the file. Please let me know where to start - what info to provide etc.
Only spent a little bit on this so if its lost it isn't the worst thing, but I'm afraid of this happening in the future! 
in the folder where you saved your work you should have 5 most recent autosaves as well 
Thanks Daz... 
but can you clarify how I can access previous saves? Opening in JACK i just see jmf file.
opening in explorer I also see a jfx file.
I'll look thru the docs now... 
Change The Filetype Drop Down In The "File Open" Dialog 
Oh I See What Happened 
I had saved maps into one directory (half life/valve/maps) and a different one set in the options (half life/ maps) 
that's not it. That directory doesn't seem to have been created even though its specified in the options...? I would have had to create that one *not* in JACK? is that the issue? 
And What Filetype Are The Backed Up Files Going To Be? 
Make Sure You Run As Admin 
J.A.C.K misbehaves or doesn't update settings changes unless you run in Admin (on Windoze). 
J.A.C.K misbehaves or doesn't update settings changes unless you run in Admin (on Windoze).

Just curious, but why should that be necessary? I don't have any programs with that problem. 
It Installs To Program Files (evil Location In Windows) 
Unless of course you have UAC disabled then the only evil location is C:\Windows 
Works Fine Here 
Have you got the latest version? I know some old releases installed user-specific stuff to Program Files, but recent ones use a subdirectory of your Documents folder, specifically "Documents\\Jackhammer" for pre-Greenlight versions and "Documents\\J.A.C.K." since the rename. I just tested 1.1.1064 in Windows 10 and changed settings persisted, despite being a standard user with the most restrictive UAC options on and running without elevation. 
Also I just learned you need to manually escape backslashes to see them on this board's post preview page, but the published post does it for you so they end up doubled. Pardon my goofy looking paths. 
I never understood the logic of restricting programs installed in "Program Files" from write access anywhere but a few locations, while programs in "Program Files (x86) or directly in C: can do pretty much as they please. So much for security, eh? 
Last time I checked the Program Files (x86) directory had the same rules and limitations as the regular one, which seemed to be the case for others as well following a quick visit to el' goog.

And writing directly to the C:\ folder is hardly harmful. Ugly, perhaps, but last time I checked there's no risk from the user creating folders or files there. System files and subdirectories of the C: drive are protected individually... 
Did that get changed since Vista? I don't know, I don't use either one.

After I install something, I move its folder to another drive and do a system restore. If it won't run after that, I'll usually delete it.

Only exception is Steam and Steam games. They're on their own separate boot disk. 
Would This Be Useful? 
I mostly dabble with map making as I have always seriously struggled with creativity! But I was messing around with J.A.C.K. tonight and thought.. wouldn't it be a cool feature to have a "create brush with selected texture" button? In the Surface Properties dialog box?

Could automate the centering of the texture and place it "selected" and "centered" in 3D/2D view?

Pardon my ignorance if this is silly, just seemed like it'd be a time saver(windows/door/buttons etc).

Bug/Feature Request 
"f" toggles texture filtering in the 3D view. It would also be nice to toggle texture filtering in the texture browser at the same time. The texture browser defaults to that horrible texture blurring. 
Feauture Request 
I'm new to mapping, but so far (apart from some crashing) JACK seems to be about the best in class for editors, good job!

A small request - a spherical "effect radius" indicator/tool for entities which rely on a radius to determine their operation, such as env_sound and scripted_sequence/sentence (Half-Life).

The tool might draw a pale red globe in 3D and maybe a red circle in 2D, size based on the radius setting of the selected entity.

It would make determining the range of these entities trivial, in much the same way that trigger brushes have a clearly visible footprint. Currently it requires careful measurement and calculations in order to place these entities effectively.

BTW, thanks for adding "centre" to the bottom right co-ordinates display, that's so handy! :D 
Another Request 
Here's another one, when you select an entity a pale arrow appears in 3D and 2D views, starting at the origin and pointing in the "forward" direction of the entity, as set by its "angles" keyvalue.

This would make placing most oriented entities (squadmaker, scripted sequence, trigger_push etc) so much easier - you'd just plonk it down and spin the compass until the temporary alignment arrow is pointing in the correct direction, in 3D or x/y views. The arrow would disappear when the entity was de-selected.

Thanks :) 
Any Way To Export Maps NOT IN Valve's 220 Format? 
I can't find any way to do it. I just want plain ole quake standard map format NOT Valve's 220 format. Am I missing something in the settings to allow this? 
Using F4 Instead Of F5 To Export The Map Is Weird 
At least for the first time. I can't get used to it. 
I think it is only selectable in the game setup. Check your quake setup and see if valve map format is selected. Otherwise maybe copy that format and make a quake-orig profile or something. 
Yes, Thanks. 
I finally did find the option in the game config setup I overlooked. 
I'm Curious ... 
Have you added a way to move brushes that are grouped without ungroup them before?

After i updated to 1.1.1064 from 11700 (Win32), i kept finding brushes grouped with others that out of nowhere were moved a few units in horizontal or in vertical.

At first i thought that maybe was a mistake from my part, but i kept getting more, till i i got a leak and found out that a brush in a group i never touched much less ungrouped, in months was moved a few units in vertical, so it can't be a mistake from my part, except the only explanation i can think of is if you added such feature of editing inside groups.

I have also gotten always since i began using JACK times when one of the views i wasn't working in zoomed out a lot out of nowhere even though none of my fingers were even close to the numbers to zoom in and out and those are all the shortcuts i use, but i always thought that i was accidentally pressing some shortcut i didn't know of, but after what has been happening these last weeks, i am not so sure ... 
Ignore Groups (IG) 
Allows to move brushes in a group without ungrouping. Present in VHE since the very beginning (AFAIR) and in JACK too, of course. 
Zoom Jumping 
Don't bump the numpad. It instazooms to different levels. 
Cascaded Groups 
Is this possible?

This would be more flexible than Ignore Groups. Click on a group in the 3D view to select it, and each subsequent click would select a subgroup, all the way to individual brushes. 
FYI About Ignore Groups(ig) 
With this feature enabled brush entities will not show their properties in the Object Properties window. 
They do show properties even in the IG mode.
But! You can't select them. That's the point. 
Out of interest did you see the feature requests I posted in post #53 of this thread?

I just re-read them and realised I didn't communicate #2 well, it should read: The ability to snap a vertex along the edge of another brush, rather than to grid.

Is there any chance we might see some of these included in a future version? 
I Have Version 1.1.1064(64 Bit) 
Maybe a different version does but this version does not show properties, only the Visgroup tab. Which is fine, I understand the point.

I only brought it up to let people know in case they forget and leave it on, like I did. Had me scratching my head for a few minutes, hehe. 
could you change it back to use the bounding boxes sizes for entities that come with the .fgd? Right now it uses as boxes ones that are the size of the model, but the collision boxes are different on most cases which makes harder to map as you do not know if they fit where you put them or not or if they are in the right position for something. They are also sized in xx.xx numbers.

Ignore Groups (IG)

Allows to move brushes in a group without ungrouping. Present in VHE since the very beginning (AFAIR) and in JACK too, of course.

Then its definitely not that what happened to me. If it were it should have been happening for years, not when i updated the program. Also pressing by mistake ctrl+Shift+W is near impossible, taking into account i don't use any of those keys at all in JAcK or Hammer.

I will investigate more into the matter and come back.

Zoom Jumping

Don't bump the numpad. It instazooms to different levels.

Whats that? Looks like it does match the second problem i reported, but I searched around in JAcK and could not find anything similar. 
Vote On Greenlight For Game Whit Jack Support ! 
Selection Issue 
So I'm running J.A.C.K. on a laptop, and all seems fine except trying to select a brush or object within the 3d or 2d view will freeze J.A.C.K. for a few seconds, then finally selects the desired object. It also freezes for the same amount of time when deselecting an object. Everything else, including manipulating objects, resizing, texture application etc is instantaneous as it should be.

I'm running JACK 1.1.1064 on Windows 10, Intel GPU and CPU. All configuration settings are correctly configured for Quake. Any idea on what could be the issue? 
Have you tried disabling hardware acceleration? 
There is no hardware acceleration. 
I Got The Same Thing... 
It makes selecting multiple vertices quite irksome. :^( 
Jedi Outcast/Jedi Academy Support ?? 
Hi, really neat engine you've made here. I'm hoping to use it instead of GTKradiant for jedi mapping.

So my question is wether you're planning on adding official support for Jedi Academy in your editor?

I don't think it should be that difficult since it's basically built on the Q3 engine.

I know that there's unofficial support on moddb to add JA to the editor, but it isn't as good as official support, the maps take a long time to load and the editor gets stuck often.

So if you could please add official support for the Jedi Academy game, that would be awesome!

Keep up the good work :) 
So MalwareBytes keeps tagging the JACK exe from Steam as having generic ransomware in it ... what's up with that? 
The last reply by XaeroX was in January. 
Ask In The Steam Version Thread 
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.