How do I select only the instance that was just spawned?

Event Triggered

-Spawn Bullet

-Set Bullet direction

Most of the time only the recently spawned bullet will be affected.

But I have seen several times where all bullets on the screen change direction to move in the same direction as the new bullet.

I don't have an isolated example but I don't believe I have any other events that affect bullet direction.

Do I need to set this up differently?

Thanks

Would Z order pick ("pick top/bottom") work in your case? Pick the sprite on top?

That shouldn't happen. The spawned item would be the most recently picked. If the subsequent actions are at the same level or lower, it should work. You'd have to show a solid example for further help.

Try using the "Pick instance by UID" condition, the value being "[sprite].count -1". This should select the newest instance. You could also try comparing the distance to the player & picking the instance w/ the lowest distance.

That shouldn't happen. The spawned item would be the most recently picked. If the subsequent actions are at the same level or lower, it should work. You'd have to show a solid example for further help.

That's what I thought as well. I have just changed the only other events that could be the cause and am going to retest. Problem was it was happening rarely so might take a while to see if it happens again.

If it is still happening I might look at using the "on created" trigger.

This part I haven't changed:

I have a lot of instances of the same object in my current project. I assign an instance variable to the latest created - and a global variable to match the latest created object.

When an instance of a particular object is created, I use an instance variable (called ActorID) that is set to the current "actor.count" as well as the global variable.

Maybe something like this will help?

Variables are awesome...

~Sol

I have a lot of instances of the same object in my current project. I assign an instance variable to the latest created - and a global variable to match the latest created object.

When an instance of a particular object is created, I use an instance variable (called ActorID) that is set to the current "actor.count" as well as the global variable.

Maybe something like this will help?

Variables are awesome...

~Sol

I agree. Variables are definitely the concrete solution if needing to track something and worry about picking which instance.

For this issue it is a bullet basically, so set it and forget it. No tracking needed.

I think I figured it out—this post was kind of a process of elimination line of thinking to rule out this as the problem.

Thank you for the comment—I will probably end up using that idea in a future scenario.

No worries!

~Sol

No worries!

~Sol

Actually, it is still doing it but I think I figured out why.

This is basically what I have

On timer

--animate

-- Wait short time (0.3 seconds or so)

-- Monster spawn bullet object

-- Set bullet direction

I actually thought this through while away from project and testing but I think this is why it is happening:

If the monster is hit/damaged and destroyed between the timer going off and the spawning (so 0.3 seconds time window) there is no new bullet spawned. Only one monster is picked and it is destroyed so no monster is left picked to spawn a bullet. And since no bullet is spawned then setting the bullet direction will pick ALL of the bullets.

So I was thinking of changing it to:

-- Monster spawn bullet object

-- Set instance variable (to the angle)

On bullet created

--Set direction to instance variable

So even if monster is destroyed and all bullets are picked it will just set an instance variable that won't be used again.

Will the On bullet created fire before the instance variable is set though? Should I put a miniscule wait in there? How small? 0.05 seconds?

Or can anyone think of a better solution?

Ugg. My first instinct when I saw your code was to blame Wait, but as is, it does work, except of course if you destroy the Monster that is then later still referred to, as you painfully found out. So switch to using a Timer on Monster instead. Then if the Monster is later destroyed, the timer will be cancelled automatically. Sorry I didn't speak up sooner.

Ugg. My first instinct when I saw your code was to blame Wait, but as is, it does work, except of course if you destroy the Monster that is then later still referred to, as you painfully found out. So switch to using a Timer on Monster instead. Then if the Monster is later destroyed, the timer will be cancelled automatically. Sorry I didn't speak up sooner.

Ahh. So in general it would be a good idea to replace any waits with timers when dealing with monsters and combat and such?

I avoid Wait for anything but the simplest things. Timers give you 100% control over your timing.

I avoid Wait for anything but the simplest things. Timers give you 100% control over your timing.

Thanks, makes sense. So easy to throw in a wait without thinking about it. Need to get out of that habit and get more familiar with timers.

If you don't mind a follow up question: How do you organize your timers? (or more accurately name them)

So lets say it takes a small amount of time for the main character to do certain actions (cast a spell, open a treasure box, prepare special attack, etc) but if hit by enemy that buildup is stopped. So if you had a timer tagged "fireballSpell" & "openChest" & "superPowerUp" etc. you would have to add a stop timer for each one of those tags in the event for the character getting hit, no? Or can you stop all timers for one instance? (of course that might lead to issues stopping all timers, not just relevant timers, for that instance)

Or I was thinking have an instance variable, lets call it timerFunction. Then could do:

On key/button pressed:

-set timerFunction to "fireball" or "openChest" or whatever they are doing

-start timer "mainCharacter" (always keep the tag the same)

On timer "mainCharacter"

-call function character.timerFunction

On main character hit

-stop "mainCharacter"

Sorry I am using you to think my thoughts through but it seems as you are filled with wisdom

Yes, that is essentially a state-machine. You have one timer, but different states within, where you perform different actions based on the state. You may even need sub-states, as your original example had three sub-timer states for the Shoot state.