projectile actors following their shooter actor's Y

Wonder Maru

Hi guys,
I'm almost done with my first game in GameSalad (hope to be able to show the project to you asap) and I'm kinda done with the gameplay, I'm basically tuning and tweaking things to polish it.

There's one thing that bug me and I can't solve.

I have a particular actor shooting (spawning) other actors (that move across the screen). This shooter thing is locked in its X but moves down on its Y when the player taps the screen.

It happens sometimes, that if the tap is in the same moment the shooter was going to shoot the projectile actor, this takes the previous shooter Y, and the result is that the projectile is offset (a little higher) from the shooter and so it stays until it goes off screen.

If I had just one shooter at a time on screen I had solved already constraining the projectile Y to the shooter Y with a Game attribute. BUT I can have more instances of the shooter at the same time, it's random, they can be 2 or 3 on screen, or maybe more, that depends on how the game evolves and since it's an endless runner most of things happening are triggered by random choices.

So, is there a way to constrain the Y of a spawned actor to its "father" actor, knowing that this father actor is a single instance of an actor that can be more than once on screen at the same time?

OR: is there another way to make this shooter actors shooting other actors without this "spawning delay"?

Thanks a lot to anyone who'll try to help me with this!

tatiang

You can sync actors by having the spawning actor change the value of an integer game attribute right before spawning and setting its own self attribute to that game attribute and having the spawned actor change the value of a self attribute to that game attribute as soon as it is spawned (i.e. at the top of its rule list but not inside of a rule).

Then use the self attributes as the row number to store or retrieve data in a table.

Wonder Maru

@tatiang said:
You can sync actors by having the spawning actor change the value of an integer game attribute right before spawning and setting its own self attribute to that game attribute and having the spawned actor change the value of a self attribute to that game attribute as soon as it is spawned (i.e. at the top of its rule list but not inside of a rule).

Then use the self attributes as the row number to store or retrieve data in a table.

yea, I was thinking about creating a table, but since I never did that before I was a bit unsure about using that.

I understand the logic of this though, I'm gonna take a deeper look at how tables work.

Thanks!

Wonder Maru

Hi,
I tried the table solution. I've been able to create, write and read from the table, but it doesn't seem solving the problem
Maybe I did something wrong, I don't know, but I think the time the shooter writes its Y position on the table and the time the projectile read it, considering the movement on the Y of both actors has an interpolation, might create this kind of delay when tapping fast.

I'm starting to think there's no solution

The_Gamesalad_Guru

You have to pay attention to the code firing order. You want the enemy reporting his position first. This is how code is scanned. Inside an actor the code fires in a logical order from top to bottom. In layers the actors blocks of code fire bottom to top so the most bottom actor fires it's code first and then in logical order to the top actor. Make sure your enemies are below your hero actor in the layer. This is the first step. Doing this kind of code is complex.

Example project for locating nearest actor. http://forums.gamesalad.com/discussion/comment/520926/#Comment_520926

Wonder Maru

@Lost_Oasis_Games said:
You have to pay attention to the code firing order. You want the enemy reporting his position first. This is how code is scanned. Inside an actor the code fires in a logical order from top to bottom. In layers the actors blocks of code fire bottom to top so the most bottom actor fires it's code first and then in logical order to the top actor. Make sure your enemies are below your hero actor in the layer. This is the first step. Doing this kind of code is complex.

Example project for locating nearest actor. http://forums.gamesalad.com/discussion/comment/520926/#Comment_520926

thanks man! I'll take a look to the order of things there

Wonder Maru

I'm still not sure, but changing the movement of the shooter, from interpolation to a simple change attribute, seems to be improving the situation.
BUT, I think I didn't understand something in the solution you guys suggested.
I have the integer game attribute keeping track of the ID, the shooter changes this attribute as soon as it gets spawned, and then change its ID to this one. Then, when moved, put its Y value into the table.
The spawned projectile change its ID to the game ID and constrain its Y to the value found in the table at that ID row.
It works. For one arrow. When a new shooter appears on screen, the new arrows change their ID to the new one and moves up towards the Y value of the new shooter.

The point is, I can have 1 to 3 shooters at the same time, shooting the same arrow actor. Each one of this updates its ID to the newest (the one contained in the game attribute), so they constrain their Y value to the same value from the same (the newest) shooter.