[REQUEST] Aliases when picking instances of same object

Hi,

I think the engine would benefit greatly from having this feature added. What do I mean by aliases?

Well, whenever you are picking multiple instances of the same object (the most common example would be collisions), you should be able to name each one with an alias, which you can then use to distinguish them throughout sub-events.

For example, the event sheet would say something like

Bullet as Bullet1 on collision with Bullet as Bullet2

And then in sub-events you could refer to each bullet by its alias instead of having to use "System -> pick nth instance" and using local variables.

This could also mean that you could simply pick different instances of the same object in an event... Let's say for simplicity that I have a RankedPlayer Sprite object in my project which has several instances, with a 'rank' number instance variable which varies throughout the runtime, and on certain situations I wish to pick the player with the top rank and the player with the bottom rank and make them fight or whatever by moving both sprites to a certain location. Without aliases, if I were to put both those conditions on an event, the event would pick an empty set because no RankedPlayer has both the top and bottom rank. The way around it would be to use two events, picking both instances separately and moving them, which is not a big deal. But what if the location was determined by an instance variable on the bottom ranked player? Then it would be much more of a hassle, because once again I would have to resort to "System -> pick nth instance" and local variables. A simple way around it would be to have Aliases force the engine to pick different instances, making it possible to have

RankedPlayer as BottomRanked rank = bottom_rank

RankedPlayer as TopRanked rank = top_rank

And then have all the logic in the subevents.

I really believe it would be a welcome and very useful feature.

I hope my explanation was clear enough

Cheers

Really nice idea.

Already exists

You can pick "nth" in a collision and it will pick the index given if you use it in a subevent, with those indices being 0, or 1, not sure if you can have more than 2 objects in a collision.

You can also reference objects by their index as sprite(index).thisvalue.

Not 100% on if that works with collision tho....

Already exists

You can pick "nth" in a collision and it will pick the index given if you use it in a subevent, with those indices being 0, or 1, not sure if you can have more than 2 objects in a collision.

You can also reference objects by their index as sprite(index).thisvalue.

Not 100% on if that works with collision tho....

I know you can work around it with "System->Pick nth instance", but you have to use local variables to store whatever information you needed about one instance if you plan to compare it or combine it with the information stored in the other one. It's quite a hassle, and if I'm not mistaken, the engine could just as well support aliases by treating the SOL as an associative array.

I just checked, and the object(index) is not re associated in the sol for the collision event. Perhaps that may be a bug? Ashley

However I still don't see how naming an object would be useful as you are stuck using the same picking methods, at least at the local level that is.

Maybe you could explain that a little more?

I just checked, and the object(index) is not re associated in the sol for the collision event. Perhaps that may be a bug? Ashley

However I still don't see how naming an object would be useful as you are stuck using the same picking methods, at least at the local level that is.

Maybe you could explain that a little more?

The thing with System pick nth is that you can't differentiate both objects within the same set of conditions, so if you want to compare their instance variables, you have to store them in local variables, but if you also want to check for individual properties, you have to do it in separate sub-events.

With aliases you should be able to do all those things within the same sub-event without having to rely on local variables, which in my opinion is a very good thing, because it helps to keep code more readable and less cluttered with unnecessary sub-events

Another godsend of a feature would be the possibility to combine "AND" and "OR" blocks within the same event. Something like

Player.X > 10

Player.Y > 10

-or-

Player.X < 20

Player.Y < 20

Where both the top conditions OR both the bottom conditions have to be true for the event to be triggered. Lack of this feature sometimes results in a lot of repeated actions and some clunky nested events scenarios that could be easily avoided

Ok, but you're still not explaining how that works in the actions side of things.

In order to compare two different instances in the same action there has to be an expression that picks the instance and uses its value.

What I described with the object index is virtually the same thing, except it does not work within the confines of the collision, other than in the condition pick nth.

If it is possible, that would be the cleanest way imo.

Also named strings are a fuzzy subject, as there are security, and minification concerns.

I'm not clear on what the advantage of the "alias" feature is over just putting object UIDs or IIDs in a local variable and using that to reference objects. It sounds like the name of the local variable would basically be the alias.

[quote:qcqg3mf5]the engine could just as well support aliases by treating the SOL as an associative array.

That would be disastrous for performance. Ordinary arrays are essential for strictly O(1) efficiency.

I'm not clear on what the advantage of the "alias" feature is over just putting object UIDs or IIDs in a local variable and using that to reference objects. It sounds like the name of the local variable would basically be the alias.

I was suggesting it as syntactic sugar, if your Object has more than 5 or 6 instance variables and you wish to compare most of them between both objects in a collision, then it becomes a tangle of local variables and subevents that would be avoided if you could just have an actual reference to each object in the same condition block. A similar thing could be accomplished if Object references could be assigned to local variables, but I'm guessing there's a good reason why that isn't implemented either.

[quote:14xf561p][quote:14xf561p]the engine could just as well support aliases by treating the SOL as an associative array.

That would be disastrous for performance. Ordinary arrays are essential for strictly O(1) efficiency.

If it's a performance issue then there isn't much to be done :c

PS: Ashley, what about my other suggestion? About having combined AND/OR blocks?

"That would be disastrous for performance."

That was a nice one.