Skip to content

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.

Sign up for GitHub

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

Jump to bottom

Let user know when GDevelop encounters an ambiguous variable #1413

Closed
kryptot7 opened this issue Feb 5, 2020 · 9 comments
Closed

Let user know when GDevelop encounters an ambiguous variable #1413

kryptot7 opened this issue Feb 5, 2020 · 9 comments
Labels
✨ enhancement

Comments

@kryptot7
Copy link

kryptot7 commented Feb 5, 2020

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

It behaves incorrectly.
gdev bug 1

But if I change it...
image

It gives me the intended behavior.
gdev bug 1a

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
Copy link
Contributor

blurymind commented Feb 5, 2020 via email

@blurymind
Copy link
Contributor

blurymind commented Feb 5, 2020 via email •
edited
Loading

@4ian
Copy link
Owner

4ian commented Feb 5, 2020

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
Copy link
Contributor

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
Copy link
Contributor

blurymind commented Feb 5, 2020 •
edited
Loading

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?
hintSheetIdea
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
Copy link
Contributor

Wend1go commented Feb 6, 2020

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
Copy link
Contributor

blurymind commented Feb 6, 2020 •
edited
Loading

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.

6rZ8g8R

:)

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

@4ian
Copy link
Owner

4ian commented Feb 6, 2020

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:
image

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
Copy link
Author

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?

@4ian 4ian closed this as completed Feb 21, 2021
Repository owner locked and limited conversation to collaborators Feb 21, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Assignees
No one assigned
Labels
✨ enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@4ian @blurymind @Wend1go @kryptot7