Wishlist For Darkradiant

[PranQster]

oops, wrong thread

Edited November 15, 2020 by PranQster
wrong thread

[7318]

I guess this wish has already been posted...

Could the key shortcuts be added to the menu functions, like in Blender? so people could learn the key shortcuts and proceed more efficiently.

as an example, in the case of "Connect selected entities" in the Entity menu, display beside it's name the "ctrl + k" key short cut.

And even maybe display it in a different colour or in Bold?

Edited November 28, 2020 by 7318

[peter_spy]

The shorcuts are displayed in the menu already:

[7318]

oh, then it means that the shortcuts are not displaying on Linux.

Edited November 28, 2020 by 7318

[SeriousToni]

Has anyone considered implementing a 3d creation process like they did in this editor for Quake / Half-Life?
Trenchbroom is able to create brushes directly on surfaces of other brushes on a 3d grid system. Pretty awesome to watch!

 

[HMart]

Will just leave this here for some future inspiration.

 

Edited March 17, 2021 by HMart

[datiswous]

On 11/28/2020 at 7:36 PM, 7318 said:

oh, then it means that the shortcuts are not displaying on Linux.

• Could the key shortcuts be added to the menu functions on Linux?
• Could some of the icons have a different icon on dark themes? Or is there a way to edit these myself? For example the dark blue color is hard to see on dark themes.

 

[OrbWeaver]

6 hours ago, datiswous said:

• Could the key shortcuts be added to the menu functions on Linux?
• Could some of the icons have a different icon on dark themes? Or is there a way to edit these myself? For example the dark blue color is hard to see on dark themes.

 

Unfortunately we don't appear to have any control over the shortcut visibility in menus. This is an aspect of how wxWidgets and GTK work, and no functions are exposed to the developer regarding this. Perhaps this is something that will change in a future version of wxWidgets.

We can easily change icons, but we don't have any way to detect the colours of the theme, so we would not be able to do this automatically. We could have more than one "icon theme" which users would select, which is something I've seen in other applications like GIMP and Inkscape. You can certainly edit icons yourself if you want (they are all in the install/bitmaps subdirectory), although of course you'd have to manually save all your changed versions and reapply them each time you upgraded DR.

[datiswous]

• Improved helpfulness in error messages

Edited March 25, 2021 by datiswous

[datiswous]

8 hours ago, OrbWeaver said:

You can certainly edit icons yourself if you want (they are all in the install/bitmaps subdirectory)

Thanks, that is the /usr/local/share/darkradiant/ directory in Linux? I might try that or try a different wm-theme. Maybe it's an idea to be able to override this somehow with a folder somewhere else, so it doesn't get overwritten during update. Not a big issue though.

[OrbWeaver]

19 hours ago, datiswous said:

Thanks, that is the /usr/local/share/darkradiant/ directory in Linux? I might try that or try a different wm-theme. Maybe it's an idea to be able to override this somehow with a folder somewhere else, so it doesn't get overwritten during update. Not a big issue though.

Yes, sorry I was giving the path in the source tree but of course this is different if you're trying to change icons in a full install.

I believe /usr/local/share/darkradiant/bitmaps would be the default install path if you have built from source and have not specified a different install location, otherwise in a packaged build it would be /usr/share/darkradiant/bitmaps.

[datiswous]

13 minutes ago, OrbWeaver said:

Yes, sorry I was giving the path in the source tree but of course this is different if you're trying to change icons in a full install.

So I guess I could change the icons before building from source and they will be implemented in the install? Haven't thought of that.

[datiswous]

Quick edit of the icons. Does look a bit easier to see.

[DeTeEff]

Don't know if this has been suggested before, but would it be possible to implement a method/feature for randomizing texture shifting on selected objects with a mouse click?

