I thought the entity window thing was sometimes triggered by closing it with ESC when actually intending to deselect an entity, but I can't seem to reproduce it now...

"Cance" was indeed caused by the custom text size setting in Windows. I had it at 125%, because otherwise the text would be a little too small for comfortable use. Something about the transition to Windows 10 that caused this hiccough. I've now set it to default and then back to 125% and it say "cancel" like it should. However, now certain other things look a bit weird, e.g. the menu bar buttons are slightly larger and the lines in the 2D window are fairly thick and black. Some weirdness in other programs, too. FFS, Windows!

Player.mdl display works, too. I did add it in the .ent file, but it still didn't show up, that's why I wondered. Apparently the reason is that I had backup copies of the file in the same directory ("entities - copy.ent" as Windows does it) which Radiant loaded instead of the actual file. :P 

It loads all found .ent and .def files.
So it's easy to drop in mod entities.
To make backup change/add some other file extesion 

So I keep fiddling around with this script for hours, wondering why it wouldn't work, just to discover Custom Radiant simply refuses save entities that don't match the .def?! In this case, a point-based trigger_once when the def has files as group-based. I would very much appreciate if Radiant would stay the hell out of my meddling and save everything I do regardless of how erroneous it may seem! (1.5 did) 

It appears to only affect point entities without models that have a negative angle set, and only changes the value when moving them. So for instance, angle -2 (=down in Quake) becomes -2.000006. Obviously, this must not happen, because it makes the affected entities stop working correctly. 

It's always done odd things like that, though I've never noticed with the up/down angles. I set an angle to 270 and it saves it a -90. I set an angle to 180 and it saves it as 179.99995 or something. 

Hi can someone give me a quick rundown on how to make entity models show up in the editor (e.g. monsters)

I'm using the .def file provided in Arcane Dimensions 1.5 - this .def file seems to have the information for model display (e.g. it contains the line

{ model(":progs/mon_hknight.mdl"); }

After the hellknight definition.

Also, I have set the custom mod correctly to AD through the project settings. 

save everything I do regardless of how erroneous it may seem!
I thought, this was discussed, but again:
some games (for example q3) don't load maps with empty group entities.
The most classic rad 1.5/net user's forum post is "Hello, i be building my map for a month, and now suddenly can't run it in game, halp :@"
The most classic solution is "open map in radiant 1.4, which removes such entities, and resave" or "rebuild from scratch/last backup"
Ridiculous, eh?
Yes, 1.5 discards brushes, contained in entities, defined, as point (with red warning in console)
Yes, there are ways to get empty group entites during normal map editing process; catching every possible way is like fighting the wind, also solution is always unique.
I added discarding empty group entities on map saving (with red warning in console); this fixes one of the biggest flaw in 1.5 branch
This is most important for non-advanced users; ofc advanced ones are aware of such behavior (literally every user hit one at some point) and can remove problem entities in 3 keypresses.
I, being advanced user, like you, would rather setup small suggested batch and keep creating with full comfort; or just use entities with brushes for tests and remove brushes for release version.
Only real solution is actual support of different entities with equal names; will look into that, though i expect too heavy research there.

angle -2 (=down in Quake) becomes -2.000006. Obviously, this must not happen
For the sake of interest, what point entities use -1 -2 angles for hardcoded directions?
In radiant brush entities angle is a string, and point entities one is actual number, transformable by editor.
Point entities also have 'angles' vector3 key for arbitrary 3d directions, thus there are no problems, except aestetics, for games, designed that way.
Transforms are performed in unified way like SceneGraph.forEachInstance( getTransformNode().transform() ), i e single function for all transforms, so you have angle transformed and committed, even if you just translate object;
One idea is to try to catch that case to omit commiting.
Meth around rotating is quite interesting:
rotation angles->radians->quaternion->matrix
current state angles->radians->quaternion->matrix
matrix*matrix
get_rotation_euler_xyz_degrees(result)->angles
Once computers computing precision is not limitless, even zero rotation can commit values.
Second idea is to use the way, entities with model use for rotation, when possible (with predefined quaternions); so -2.000000 would stay -2.000000, 180.000000 180.000000 etc


