Let user know when GDevelop encounters an ambiguous variable

[kryptot7]

Describe the bug

Let's say I want to make both of my Player objects always face towards my Ball object. I have the following code:

It behaves incorrectly.

But if I change it...

It gives me the intended behavior.

I believe this is because of Player.X -- it's ambiguous because there are two "Player" objects in the scene. When I am comparing the Ball's position to Player.X, which Player do I mean? GDevelop seems to assume I mean the one on the left. (IIRC, I created that one first.) That means both Player objects adjust their orientation depending on where the first object is, not on an individual basis.

I think that GDevelop should warn the user when it encounters an ambiguous variable like this and has to assume the answer. It could display an icon next to any events with ambiguous variables to aid in bug-hunting. So in this example, after I typed "Player.X", GDevelop could have caught that there were multiple Players in the scene and warned me. Or, it could have warned me when I ran the scene with a popup like: "Variable "Player.X" is ambiguous, because there are multiple instances of "Player" in the scene."

To Reproduce

See above description and included file.
2020-02-05 Ambiguous variable.zip

Other details

Windows 10 1909 x64
GDevelop 5 beta 88

[blurymind]

You have two instances of a player object :) don't think that's a bug

…

On Wed, Feb 5, 2020, 10:08 PM Landon J ***@***.***> wrote: Describe the bug Let's say I want to make both of my Player objects always face towards my Ball object. I have the following code: [image: image] <https://user-images.githubusercontent.com/30781325/73885852-7e24db80-4836-11ea-9903-0b7b67a69b2a.png> It behaves incorrectly. [image: gdev bug 1] <https://user-images.githubusercontent.com/30781325/73886075-e5db2680-4836-11ea-8bff-35c458560e10.gif> But if I change it... [image: image] <https://user-images.githubusercontent.com/30781325/73886189-1c18a600-4837-11ea-96ee-623ceab3ceb2.png> It gives me the intended behavior. [image: gdev bug 1a] <https://user-images.githubusercontent.com/30781325/73886254-3e122880-4837-11ea-8947-0cf3df09c53f.gif> I believe this is because of *Player.X* -- it's ambiguous because there are two "Player" objects in the scene. When I am comparing the Ball's position to *Player.X*, which Player do I mean? GDevelop seems to assume I mean the one on the left. (IIRC, I created that one first.) That means both Player objects adjust their orientation depending on where the first object is, not on an individual basis. I think that GDevelop should warn the user when it encounters an ambiguous variable like this and has to assume the answer. It could display an icon next to any events with ambiguous variables to aid in bug-hunting. So in this example, after I typed "Player.X", GDevelop could have caught that there were multiple Players in the scene and warned me. Or, it could have warned me when I ran the scene with a popup like: "Variable "Player.X" is ambiguous, because there are multiple instances of "Player" in the scene." To Reproduce See above description and included file. 2020-02-05 Ambiguous variable.zip <https://github.com/4ian/GDevelop/files/4162233/2020-02-05.Ambiguous.variable.zip> Other details Windows 10 1909 x64 GDevelop 5 beta 88 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1413?email_source=notifications&email_token=ABRRWVLR26LVPW5YPPWEBX3RBM2GHA5CNFSM4KQS4FIKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ILK65BQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRRWVJJTYIEI4S5KOWNVKTRBM2GHANCNFSM4KQS4FIA> .

[blurymind]

I can see how this can be confusing. The condition column is kind of acting like a picker to decide what objects to affect. To get what you want I think you need to tell it to do it for each player object. I think we had something in the wiki about that. If not this would be a great addition to the topic with explanation :) It would be cool if we could communicate in a subtle way when the actions will be enacted on the entire object class and when they will only affect the instances that meet the condition

…

