%.3f might be not enough precise in case of aligning big models
Though snapping with reasonable epsilon would be nice, if other means wont work.

Thanks for fresh idea about "origin" key, will be okay for tmp workaround (TM).
Actually group entities can use origin key in editor and in games, but this is rare case, it seems. 

https://goo.gl/UyXRUJ

binds...
* ctrl + e: ExpandSelectionToPrimitives (select group entities w/o parent node)
* ctrl + m3 texture painting by drag
* Tab + mWheel in freelook: offset focus distance with dist2origin/8 step; exponentially, if moving far away
* m2 drag in cam = sideways+updownways strafemode; do not enter/quit freelook, if long button press (>300ms)
* m1 drag in freelook = sideways+updownways strafemode (mainly for visual editing)
* ctrl + m3/drag = seamless brush face to face texture paste; works for any faces in BP mode, only axial ones in AP
* ctrl + shift + a: select all visible brush faces and curves, textured by selected shader
(more obvious way, than existing ones: components mode::faces->shift+a and find/replace to empty)
* shift during creating brush = quadratic brush
* drag clipper point + shift = constrain to axis with biggest move amount

menus...
* view->show->Entity boxes (always show bbox for ents with model)
* Misc->Colors->Themes->Blender/Dark color theme

Misc...
* fix: QNAN texture projection after scaling cuboid on Z axis (brush primitives + texture lock)
* preferences->display->entities->Names Display Distance (in cam) def = 512u
* always show selected/childSelected entity names (unselected is optional)
* fix: mouse texture grab/paint commands ignore filtered faces (caulk filter)
* fix name case sensitivity in shaders (non plain textures) loading during map/model loading
* all patch prefabs are created aligned to active projection
* preferences->display->entities->Names Display Ratio (2D): hide names, if view_size/bbox_size > value; def = 64
* surface inspector: renamed poorly named Axial button to Reset
* arbitrary brush texture projections in brush primitives map format: axial, from ortho view, from cam
* frame 2 frame time render stat
* renamed confusingly named command GroupSelection to RegroupSelection
* fix: changing clipper color via theme loading doesn't require restart
* fix: changing CameraSelectedBrushColor, SelectedBrushColor don't require restart
* -gamedetect command line option to enable game detection
* don't disable aero by default; -aero command line option disables one
* "Don't show" (during session) checkbox in Light Intensity dialog
* fix: show-grid toggle hides grid, when snap-to-grid is off too
* region mode: draw out of region part of grid in subtle style
* restrict unwanted angle(s) keys commits on moving generic, eclassmodel, miscmodel entities
* reverted angle(s), origin, scale entity keys save format from %f to %g
* fix uniform rotation operations for generic entities with angles key
* use more precise meth for rotating point entities with only angle rotated
* snap tiny inaccuracies in angle(s) and origin point entities keys
* workaround: don't discard empty group ents, having origin key
* entity class convertion: prevent converting worldspawn; prevent converting point entity to empty group 

This looks, like autoconverted from fgd w/o correct model key handling
Correct syntax in def is:
model="progs/mon_hknight.mdl"
find/replace :)

Great, thanks :)

I also have a feature request. I think it would be a big texture alignment time-saver if you could select a face, and an edge, and then have a command to automatically rotate/align the face texture along the selected edge - possible specifying what axis of the texture to align along the edge (e.g. align horizontal or align vertical) 

I agree, something of that sort would be fine, custom texturing opportunities were always nearly nonexistent in radiants.
Described setup is quite complex, best thing, i can imagine around this, is uv editor with nifty snappings, like in trenchbroom.
Other (more simplistic and usable for mass processing) idea was a button to toggle through edges, aligning to ones; though texture has two axes, so two buttons :) That would be possibly cool, just have no idea, if i can handle related meth, one is black magic for me, tbh.
But after all, when got it aligned, you most likely would like to scale/shift to match other edges, while keeping align to initial edge; that is work for uv editor for sure 

niger - ah, it seems you have a good sensibility for the issue. If you do ever get around to a solution it would be very much appreciated here :)

