Jump to content
The Dark Mod Forums

Func_* And Their Origins - Selection And Sizing


Recommended Posts

See entry 238.

 

I'm bringing this here, because I can't possibly reflect all opinions, and this probably requires some design decisions.

 

The following are what I can make of the situation after using it for a bit:

 

DoomEd:

1. Create a brush. Convert it to func_static. Deselect

2. Re-select it and drag it - it moves. Size it and it resizes.

 

Pro: The entity is treated as a single item to the user. Ease.

Con: For all intents and purposes, there's no real 'draggable origin' functionality. Kinda lame.

 

DarkRadiant:

1. Create a brush. Convert it to func_static. Deselect

2. Re-select it and drag it - it moves*. Size it, and it does not size.

3. Hit tab. You've now selected the brush itself, and you can resize it.

4. Drag it, it moves and the origin does not.

 

The entity seems to be two objects to the user, a brush, and a parent origin. Maybe cumbersome, but we'll see...

 

Pro: this allows the user to drag the brush around with the origin*, to have draggable origins. Then, reposition the brush after the origin is placed. Kinda cool (although the bug below* makes it actually work better).

Con: requires extra steps to make sure you are moving the right thing, and can be annoying. Perhaps the selection order should be reversed? (brush first, then parent origin (they more likely/frequently want to move the whole object than just the origin))

 

Problem:

As mentioned, selecting the brush first currently causes the origin to stay fixed. So if you select your door to move it, the origin stays where it is. If you drag it across the room, the origin is still on the far side. Annoying.

 

*Bug: (mostly inconsistent behavior - the main reason I started this thread, because it's not clear if this is truly a bug, or the intended behavior, but either way it's acting inconsistently)

 

1. Create brush. Convert it to func_static. De-select it.

2. Re-select. (at this point, you could drag the unit around, but not resize). Hit tab. Resize the brush a bit.

3. Problem #1: Hit tab. Now that you have resized, you can no longer tab-toggle the selection. De-select the object, and then re-select it for the next step.

4. Problem #2: Drag. Now that you have resized, you somehow broke the connection, and now the origin moves around by itself, leaving the brush behind.

 

Again, that's actually pretty cool and useful. But it's not clear if that's a bug, or intended, and either way it's behaving inconsistently/exhibiting multiple behaviors.

 

So I'm posting here because I don't pretend to know the 'absolute best' way.

However, I am inclined to suggest the following:

 

1. Select brush first, then the user can tab between origin and brush (as now, just reversed).

2. When the brush is selected, it translates, rotates, or sizes, all as a whole (takes the origin with it).

3. When the origin is selected, it translates alone (leaves brush out of it).

 

