a very convenient thing is to enable and disable groups with sets of events using an event. I did not find it implemented or not. There is a similar in ClickTeameFusion2.5
Yes that would be great from UI point of view. A workaround is to nest your
events under one parent event and disable and collapse it. The downside is
that you can't label it like you can with a group, so you have to also add
a comment
On Sun, Feb 2, 2020, 4:50 AM vinurd notifications@github.com wrote:
a very convenient thing is to enable and disable groups with sets of
events using an event. I did not find it implemented or not. There is a
similar in ClickTeameFusion2.5—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/4ian/GDevelop/issues/1407?email_source=notifications&email_token=ABRRWVIP6HRRGJH7PY2OZQDRAZGJ3A5CNFSM4KOXNLX2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IKMGXGQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABRRWVJT7PRGEAJ4O65SI3TRAZGJ3ANCNFSM4KOXNLXQ
.
I never implemented this because I consider this can be done using variables. It would be kind of feasible to add an action to enable/disable groups but this implies that groups are now some "global variables". I would rather add support for boolean variables :)
This request it's not interesting at all.
You can do the same thing with an action and a condition.
Add this feature need some quite work in the engine, just for do same thing in two lines in eventsheet...

The group disable feature is available in all other software with an event sheet and does save a few clicks having it - since it lets you debug faster - enable and disable grouped events without the need to make a new variable for them.
Label grouped events without having to add a comment above them and move the comment along with their root event row every time
I think it would be nice to have it as its convenient, but I dont think it is on the top of the list of nice to haves for me :)
I have mixed feelings about it because I understand it's convenient, but am unsure because deactivating event groups is equivalent to manipulating global variables.
As GDevelop has functions, how should that behave if I launch an action in the scene _Disable event group called "Player handling"_ but there is an extension that has somewhere in one of its action/condition/expression, an event group called "Player handling".
Should we:
I think we should go for the second solution (because having the user running the risk of breaking extensions without knowing it is a no-go, we're would break encapsulation). But this means that we must explicitly show in the interface that "Disabling an event group works only for event groups in this events sheet" - and possibly show an error if we don't detect an event group with the specified name in the events sheet?
Another related "corner" case, if I disable an event group in a behavior, do we agree that this is disabling the event group for all the object having this behavior (i.e: like when you disable the event in the events sheet)? Or should that be only for the current object behavior? (this is a problem of scope - which is why we have global, scene, object variables and behavior properties :))
Again I understand the need for this, but I think this kind of feature needs to be very carefully made to be intuitive and not dangerous - so not at the top of the list for now :). I would be interested in alternatives that integrate with GDevelop existing features: for example, we could make a context menu option that would wrap an event group into a condition checking a variable (so that it's faster for users that want to debug the game)?
It should behave the same as deactivating all the events that have been nested under the group. So group in the other apps with an event sheet is kind of treated as an ordinary event row you can nest things under and when disabling it in the event sheet, the things nested under it are disabled (Gd already has that for event rows). Its like a comment that inherits some properties from an event row (nesting + enable/disable).
But it also serves the function of a comment - so when you drag the group, you also drag its label.
So think of a group's equivalent that people are asking for in GD as this:

This is kind of how I've been replicating Groups from Construct and Fusion in Gdevelop, but it is kind of crappy, since I have to select both the comment and the Event row that is parenting the stuff I want to enable/disable
Think of of it as an event row that can't take any conditions or actions and has a comment/label field.
But you can still nest things under it and disable it and behaves the same way as what disabling an event row does - it disables all the logic that is nested under it.
Its more for organizing your logic into easy to toggle on/off blocks you can label and move around. It's not for doing advanced things in the runtime. It is purely an aid for the UI to do what I described with less effort. Construct and Fusion can enable/disable groups during the runtime - with a specific condition/action, but I rarely use those features.
I personally use groups to isolate some logic, see if my game works faster without it, or see if a bug occurs when its disabled.. That kind of thing. I also like to collapse logic very often - I prefer it to creating more event sheets and including them when doing something fast. I like to organize it into blocks that can be collapsed
... I think Gdevelop treats groups very differently by the sounds of it. groups are a more advanced concept in GD? One that might open a can of worms if it had and enable/disable. Groups in the other apps are really just a simple event row with a label on it and no actions/conditions
I've made a extension for that. It was simple to add and try, you can now test the possible issues.
Disable_Events_Extension.0.0.1.json

Most helpful comment
This request it's not interesting at all.

You can do the same thing with an action and a condition.
Add this feature need some quite work in the engine, just for do same thing in two lines in eventsheet...