Trouble with Containers

This forum is currently in read-only mode.
  • Hi. Can anyone tell me what I'm doing whrong here?

    Arrows and Containers

    I'm trying to get arrows to point from the player to both of the enemies. I have the enemy and arrow wrapped in a container, so I think that whenever the arrow references the enemy, it should default to the instance of the one that it is grouped with.

    Right now I have the arrows centered on the enemies and pointing to the player and everything works fine. However, if I go into the event sheet editor and reverse the targets so that the arrows are centered on the player and point to the enemy, both arrows point to the same enemy.

    By the way, I used tips from DeadEye's post about "This Cursed Rock" to initialize the enemies:

    This Cursed Rock

    So it's possible I made mistakes with that part that are causing my problems.

    I appreciate any help!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I think this is what you want.

    <img src="http://willhostforfood.com/files3/367943/arrows.jpg">

    The key is the "For Each" condition

  • Perfect!

    Thank you so much. That did the trick.

  • I think it's strange that it works without the for each when the arrows are positioned at enemies and pointed to player, but needs for each other way around. Shouldn't it be the same, whatever the actions are? The arrows are pointing to enemies, so shouldn't the action pick THE enemy the arrow is paired with, without need of for each? At least it picks THE enemy when positioning, so why not when pointing?

    I think this is a bug.

  • It's not a bug, it's just how Construct works.

    When you say "Aim at <something in my container>", it aims at the paired instance from its container.

    When you say "Aim at <any old object>", it usually just picks the first.

    For Each is the way around it.

  • It's not a bug, it's just how Construct works.

    When you say "Aim at <something in my container>", it aims at the paired instance from its container.

    When you say "Aim at <any old object>", it usually just picks the first.

    I know that, but isn't the enemy something in the arrow's container? According to that logic, it should work both ways around!

  • [quote:3knli77y]When you say "Aim at <any old object>", it usually just picks the first.

    Ashley are you sure about that? I seem to remember code wise that it usually pairs objects together automatically, so if you have 5 tanks and 5 turrets and use an action 'always - set turrent to tank.x, tank.y' it pairs them up even if they arn't in a container....and when they are in a container the only difference is that any conditions the select/unselect tank will also select/unselect turret....

    I'll have a look at this when I get home... at work and cant open cap files

  • I modified a test cap from the original, and I think that it shows pretty clearly the odd behavior.

    http://drasa.nipponfever.net/muu/container_test.cap

    I simplified the situation: now there is no spawning, the contained sprites are already there, and it should be clear from the events that the arrow should point to the corresponding sprites, but they doesn't...

    WTF. Even having one pair WITHOUT containers trigger this bug, but for each corrects it. Strange.

    Also encountered two crashes, which of one I was unable to reproduce, and one happened when cloning a layout, and then copying the all events from layout 1's event sheet editor to layout 2's. I'll post it to the tracker.

  • Ah was a bug in the plugin itself.

    Basically there was this line:

    CRunObject* pTarget = params[0].GetObjectParamFirstInstance(pRuntime);

    which should have been this line

    CRunObject* pTarget = params[0].GetPairedObjectParam(pRuntime, this);

    Having a search through the file I found that ZBehindOf, ZInfrontOf also have the old code and so will have the instance pairing problem. Other than that the pairing system should work.

  • yeah i always get those 2 lines mixed up.

  • It seems like a lot of people have confusion about things like this (including myself). I'm wondering if this bug fix is going to make it a lot more intuitive to work with sprites/containers that have multiple instances.

  • Well now that this bug is corrected, http://drasa.nipponfever.net/muu/container_test.cap <- this works like expected! :) And there is not need for For Each.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)