0 Favourites

Containers with families, trying to use less code

  • Currently, Baddy is hard-coded in because if I try to use the badguy family instead, none of the enemies individually work by themselves, everything is triggered as one object and I can't put their detectors on the family, so none of the enemies have their own detctors. Will I have to just keep copying and pasting this code for every different enemy?

  • Families should do what you want. Can you make a smaller example, so we can see what you might be doing wrong?

  • Containers do not work with families. However, you can manually link objects together using a common variable value for instance (like linking the detectors with the sprite UID). You will need to explicitely pick objects though.

  • I completely missed the headline.

  • Families should do what you want. Can you make a smaller example, so we can see what you might be doing wrong?

    Sorry, I used a large example to cover all the possibilities.

    Containers do not work with families. However, you can manually link objects together using a common variable value for instance (like linking the detectors with the sprite UID). You will need to explicitely pick objects though.

    Yeah, I read that was the case. So, should I give each badguy a variable, put the detectors in each badguy's container, assign a variable to all the detectors and badguys, and pick each of them and give them the nearest UID?

    Or should I just duplicate code?

  • blackhornet Magistross There's also this containerhelper behavior that allows for picking family children by UID, but I'm too stupid to understand how it could be useful:

  • Is there some other way of being able to reference families whilst maintaining individual instance profiling? I'd have thought duplicate event groups would have been really really discouraged, but how else can I use the events I'm using?

  • Yeah, I read that was the case. So, should I give each badguy a variable, put the detectors in each badguy's container, assign a variable to all the detectors and badguys, and pick each of them and give them the nearest UID?

    Or should I just duplicate code?

    Do something like below.

    On family "badguy" created

    For each "badguy"

    create/spawn detector

    set variable "detector.parent" to "badguy.UID"

    Then if the detector colides with whatever it is to collide with do:

    On detector collides with whatever

    for each detector

    pick badguy by uid [detector.parent]

    do events for badguy

    Should work IIRC. Let me know if it does not, I will be using a similar method to link inventories to NPCs and Loot Containers in my current project.

    Also family.uid=object.uid, you can also use that to check if a family member is a particular object type IIRC.

  • >

    > Yeah, I read that was the case. So, should I give each badguy a variable, put the detectors in each badguy's container, assign a variable to all the detectors and badguys, and pick each of them and give them the nearest UID?

    >

    > Or should I just duplicate code?

    >

    Do something like below.

    On family "badguy" created

    For each "badguy"

    create/spawn detector

    set variable "detector.parent" to "badguy.UID"

    Then if the detector colides with whatever it is to collide with do:

    On detector collides with whatever

    for each detector

    pick badguy by uid [detector.parent]

    do events for badguy

    Should work IIRC. Let me know if it does not, I will be using a similar method to link inventories to NPCs and Loot Containers in my current project.

    Also family.uid=object.uid, you can also use that to check if a family member is a particular object type IIRC.

    Gonna try this, should I still use containers at all, or just remove the two detectors from the container and spawn them? Also, is that definitely spawn and not create (two different processes)?

    Also, how about turning each character left or right? Is that just a case of using foreach?

  • In your situation I figure spawn might be more convenient.

    I would remove the containers, otherwise you will end up with creating too many detectors and badguys. Bah, I am not sure if this would not create a feedback loop if you forget to remove the containers. Badguy spawns detector via event, detector spawns rest of container on event creating new badguy, badguy spawns new detector via event etc.

  • In your situation I figure spawn might be more convenient.

    I would remove the containers, otherwise you will end up with creating too many detectors and badguys. Bah, I am not sure if this would not create a feedback loop if you forget to remove the containers. Badguy spawns detector via event, detector spawns rest of container on event creating new badguy, badguy spawns new detector via event etc.

    Yeah, you're right, I think it would create an ungodly loop if I left them in.

  • Construct 3

    Buy Construct 3

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

    Buy Now Construct 3 users don't see these ads
  • Pulstar seems to work perfik! Bit of a mess, mind:

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)
Similar Topics Posts Views Last Post
Unread hot topic
78 10,772
Josek5494's avatar
Josek5494
Unread hot topic
76 9,273
Pandadoor's avatar
Pandadoor
Unread hot topic
0 Favourites
[plugin] 3D using Copperlicht
72 25,982
Reken's avatar
Reken