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.) 

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. 

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. 

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 

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... 

 

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? 

 

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. 

Unless of course you have UAC disabled then the only evil location is C:\Windows 

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...