How to do a loop that picks two instances of a sprite via different instance variable values

Post reply
0 favourites
  • 15 posts
From the Asset Store
Textbox via Spritefont
$10 USD
Forget about default textbox restrictions, you can create sprites atop of the textbox
paradine's avatar
paradine

  • Hello,

    I want one sprite to follow another sprite, and have this dynamically configured -- which follows which.

    To this end i have an instance variable in each sprite where i set what sprite is the follower and what sprite it follows.

    I now need to do a loop that (during every tick) picks out a first sprite, looks-up an its instance variable the another sprite, and then picks the other sprite to retrieve its location information.

    But, how do i pick a second sprite within the loop since i only can refer to one sprite type in the loop -- how does the loop know which sprite i am referring to -- or how i can tell the loop which sprite i want to refer to for picking

    any thoughts are much appreciated,

    Dan

  • there's a couple of ways. The way I like to do it is make 2 families

    One family is called "Follower"

    The second family is called "Followee"

    Put your sprite in both families

    Now you can do something like

    For Each Follower

    Pick Followee by UID "Follower.FollowUID"

  • Thanks,

    Yes, I tried families,

    Trouble is that once i refer to picks by family, i can't access the instance variables of the underlying sprites via the sprite family name.

    However, I need to access instance variables so i can do conditions across both sprite families.

    is there a solution for that?

    EDIT: to be more precise:

    The expression:

    SpriteFamily.instance_var_name

    does't work, when instance_var_name is defined in the underlying Sprite.

    However, now that i think of it, perhaps, i need to define instance variables on the families to begin with and not the underlying sprites -- in the documentation it states that sprites inherit instance variables -- so perhaps that's the way to go ...

    thanks,

    Dan

  • Thanks,

    Yes, I tried families,

    Trouble is that once i refer to picks by family, i can't access the instance variables of the underlying sprites via the sprite family name.

    However, I need to access instance variables so i can do conditions across both sprite families.

    is there a solution for that?

    thanks,

    Dan

    You can access the underlying sprites by doing Pick Sprite by UID Follower.UID

  • And yes, if the functionality given by the sprite's variables is something that should reside in a family, you can just move the variables over to the family

  • Eager to try to move instance variables to the sprites.

    Also, how C3 deals with the same instance variable name on two different families having the same underlying sprite type. The underlying sprite woudl inherit the same instance variable name from two families -- hopefully, only one then available for both families.

    Edit: C3 only allows one instance variable name per all families for same underlying sprites.

    I guess the solution is to define two parallel ones and set them each.

    Dan

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • ok,

    looks like the idea of a parallel instance variable seems to work --

    So name a sprite type has a name instance variable and the family of that sprite type has an f_name instance variable-- which is inherited to the sprite type as well.

    I now ensure that both are the same by creating an on start of layout event where i for the sprite f_name to name.

    Like this name is now available in both family type and sprite type ...

    thanks,

    However, I think in the future a simpler solution should be available, for example, to simply add an alias for sprite type in picks and then refer to the alias in expressions -- an alias would have all properties available and be treated as if its a different type for picking.

    Dan

  • ok,

    looks like the idea of a parallel instance variable seems to work --

    So name a sprite type has a name instance variable and the family of that sprite type has an f_name instance variable-- which is inherited to the sprite type as well.

    I now ensure that both are the same by creating an on start of layout event where i for the sprite f_name to name.

    Like this name is now available in both family type and sprite type ...

    thanks,

    However, I think in the future a simpler solution should be available, for example, to simply add an alias for sprite type in picks and then refer to the alias in expressions -- an alias would have all properties available and be treated as if its a different type for picking.

    Dan

    From what you describe it sounds like you don't need any variables in the Sprite. Couldn't you just have all the variables in a family and only ever perform code on that family?

  • Thanks,

    As far as I understand, this would not work. I need two types, each picking from the same set (type) of instances and accessing the same instance variable. Unfortunately, one can not share the same instance variable between a type and a family, hence i need to duplicate and replicate the instance variable and its value.

    Either between a type and a family or between two families ...

    As mentioned, I think, best would be to have an alias mechanism, if this is easy to include in the current pick paradigm -- its a solution "between" the others we discussed.

    Dan

  • You don't need two families for this, one will do. Then you reference the Family and the base sprite to get the two unique objects.

  • Thanks.

    Yes, that is what i've done.

    I am now wondering if i should work with different object types to begin with, and use families for common actions.

    Although, i guess, its not possible to create object types only object instances.

    So, this would only work if i have a fixed number of objects...

    Dan

  • Not sure why you think you need a fixed number of objects. This can work for dynamic object creation too.

  • Hi,

    Its the other way around:

    I am thinking that if I can live with a fixed number of objects, that is not large, then each object can be a single instance of a dedicated type.

    Dan

  • I would use containers. And then there are many options to set the follow behaviour depending on what you are after.

    Here's a small example showing using containers and lerping position of follower to leader waypoints saved as instance variables every .2 secs.

    This works for any number of instances with no picking required, but you could handle the movement in any way you like

    https://1drv.ms/u/s!AkmrWgxeuxlKg_8Q_K0U4mR7vuid2Q?e=zZ9xpP

  • Great. thank you.

    Will check it out

    Dan

Post reply
  • 15 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)