On Wed, Feb 5, 2020, 10:57 PM Todor Imreorov ***@***.***> wrote: You have two instances of a player object :) don't think that's a bug On Wed, Feb 5, 2020, 10:08 PM Landon J ***@***.***> wrote: > Describe the bug > > Let's say I want to make both of my Player objects always face towards my > Ball object. I have the following code: > [image: image] > <https://user-images.githubusercontent.com/30781325/73885852-7e24db80-4836-11ea-9903-0b7b67a69b2a.png> > > It behaves incorrectly. > [image: gdev bug 1] > <https://user-images.githubusercontent.com/30781325/73886075-e5db2680-4836-11ea-8bff-35c458560e10.gif> > > But if I change it... > [image: image] > <https://user-images.githubusercontent.com/30781325/73886189-1c18a600-4837-11ea-96ee-623ceab3ceb2.png> > > It gives me the intended behavior. > [image: gdev bug 1a] > <https://user-images.githubusercontent.com/30781325/73886254-3e122880-4837-11ea-8947-0cf3df09c53f.gif> > > I believe this is because of *Player.X* -- it's ambiguous because there > are two "Player" objects in the scene. When I am comparing the Ball's > position to *Player.X*, which Player do I mean? GDevelop seems to assume > I mean the one on the left. (IIRC, I created that one first.) That means > both Player objects adjust their orientation depending on where the first > object is, not on an individual basis. > > I think that GDevelop should warn the user when it encounters an > ambiguous variable like this and has to assume the answer. It could display > an icon next to any events with ambiguous variables to aid in bug-hunting. > So in this example, after I typed "Player.X", GDevelop could have caught > that there were multiple Players in the scene and warned me. Or, it could > have warned me when I ran the scene with a popup like: "Variable "Player.X" > is ambiguous, because there are multiple instances of "Player" in the > scene." > To Reproduce > > See above description and included file. > 2020-02-05 Ambiguous variable.zip > <https://github.com/4ian/GDevelop/files/4162233/2020-02-05.Ambiguous.variable.zip> > Other details > > Windows 10 1909 x64 > GDevelop 5 beta 88 > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#1413?email_source=notifications&email_token=ABRRWVLR26LVPW5YPPWEBX3RBM2GHA5CNFSM4KQS4FIKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ILK65BQ>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABRRWVJJTYIEI4S5KOWNVKTRBM2GHANCNFSM4KQS4FIA> > . >

[4ian]

Yep I agree these issues are hard to debug in a game!

I think that GDevelop should warn the user when it encounters an ambiguous variable like this and has to assume the answer

Unfortunately, it's not trivial to warn the user about this because we don't know the number of objects, only at runtime. (At runtime, if you use an object in an expression, the first one in memory in the list of picked objects is used)

We could try to :

• add a check at runtime and report a warning somewhere, but this will severely impact the performance.
• add a warning in the events sheet if we see that there is more than one "Player" (in your example) instance on the scene... but there will be tons of false positive because most of the time you run conditions to ensure you have only a single object. Or you could delete object. And there will be tons of false negative because you can create objects during the game.

So it's not an easy problem, not sure if it's "mathematically" solvable actually :) Though if you have idea about heuristics, let me know.

[blurymind]

Do we need to make it a warning? I see this more as something that can be communicated in a subtle way in the event sheet.

This sort of thing is present in literally all engines with an event sheet - both fusion and construct suffer from the same thing. They deal with it by extensively explaining in their wiki how object picking works

[blurymind]

Not sure if this would help communicate picking better or confuse people more, but what if we just add the word "each" or "the" before the object in the action - based on whether the object is"picked" in the condition?

I dont think any event sheet has ever tried to tackle this somehow. Maybe we will be first at that? Maybe I am oversimplifying this and there is more to it?
If the end goal is to somehow better communicate what will happen in the most natural language as possible, I cant think of a better way

[Wend1go]

Or maybe add a number in brackets next to the object in the pick object dialog to show the number of instances in the scene, like:
Player(2)
Bullet(0)
Wall(142)

Or Player (2 instances in scene) in a tooltip on hover.

[blurymind]

Or maybe add a number in brackets next to the object in the pick object dialog to show the number of instances in the scene, like:
Player(2)
Bullet(0)
Wall(142)

Or Player (2 instances in scene) in a tooltip on hover.

:)

It all goes down to a much clearer programming experience for the non-programmers

[4ian]

maybe add a number in brackets next to the object in the pick object dialog to show the number of instances in the scene

I'm not sure we're making things clearer with a number. I can see people asking "why is there 0 marked next to my object? Does that means that my bullets fired from my spaceship won't work? Is there a limit?? How can I set it to 1???" => no this means that you don't have any on the scene... and that's it 😬

but what if we just add the word "each" or "the" before the object in the action

I think there is more to it, at least the distinction between "a" and "the" might be ok, but "each" is confusing. In your example, if I have 2 players:

then "each" is confusing: "why is there a each on the first event but a "the" on the second? Does that mean the action won't be repeated for each player that satisfy the condition?" 😬

They deal with it by extensively explaining in their wiki how object picking works

I would prefer that we write a page about this in this case as a first step :)

But I think we're getting a bit out of the scope of the original problem.

The original problem is not about not knowing the number of objects in the conditions or actions. It's about not knowing that an expression will only be evaluated with the first object in memory when there is one in an expression.

Arguably, there is no issue with conditions and actions (not saying that they are perfect, but this thread is not showing an issue here). The issue is with understanding what objects expressions are using.

[kryptot7]

Since GD already assumes Player.X refers to the first Player in memory, would it really hurt performance to check if there are other Players? Is there an integer like "numberOfInstances" that GD can check, and if so show a warning?