I see now the after comparing the .map files. My assumption that VHE and JH used the same system was wrong.
XaeroX Fixed the error. Used a different version of compile tools.

Found I was able to crash the editor by exporting to map. I can load the rmf from VHE into Jackhammer fine, works/compiles. If I load the .map and then export from Jackhammer crashes.
I sent that in to support.

Thank you for your help. 

Thank you for the archive. There was no crash on export, but a crash on import, and I've fixed it. You should check the new version of JH when it's available for further consideration.
Yes, because of the complexity it's impossible to compile your map with a JH's Q1 compiler. 

Just tried this, found it to be excellent.

However there is a small issue, for some reason the texture browser is only displaying white instead of textures, see this screenshot:

http://br0gspot.files.wordpress.com/2014/02/jh_tbrows.jpg

Everything else works fine so far... 

Great stuff so far, with one roadblock at the moment. Modern q2 clients can load in alternative texture formats (png, jpg), so it would be nice to be able to access these resources from JH.
I've modified the gamecfg.ini to bring these in, and the files are enumerated in the folder list, but they aren't accessible from the texture browser. 

If the authors of alternative clients want their support in JH, they may contact me and tell what they exactly need. There are billions of different Q1/2/3 forks, but I personally use none of them. :)
Or, alternatively, wait for Plugin SDK, because such support can easily be achieved via plugins. 

Fair enough :P

One non-extension request, then:
When pasting a brush in the x/y window, it should inherit the z of the origin brush. Right now, pasted brushes align to the center of the camera axis you are not pasting in. The same logic can apply to brush creation. 

Seeing the models is quite awesome in the 3d viewport. I like how as soon as you type a number on a "skin" key that it auto-updates the model. I wish the monsters could be animated though. I tried "frame" as a key but it didn't do anything to change it. The weapons spin though which is fantastic!

The only thing major feature missing now from this awesome editor is lighting preview in the 3d view. Ahh then I would never have to compile again lol. Dream on Qmaster, dream on. 

>>I tried "frame" as a key but it didn't do anything to change it.
Use "sequence" key. But animation is not available, because frames are changed by game logic. Internal sequences, i.e. "frame groups" (particularly, flame models) are animated correctly. 

A torus tool, or skew function? As it is, I have to go from GTKRadiant to Jack to work on curves pipage and the like. 

Well, torus is better implemented as a model.
What do you mean by "skew"? There is a third editing mode, "shear" (click the selection two times to activate it) - isn't it? 

Not seeing the models in the 3d port, and the console is full of "can't load *.mdl". What am I doing wrong? Otherwise, having a blast with Jack otherwise thus far. 

 

Hey I've just tried Jackhammer today for the first time and I must say I'm very pleased so far. Finally an editor that's not crashing every 10 minutes hurrahh. :)

However once I tried to compile a map , any map I get this:

>> There was a problem compiling the map.
>> Check the file D:\Steam\SteamApps\common\Half-Life\Firestorm\mapsop4f20.log for the cause.

It's compiling without making signaling that the maps folder is a folder \ <<< that sign is missing. What can I do as it appears I'm the only one suffering from this.

game exe: D:/Steam/SteamApps/common/Half-Life/hl.exe
base game folder: D:\Steam\SteamApps\common\Half-Life\

mod dir: D:\Steam\SteamApps\common\Half-Life\Firestorm

source dir: D:\HL Editing\current mapping\Jack


I'm using Vluzacn's ZHLT v33 compilers 64bit for Half-Life1. 

Nevermind I've solved it myself. I had to disable "copy file $path/$file $bspdir/$file.$ext

It's still weird as I have to click on that everytime I wanna compile something. Otherwise the error returns.

Also 1 request: Make make it possible to increase the camera turn rate. Perhaps build a new button within the options where you can accelerate the turn rate speed of the camera. At the moment it's so slow and steals time. 

I'm posting this here as a request to reach out to XaeroX, or whomever is the main developer of Jackhammer, for a one on one conversation in regards to Jackhammer, and a potential problem it seems to be having.

