Wishlist For Darkradiant

[sparhawk]

I think we should create a thread where you can put requests and suggestions for Orbweaver. This thread should be NOT a discussion thread. If you want to discuss a proposal, create a specific thread for it. I want it to be only for collecting proposals, so we have an overview of what people might want to have. I guess this might also help Orb to decide what he should focus on once he gets productive.

 

BTW: I really appreciate your effort, because we can really use this.

 

So my personal wishlist proposal is that I would like to see a group handler. Similar like in Blender, where you can select several objects and put it in a group. When you select one or more of these groups, the objects are visible. If the group is not selected, it's invisible.

 

In Blender and other 3D apps this is called layers (forgot the name before so I had to look it up).

[Gildoran]

My personal wishlist proposal is to be able to have vertex coloring on the control points of patch meshes, so I don't need to use external modelers to use vertex coloring. I'm not expecting this to happen, but as long as we're placing all of our wishes on this thread...

[New Horizon]

Hmmm, wishlist...in no particular order.

 

1. Proper light inspector, like the one in doom 3.

2. Model viewer that is superior to DoomEd.

3. Revamped entity inspector, Hierarchy based like Dromed and T3ED.

 

Too tired to think of more.

[OrbWeaver]

Proper grouping behaviour - accepted, although this raises an issue that I will discuss in another thread.

 

Vertex cols on map geometry - on the back burner unless I can think of a simpler way to implement this. There may be alternatives, such as limited in-editor texture modification.

 

Light inspector - accepted. We want as much functionality in here as possible.

 

Model viewer - accepted, although I will need more details on what is required here.

 

Entity browser - already a top priority, the flat menu sucks.

[sparhawk]

Not to froget: A good objective editor (has to be designed first anyway) and dialogs to easily setup stim/responses.

[New Horizon]

Not to froget: A good objective editor (has to be designed first anyway) and dialogs to easily setup stim/responses.

 

Aye, indeed. Is it possible for us to separate Stim/ Response from the entity inspector? I'm not sure if that would be the best way to do it...just a suggestion though. I'll really have to dig into Dromed and T3Ed this week to see what we can do to make this familiar to the Thief community, yet more intuitive.

[SneaksieDave]

Just thought of one, or at least I think I did (I don't know how it works yet, so I might be wrong): a skin picker.

 

Also: if at all possible, a usable/understandable model scaling method, even if it's just the rotation hack with hidden calculations. W00t.

[OrbWeaver]

Objective editor - accepted.

 

Stim/response - already on the list.

 

Skin picker - @SneaksieDave, what exactly do you mean here? There is already a skin browser, are you talking about improvements to this?

 

Model scaling - should be possible to implement, however I am slightly uneasy about adding this functionality because models are not "meant" to be scaled. If we can be sure that there are no ill-effects caused by scaling models then I don't have a problem.

[SneaksieDave]

Honestly didn't even know there was a skin browser. I thought people were manipulating skins manually to change them.

 

I figure the scaling, while limited, (the bounding boxes don't scale too, right?) still has some valuable use. In T3Ed, I made a whole unfinished level with scaled up stuff, and used invisible clip models to make simple collision boxes and it worked great (lots of collapsed corridors, oversized columns, etc).

[Gildoran]

When things are scaled up, does the renderer properly take that into account when culling them? (e.g. does it cull them according to the bounding box of their original size, or their scaled size?)

 

(the renderer doesn't render objects in PVS if their bounding box don't intersect the neccessary portals in screenspace)

[Domarius]

Well, probably don't assume the bounding box changes. The gist I got from Brian is that they didn't support scaling.

[Gildoran]

I'm just worried that if we scale up objects, they may appear to pop into and out of existance.

[oDDity]

This is related to the grouping feature, but it would be nice for a collection of objects such as a prefab to rotate around a central point.

[OrbWeaver]

I would quite like to "Blender-ise" the rotation mechanism, so that rotation could be performed around an object's centre, the centre of a group of objects or an arbitrary point specified by the user.

 

Imagine being able to arrange pillars in a circle by duplicating one and rotating around the centre of the room.

[Gildoran]

I know that for D3ed, you already can rotate a selection of objects around a common center point. (I forget the exect keys to do it... check the command list for info on how) Does GTK radient not have that feature?

[Ishtvan]

I don't know if this is in GTK already, but it would be nice to have a "reverb editor" or sound environment editor that could generate the text entries to the sound information file (I think it's called ASX but not sure) based on where the cursor is in the map, either the location it's in or the area number. I'm told the Quake4 editor has a feature like this. We talked about this before, and are not sure it's possible to predict what portal area number a given area will have since those seem to be assigned during the D3 map compile.

 

Also, it would be nice to be able to choose from some reverb presets like "stone hall", etc.

[New Horizon]

I wouldn't mind seeing some kind of user friendly materials and def file GUI. Something where we can select and object and just pick the options we want on it from little drop down boxes...surface type, noself shadow, paths to textures...etc.

[Gildoran]

I highly recommend this site. It pretty much has a complete list of keywords and what they do, along with blend-modes, a short description of how materials work and everything.

[New Horizon]

I highly recommend this site. It pretty much has a complete list of keywords and what they do, along with blend-modes, a short description of how materials work and everything.

 

It would be pretty cool if we could add those descriptions to our own little tool.

[SneaksieDave]

Currently there is a problem with implementing items like torches as prefabs because names are preserved, thus messing up triggering.

 

See: http://forums.thedarkmod.com/index.php?s=&sh...indpost&p=70114

 

Even if the torch problem is fixed in a programmatic way (*crosses fingers*), it would still be useful for other, non standard items, if DarkRadiant had logic built in to preserve assocations/relations, instead of names.

 

E.g., a prefab made up of:

 

torch_trigger_1

torch_light_1

 

would be "intelligently" duplicated as:

 

torch_trigger_n

torch_light_n

 

Where I suppose n could be consecutive numbers within the map (perhaps the first lowest instance among all items within the prefab could be determined), or failing that, perhaps just a random number or string.

 

For instance, "torch_trigger_356a" would rarely collide with another entity of the same name. If it did, the user would only need to generate another.

 

Disclaimer: I don't know for sure this isn't already in GTKRadiant, as I don't currently have it installed.

[OrbWeaver]

If you import a prefab with name "object_1" and you already have an "object_1" in your map, then the imported object becomes "object_2". I tested this by importing a prefab with a single model several times, and each time the number was incremented.

 

I don't think any target translation happens, as this is just a key/val on the entity which will be imported as-is (just like color or classname).

[Gildoran]

In my experience target translation occurs upon duplicating an object, though that's the only key that seems to be translated.

[OrbWeaver]

In my experience target translation occurs upon duplicating an object, though that's the only key that seems to be translated.

 

Are you referring to your experience with D3Radiant or GtkRadiant?

[Gildoran]

Sorry, that was D3Radient I was talking about.

[Ishtvan]

Btw, I'm pretty sure this has been suggested already, but some kind of GUI plugin to set stim/response stuff up would be nice. It's basically setting spawnArgs on the entity, but it's a bit of a pain to do by hand and remember which integers are which for different stim types. Some stim/response vars will probably be added, but the ones we have now will probably stay the way they are.

 

Something like a toggle between stim or response, then a pulldown menu for response type (that automatically converts to the corresponding int so we don't have to manually check that table), then a menu for state (active/inactive/etc), then a box for the name of the script to call (and the code would automatically put all this stuff in correctly named spawnArgs).

 

Ents can have multiple stims and responses on them, so maybe something to display them and address each one as well. (In the spawnArgs they're indexed numerically, "sr_class_1" sr_class_2" etc.)