Wishlist For Darkradiant

[peter_spy 1408]

Quote

Where belong the wishes for new entities or prefabs?

If you need functional props (models mapped to entity defs), this is probably the best section: http://forums.thedarkmod.com/index.php?/forum/4-art-assets/

Edited July 17, 2019 by peter_spy

[JackFarmer 356]

Thank you, Peter.

[Geep 174]

I don't know if this is already wish-listed, but after getting bit once again by this aggravating usability issue and having to tediously re-enter my work, let me report it:

Consider a usual popup dialog window, which typically has [Save] and [Cancel] buttons and an [X] in the upper-right corner. Examples include the main dialogs of the Objectives and Conversation editors, and their respective child dialogs.

In traditional desktop Windows, treating the [X] as equivalent to hitting Cancel is poor practice. What you should do is:

1) When [X] is hit, determine if the user has made any changes to the data managed by the window (or its children). Circumstances will suggest how best to do this.

2) If so, bring up this popup dialog:

     "Do you want to save changes to <whatever>?"

     [Save] [Don't Save] [Cancel]

(where [Cancel] here only dismisses the "Do you want to save..." popup, not its parent. Treatment of the other cases is obvious.)

An alternative, acceptable particularly for child dialogs, is to remove the [X] entirely. You can still hit [Cancel], definitely knowing you're throwing changes away.

[OrbWeaver 509]

19 hours ago, Geep said:

Consider a usual popup dialog window, which typically has [Save] and [Cancel] buttons and an [X] in the upper-right corner. Examples include the main dialogs of the Objectives and Conversation editors, and their respective child dialogs.

In traditional desktop Windows, treating the [X] as equivalent to hitting Cancel is poor practice. What you should do is:

 

Typically we aim to follow the GNOME Human Interface Guidelines for DarkRadiant,  largely for historical reasons (it was derived from GtkRadiant, although it only uses GTK on Linux now via the WxWidgets back-end implementation).

However, neither Objectives nor Conversations currently comply with the guidelines, because:

• They are a curious hybrid of instant-apply (creating or deleting objectives or conversations entities) and explicit apply (editing the contents of those entities). This means if you click the cancel or X button, the entities will be left in the map but any changes you made to those entities in the bottom part of the dialog will be silently discarded.
• If they are instant apply dialogs (which the HIG seems to recommend where possible), they should only have an X button to close the dialog, not OK/Done/Cancel buttons. The HIG doesn't specify exactly how users should cancel their changes in this case, but I assume the expectation is that they would use the Undo function.
• If there are supposed to be explicit apply dialogs, they ought not to have an X button at all (although again the HIG is a little vague on this point — it says that instant apply should have an X button, but does not explicitly say that explicit apply should not have one), but should have Done and Cancel buttons which behave as you would expect.

So you are right that there is a usability problem, but the recommended solution is not to have dialogs pop up additional dialogs. Either the changes should be applied as soon as you make them and clicking X just makes the dialog go away, or there should be no X button at all.

Quote

An alternative, acceptable particularly for child dialogs, is to remove the [X] entirely. You can still hit [Cancel], definitely knowing you're throwing changes away.

That does seem to be the shortest path to avoiding data loss in this case, although the fact that entities are created immediately and left in the map even if you explicitly Cancel is still a deviation from recommended behaviour.

[Geep 174]

"Curious hybrid" - that's an apt descriptor of a lot of software projects. Particularly ones that are cross-platform or the work of many loosely-managed hands over many years. It's tough to then try to revise such projects towards a holistically consistent approach.

That said, if you could come up with a few relatively-quick hacks to avoid data loss, I'd thank you.

[peter_spy 1408]

Not sure whether it was already mentioned, but is it possible to eliminate rounding? It's problematic mostly with texture scale and changing light colors. For example, high-res textures often require 1:8 and 1:16 scale-down ratio (0.125 and 0.0625 respectively). The value of 0.125 works correctly, but 0.0625 gets rounded to 0.063. As GPUs get more and more powerful (and have more VRAM), we'll be able to use 2k and 4k textures more frequently. But as of now, we can't scale them down more than 8 times without loosing precision. So a 2k tiling texture has to cover a 256 x 256 units space minimum, a 4k texture has to encompass area of 512 x 512 units, etc.

[LDAsh 40]

Ability for "Fixed Subdivisions"  of "Patch Tesselation" in "Patch Inspector" to be higher than 32, or at least not cap patches back to 32.  NetRadiant can currently load map files with higher values even though the GUI still says 32.  I managed to get up to 4444 4444 which was many millions of triangles.  I think this is a good move to help future-proof the software.

[OrbWeaver 509]

On 2/16/2020 at 1:15 AM, Geep said:

An alternative, acceptable particularly for child dialogs, is to remove the [X] entirely. You can still hit [Cancel], definitely knowing you're throwing changes away.

Close button is now removed for all modal dialogs as of Git revision 8ee8e4213042057192b8a6d36f05c497b513b76b.

[Geep 174]

[JackFarmer 356]

It would be great if mappers could define EFX within DR.

The info location entities are needed for definition of relevant areas anyway.

Thus, I wonder if there is the chance to add a new property there, something like: "efx" and when applied, it should display  "Select Reverb" (similar to "Choose Model/Choose Skin" for other entities).

 

 

 

Edited March 22 by JackFarmer