Often when you create objects that consists of many small but similar bits (stairs, railings, beams and such) you create on bit, then clone and drag the new object out (At least that's how I do it). Even if you have texture lock disabled the surfaces that's facing the way you're dragging stay the same. As it is now, I take some time afterwards to select some of these, shift them, and then select some others and shift some more, to break up the repetition. Would it be possible to have a feature, like select every part with alt+shift and click a box and WHOOSH, some algorith shifts the indivdual textures at random?

It could even be a popup box with several selections so you can adjust which textureorientation-stuff that should be offset/randomized (shifting, rotation, scale and so on).

[greebo]

There's a script in the main menu which can shift textures by a random amount. Don't know if it's cutting it for you, but it might be worth a shot.

[DeTeEff]

Aha! Thanks a lot, o mighty coder!

[thebigh]

That "shift by a random amount" feature would be more useful if it randomised each selected face independently, if you have multiple selected faces. I use it mainly for making stairs look less cloney and it would be nice if I could select all the front faces and randomise them relative to each other all at once.

[greebo]

1 hour ago, thebigh said:

That "shift by a random amount" feature would be more useful if it randomised each selected face independently, if you have multiple selected faces. I use it mainly for making stairs look less cloney and it would be nice if I could select all the front faces and randomise them relative to each other all at once.

The current script doesn't do this? If not, just put in on the tracker, it sounds like it could be an easy fix.

[thebigh]

43 minutes ago, greebo said:

The current script doesn't do this? If not, just put in on the tracker, it sounds like it could be an easy fix.

I thought maybe there was a good reason for doing it that way that I wasn't aware of, but I have raised the issue on the tracker now.

[DeTeEff]

I have dabbled some in creating custom models/modules and when I changed the path/maptree I (of course) broke a lot of models in the mission. Is there any easy way to find these broken blue/black boxes besides snaking through the mission with noclip or in DarkRadiant? Could it be possible to implement coordinates? The consol is very useful when it comes to reporting not functional visportal separators.

The consol error; "Couldn't load model: 'models bla bla (nor the fallback to LWO)

[greebo]

You could select one of the faulty models, and then use the script "Select all Models of same Type". Does that work for you?

[jonri]

On 6/2/2021 at 1:00 PM, DeTeEff said:

I have dabbled some in creating custom models/modules and when I changed the path/maptree I (of course) broke a lot of models in the mission. Is there any easy way to find these broken blue/black boxes besides snaking through the mission with noclip or in DarkRadiant?

I reorganized my modules once, and what I did was just open the .map file in a text editor and use find/replace to swap out the old model path for the new one.  Make sure your map isn't open in DR before doing it, and consider making a backup copy as well, but the .map file is just plain text so it should be safe to do it this way.

[DeTeEff]

On 6/2/2021 at 8:22 PM, greebo said:

You could select one of the faulty models, and then use the script "Select all Models of same Type". Does that work for you?

Oh, sorry for not noticing this post earlier...Yes, that works. (But I have already put an hour into searching through the mission for all faulty models I'm an expert on spending my time wisely! Haha)

[datiswous]

I would like it if in the Propperties window, when resizing that window, the name of the tabs get removed so you only see the icons, this way when resizing you'll always have the total amount of tabs in view. At the moment when you resize you see arrows to scroll through the tab view, becouse the tabs themself don't resize.

 

 

Edited June 18, 2021 by datiswous

[greebo]

I'm pretty sure that this is out of our control. DR is using wxWidgets, and the whole point of using that framework is that one gets the native controls of Linux, Windows and Mac - so you're basically stuck with the controls those systems provide for better or worse. Sometimes there's a flag one can set on the controls that might have some impact on how the native controls get rendered: for the wxNotebook control this is basically what we have:

• wxNB_TOP: Place tabs on the top side.
• wxNB_LEFT: Place tabs on the left side.
• wxNB_RIGHT: Place tabs on the right side.
• wxNB_BOTTOM: Place tabs under instead of above the notebook pages.
• wxNB_FIXEDWIDTH: (Windows only) All tabs will have same width.
• wxNB_MULTILINE: (Windows only) There can be several rows of tabs.

Apart from playing around with these flags, the only other alternative would be to roll our own and create a custom Notebook-style control, using toggle buttons or whatever. While possible, I'm not really in favour of doing that unless I really have to. Or take a step back and re-think the whole dialog, and whether it's necessary to have all of them in that one place.