The details of this problem are big, and I don't want to copy and paste all of that onto here, which is why I would like to speak privately about it. If you could get in contact with me via email which is in my profile, or whichever way you are comfortable with, it would be highly appreciated. 

For those who may know what I'm talking about, I'll say it here. I'm leaving out a lot of details, so I'll just give the really condensed version and hopefully that will be enough.

I have a map, fairly complex. I save it in Worldcraft 1.6. Compile it, no leaks.
Same map, save it in Jackhammer. Compile it, multiple leaks passing through solid brushes (as well as many off point warnings in the compile log).

So what's the story here? 

all i can think of is floating point planes in the map file 

That would be my guess as well. Maybe upload the two map files somewhere so that we can take a look? 

How's it going?

Is there a plan for any more updates, or is the current plan to work work work and get it ready for full fledged release? As it stands, it's almost ready as is. Honestly, the only thing holding it back for me is the hotkey for Deselect (should be *SHIFT* plus Q in my opinion, not CTRL) but if a full release has support for remapping hotkeys then woohoo!!

Anyways, Jackhammer is now my goto editor for Quake mapping. I love it!

(P.S. There is some mysterious bug that causes the CTRL or SHIFT keys to become stuck on, at least as far as Windows is concerned. I've noticed it on both Win7 and Win8. How to reproduce: map like a fool. How to fix: *shrugs* it seems to fix after hitting the key a bunch of times while typing something in Notepad) 

And if the latter, what long term value does such an editor provide since the Quake community tends to outlast the lifespan of closed-source projects.

[Sure I hate to ask, but is very valid question looking at graveyard full of closed-source map editors of yesteryears's ...] 

>>How's it going?
Delayed a little, because I have recently switched to some other projects. But there will be new releases for sure. ^^
>>should be *SHIFT* plus Q in my opinion, not CTRL
Why? Ctrl-based hotkeys in "Edit" menu are standard de-facto. I don't understand why Valve (or whoever) decided to use a shift-based one.
>>graveyard full of closed-source map editors of yesteryears's
Opensourceness is possible. But actually I don't care. :)
The primary goal of the editor is to support my own game engine. But I'm grateful to the Quake community for the testing, of course. 

Very neat to see this!

Are there any plans to support saving .map formats older than v220 in the future, or is this unlikely to happen? (I've seen the v220 compilers for Quake1, but not for other Q1 or Q2 engine games) 

that the older .map formats don't support texture rotation in a way that works well, or at least not with accuracy. It takes a lot of fiddling around in a pre-v220 editor when you try to get alignment right in the more complicated parts. It's why QuArK was made from the start, to address texture alignment.

That's one of the reasons that I think explain why the original levels in Quake (and Quake II for that matter) were so blocky (and even then the textures weren't always... right). Try and do a simple five section 90 degree curved wall or arch in the original .map format and you will see what I mean. Sure you can get it to align simpler textures (or at least make it unnoticeable to the casual viewer) but it's not intuitive and what works one time may not work the next time.

I once abandoned an entire Egyptian themed map because a central area just wouldn't line up texture-wise no matter how much I tried to tweak it (hieroglyphics themed textures pointing to areas that you needed to go to next) and it just really messed up the entire feel of it. The WC 1.6 .map format just can't handle that fine level of detail. It wasn't written with that in mind. 

Best practice would be avoiding rotations or flips while using texture lock, and not modifying the world/face projection. (As these are the two spots that cause issues.)

It could be a nice feature to have for those who want to use the editor for a variety of older games though. (Like myself! Currently I use http://www.ogier-editor.com/mapconv/ to build levels in Hammer) 

I agree, however sometimes even that doesn't work out so well with the pre-220 .map format.

As long as you stick to the grid and keep it somewhat limited in angles, 99% of the time you won't have any issues at all. It's when you start adding things like arches, curved walls and so on that the older texture methods used pre-220 start to get misaligned. You can of course tweak them in most cases (or hide them by using flatter textures or textures where, by their organic nature, allows for mismatched faces) but I can't tell you how many times I've had to stretch, skew, rotate or otherwise tweak an angled surfaces texture to get it to match the one next to it and look right.

I suppose I was just too anal about that stuff to let what the player would probably never notice anyway to slide.