-
Notifications
You must be signed in to change notification settings - Fork 776
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New gui extension system - behaviour parameters very limited compared to function parameters #1189
Comments
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. 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 |
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 |
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.
(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 ;) |
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>
.
|
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 " 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...) |
A few notes:
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. |
@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? |
Converted to discussion. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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 :)
The text was updated successfully, but these errors were encountered: