Wishlist For Darkradiant

[greebo]

I was going to suggest the numeric + and - but they are in use for cam speed. It may have been I who suggested adding keys for cam speed but in fact the default is so ideal I don't use them. Maybe nobody does. How about numeric + and - for far clip plane and Ctrl numeric + - for cam speed?

Hm, I'm a heavy user of the camera speed changers - I use them a lot when tweaking models or fine-tuning rotations.

 

What about using the Division / and Multiplication * signs on the Numpad?

 

If nobody else is using camspeed modifiers and most people want to have far clip modifiers assigned to +/-, then I can of course just change the binding in my local DarkRadiant instance, no problem either.

[jdude]

How about CTRL + ALT + Up arrow/Down arrow. I'd find it easier to manage since it's arrows.

[Fidcal]

I have a feeling that this far clip plane might get heavy use so I'd avoid Ctrl if poss and just have a single key so either [ ] or keypad / * should be fine. I have to keep reminding myself these are only defaults anyway.

[jdude]

I'd like to see a function where you can hold a button and select all the faces in the 3d view you put your mouse over, rather than having to select each face one by one.

[Serpentine]

ctrl+shift then drag a box in 3d view? Or are you talking about a more "the visible(i.e not occluded) faces it touches"?

[jdude]

Yes i only want to select the visible faces not any behind it.

 

Another helpful thing would be the ability to copy and paste multiple parameters. I'm making a lot of mushroom models and for each I have to go noshadows 1 solid 0. Perhaps having checkboxes for the model viewer for when you make models to turn these params on and off would be a good idea, along with any other common model properties used, like color.

[greebo]

You can mass-apply properties to selected entities. Select one mushroom in the map, then select in the Script menu "Select All Models Of Type" (which will select all entities with the same model), then set "noshadows" "0" in the Entity Inspector.

[jdude]

Oh nice! You're always one step ahead of me Greebo lol

[jdude]

Oh, you know when you make a patch and it creates it facing the view your using? Could we get the same system for cylinder patches? They always face down currently.

[greebo]

Possible, yes.

[SneaksieDave]

Agree, and it's probably be best if it was consistent for all of them.

 

1. Currently simple meshes are created aligned with view. Great!

2. Currently bevels are created top down (when created from top), which is useful, but from the bottom up (when created from sides) which is confusing and not useful. I'd say they should always be created showing the straight side (as the top currently does), for any view (e.g., create from side view = bevel laying on side). To do it the other way (showing the curve to the view) is too ambiguous.

3. End caps are currently created on their sides regardless of view, which is only useful for curved walls. Should be same as bevels, since they are just double sized bevels, most likely to be used for arches.

4. Cylinders and cones are always aligned top down, which is usually useful, but limited.

 

IMO, it'd be most desirable to have all patches inclusive be created aligned to current view, so if used correctly, no confusing rotation is ever needed.

[Komag]

Is this tracked? I just pulled out a very long brush to make a sideways cylinder only to have it be a very wide short one!

[SneaksieDave]

Thanks for bumping this. I was positive it was, but I'm not finding it. The closest I'm finding is the old, addressed version just for bevels: http://bugs.angua.at/view.php?id=1989

 

This issue has some confusion surrounding it, so I will try to make one single issue with a summary of the whole request for design. Will add the new link here when submitted.

[SneaksieDave]

