News | Forum | People | FAQ | Links | Search | Register | Log in
The NetRadiant Level Editor
NetRadiant-custom is continuation of NetRadiant, based on GTKRadiant, which supports numerous games, with some emphasis on Quake.

win32 build
win64 build
github

Simple install instructions are included in q1pack\q1pack.txt
First | Previous | Next | Last
Edit... 
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. 
Edit 
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. 
Editor Model & Frame Display 
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. 
You Know What? 
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 
Ah 
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. 
Thats No Good Lol 
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 :) 
Pointfile 
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? 
Yeah Sorry My Mistake 
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. 
Flipping And Grid Offset 
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. 
#84 
Great, thanks for this :) 
Entity Def 
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 :) 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.