Wishlist For Darkradiant
Posted 24 March 2006 - 05:09 PM
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).
Posted 24 March 2006 - 11:50 PM
Posted 24 March 2006 - 11:57 PM
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.
Posted 25 March 2006 - 05:05 AM
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.
Posted 25 March 2006 - 02:53 PM
Posted 25 March 2006 - 05:00 PM
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.
Posted 25 March 2006 - 06:00 PM
Also: if at all possible, a usable/understandable model scaling method, even if it's just the rotation hack with hidden calculations. W00t.
Posted 26 March 2006 - 05:06 AM
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.
Posted 26 March 2006 - 10:56 AM
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).
Posted 26 March 2006 - 11:03 AM
(the renderer doesn't render objects in PVS if their bounding box don't intersect the neccessary portals in screenspace)
Posted 27 March 2006 - 04:16 AM
Posted 27 March 2006 - 05:14 AM
- Emil Zola
character models site
Posted 27 March 2006 - 05:20 AM
Imagine being able to arrange pillars in a circle by duplicating one and rotating around the centre of the room.
Posted 27 March 2006 - 05:28 AM
Posted 27 March 2006 - 07:15 PM
Also, it would be nice to be able to choose from some reverb presets like "stone hall", etc.
Posted 10 April 2006 - 10:18 PM
Posted 11 April 2006 - 08:22 AM
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.
Posted 05 June 2006 - 12:01 AM
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:
would be "intelligently" duplicated as:
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.
Posted 05 June 2006 - 03:29 PM
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).
Posted 27 June 2006 - 09:10 AM
Posted 27 June 2006 - 09:15 AM
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?
Posted 27 June 2006 - 01:37 PM
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.)
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users