I mentioned my idea because it's already possible in the editor to have an edge and a face selected at the same time, so you wouldn't need much extra UI stuff (maybe just shortcut commands to execute the texture align operation?) 

Thank you for looking into and addressing those issues. The new features seem nice, too. I'll have to teach myself to use the texture projection/drawing stuff more (usually a ctrl+c/v type of user).

What I now expect is for Kinn to make a map! 

What I now expect is for Kinn to make a map!

Born too late to make maps in 1997, born too soon to make maps in the Honeysock era - born just in time to spank a couple out in 2004 before being whisked off to enjoy a life of crushing responsibility and lack of free time. 

 

 

In Quake 1 mode, would it be possible to make func_detail subject to the details filter, instead of the entities filter? That would be very handy :) 

True, added func_detail to world and detail filters.
Filter system is nonmodal + ericw might add actual detail face flag support one day (or has it been it added?), thus there is problem with correct structural filter processing, if i try to to make it to work for func_detail too:
-it filters brushes, having structural faceflag inside func_detail
-filters all entities besides func_detail :D
So let's run w/o this one 

Some Radiant versions have a "Z Window" - for me, I always found this ultra handy when you have room-over-room stuff. Image here: http://www.planetpointy.co.uk/archive/editing/tutorials/images/figz_1.gif

I can currently region things off in the z-axis by creating a brush and using Region->Set Brush.

Problem is, I am constantly turning regions on and off, and having to create a region brush every time like this really slows things down.

If I don't care about stuff above and below, Region->Set XY (bound to a shortcut) is extremely quick, but obviously this isn't great with room-over-room

The addition of the old Z-Window would complement Region->Set XY and give the best of both worlds without having to create a brush everytime.

Food for thought! 

I may be thinking of DoomRadiant with that Z-window thing - I remember there being clamps in the z-window that let you bound what gets displayed in z.

Or I may be imagining things! I wish I could check actually but I don't have Doom 3 anymore 

So it shows only z bounds of only selected stuff.
Can't quite imagine the special use of it.
May be you want to choose layout with more projections shown.
The way, i use, is rectangular selector + region button on toolbar; one feels enough quick. Can combine that with hiding too.

Some thoughts to think there tho:
Region->Set XY indeed always does XY; might work for other projections too
Region->Set Brush can be removed, as duplicate of 'select inside brush', 'region set selected' and forcing to use slower method. 

Ic better now, z view probe position is set via shortcut and all stuff is displayed there
Clamps appear to do nothing (q4 editor)

So it's basically for aligning things on z
Levels tend to be more flat, than high, so side wireframe views (with z) are usually more complicated
So that additional system benefit is somewhat simplification i think 

Region->Set Brush can be removed, as duplicate of 'select inside brush', 'region set selected' and forcing to use slower method.

I would be inclined to leave it alone actually - it's better to keep the option of doing it in one step ("region set brush") than having to do it in two steps ("select inside brush", "region set selected")

Region->Set XY indeed always does XY; might work for other projections too

I quite like the idea of "Set XY" to work in other projections. For that to be useful though, successive region operations would have to be subtractive - e.g. you would typically want to do a "Set XY", and then change the view to (e.g.) ZX, and set the region again, but everything that was hidden in the XY step would have to remain hidden in the ZX step.

Currently, regioning is not subtractive (the region is reset each time) - but making it subtractive to better support different projections might not be a bad idea. 

If you were to do that, having "successive region operations are subtractive" as an option in preferences might be best, so as to not upset those who like regions to work the old-fashioned way 

I agree, at least region-set-xy must be subtractive.
For old behavior can click region-off; one additional click is ok, as cost for not overcomplicating preferences and code.
Though rectangular selector + region button on toolbar way does wanted thing quickly and w/o creating brushes.o 

Though rectangular selector + region button on toolbar way does wanted thing quickly and w/o creating brushes.o


Ah yes I've just tried that and that's not bad, probably better than the creating brush method. 

For editor display purposes I would find it really useful to be able to set any individual non-brush entity to appear as a model with a given frame in the editor. This would be most useful for things like "misc_model" entities, where you need to be able to see the correct model and frame in the editor in order to position the thing in the environment.

