Jump to content
The Dark Mod Forums

Wishlist For Darkradiant


Recommended Posts

  • 5 months later...

Is there any way to get DR to preserve its window settings from the last use? If you use 4 view panes and have them accordingly dragged them to spots you like them, every time you open DR they have to be rearranged again. Also, on three monitors the outside DR boundries don't remember their size and position, I always have to resize everything every time I start DR. Even if I had it maximized on the center monitor it opens unmaximized across all three.

 

Is there a way to set these to fixed positons on startup? Or is this a windows/nvidia issue. Its a small annoyance admittedly but none-the-less.

 

Oh, and this is with 1.8 and previous versions.

Edited by Lux
Link to comment
Share on other sites

hmm... maybe its a video driver issue then. Until just the last driver revision I've had issues with context menu placement in windows. Specifically right click menus. However I've not had any program settings, window settings, issues with other software.

 

I'll have to dig around on this then.

Link to comment
Share on other sites

Ok so tried that. Behavior is odd. If I maximize to my center screen and set my interior window sizes, then close DR. Upon reopening it maximizes to all three screens but the interior window border locations are preserved. Just that the main window is maximized on three screen instead of just the center.

 

If I don't maximize it and just size the main window myself to whatever and then adjust the interior window borders, then close DR. Upon reopening, nothing is preserved as was the case before.

 

It is curious though that it had some effect on it. It was worth a shot though. I wasn't aware of the compatibility setting so thanks for mentioning it.

Edited by Lux
Link to comment
Share on other sites

if you exit darkradiant via the exit option in the file tab, then it should save your window positions, if you exit via the 'x' in the top right hand corner, then it doesn't.

 

think its along the lines of the 'x' = alt + F4

and the exit option in the file tab menu is the normal way to close the program and it saves your settings.

Edited by stumpy
Link to comment
Share on other sites

Haha, and again, same behavior here. Using the exit under the File menu produces the same results as described above.

 

Yes it keeps internal window positions which is at least part of the issue.

 

The main window after maximizing to the center screen, upon re-opening maximizes to all three.

 

The only option for me under "Multi-Monitor" in prefs though is "0 (5760x1200)". I'm sure if I were not using display span this would allow me to select the center monitor but as I'm not and it is a display span than I'm guessing the onus lies with Nvidia for not properly detecting which monitor the application was last used on. Not suprisingly, the last two driver iterations (they're still rather young for the 780) have not allowed you to maximize to a single monitor anyway. That just got fixed with this latest release.

 

I suppose I'll have to live with it.

Link to comment
Share on other sites

  • 4 weeks later...

Each time I hit "f" to floor something, I wish it had the option to auto-snap-to-grid rather than having to then hit control-g in addition.

 

In fact, I just switched the shortcut for floor to ctrl-f so it's quicker to hit in succession. I might make an autohotkey macro for DR so F does both all the time.

"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Link to comment
Share on other sites

  • 1 month later...

This thread's been going for so long that it's kind of hard for me to get to know what has been suggested and accepted/rejected. So I'll just throw my few cents in here anyway. Forgive me if I'm just repeating anything.

 

I've been a long time user of Source SDK, specifically for HL2dm, and some features I'll be suggesting may be easily researched in the Source SDK wiki. So, forgive me for suggesting that one thing or another ought to be similar to Source SDK. It's just that there's very good reasons why I consider Hammer the best editor I've ever used (and I did try a ton of them).

 

In no order of importance:

 

