Ideas Why Group Selection Works This Way?

Post reply
0 favourites
  • 11 posts
From the Asset Store
Selection Frame
$5 USD
Selection frame like in RTS games, works both on mobile and desktop devices.
paradine's avatar
paradine

  • I'd prefer to not reopen an issue that was closed on github as not a bug, so I'm looking for some insight on why group selection works the way it does, perhaps it prevents some crashes/bugs from happening when groups are moved:

    If I may ask, what's the rationale behind a whole selection turning into only the group being selected once moved outside of a top level group?

    The reason I ask is because if the group you are disabling is collapsed there is no discernible indication that only the group is now selected once you move it outside of the top level group and re-enable it:

    Tagged:

  • What this shows, and what Ashley has confirmed: github.com/Scirra/Construct-3-bugs/issues/4797, is that when a group and the events below it are selected and then moved outside of a top-level group it diverts to only the group header being selected. This is apparent if the group is not collapsed, however as far as I'm aware, if the group is collapsed there is no visual indication of this selection defaulting to only the group header.

    Thus, I was curious what benefit/rationale there is behind defaulting to only the group header being selected when moving the selection outside of a top-level group.

  • Here's the thing, your actions are different in either case. If you don't collapse the group (not necessary), you can see it clearly.

    Clicking an event (or group) selects the event and its sub events.

    Dragging an event will leave only the dragged event selected.

    This doesn't have anything to do with groups in particular, nor top level or sub level events. It will happen if you drag anywhere, from top level to sub or vice versa, and it happens with sub events as well.

    If you drag a group to the top level, then click it, it will select all sub events as well.

  • Yes, this wasn't about what it's doing but moreso why (presumably there is a good reason?), but thanks.

  • If it really bothers you and you still want to try getting it changed, I would describe the bug, or unexpected behavior, as: When dragging to relocate multiple events, sub events are no longer selected upon dropping.

    This could be considered inconsistent behavior with the fact that when dragging multiple events at the same level, they all remain selected upon dropping.

    It doesn't seem like an intentional design to me, so it could very well be a bug. Or it could be a specific workaround for another issue.

  • Well for me personally it's now on my mind, thus, the odds of it happening to me are lower. However, the reason this came about was that I discovered after disabling/enabling some collapsed groups and moving them around for organization purposes that my project wasn't working as intended, thus I retraced my steps to discover that the collapsed groups I had toggle disabled/enabled were still disabled in terms of the events below.

    The main potential issue for an unaware individual is that a collapsed group will not give any indication of this default selection mechanic when dragging groups, as the only thing you can see is the group header of a collapsed group.

  • The main potential issue for an unaware individual is that a collapsed group will not give any indication of this default selection mechanic when dragging groups, as the only thing you can see is the group header of a collapsed group.

    Stuff like this never get added. Thous fall into 0/1 vote suggestion category, that C3 devs consider as user forced work onto them or user super cool idea and not as possible helpful case, which is there to help engine/editor workflow.

  • I think I understand what you are saying? It's such a small issue, that doesn't affect most users, and thus, is not considered worth the time? If so, fair enough.

    It's indeed difficult to address sparse cases. This issue is more relevant to those with larger projects that rely on collapsing groups more often than most. In these scenarios being able to see that the events are being deselected when moved outside of groups would be beneficial, but if that deselection mechanic is integral to how the engine/editor works, then I can see why it should be left alone.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Haha, wow. Changing the way the issue is presented convinced Ashley to fix it. ^^. Welp, thanks oosyrag.

  • Refining the scope of a problem by narrowing it down to its core, and presenting it in a clear an concise manner makes a huge difference. This is true for both bugs and suggestions.

    As I've mentioned elsewhere, the responsiveness from the developers is mind bogglingly superior to any other software I've used, yet people seem to complain all the more for it due to increased expectations here.

Post reply
  • 11 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)