You mean "@WorldClass"?
Well, it was added just in case in some engines worldspawn class will be named something different.
It will be nice, if not support FGD extensions of each other, at least parse without errors, silently ignoring them. 

No, I mean "@Main". I can't find it right now, but there was an FGD file that had such a class and I assumed that was a JH addition. I suppose I was wrong. I haven't come across an FGD containing "@WorldClass" yet, but it sounds like a good idea provided there are such engines. 

It seems that Jackhammer isn't freeing memory resources for the current mod when closing the file. When I have my quake map loaded, it uses 277MB but when I close it it doesnt free up that memory. FYI. 

Of course it doesn't free memory. Why should it?
Most of the memory is eaten by textures, and no one wants them to be unloaded and then precached again for each map opened. Instead, JH doesn't unload them until the editor itself is closed. As for the map geometry it is certainly freed upon closing a map. 

freed memory often isn't returned straight to the OS, either - applications just hold the pages until they need them again. 

Ok, I just tried and I can confirm this setup does NOT work:
@PointClass base(Appearflags, Targetname) studio() size(-16 -16 -16, 16 16 16)
= misc_model : "Custom Model" [
mdl(studio) : "Model to load"
]
It just displays a bounding box.
Replacing "mdl" with "model" works, but that's not an option.

This is in Jackhammer 1.1.855 64-bit 

Have just tried exactly what you wrote. And it worked! O.o.
http://pix.academ.info/images/img/2016/01/19/5f36552215aef482639e59999eb88585.jpg

Are you sure you don't have another misc_model defined in other FGD or earlier? In the case of duplicates JH will use the first definition. Please rename the entity to misc_model2 and check whether it helped. 

It must be that the .jmf format stores the rendermodel and doesn't bother refreshing it when the fgd is updated.
All my old misc_models had the bounding boxes, but then I noticed any new ones I made correctly showed their models. I selected all my old ones, changed them to some other type, changed them back, and now they all work.
So yes, the fgd entity studio() setup you posted works correctly. 

Oh yes, specific key overrides are stored in JMF, I forgot that, sorry. 

When checking for map problems, if I use an entity not defined in the fgd and give it a targetname, any entities targeting it will give an error: "Unmatched 'target' field ('name')" Would be nice if the editor would check all key|value's for the 'targetname'. 

Unfortunately it is not possible after I've got rid of hardcoded keys. Editor doesn't know what is it - "targetname". It searches for matches between target_source and target_destination FGD fiels. If an entity is not defined - it is assumed it has no targetname, target, model, scale, rendermode etc. 

I have a request that will enable some Quake hacks but doesn't harm the editor.

In the Entity Report window, entities should be sorted by the user. The grid is sorted by entity class today, but it should also be sorted by name and target if the user clicks columns titles.

And best of all: there should be Up and Down buttons, so the user sort the entities manually. What for? The Quake MAP exporter would write the entities in the order they appear at Entity Report window. Then some Quake hacks would be possible and better controlled (ask Preach).

The entity list order should be saved in the JMF file, so the customized order don't get lost. When you open a map (JMF or MAP), the Entity Report window would be populated following the order the entities appear on it. So, the entity order only changes on user command.

This functionality wouldn't harm other games and would be useful for ones where entity order is important.

See? It's so easy! I just have to write all this down and keep bugging you about it. 

The latest version of JH sometimes messes the texture information on faces after rotation. That causes light (latest ericw's) tool to interrupt. This issue can be fixed by finding such faces (they look like the texture is overextended there) and selecting world or face checkbox there. 

That's not really a bug report. They can't do anything with that. Are there repro steps they can use to see the bug happen reliably? 

I can't say there's a 100% way to reproduce that, but the most often ii happens if you have a brush with a non-rectangular shape that has a face with UV-lock aligned texture (the latter is not nesessary). Then I clone such brush using shift+drag and rotate it 90 degrees using handles (fixed 15-degree rotation). Then I repeat these steps with each cloned and rotated brush.
Texture lock is on, scale lock is off, UV lock is usually off.

This is also the WTR that Y-scale of UV-lock aligned textures somehow changes when cloning and rotating brushes that probably causes all other problems. 

If you check for problems those faces should be listed as having bad texture coordinates or something. 

You set the texture to be projected directly onto this face first, then you rotate the face but not the texture projection, which leads to the texture coordinates being co-linear, which leads to light not being able to create a lightmap page for it. 

That I think toggles between if it uses world or face projection by default. Try pushing it?
I think that's what it does anyway? 

If that button works when rotating brushes and not only when creating them. Need to check it.
I often see that cloned rotated brushes loose both world and face checkboxes on its faces. 

For the record, I've seen this error as well but never had enough info to report it. I generally run the map check and auto-correct them all. 

Feature/Bug:

Please make it so brushes don't lose their grouping if I clip them.