Saving an instance ID

[zatsme]

It would be useful to save an instance ID after it has been picked so we can use it outside of the current pick condition.

i.e. The current example I'm working on highlights the nearest instance while I press the mouse button and I want to be able to un-highlight it later in the code once I release the button.

I'm sure there would be other uses for this 🤔

Zat

[Wend1go]

Well you could basically achieve this via linked objects extension but never the less I like your idea.

Maybe as a new type of variable in addition to Number and String so that we could write something like:

Mouse/Touch is on object MyObject              Do selected objects to variable xyz
Mouse button released

The ToString function could then convert the object into its ID. But it could get problematic if there is more than just one Object in the filter.
Having this for Global, Scene and Object variables would also make it easier to "join" together bigger game entities consisting of multiple objects like screen filling end bosses and the like.
This could also circumvent the problem with interaction between different instances of the same object.

[4ian]

It's an interesting problem 😊First thing to note, I'm not sure that saving "IDs" is really the way to go because it's not necessarily something that I want to keep in the game engine (to have ID attributed to objects). In fact most of the game engine don't use IDs at all and I'm almost sure I could remove the usage of it in the two/three places where it's used :)

This being said, you are right that it would be interesting to somehow "store" one (or more) specific instance(s) to easily and efficiently retrieve it later. It's something that you can do with variables but performance could be better because GD will still need to scan through all the instances.

In another way, what we could need is a "hashmap" or at least a list of instances.

I don't have an immediate solution for now, but I think there is a simple and powerful concept to find here!

EDIT: for example, we could introduce an extension/feature with two action/condition:

1. the first to "save" the list of picked instances into a list with a name.
2. the second to "pick" back from this saved list of instances (by giving the name of the list).

Should be quite easy to use. Implementation can still be a bit tricky because you have to ensure that any deleted object is removed from the lists.
Also some considerations about the scope of these lists (should there be global lists, scene lists like global and scene variables?).

[Wend1go]

Sounds interesting.
Could it also solve the following problem when adding an instance of the same object and applying it's mothers values to it?

Trigger Once        Add object MyObject at position MyObject.X(), MyObject.Y()
                                Do MyObject.Variable(initial_height) to the Hight's scale of MyObject
                                Do MyObject.Variable(initial_width) to the Width's scale of MyObject

(This currently doesn't work and adds the size it to both instances)

[blurymind]

Could help with saving and loading instance states/variables

…

On Mon, 19 Nov 2018 07:19 Wend1go ***@***.*** wrote: Sounds interesting. Could it also solve the following problem when adding an instance of the same object and applying it's mothers values to it? Trigger Once Add object MyObject at position MyObject.X(), MyObject.Y() Do MyObject.Variable(initial_height) to the Hight's scale of MyObject Do MyObject.Variable(initial_width) to the Width's scale of MyObject (This currently doesn't work and adds the size it to both instances) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#747 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGMbVeirT11SoLtb6uU18sqHEAEaAoSJks5uwluRgaJpZM4YetfK> .

[4ian]

Could it also solve the following problem when adding an instance of the same object and applying it's mothers values to it?

I think in this case you'll still need to use two events:
One to copy values (MyObject.Variable(initial_height) and MyObject.Variable(initial_width)) into temporary variables.
The second one to create the object and set its scale.

This is because the solution I'm proposing is a way to store/save list of objects, but this don't change the way object lists are used in events (i.e: for each object, there is a unique list of objects picked for it).

[zatsme]

What are these in the debugger and could they be used at runtime to identify objects?

[Lizard-13]

Well, there's an id in the runtime object:

GDevelop/GDJS/Runtime/runtimeobject.js

Line 34 in 32f56f3

this.id = runtimeScene.createNewUniqueId();

But it isn't used anywhere, or very few times, because I haven't noticed it in until some months ago.

[4ian]

Yes, these are IDs but as I said it's not necessarily something that I want to keep in the game engine.

You can't use them in events (and that's a good thing because they will be gone at some point :) They would not be faster than using a variable anyway).
The debugger and a few other functions are the only place where they are used. In theory they could and should work without (it's just that it was convenient for the debugger).
Instead we should go toward solution that are more high level and more expressive like lists/dictionnary of objects

[zatsme]

Lists would be good, although would they not act just like groups do already? Why not make groups accessible to the runtime, create group and add to group actions might be all that is needed, we can already ierate through a group and the order doesn't seem to change. Deleting an instance removes it from the group already... 🤔

[4ian]

Answering late, but groups do not exist at runtime. They are only a logical way of grouping objects in events. When events are transformed to code, groups are used to create the events/actions/conditions for the associated objects, but are then totally invisible in the game.
So it would not be possible to create/add/remove groups during the game - even though the solution of having lists of objects can sounds similar.

[Wend1go]

Maybe the pixi containers could be utilized for that.

[4ian]

Pixi containers are more a way to group pixi objects that are rendered on screen (for example, each layers are containers, containing the pixi objects of each instance that is on the layer). The game engine is also agnostic toward pixi: it could run without (and is actually running without pixi when you're exporting with Cocos2d-JS - even if I don't particularly recommend it).
Here what we need is a way to have actions to say to "remember" a specific instance of an object, and a condition and/or action to "pick" back the instances