I set an angle to 270 and it saves it a -90
arctangent returns values in range ( -180, 180 ) :)

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

Shrinker here,

I disagree with your defense about the limited precision in computing.
It should not be used to defend deteriorating numbers, but rather be taken into account to make sure that doesn't happen in the first place whenever possible. Numerical stability is very important because this is about user input, and the little errors can add up over time and cause frustration.
Also, what is often not considered is that the conversion of floating-point byte patterns to strings and vice-versa can also lead to a loss of stability already because of only limited digits being shown depending on the format configuration.

Your effort to have the editor "understand" all geometric keys is very commendable and allows you to do neat things an editor without that understanding can't do, like manipulating rotation values, velocity vectors and the like accordingly or making sure all of this also works when shearing or scaling the selection too. Putting it all through a unified computation pipeline is also nice in order to make sure you can deliver a high processing quality in everything.

But:
When doing translations, and you can certainly discern those based on where your transformation comes from, and carry that through with a flag, rotational values shouldn't be touched.
When doing 90 degree rotations, which again could be carried through with a flag (the original Radiant's Tab key caused this transformation), the transformation matrix should be tuned to have perfect 0s and 1s in it* so that in the end, for coordinates and directional vectors, you have perfectly swapped coordinates instead of slightly deteriorating coordinates.
(*): something along the lines of that is also found in C++ optimizer settings for a reason - special treatment for 0s and 1s in computation to be more in line with the user's expectations and to ensure numerical stability better

Normalizing your angles between (-180, 180] is a design decision, and that's okay - you could also have decided to make them always negative or always positive depending on taste or what your users are familiar with. -- but as just mentioned, that should only apply when you actually have to manipulate the angles.

Keep up the good work! 

Hey, Shrinker.
I'm not the author of all those cool transformation codes, but SPoG - primary 1.5 radiant branch developer (and 3ds max fan, i believe);
I'm just telling, why that half transparent black box works, like it does, and name visible solutions (ones you named in general).
Though all these workarounds don't look as neat and straight, as original code does; perhaps other way could be converting all computations to doubles; also things to mention, current way produces no problems for games like q3 or doom3, you simply edit visually and don't care about not super accurate values.

One thing, code is not fully mathematically correct there: works ok only when rotating on axis, entity is rotated initially (or initial rotation = 0). Perhaps you have idea why that could happen in described meth, one looks legit for me :) 

For the sake of interest, what point entities use -1 -2 angles for hardcoded directions?

Shooter traps, for example. Like with group entities, the game code automatically translates the values into angles the engine can work with.

I don't know about the code and how it has changed over time/versions, but this did not occur with Radiant 1.5, and I'd be very surprised if it did with the old Netradiant. "-2.000000" seems to do the job as a workaround. 

It's undeniable that Quake is doing something very hacky with those -1 and -2 angle values, but the fact is that any editor which wants to support Quake can't afford to normalise angles to the range -180 to 180. Leaving aside the precision issues, if I want to have an entity facing at 358 degrees, normalisation will change that to -2, and now my entity faces down when it's loaded into Quake.

Of course, the developers of Radiant are under no obligation to support Quake. There are other editors available today which do have this as a goal, and get these kind of details right. But I'm sure it's a shame for people who prefer it as an editor. 

Oh snap!
Good observation about radiant 1.5, found related commit:
https://gitlab.com/xonotic/netradiant/commit/f85ed10a525f0740eea98350f2cb0ed84db8530c
Fixing one, breaking the other >_<
Changing number to string format... %g was supressing those small inaccuracies automatically, except 0 case: stuff like -3.50835e-015 occurred

Preach: i think restricting those unwanted angle commits on every move will be enough to repair the problem, so you will be able to safely set 358 and even 359 angle :3 

Maybe use "%.3f" to round to 3 digits after the decimal point?

I added discarding empty group entities on map saving (with red warning in console); this fixes one of the biggest flaw in 1.5 branch

How about checking for an "origin" key. If there is no "origin" key, it's probably an accidentally created empty brush entity and can be deleted. If there is an "origin", the mapper probably made it on purpose like negke's case, and the entity should be preserved. 

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