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. 

This is so-called 'stupid quake bug'
Orienting model is much simpler via rotation manipulator
ad_quake misc_model definition: angles: "pitch roll yaw"; actually is pitch yaw roll :) 

A very small/minor feature request. The pointfile that Q1 compilers generate uses the extension .pts instead of .lin, so it would be nice if the Pointfile function in the editor searched for a .pts file as well if it can't find one with .lin. 

True. Does .pts uses same format, as .lin? 

Yes, when renaming the file it displays fine in Radiant. 

This is so-called 'stupid quake bug'

I think its more just a difference in how Quake 1 interprets angles_x versus radiant. I'm not saying radiant's wrong - I assume its treatment of angles conforms to how Quake 3 does it.

Orienting model is much simpler via rotation manipulator

Yep, that's what I am using.

ad_quake misc_model definition: angles: "pitch roll yaw"; actually is pitch yaw roll :)

Yes, although that's an unrelated issue I think.

I'll just check with the coders to see what Quake 1 is doing with angles vs Quake 3... 

It's not question of interpretation, but well-known pain-in-the-ass bug, making even more problems, than necessity to inverting pitch everywhere in engine.
Problem src is mathematical mistake in VecToAngles function;
Bug is present in q1, hl, q2 and possibly in q3 in some masked form, since function is still wrong there.
Need to sorta support that behavior in editor, it seems.
I'll look, if this is possible.
Is it problem only with misc_models, or some more entities use angles key? 

I guess it is a bug with quake, not a "feature", heh.

Well, existing workaround is easy now that I know what's going on. However, it could make sense to support it in the editor, for future users who are not aware of the bug or don't want to mod it out in the quakeC.

I am not aware of any other entities it affects - I think misc_model is the only thing where you want to mess with angles_x and also see the model in the editor. 

Hi, I've noticed a change in behaviour with the flip operation, from previous versions, that for me is undesirable.

In older versions of NetRadiant, when you flipped an object, it sort of mirrored it along a grid line, so the components still had the same grid relationship when flipped. I find that 90% of the time this is what I want.

Now, it makes it so the flipped object sits in the same space as the original, but typically this will just mean all the components of the flipped object are now sitting on the wrong grid, and it takes longer to re-position it.

See image here: http://i.imgur.com/25pRmmI.png

This is not a problem for simple objects, but with large complex structures, I find I have to spend more time shuffling it into the desired position.

Could I request either adopting the old behaviour again, or adding an option? 

Ok, i'll try to add snapping of transform origin specially for flip commands.
Atm there are two options to get old result, but behaving like that by default is likely to be better. 

Great, thanks for this :) 

I noticed the Q1 entity definitions file contains some errors. The box size of the powerups is wrong, posing the risk of them falling out of the level. There also were some non-existing entities and missing spawnflags here and there. Apart from that, I was almost inclined to rewrite the entity descriptions, because the writing is inconsistent and in some places misleading, to say the least. Maybe I'll do it at some point.

If anyone is interested in a slightly updated version, you can grab it here. 

Nice one, numerous worthy commits there.
I do grab it for sure :) 

The spawnflag to have a light start switched off is 1, therefore the correct line in the definition must be:
<flag key="START_OFF" name="Start off" bit="0"/>

Btw, this thread should probably be renamed to "The Custom NetRadiant editor" since it's really only about this new version. 

 

I took my cues from you all in the General Abuse thread before compiling this into one list. Ironically, I still have never even used any Radiant. 

the default for all spawnflags should be zero. 

Qmaster: I meant the error was introduced by me, because the whole start_off part is missing in the def file that comes with the editor and I added it in the first place.

metl: It is. Just the way the def file works: bit=0 makes it spawnflags 1; bit=1 is spawnflags 2; bit=2 is spawnflags 4 and so on. 

i see. 

https://goo.gl/UyXRUJ


binds...
* doubleClick/Enter in Entity inspector Class list = convert entities
* ctrl during creating brush = cube brush
* m3: apply texture name and alignment to selected primitives
* ctrl + shift + m3/drag: project tex from face in tex clipboard to brushes(BP format) and curves[/list]

misc...
* on worldspawn entity create/convert to one do most expected move-selected-primitives-to-worldspawn
* convert point entity to group one = placeholder brush at origin + remove origin key
* convert group entity to point one: set origin key to contained primitives center
* fix uniform rotation operations for eclassmodel, miscmodel entities
* scale miscmodel entities uniformly
* added func_detail to world and detail filters
* region->set_xy: using active projection, not just xy one; is subtractive (no region off before applying)
* new brush prefab: icosahedron
* refactored CSGTool, improved Hollow::diagonal algorithm stability
* fix scaling for doom3 brush format
* Pointfile function: try to also load .pts leak line file (q1), if .lin isn't found
* snap transform origin for flip commands
* change light intensity save format from %f to %g to prevent .99999 on transforms
* support 'stupid quake bug' (invert pitch in angles)(generic and miscmodel ents)(cfg: entities="quake" in .game)
* clipper: place 1st and 2nd points far, 3rd near to ease 3 points clipping
* fixed q1 entity definitions (negke)
* changed surface inspector behavior from 'set whole texture projection' to 'set modified value' (makes sense for multiple surfaces selected)
* BP: surface inspector and Tex* binds scale texture by its axes, not world axes
* BP: fix rotation of tex projection with scale S != scale T
* BP: fix ruining nonregular tex projections by surface inspector (for example after fit/seamless/arbitrary projection)
* jump over tex projection scale = 0 case, while modifying one (AP and BP)
* fixed and improved normal finding in patch texture autocap algorithm
* removed axis cycling in patch cap texture; using autocap
* patch cap texture: project, using brush texture projection math of current mapformat to make it seamless with brushes by default
* Surface inspector->Project functions work for curves (in AP map format too)
* place created simple patch mesh not in middle of bbox, but on edge to make result more usable
* prefs-interface-layout-single scrollable toolbar
* tweaked Human Radaint GTK theme: toolbar pixmap separators, more compact toolbar
* Human Radiant Dark GTK theme
* new texture lock algorithm for BP map format, supporting any affine transformations
* more robust texture lock algorithm for AP map format, locking what is possible to; also improves seamless face2face tex paste function
* experimental fix of rendering scene and evaluating brush/patch representation TWICE on every transform (literally after every mouse move fraction) 

 

very happy to see lots of little fixes for things that bugged me in the past!

For me, the holy grail would still be a "one-click" method for rotating a texture to align with a given face edge, but it's still great to see the various little texturing improvements in this update. 

* doubleClick/Enter in Entity inspector Class list = convert entities
Hm, I always used that to turn world brushes into the specific group entity. Seemed more intuitive than the m2 menu for some reason.
While allowing group<->point conversion is neat in theory, for my purposes anyway, it's really a non-standard edge case thing that I'm not sure needed dedicated editor support. By "dedicated" I mean a way to actively do it, rather than simply accepting manually converted entities.


Not sure if this is actually the case, but earlier on it seemed like an increased UNDO queue size does not affect redo in the same way?!

I only just noticed the color/theme settings. Good stuff.

Minor feature idea: There's that option to make the clipper use caulk. Since in Q1 there is no "caulk" texture, there could be an extra checkbox to make the clipper use "skip" instead. Or maybe even one with a field where you can enter the name of any texture to be used when clipping.