New gui extension system - behaviour parameters very limited compared to function parameters

[blurymind]

This seems like an unfortunate limitation at the moment. When you want to develop your extension as a behaviour, you are limited to only number, string or boolean for properties.

The only way to have another object as a property is to do it in a function.

The other limitation is that it seems that you cant select a resource anywhere (as in json file)

Having this be on par would be very helpful in letting me make an out of the box npc extension for my dialogue system that requires less work to get working by the user.

I kind of actually started making it and finding that some things are still not doable if you are using the gui approach to make an extension- things I need to make it convenient to use :)

[blurymind]

Another example of this big limitation - you can't set up an event to be triggered when a parameter selected object collides with the object your behaviour is attached on. Parameter selected objects are only available in functions - where you can not access the object that behaviour is attached on.
In behaviours you dont have the option to select objects as parameters- only string, number or boolean

Surely there must be a way to have these share this data :) It seems that it is easier to write extensions in javascript than using the visual system

[blurymind]

Lets say I want to make an extension where you have a behaviour with actions and conditions. The actions/conditions need to have access to the object that the behaviour is attached on somehow. So I can make a simple condition where it returns true when a parameter entered object collides with the object that the behaviour is attached to

[4ian]

The actions need to have access to the object that the behaviour is attached on somehow

You can already access in events to the behaviour to which the object is attached. It is an object that is called "Object".

If you want to force your behaviour to be used with a certain object type, then edit the behavior configuration, there is an option for that. You'll have access to all the actions/conditions for this object type.

This being said, I can picture use case that would benefit from integration with other objects, but nothing related to this is trivial to implement nor trivial to make intuitive in GDevelop - and could lead to a bad design that we're stuck with forever.
Hence I would need you to restructure your thread suggestion to:

• an example of what you're trying to do, or too.
• what you tried to use in the current design of GDevelop (for example, have you used the object attached to the behaviour?)
• what is/are a possible solution(s)/additions.
• do you think of alternative solutions? (For example: are you sure passing objects as behavior properties is really what you want? What when objects are created? Or deleted? Or there are multiple of them? I can't remember any behaviour written in JS keeping reference in this to object(s), which seems to be what you think is missing?)

(This is the feature issue template)

I know I'm being a pain at asking this but if this kind of template force you to structure your mind and make sure that you've not bypassed something already existing. It also help me to better understand your problem. Right now it's a bit hard to 'parse" your messages because they seems like a mix of things that you wrote as you tried things ;)

[blurymind]

I had this idea of creating a behavior called "npc" which can be attached to the object that is to be the npc. The behavior takes a bunch of parameters: such as the player controlled object, the dialogue tree branch it calls and the input if such is needed. So when the player controlled object is overlapping and object with the npc behaviour and if needed a key input is called, start dialogue from the specified branch. This is mimicking the design in the rpg maker engines so the end goal is to make that engines users feel right at home. Unfortunately I couldn't get that behavior to work because of the reasons I explained. I guess for now I will leave the idea of including it as example and do something simpler, less reusable. Once the basic example is complete along with the wiki, maybe even someone else will try to do it :)

…

On Tue, Aug 13, 2019, 8:58 PM Florian Rival ***@***.***> wrote: The actions need to have access to the object that the behaviour is attached on somehow You can already access to the behaviour to which the object is attached. It is an object that is called "Object". If you want to force your behaviour to be used with a certain object type, then edit the behavior configuration, there is an option for that. This being said, I can picture use case that would benefit from integration with other objects, but nothing related to this is trivial to implement nor trivial to make intuitive in GDevelop - and could lead to a bad design that we're stuck with forever. Hence I would need you to restructure your thread suggestion to: - an example of what you're trying to do, or too. - what you tried to use in the current design of GDevelop (for example, have you used the object attached to the behaviour?) - what is/are a possible solution(s)/additions. - do you think of alternative solutions? (For example: are you sure passing objects as behavior properties is really what you want? What when objects are created? Or deleted? Or there are multiple of them?) I know I'm being a pain at asking this but if this kind of template force you to structure your mind and make sure that you've not bypassed something already existing. It also help me to better understand your problem. Right now it's a bit hard to 'parse" your messages because they seems like a mix of things that you wrote as you tried things ;) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1189?email_source=notifications&email_token=ABRRWVNDP5XFYH3IXSXUKS3QEMG5TA5CNFSM4ILNW7B2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4GZWLY#issuecomment-520985391>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRRWVNQHQ7BSYWFW6LD7R3QEMG5TANCNFSM4ILNW7BQ> .

[4ian]

Ideally, you would leave the work of starting the dialogue to the scene, which is the caller of the behavior. You could have a behavior action which would be "Check collision between _PARAM0_ and _PARAM2_ and start dialogue if necessary". _PARAM0_ is the object having the behavior (i.e: the npc) and _PARAM2_ the thing that we're testing collision with (i.e: the player).
So for this action, you would have to add an additional parameter (in addition to the first two default parameters, which are always the object and the behavior), which is an object "Player".

Would that work?

It's not as automatic as "add this behavior and select the player object and you're done". It's something that we might explore later. But it's still similar: "add this behavior and an action to auto start dialogue when in collision with the player". With the added bonus that it's more flexible (you can change the "player" object, you can use condition to change when you want auto start to work, etc...)

[4ian]

A few notes:

• I'm thinking of "object prefabs" or "composite objects" that could be used to create objects composed of other objects, but this is quite unrelated to your problematic.
• I'm also thinking of behaviors that could be based on other behaviors - but this is also unrelated.

Passing objects to behaviors is as I said something that we might explore - though it's good for now to see if you can do your stuff with just object as parameters of actions/conditions.

[Silver-Streak]

@blurymind I'm going through older issues to bring attention to them or close them out.

Is this still an issue? I'm seeing that behaviors now have options to have a function within them, allowing all of the function parameters. Does that solve this, or is it more that the lifecycle functions don't have parameters allowed?

[Bouh]

Converted to discussion.