Does create object at coordinates of another object pair it?

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Hey everyone, I'm new here and need some help.

    I've been reading lot's of articles and learning a lot but I can't seem to find the answer to this one:
    I'm making a game where I have spawners that will spawn enemies, that then spawn their appropriate child objects.
    So far it seems to be working but I'm running into some issues I'm trying to debug. I have it set up like this:

    A spawner event creates the enemy first, and the enemy spawns with a flag "spawn children" on.

    Then

    - pick one of enemy
    + "Spawn children" is on
    -- create Line-of-Sight at 0.0 from enemy
    -- set "Spawn children" off


    The line of sight seems to scope correctly to each instance of the enemy with event like

    - Always
    -- set position at 0.0 from enemy


    I've read that I would need to create the child objects in the same event as I create the enemy to "pair" them. However at least for positioning my method works.
    So I was wondering whether or not this paring is applied also when you create at another objects position, so I can rule it out in my bug testing as the cause?


    Thank you for you help!

    You can store parent's fixed value in child's alterable value, then scope childs by that value to make your own pair system. The built-in parent-child system is somewhat a blackbox, and has limitations like you can only assign a child at the same time when parent is created.

    Thanks for the reply.

    I am actually using an ID system in the alterable values. I populate a global value called "Enemy global ID" (by adding 1 everyone time an enemy is spawned) which I then reference to when assigning ID to the subsequent enemy in it's "Spawn children" event that I talked about earlier. I am just trying to figure out how to pair all of these objects to the parent in the best way possible since doing a "for each"-loop and then referencing ID sometimes doesn't work and I don't know why. (I am aware of object scoping only being affected on the left-side object when comparing ID's). I guess what I really would like is a map of all the ways in which the program autoscopes, since it's so hard to figure out where it autoscopes and where it doesn't. Sometimes adding a for each loop seems to do the exact opposite. For instance, I have a movement type where the enemy moves towards the player or another enemy using Sin/Cos calculations, if I do no scoping at all, it will sync all enemies to the movement of one. I have tried using the "for each"-loop in combination with ID in various different ways and it still requires all instances to see me, before the code is read appropriately. Changing the order of the ID scoping seems to affect which one of two enemies is the one that will scope correctly, instead of making it work. Long story short, I'm finding it hard to understand, and want to know what is autoscoped and when.

    Thank you for your time!

    Quote from defisym

    The built-in parent-child system is somewhat a blackbox, and has limitations like you can only assign a child at the same time when parent is created.

    Do you happen to know which commands are then affected by this built-in system? Like for instance, I noticed the program can pair "set position at 0.0" even without create events or any scoping, I assume just based on the fact that it does it once per object.

    I solved this problem, I think for each loops do something to the way events are read in runtime. Not sure what though. I know fast loops stop the runtime until they finish, not sure what for each does. If anyone is reading this with similar problems, try isolating your for each loops so that they run separately, instead of including events that are non-related to the loop that need the same conditions.

    I'd advise against ever using the automatic scoping anymore.

    Fast Loops and ForEach loops both run before other standard events. Fast Loops break scoping (so if you've selected a specific object by events and then run a fast loop, that object is no longer scoped and needs to be re-scoped within the loop). ForEach loops automatically scope objects based on the criteria set in the event that initiates the ForEach (ex. If "Example Object" flag "scope" is on, start ForEach "scope_loop" for "Example Object" will automatically only run on "Example Objects" that have the "scope" flag on).

    ForEach loops can be a bit less process intensive, but also a bit slower than fastloops. It's basically running the same code a bunch of times in a row, so if you scope too many objects at once it's possible for the player to see the events unfolding. A ForEach changing the frame of an animation of 100 objects might not change all 100 objects fast enough that they appear to change at the same time, whereas fastloops halt the game until they finish running so all changes are applied at once from the player's perception.

    Just mentioning a little tip for those who have :cf25+: 2.5+ (and hence access to 260 named altVals).

    When I store a paired object's fixed value, I find it neat to store it in Alterable Value ID. It's kind of like how people often store an object's position XY values in Alterable Value X and Alterable Value Y. It's a small thing, but it does come with a few advantages:

    -you already have a 'readable' altVal without having to give it a unique name (because you're storing a unique ID that will let you identify paired instances later)
    -It's very low down the altVal list, so it's very unlikely to ever conflict with other altVals you've used
    -If you make it a habit to always use Alterable Value ID, you can easily reference the pairing later without having to stop and remember where the pairing ID is stored. It'll also be easier to repurpose code from one set of objects to another (or one project to another).
    -It's easy to reach in the Expression Editor because it appears at the very end of the dropdown menu (when you drag the scrollbar all the way down)

    Please login to see this link.
    My Fusion Tools: Please login to see this link. | Please login to see this link. | Please login to see this link.

    Quote from Volnaiskra

    Just mentioning a little tip for those who have :cf25+: 2.5+ (and hence access to 260 named altVals).

    When I store a paired object's fixed value, I find it neat to store it in Alterable Value ID. It's kind of like how people often store an object's position XY values in Alterable Value X and Alterable Value Y. It's a small thing, but it does come with a few advantages:

    -you already have a 'readable' altVal without having to give it a unique name (because you're storing a unique ID that will let you identify paired instances later)
    -It's very low down the altVal list, so it's very unlikely to ever conflict with other altVals you've used
    -If you make it a habit to always use Alterable Value ID, you can easily reference the pairing later without having to stop and remember where the pairing ID is stored. It'll also be easier to repurpose code from one set of objects to another (or one project to another).
    -It's easy to reach in the Expression Editor because it appears at the very end of the dropdown menu (when you drag the scrollbar all the way down)

    iIRC there was a bug several years ago, don't know if it has been fixed: using an unallocated value (didn't add that one in value tab) in other runtimes like Android will cause crash.

    So....according to one person it might be a problem because it's an allocated value. According to another, the opposite is true: it might be a problem because it isn't an allocated value X)

    Please login to see this link.
    My Fusion Tools: Please login to see this link. | Please login to see this link. | Please login to see this link.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login