Being able to quickly iterate then export would be a huge boon.
That doesn't excuse the piss poor tools. Also heavy reliance on 3Rd party programs kind of misses the point of an all in one game Dev environment.

I guess I really disagree with your views 

With all due respect, Lunaran, I could not disagree more. A while back I posted a comment with some thoughts about this on Joe Wintergreen's video regarding the topic: https://www.youtube.com/watch?v=b64lKqbbaUM But I'd like to elaborate.

There's a difference between "building BSP architecture" and "using BSP-style tools to build mesh architecture". HammUEr does the latter, from the sound of things. No one is advocating a return to BSP brush based engines, only that simple, intuitive, accessible tools like those found in Hammer be made available in modern editors. Hardly a non-trivial development task, but with million-instance foliage rendering and hundred-square-mile procedural terrain handled so well, I'd think this is comparatively straightforward.

For more than a decade I've heard your arguments thrown in my face with an eye roll and exasperated sigh every time this comes up, and they're just as insulting now as they were ten years ago. Working with 3D applications is as sluggish as ever when you have simple, low end needs like mine.

It's like a tractor trailer: When you're a professional driver, delivering tens of thousands of pounds of food to a supermarket from a distribution center, the vehicle makes sense. You have extensive training, and the trucking company handles operating costs and maintenance. But when you're an individual who just wants to take his family to the grocery store to pick up a few things for dinner, a minivan is the better choice. The commercial truck holds much more cargo, much more weight, is engineered to a higher standard, and will go for literally millions of miles when properly cared for. But the thousands of dollars a week in fuel, the vehicle height, weight and turn radius limiting the roads one can travel, noise and idling ordinances, and difficulty of parking make the vehicle wildly impractical if you don't need its power. You're not simply ABLE to use its capabilities, you're OBLIGATED to.

A more fitting analogy, though, might be "Why do you need Blueprint? Do all your game logic prototyping in Visual Studio! In fact, forget high level languages like C++ and do everything in Assembly, that gives far more power."

We're not earning crane operator licenses, we're not joining the military, this isn't some delicate responsibility you risk handing over to people who might get someone killed through lack of professionalism. Exclusivity of game development as a whole, or even just mapping as a part of that, to only the handful of elites who can work in The One True Way is not something I'm comfortable with. I don't care if Bob Ross' students only paint "motel art", they are and should be able to create simply because it makes them happy, without having to get an art degree before being granted that privilege.

I understand how the tools came to be the way they are, and if they're only ever going to be targeted at professionals, or aspiring professionals, there's no problem. But with engines like UE4, Unity, and Source 2 (which I might add seems to do things the way I want, see the Dota 2 Workshop Tools Alpha version of Hammer for reference) being lowered in cost and opened to a wider audience, I don't think it's unreasonable to suggest less professional people could have a bone tossed our way with regard to polyhedron editing interfaces. 

BSP is invaluable for prototyping and white boxing levels before going into the meshing stage. That's been the standard for years ... so anything that helps with the building of BSP is still useful! 

When selecting a object and then opening the texture application tool in "Align to view" mode, make the alignment be applied to the whole selection at one.

Currently, Jackhammer ignores the selection and only aligns a single surface. 

"at one" = at once. Autocorrect fail. 

Select as many faces as you wish, and then hit Ctrl+Shift+A.

I'm not going to convert either Trenchbroom or Jackhammer to UE4. :) Although I appreciate the quality of Unreal engines, I'm still developing my own, and the primary goal of JH is to support it. That is why it now supports lots of wysiwyg features, like animating effects, skybox rendition, etc. Support of these features in Quake/Half-Life/Quake3 is, well, a kind of side effect. :) 

When will you create the Volatile Engine thread here at Func_? I wanna try it. 

Well, at least when there is a playable demo version/ :)
However I think most people here are not interested in amateur engines, since it is a Quake-related website. JH itself is another matter because it supports Quake. 