On second thought, this needs discussion (probably why this hasn't been addressed so far). In trying to write up a consistent system, we run into a few bumps that need working out. So not to pollute this thread, started a separate request for discussion here: http://forums.thedarkmod.com/topic/11321-alignment-of-patches-in-darkradiant/

[Serpentine]

Soooo greebo, have I ever told you how you are the best and I love you like a brother whom I wish to name my firstborn son after?

 

Now, I've been thinking that DR while it's awesome there are some things that would make life just that little bit easier (for me) most noticeably would be measuring tools

 

For example I often have to guesstimate the distance between entrances to an area and a distance-closing visportal, if I could have a tool to measure between two points on the grid in doom units, that would be most helpful. In fact if it could work a bit like the clipper tool in which you drop two points and it just shows the distance between them to the side of the line. Perhaps the ability to use them as directional guides for textures or as guides to make patches/brushes (but that's just extra work and I haven't really though about if they would be useful or not)

 

Another tool would be using something similar to the above point would be a basic protractor/angle tool. Drop a midpoint and then two points to measure between. The next part gets a bit more confusing to understand : using this tool with a single entity selected perhaps it could be used to get relative rotation in Euler angles too, for example I want to open my door to a certain point - I select the door then place the starting point at the doors current 'opposite' end, and then the opening end point. the angle is measured from the origin vertex thing of the door and the two points to give a relative amount that can be used with the 'rotate' spawnarg.

 

Anyway, just some badly written, wishful ideas - I could provide mock-ups if you think they are interesting.

[SneaksieDave]

if I could have a tool to measure between two points

Do you know about the Preference, Orthoview | Show Size Info?

 

Another tool would be using something similar to the above point would be a basic protractor/angle tool.

Cool...

[greebo]

Feel free to add those features to the tracker. I've been in need of such a measurement tool myself a couple of times, though I mostly fell back to using the size info of temporary brushes.

[Fidcal]

With the door rotation I often just rotate the door with the arbitary transform dialog to see where it reaches then undo and repeat with a different value until its right. Needs rotate around origin set. Copy the rotate value into the door rotate property.

[Serpentine]

Do you know about the Preference, Orthoview | Show Size Info?

You, however it only measures the X/Y bounds of whatever, making it hard to work out something like the length of a diagonal face (i.e useless for a lot of triangles or mental Pythag is just your thing )

 

Feel free to add those features to the tracker. I've been in need of such a measurement tool myself a couple of times, though I mostly fell back to using the size info of temporary brushes.

Will do, made a mock up for the ideas too.

Ruler

Angle findery tool

 

With the door rotation I often just rotate the door with the arbitrary transform dialog to see where it reaches then undo and repeat with a different value until its right. Needs rotate around origin set. Copy the rotate value into the door rotate property.

Yeah, that's usually how I do it but that case doesn't apply to a lot of other things, specially when you're looking at translations and making some fancy geometry or whatever - it's also more a case of "provide a low level tool and someone will find a use for it, even if unintended"

[Tels]

Here are two ideas I'd like to see get added:

 

* add a filter for "LODE" entities (have "_lode" on one of their textures?)

 

* add support for "rotating" an enity created from a brush without actually rotating the geometry, but instead set the "rotation" (or "angles"?) spawnarg.

 

The reason for the second request is that if you rotate a LODE entity inside DR, you get the geometry rotated. Inside the C++ code, however, I was not able to recover this rotation (one could, of course, look at the raw geometry, but this isn't that easy). So, currently, to get a rotated LODE entity, you need to rotate it inside DR, note how much you rotated it around the Z-Axis, undo the rotation, then set the "angle" spawnarg to the proper value. That is quite cumbersome...

 

How hard would it be to add that DR rotates the geometry, but writes out to the map file the unrotated geometry and a proper rotation spawnarg instead?

[Baddcog]

Regarding patch faces,

 

It would be awesome if you could make a brush, then select a single/multiple faces, hit create simple patch and have that/those faces turn into patches.

 

That's how Hammer works (displacements), great for things like tunnels, build four cube tunnel, then turn inside faces into patches. Easier than aligning 4 patches... You can actually build an entire section of tunnels out of brushes first, then patch them and they are in place.

[greebo]

You can use the "Brush > Create Decal Patch", though it only works for faces with 4 vertices.

[Tels]

Here are a few small wishes:

 

1. I wish the default filters come with a few more variants, I have added the following, which make working with a map like NHAT 3 much easier:
    
   * ladders
   * leaves
   * SEED
    
   See the attached file. filter.txt
    
   However, even with these filters, it is very hard to navigate the forest. Not only due to drawing speed but also because:
    
   
2. hidden faces are still selectable - that is if you click on a tree-leaves face, you select the tree. So you can't see the massive amount of foliage, but you can't select anything without hitting a tree...
   
3. Hiding by model. Currently you can only hide either "object" (brush/patch), or by "texture" or "entityclass". However, all the massive amounts of trees, rocks etc are "func_static", so you can't really hide them as you can only match on "func_static" and that hides anything else, too. What we'd need is a fourth entry "model" and then you could hide all models that have "tree_" in their name.
   

[Fidcal]

I must admit, trees do often get in the way. I seem to frequently click and hide those individually as they can totally obscure the area from above. Any performance impact from testing deeper?

[Tels]

I must admit, trees do often get in the way. I seem to frequently click and hide those individually as they can totally obscure the area from above. Any performance impact from testing deeper?

 

Hm, I don't think so. In NHAT 3 all the trees make the drawing take so much time, it really really lags. But hide all func_statics, and the drawing time is realy low - only that you can't hide only the trees. I think the "hide" tests are done only once (when you toggle the menu).

 

Edit: NHAT 3 has a few hundred trees, so hiding them manually is erm, well, impossible without going insane