We then have the dual treatment (assuming that's desired), we have draggable origins (big improvement over DoomEd), and hopefully it clears up the bug/inconsistency above.

 

Sorry for the rambling form of this post. It's been revised several times, and it's still confusing, but it's a confusing issue, with a twist. ^_^

Link to comment
Share on other sites

*Bug: (mostly inconsistent behavior - the main reason I started this thread, because it's not clear if this is truly a bug, or the intended behavior, but either way it's acting inconsistently)

 

1. Create brush. Convert it to func_static. De-select it.

2. Re-select. (at this point, you could drag the unit around, but not resize). Hit tab. Resize the brush a bit.

3. Problem #1: Hit tab. Now that you have resized, you can no longer tab-toggle the selection. De-select the object, and then re-select it for the next step.

4. Problem #2: Drag. Now that you have resized, you somehow broke the connection, and now the origin moves around by itself, leaving the brush behind.

I had that one or two times as well and I can't quite imagine what the cause of this is. I couldn't reproduce it but as you're experiencing it as well, it's almost certainly a bug. A tough one, because of its wonky reproducibility.

 

So I'm posting here because I don't pretend to know the 'absolute best' way.

However, I am inclined to suggest the following:

 

1. Select brush first, then the user can tab between origin and brush (as now, just reversed).

2. When the brush is selected, it translates, rotates, or sizes, all as a whole (takes the origin with it).

3. When the origin is selected, it translates alone (leaves brush out of it).

1. Might be possible, but I'm unsure if that is always desired. Just two days ago I changed the selection behaviour such that the whole entity is selected when clicking in the cam view, not the single brush.

2. is almost certainly not possible. If the brush is selected, we have the child of a func_* entity selected. There is currently no way to propagate the transformation from child to parent. The only way is to propagate transformations down the hierarchy, from the func_static entity to their children, as it works now.

3.The origin itself is not selectable currently, as it is no instance by itself. We could go the way of the light center and make it a draggable instance, although I'm not sure, if that opens another can of worms.

 

How pressing is it? I would be grateful if I hadn't to look at it right now, because working with the RadiantSelectionSystem is a huge pain and I've gone through that four or five times now. I'm almost as far as to say that I rewrite it from scratch, because the current system is so fricking weird to work with.

Link to comment
Share on other sites

I had that one or two times as well and I can't quite imagine what the cause of this is. I couldn't reproduce it but as you're experiencing it as well, it's almost certainly a bug. A tough one, because of its wonky reproducibility.

Seems 100% reproducable here; you're not getting that? :(

 

In fact (I just figured out as a result of this): if you create a two-brush func static, then select, and tab to the second brush, resize it, and then deselect and reselect the whole thing, you can't move it as a unit anymore. So it happens to multis too.

 

1. Might be possible, but I'm unsure if that is always desired. Just two days ago I changed the selection behaviour such that the whole entity is selected when clicking in the cam view, not the single brush.

Right, that's a definite improvement. Multi brush objects are clearly a bit different, but I'd imagine they could follow the same model. In a way, it's just imitating DoomEd from the start, and then adding DR's new func. First step selects the object as a whole and lets you do whatever to it. Tabbing then gives the parts.

 

2. is almost certainly not possible. If the brush is selected, we have the child of a func_* entity selected. There is currently no way to propagate the transformation from child to parent. The only way is to propagate transformations down the hierarchy, from the func_static entity to their children, as it works now.

I'm confused. That's the way it currently works, just with a bug in there somewhere. You select the object, and everything translates as a whole.

 

3.The origin itself is not selectable currently, as it is no instance by itself. We could go the way of the light center and make it a draggable instance, although I'm not sure, if that opens another can of worms.

But because of the bug, I can select the origin. Maybe put that to use?

 

Damn, this is what makes remote interaction so hard. I'm betting a lot of times we're talking about the same thing, but just looking at it from different directions. :(

 

How pressing is it?

I'd say it can be worked around for the most part at this time.

 

Edit: You know, on reading this over and over, it sounds like the "bug" is the desired behavior already. If it can be found, maybe it can be exploited. Maybe some pics could demonstrate.

Link to comment
Share on other sites

I doubt this helps much, but for the sake of onlookers and possible clarifications.

 

1. Just after click selection of a func static. The brush is highlighted. The origin is highlighted. The functionality suggests that the origin is "in charge" at this point, because the object can be moved, but not resized, and pressing tab will lead to picture 2.

 

2. After one tab press, the brush is selected, the origin is deselected. Note the func_static text is not highlighted; I assume that is because it is the parent, and not the focus anymore.

 

3. After a drag to the right. The brush moved, the origin did not. Useful in some cases, annoying in others. If the desire was to move the origin, the best action would be to move the origin; not to move the whole thing to place the origin, and then move the brush away as a second step (the way it currently works, when not showing the bug)

 

4. A resize, possible when the origin is deselected only

 

5. After the resize, a de-select and re-select gives this, the "bug" state. The origin and brush are now separated, and the origin can be grabbed and positioned by itself! This in my opinion is great, and the way it should be implemented, that is:

 

-Selection selects brush first, brush moves all, tab gives origin, origin moves self only.

 

For multi-objects, the selection of the whole could (and should) still happen first, but actual operations on the origin should come only after it is tabbed to.

 

Hope that clears up any lingering confusions!

post-58-1174927184_thumb.jpg

Link to comment
Share on other sites

Don't know. It almost certainly is not just a small bug, but more or less a consequence of the weird design. Sorry if I sound a bit non-constructive at the moment, but it is frustrating working on that particular problem. Everytime I change something and think it's fixed, two new bugs arise because of some code somewhere else interfering. This section seriously needs a new concept, but that is one of the three core parts of GtkRadiant (next to the Renderer and the SceneGraph) that haven't been changed yet.

 

I will take a deep breath and perhaps I can do something about it, but I want to work on the S/R stuff first. Please track this on the Bugtracker, if you haven't already. :)

Link to comment
Share on other sites

  • 2 months later...

Ok, I finally could resolve that bug concerning child brushes of func_* entities not being transformed any longer after the drag resize manipulation. The resized brush is transformed now along with all the other children of the entity.

 

I also thought about the idea of making the origin a draggable instance by itself (like the light center), and I think I know how to do this, but I'd like to fix some other bugs first.

 

edit: New snapshot is up: http://darkradiant.sourceforge.net/snapshot.php

Link to comment
Share on other sites

Confirmed. I won't close out satellite issues yet as they will still depend on whatever other fixes come, but it looks like this first problem in the task is corrected (and definitely helps). :)

 

While I'm on this topic, I'll report a little strangeness I noticed now that I may not have mentioned before:

 

-Create brush, convert to func_static. Deselect.

-Reselect, hit tab, and move the brush around - it moves separate from origin (by current design)

-Hit tab again. You've now reselected the entire object, and can move them as normal.

 

Compare that to:

 

-Create brush, convert to func_static. Deselect.

-Reselect, hit tab, and resize the brush a bit.

-Hit tab again. The origin does not become reselected, so there's an inconsistency/possible problem.

 

However, if you select the brush again (do not deselect first), now you've got both origin and brush again. If it could be tabbed to, as with move operations, it'd be more consistent and user friendly.

Link to comment
Share on other sites

I can confirm that, it only occurs when drag-resizing the brush. I don't exactly know but maybe the finalisation of the resize operation does something to the current selection (which resets the group cycle - as if you select something completely different).

 

Which satellite issues are you referring to?

Link to comment
Share on other sites

I have to still look through the database to see which might apply and which can be closed now. Perhaps 238, but I'm not sure how 'solid' we are on the method at this point (select->tab->action). I assume (hope) there is a possibility that could change with any kind of selection overhaul (to allow for actions like resize, move, and texture without needing to tab first).

 

Here are raw notes (not for consumption, but what the hell) I'd taken so far in an effort to better categorize the selection/func_* related issues in bugtracker. There might be stuff missing, as I still have to make sure everything in the database is covered:

 

-------

1. single brush func_*: to Apply Texture (RMB in Media tab), user must select and then Tab to get off the origin and onto the actual brush.

-progress inhibitor/annoyance

-may change with selection overhaul

 

2. multi-object func_*: to select individual part, tab through. but, resizing 'breaks' connection to group. Next time group is selected, this object will be treated as separate. To fix, grab that object again and move (or resize) it a bit. Then reselect group.

(Seems to be FIXED: http://forums.thedarkmod.com/index.php?showt...p;#entry115111)

 

3. desired: ability to drag the origin around by itself

 

4. desired: if #3 cannot be achieved (direct manip of origin), then existing method is fine (drag the whole group around to place origin instead), but then a method to grab and move all parts *except* the origin is needed. Imagine a 20-brush drawbridge, you move the group to place the origin, but then you have to reposition each of 20 parts manually - argh. Instead, one state should exist in the next-object list such that the parts are selected, and the origin is not.

 

5. the inconsistency in behavior mentioned above ( http://forums.thedarkmod.com/index.php?s=&am...st&p=115111 ) Although minor, clearing this up would probably help this process feel better/much more friendly as a whole.

Link to comment
Share on other sites

1. single brush func_*: to Apply Texture (RMB in Media tab), user must select and then Tab to get off the origin and onto the actual brush.

-progress inhibitor/annoyance

-may change with selection overhaul

No need to overhaul the selectionsystem just for that, I'll adapt the behaviour of the apply texture routines to cover these group entities as well. :) This is tracked, so I'll eventually work on it.

 

3. desired: ability to drag the origin around by itself

Yes, this seems to be desirable. I'll see what I can do.

 

4. desired: if #3 cannot be achieved (direct manip of origin), then existing method is fine (drag the whole group around to place origin instead), but then a method to grab and move all parts *except* the origin is needed. Imagine a 20-brush drawbridge, you move the group to place the origin, but then you have to reposition each of 20 parts manually - argh. Instead, one state should exist in the next-object list such that the parts are selected, and the origin is not.

You can select all "brothers and sisters" objects grouped under the same func_* entity by selecting Menu > Edit > Expand Selection to Whole Entities (Ctrl-Alt-E). This selects all children but not the entity/origin. The focus must be on a child element for this to work, but I think I can add another command that selects the children when just the parent (func_*) is selected.

Link to comment
Share on other sites

Aha, is that what that does? A little cumbersome (since you must tab to a child first), but it's a decent workaround. :)

I think I can add another command that selects the children when just the parent (func_*) is selected.

That sounds even better. :) This is of course assuming it's needed. If #3 works (manually drag origin), it might not be. Will have to think on that... *rubs chin*

Link to comment
Share on other sites

This was easy. ;) The new command can be found under: Edit > Select Children. This de-selects all selected groupnodes (func_* entities) and highlights their children instead. Works with multiple entities too of course.

Link to comment
Share on other sites

Serious? :blink: That was quick. This alone has been my main source of DarkRadiant-Related-Anxiety of late. :laugh: I'm left thinking I must be forgetting something, because for some reason, this seemed like a very big deal before, something not to be fixed for a long time, requiring a selection redesign, etc.

 

Huh! I'll try to check out the snapshot after work tonight, and let you know if I can figure out anything that's missing, but if I understand the above correctly, that might be all (of these) func_* concerns covered.

Link to comment
Share on other sites

1. Texture from parent level: verified

3. Origin dragging: verified (wow, very simple and cool... DoomEd is beaten yet again)

4. Select children: verified, and I see it has a shortcut too - nice

 

I'll think on this and kick it around more tomorrow, but so far I haven't found any problems. The only remaining (minor) thing I can think of at this time is the cycle/select inconsistency in #5 above.

 

These are awesome fixes greebo, and a major relief! I was worried about these. ^_^

Link to comment
Share on other sites

Thanks, you were not the only one worried about these. ;) The first bug (the one with the brushes transformation) really cost me some nerves (you probably did notice that :D) and I'm glad that it's gone now.

 

It's also funny that it took me about a week to get the draggable light center working back in November and now I could do it in about an hour (with an even cleaner solution).

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

      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
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...