|Posted by XaeroX on 2016/07/14 21:33:43|
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).
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:
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?
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:
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.
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.
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.
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?
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
You must be logged in to post in this thread.
Website copyright © 2002-2023 John Fitzgibbons. All posts are copyright their respective authors.