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. 

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?