Now - I can set the model in the editor with the "model" key, but I can't set the frame. However, the "model" key is used by the QC, and really I'm looking for something that can't affect the QC, because there's no telling what keys the QC are expecting to be set (e.g. for AD you have to set the "mdl" key), and furthermore, setting the "model" key on an entity that shouldn't have it set from the editor - could break a mod.

So really to ensure it can't break mods - I'd want something like these keys:

_editor_model
_editor_frame

Importantly the _ underscore makes the QuakeC ignore it, ensuring this can't affect anything in the mod.

Any thoughts? 

Hey, i don't quite get, what you want
Entities with classname misc_model do show arbitrary models
Frame is bbox, right?
Showing arbitrary models and boxes for any point entities would mean adding corresponding functionality to all ones, which is huge overkill
You are able to set displayed model and bbox in .def or .ent, like for weapon_* entities for instance 

Frame is bbox, right?

Frame is model frame - nothing to do with bbox. Many models intended to be used as "misc_model" would have multiple frames where the model varies wildly in size and/or appearance. Imagine a tree model with multiple frames each representing different sized trees, with branches in different positions.

Being able to see different frames in the editor is also really useful when placing (for example) crucified zombies (monster_zombie) or any other entity where you want super-precise positioning in the world.

Currently the models are displayed only at frame 0.

Entities with classname misc_model do show arbitrary models
Showing arbitrary models and boxes for any point entities would mean adding corresponding functionality to all ones

Ok, I'm fine with it only working for misc_model.

Currently in the editor, using the "model" key works, yes.

This is fine if setting that key doesn't cause unintended consequences in the mod. As I say, some mods might not want this to be set through the editor. For example, AD's implementation of misc_model requires you to set the "mdl" key instead.

Someone like Preach is probably better qualified than me in explaining if there are any situations where setting "model" in the editor could cause issues in the QC

Really it's just the editor has no knowledge of what the mod might do with any given key/value which is why I suggested using keys that are totally insulated from game code (i.e. keys prefaced with the underscore character). Same reasoning applies with any hypothetical key that would specify what frame to display.

You are able to set displayed model and bbox in .def or .ent, like for weapon_* entities for instance

That's great for most stuff, but really I'm talking about things like misc_model and related entities which are all about placing custom models.

Just to re-iterate, I'm fine for this only working with misc_model if it's problematic to make it a general thing. 

I'm overthinking this and overcomplicating it. Please ignore my posts #70 and #72.

Using the "model" key on misc_model works. That's fine. Leaving it at that, all I'm requesting in addition, if at all possible, is some way of also specifying which model frame to display in the editor on the misc_model. 

Aha, model frame
Mdl loader doesn't support loading frames other than 0 atm, and this format stuff is obscure for me
From what i read, while repairing loader, mdl models can contain groups of frames ('sequences'?) and lone frames
The only found code with support of loading sequences was game src

Besides that there are quite a few of pretty q1 specific stuff: loading skins from .mdl, loading correct sequences, depending on spawnflags, loading different models, depending on spawnflags, loading .bsp as model; Which also would require .ent/.def/.fgd formats change 

It sounds like a bit a faff then if the model loader is only set up to read one frame. I know a bit about the .mdl frame format and yes they did complicate it with frame groups.

It's probably not worth the effort then for now.

Here's another thing I found whilst messing around with misc_model...

in the editor, I orient the model by setting "angles" until it looks good.

In the Quake engine though, "angles" is treated differently, and the model is oriented differently in game to how it appears in the editor.

The difference is how NetRadiant seems to treat the x value of the angles vector, compared to how Quake treats it...

They seem to be reversed with respect to each other. This is best illustrated with a picture, so....

http://i.imgur.com/KpBsWHB.png

This sign discrepancy only appears on the x value of angles, the y and z are treated the same in the editor vs in quake.

The current workaround is to set the angles visually in NetRadiant, getting it to "look" correct, but then before saving, I just reverse the sign of the x value. This fixes it in game, but it just adds another layer of fiddliness to everything.