1- Transparent "tool textures". Such as visportals, clip brushes, nodraw, etc. Certain solid materials or ones that can be used to seal the map, such as caulk or portal_sky should perhaps remain opaque, though. Here's a visual representation of how it looks in Valve's Hammer editor. (Orange ones are triggers, red ones are player clips, green ones I can't remember. But it should illustrate my suggestion well)

 

2- A more conventional way of selecting things. I'm not sure of the reasons behind this selection method, to be honest. I can't see any real advantages to it. And it introduces the danger of creating brushes accidentally, but it's due to the unavailability of a "create brush" tool that would need to be activated prior to creating brushes. If that existed - and was by default - any accidental clicks would result in selections being made, nothing else. An accidental click that might drag a selection might happen, but it very well may currently. The current selection method is cumbersome, and doesn't allow for a simple 1-click selection if one is already made, among other issues.

 

I'm not fond of conventions, but when it comes to software controls, I'm all for them.

 

3- A modifier key to accelerate camera movement by an adjustable percentage. This would be useful for large maps, instead of having to go to the menus to change camera movement between surgical maneuvers and traveling to the other end of the map and simply flying around. A button for temporary precision movement (adjustable speed or percentage too) might be a good addition as well.

 

4- Color coding or textured 2D views. Not strictly necessary, but I had already times where it might have been quite useful. For example, when making a large city map, I layed out the roads, and then roughly blocked out the buildings around them. At some point the view became a confusing mess of white lines where I had to decipher what was what by selecting and looking at the 3D view. (Maybe color coding layers?)

 

5- A tool that might be similar to Cordon Bounds in Source SDK. This tool is very handy in many situations. Most noticeably you can use it to select a portion of a map, and then toggle whatever is outside the selection to be hidden or shown. This helps minimize clutter in the 2D views, for example. But no only that, it actually works as a map sealing boundary, meaning you can compile a map that is surrounded by the cordon and it won't ever leak because the cordon acts as a sky brush and effectively surrounds everything that's visible. This also makes it very handy for quick mock ups, quick test maps, etc. (EDIT: The make room button already kind of makes up for the inexistence of such a tool as this one, in regards to making quick tests and mock ups, but has the downside that you can't intersect the already existing geometry when using it to quickly enclose the map - see note below)

 

(Note: Hammer doesn't compile whatever is hidden, which makes this tool pretty safe to use (you never get leaks). Dmap however, compiles hidden stuff, as well as hidden layers. This difference in behavior would have to be taken into consideration).

 

6- A way to exclude "stuff" from compiling. When running tests I often change things around and then it doesn't work and I have to revert everything back to how it was. And I repeat that process a lot... I can save several versions of the map, but untidy as I am, they'll stay there for the rest of eternity, cluttering my hard drive. I'd prefer to be able to build several versions of whatever I'm testing inside the editor, and exclude some of them in a way that dmap would ignore them. This would have other uses, this was just one example.

 

Maybe mark layers as excluded?

 

7- Layer "folders". Might help organize them, but more importantly it might help reducing the size of the list.

 

8- A more flexible way of resizing views relative to each other when using Split Pane window layout. Currently, resizing horizontally works well, the left ones adjust as you drag it. But resizing vertically doesn't. The right side is independent from the left side. Which makes clicking on the center and dragging not resize all 4 views as I would've expected at first. For this reason I've been using the default layout, as this way I can have a large 2D view and it's easy to change the camera angle. But for those who like using 4 views, this might be handy.

 

9- A way to maximize views when using the Split Pane layout. Again for anyone who would prefer to use 4 views, pressing a key to toggle between 4 views and 1 maximized view would be handy.

 

My preffered work flow would be 4 views for general usage, and a miximized view for detailed work. As well as a maximized 3D view for flying around when searching for mistakes, evaluating things, etc.

 

10- A way to group "stuff" for easy selections and easy adjustments. I haven't tried func_group, but the idea seems a bit dodgy, as I don't see an easy access to it (correct me if I'm missing something here). I'm currently using func_statics for this effect, whenever possible.

 

Note: layered groups might be a good idea too. By that I mean, for example, grouping two groups would obviously create one group. But disolving that group would revert back to two groups (which would in turn have to be dissolved as well), not to loose objects straight away.

 

Also, a useful adition, but not strictly necessary: a way to manipulate objects within groups. Maybe a toggle button next to vertex/edge/face selections, for group component manipulation.

 

11- A way to merge vertices, or snap selection to vertices, would be really handy for solving unforeseen problems with patches, or other problems of the same nature.

 

12- A way to make selections on 2D views behave in such a way that if you click on a line it selects the nearest brush to whom that line belongs to. Clicking on empty space would behave as it already does, just clicking on lines would behave differently. This would be handy so you wouldn't need to be hiding stuff to make simple corrections or adjustments, for example.

 

Of course that if you had several brushes sharing that line, you'd run into the same problem, but for this I would suggest also adding a way to cycle through brushes that occupy the space the mouse is clicking on. Maybe a modifier key that could select the next brush at each click?

Edited by Skaruts

My FMs: By The Cookbook

Link to comment
Share on other sites

Of course that if you had several brushes sharing that line, you'd run into the same problem, but for this I would suggest also adding a way to cycle through brushes that occupy the space the mouse is clicking on. Maybe a modifier key that could select the next brush at each click?

 

Clicking multiple times on a brush you're selecting, when there are multiple brushes under the cursor "depth-wise" in the view, will cycle through all the brushes under your cursor one after the next.

Link to comment
Share on other sites

 

 

Tab currently does this.

And there's a toggle button for switching between selecting whole group and group members. I have it hotkeyed.

 

Some good suggestions above. ps I wasn't entirely convinced by my own argument for the selection method either!

Link to comment
Share on other sites

Tab currently does this.

Indeed. Thanks. I scratched that part. If there's anything else I missed I'll do the same.

 

Clicking multiple times on a brush you're selecting, when there are multiple brushes under the cursor "depth-wise" in the view, will cycle through all the brushes under your cursor one after the next.

This doesn't work for me. All it does is select and deselect the same brush repeatedly.

Edited by Skaruts

My FMs: By The Cookbook

Link to comment
Share on other sites

10- A way to group "stuff" for easy selections and easy adjustments. I haven't tried func_group, but the idea seems a bit dodgy, as I don't see an easy access to it (correct me if I'm missing something here). I'm currently using func_statics for this effect, whenever possible.

 

Note: layered groups might be a good idea too. By that I mean, for example, grouping two groups would obviously create one group. But disolving that group would revert back to two groups (which would in turn have to be dissolved as well), not to loose objects straight away.

 

Also, a useful adition, but not strictly necessary: a way to manipulate objects within groups. Maybe a toggle button next to vertex/edge/face selections, for group component manipulation.

 

Func_group's accessibility is easier than I thought, now that I learned how to convert things into entities. I was having trouble doing this because the wiki , as far as I've noticed, doesn't mention anything about right clicking the brush and selecting "create entity"(EDIT: actually it mentions it in the Must Know Basic Intro page - but having overlooked that, it took me a while to guess), and I was expecting the Create Entity shortcut would create a totally new entity regardless of having a brush selected, and that the way to convert something into an entity would be through the entity inspector, by clicking the Choose Entity Class button. Turns out the button doesn't seem to do anything in that regard.

 

Either way, there's a problem with func_group: when I included func_statics into a selection I wanted to func_group, the create entity option was greyed out. This makes sense, considering func_group is an entity, but reduces its handiness.

 

I would further suggest two things:

 

1- That there ought to be a way to group objects that worked independent from entities and was not an entity itself, so that it could be more versatile and could lose these limitations.

 

2-. That the method for converting to entity be made more intuitive, and that the button in the inspector could be used for this. (I would assume it's intended to, maybe just needs a fix)

Edited by Skaruts

My FMs: By The Cookbook

Link to comment
Share on other sites

I actually like the idea of making some textures in the editor transparent. However, as far as I know the game just takes the image defined as qer_editorimage in the material file as editor texture. So you maybe can achieve this effect by making those pics transparent.

 

Regarding the way selection works: All mappers working with DR are used to it. It took some time before I got it either, but after I've worked with DR for some hours, I just got used to it. So you should, too, maybe.

 

Regarding camera movement: You can shift+middle mouse-click in the 2D window to teleport the camera, and you can move pretty fast in the 3D view using your mousewheel.

 

Regarding some of the other stuff: If you plan your mission well, you can divide it into several pieces which you can map independent from each other, and then just merge once most of the work is finished. It's maybe a bit unconventional, but should work well with big missions.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I actually like the idea of making some textures in the editor transparent. However, as far as I know the game just takes the image defined as qer_editorimage in the material file as editor texture. So you maybe can achieve this effect by making those pics transparent.

Definitely going to try that. Thanks.

 

Sorry to break the rule of not discussing things here, just for the sake of clarifying my thoughts and the experience I'm having:

Regarding the way selection works: All mappers working with DR are used to it. It took some time before I got it either, but after I've worked with DR for some hours, I just got used to it. So you should, too, maybe.

I've been messing around in the editor for a few days, two of them in full, and I can say I'm used to it already (I don't think about it anymore, I just do it). However, there's still a subconscious discomfort constantly nagging me in the back of the mind and it doesn't seem to be getting away, due to having to press shift and esc repeatedly and constantly - because selecting/deselecting things makes up for 90% (if not more) of the editing workflow and is the primordial requirement for almost every activity in the editor, it should be a comfortable action to perform.

 

At the end of the day, humans can adapt and get used to nearly anything. That doesn't mean we should leave everything as is. One thing I usually say and keep as a personal "rule": if it doesn't feel right, then it's probably not.

Edited by Skaruts

My FMs: By The Cookbook

Link to comment
Share on other sites

selecting/deselecting things makes up for 90% (if not more) of the editing workflow

 

Well i guess if you spam select/deselect 9 times before making a useful action, you probably want to get in some more practise at mapping.

Edited by ungoliant
Link to comment
Share on other sites

LOL :laugh: , that was rude.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Damn, i guess that ruins my reputation for being the most well-adjusted, PC and newbie friendly member of the community :rolleyes:. i get a little snippy when people that have been using the the game/editor for less than 5 hours start up with the mega-text-walls of stuff the overworked pro-bono devs should jump right onto.

Link to comment
Share on other sites

I actually like the idea of making some textures in the editor transparent. However, as far as I know the game just takes the image defined as qer_editorimage in the material file as editor texture. So you maybe can achieve this effect by making those pics transparent.

 

Perhaps compare to the speaker entities' textures, which are already transparent, as well as their spheres.

"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Link to comment
Share on other sites

Perhaps compare to the speaker entities' textures, which are already transparent, as well as their spheres.

http://forums.thedar...ditor-textures/

 

Well i guess if you spam select/deselect 9 times before making a useful action, you probably want to get in some more practise at mapping.

 

Ok I exagerated the math. :) But you still select/deselect something for each of almost every thing you do.

My FMs: By The Cookbook

Link to comment
Share on other sites

Ok I exagerated the math. :) But you still select/deselect something for each of almost every thing you do.

 

Until you get used to a way of working. After reading this discussion I paid attention to what I was doing in DR last night. Unless I'm working with a small layer, I do most of my selecting in the camera view, which I have on a separate monitor. I'm sure others have their own preferred method. By the way, the camera view does allow for easy quick precise movement without going anywhere near the menus. CTRL+ALT+mouse strafes smoothly after you right-click to direct your mouse movements to the camera view, and you already have your non-mouse-hand over those keys if you're selecting stuff, so there's nothing awkward or slow about it once you get used to the system. Big and small movements in any direction are both only a gesture or flick away.

 

EDIT: and smooth/small zoom is CTRL+SHIFT+mouse.

Edited by SteveL
Link to comment
Share on other sites

The selection also bugged me the first time i used DarkRadiant, my first ever radiant type editor, coming from Modo it was a really different way of thinking about it, but now i don't mind and it is also how selection works on all radiant editors i tried ever since, so is nice to at least have consistency between them. The thing i love about darkRadiant is the camera navigation you guys really nailed it.

 

One thing i would love to have on DarkRadiant was the ability to scale models.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...