I am all interested in amateur works (or else I wouldn't be doing some of my own) and hope to hear from your engine soon. I'm sure there is room for a Volatile II thread here (how about an "other engines' thread). 

yeah not sure how you got that impression. if it's vaguely quake-like, i'm sure someone here wants to read about it.. 

I'm curious, but does Jackhammer have the ability to also save maps in the old format, or only in the v220 format? 

Sorry, it is not possible. JH operates with texture axes, and there is no way to save them in the old, very limited format. 

Unity has Probuilder. Here is nice overview:
https://www.youtube.com/watch?v=Xgt-a6-1Y3c

...and Here is newer demo
https://www.youtube.com/watch?v=Kjqx6cKUepc

I have heard Unreal will get it too!

To not OT too much, i wanna say i love Jackhammer <3
I would love to see some brush boolean operations :) 

Thought I'd ask again, good to know. I hadn't realized that the compilers included with the Jackhammer install had been updated to handle the 220 format.

As Jackhammer already supports texture paths and surface flags, I've updated MapConv to be able to convert maps created with it back into the old format as well.


One thing I have noticed while using Jackhammer is some strange texture alignment issues. After applying a rotation to a texture, moving or copying the brush causes the rotation to flip (this is without texture lock enabled). Changing the textures rotation again causes further issues.

I've attached a sample below:
http://www.ogier-editor.com/files_dod/Jackhammer_Rotations.jpg

1 - A texture on a brush surface is given a rotation of 20'.

2 - If the brush is moved (in this case I nudged it one unit to the side) the rotation then appears to be flipped to -20', although the surface properties still list the original 20'.

3 - If the rotation is changed again (in this case setting it back to 0'), it then looks as if the texture has been rotated -40'. 

Loving Jackhammer so far. Finally got around to setting it up yesterday after worldcraft wiped all my _color light settings.

Question: How do you create new cameras in JH? The default one always starts out in the middle of nowhere (probably the world origin or something sensible like that but whatever...) for me and so I have to navigate it to a sensible spot before I start mapping.

Idea: How about a button to switch doors/lifts/etc. to their "open" position, not only to preview what they'll look like in-game but to allow easier texturing access to faces that they may be covering? When "open" they could be faintly grayed out, and selecting them in the 3D view could switch them back to "closed" for the duration of the selection to avoid weird situations where people try to edit them in the wrong position. The more I think about that the more complex it gets in my head so probably not such a fab idea, but it would be pretty cool if it was doable! 

The editor cannot possibly know about the code that lies behind entities, and has no way of knowing what a "door" is. Just either temporary move the door to the open position yourself or just hide it? 

That's a cool idea, actually. 

It COULD given the right meta data ... Plats, doors, etc are all just simple linear moving entities. 

I remember from my very early attempts at Quake 3 editing that at least one version of Qeradiant (2.02 maybe) could animate func_train entities.

I don't recall whether it was a built in capability or a plugin of some kind and I don't remember if it was limited to func_trains or if it could animate other moving entities also.

So at least it's possible. 

But you're talking about a Quake-specific (at least iD dedicated) editor. Jackhammer is not. 

What game does it support that isn't derived from Quake?

Anyway, it's easy enough to just disable something that's not available for the game currently being edited. 

Make the camera start near the player's spawnpoint, when available.

Also, XaeroX, can you add an option to limit camera rotation to multiples of 15 degree angles? 

"Make the camera start near the player's spawnpoint, when available."

I'd rather it remember where the camera was the last time I had that map open.

"Also, XaeroX, can you add an option to limit camera rotation to multiples of 15 degree angles?"

Wat? 

An option similar to the "Default to 15 degree rotation", but for the camera.

Also, it would be nice to be able to drag the camera in the 2D views.

And good idea about storing the camera position in the .jmf file. 

An option similar to the "Default to 15 degree rotation", but for the camera.

https://www.youtube.com/watch?v=PEZWYXPvmS8