Some actors can't keep up

Armelline

I've just encountered a minor issue for the second time, and this time it's looking like it might prevent me from entering my game into the Game Jam, so I really need to get to the bottom of it.

The issues is this: I have a bunch of actors on screen, and every x seconds I move them all x pixels, in sync. I'm doing this by having them monitor an boolean attribute, and when that attribute is TRUE, I change their position with a change attribute.

For all but 2 of the actors, this works fine. For 2 of them, they will move a fraction of a second after the others. The actors are spawned in random positions on a grid.

Considerations:

1. It is not the same actors every time (there's randomness to which "walls" are spawned and which aren't)
2. Additional actors are spawned AFTER the first group, and none of these ever exhibit this lag, so it doesn't seem to be an issue with too many actors.
3. If I add more actors, the one or two that are initially affected will remain affected, no new ones will be.
4. They are generally in the same area of the screen. They're not the first actors spawned, but they're in the first 1/4 or so of the total.
5. They are spawned instances of the prototype, they are identical to all the others.
6. I experienced this problem in a project before, where all but 1 of the actors would start moving at the same time, with the last one moving slightly later. In that case I was using a change velocity to move them, so it doesn't seem to be directly related to the change attribute I'm using here.
7. In this previous project, it was a change to an integer that triggered the movement, not a boolean, so attribute type doesn't seem to be the cause.
8. When I display the boolean in a display text on all the actors ("When boolean x is true then display text"), it displays later too on the affected actors.

These actors simply seem to be fed the update to the boolean later than all the other actors. Actors spawned before and after are unaffected, and I can double the number of actors on screen without any others becoming affected.

Anyone have any ideas about this? I'd normally spend time troubleshooting it and pinning down the exact cause or bug in my game or in GameSalad, but with less than 12 hours until the deadline and all my Christmas shopping to do this afternoon, I really don't have time to figure this one out.

Hopscotch

@Armelline, I have something that is maybe related to...

@Armelline said:
4. They are generally in the same area of the screen. They're not the first actors spawned, but they're in the first 1/4 or so of the total.

I have a project where moving Actors start to jitter over a certain area of the screen. There is no interaction between actors, drag, collisions or anything such. Yet actors will move fine, then jitter/lag over the same square area of the screen, then continue smoothly again. Doing this in any movement direction. The cause seems to be a full screen background image, although it only affects a portion of the screen.

Do you notice your issue in creator or device?

Socks

My first thought for situations like this would always be layer order (making sure the actor giving the command to move is beneath the objects being moved), but as they are being spawned this is unlikely to be the issue.

Do you have a camera in the scene (and unlocked actor controlling the camera?)

Armelline

@Socks said:
My first thought for situations like this would always be layer order (making sure the actor giving the command to move is beneath the objects being moved), but as they are being spawned this is unlikely to be the issue.

The "command" actor is indeed below the actors being moved.

Do you have a camera in the scene (and unlocked actor controlling the camera?)

Not a single unlocked actor. No camera control.

@Hopscotch said:
Armelline, I have something that is maybe related to...

The actors will display this odd behaviour wherever on the screen they end up. The affected ones always get spawned in the same general area. I'll see if I can do a quick video, parring it down to just the walls.

Do you notice your issue in creator or device?

Both.

Here's a gif showing the problem. I restart it several times to show that it's only one or two actors and generally in the same kind of place. Also, it seems in my various attempts to fix the problems I accidentally have the far left walls spawning in sight, instead of off the screen. All you're really interested in is the slacking actor at the bottom.

I was trying to get the whole game finished in the 4 hours I had so the spawning is done using GameSalad's loop behaviour, so is far from ideal and can be sped up considerably.

I've never seen a wall do it that wasn't spawned as part of the initial batch.

Edit: Just ran a quick experiment to confirm that the same thing happens with the "Move to" behaviour, and it does. It seems to be related to the specific instances of the actor not seeing the change to the boolean until after all the others.

tatiang

I'd normally spend time troubleshooting it and pinning down the exact cause or bug in my game or in GameSalad, but with less than 12 hours until the deadline and all my Christmas shopping to do this afternoon, I really don't have time to figure this one out.

I'm interested in discovering the cause but it would take time you don't have and time I don't have (still haven't done Christmas shopping nor submitted my Game Jam entry). I don't have a suggestion for a quick fix but I'm happy to help debug the issue a bit later.

Armelline

@tatiang said:
I'm interested in discovering the cause but it would take time you don't have and time I don't have (still haven't done Christmas shopping nor submitted my Game Jam entry). I don't have a suggestion for a quick fix but I'm happy to help debug the issue a bit later.

Yes, I've got my shopping done now but there's no way I'm going to get that game fixed in time. I'll have to just throw together a quick something this evening to get my name in for those sweepstakes. Really sad I didn't get time to work properly on this entry Hopefully this won't be the last jam in the coming months! (Prizes or not I love them.)

When/if I pin down the problem I'll be sure to update this thread!

One extra thing I noticed though, but haven't had time to double-check: The "lagging" actors only ever seem to appear on the first row spawned. If I skip spawning the first row, they'll be on the second.

Socks

@Armelline said:
Edit: Just ran a quick experiment to confirm that the same thing happens with the "Move to" behaviour, and it does. It seems to be related to the specific instances of the actor not seeing the change to the boolean until after all the others.

GameSalad has always (I mean alwaaaaaaays) had an issue with the initial spawned actor when you are spawning multiple actors.

Manto

How do you set the attribute back to false?

Armelline

@Socks said:
GameSalad has always (I mean alwaaaaaaays) had an issue with the initial spawned actor when you are spawning multiple actors.

This isn't the first one spawned, but it's always in the first pass through the loop. Since I was working to a timetable, it was easier to destroy actors than carefully control the spawning. So I'm actually spawning the entire grid but only showing the walls I want to keep, and destroying the rest. So it's probably the 10th-15th actor spawned that the problem occurs in.

Hopscotch

Polishing one and trying to maybe finish a second. If it wasn't for sound.

tatiang

Ah, what's time anyway?

So I created a quick test file (attached) using Move To and noticed that if I activate a boolean change with a click, I don't see the problem you describe... unless I click right after the scene starts:

Could something like an After 0.1 seconds timer help with this issue? Maybe the boolean is changing imperceptibly before the spawned actors have a chance to "see" it.

Armelline

@Manto1 said:
How do you set the attribute back to false?

I tried a few things. In the version in the gif, it's a timer that triggers a set interval after the attribute is registered as true. 0.5s I think I put it at. When I've experienced this problem before, though, the triggering attribute wasn't being set back to false - when a number changed from 1 to 2 everything would start moving, and just like in this example one actor would lag behind.

I've done similar things many many times but only in these two instances did I have this problem.

@tatiang said:
Could something like an After 0.1 seconds timer help with this issue? Maybe the boolean is changing imperceptibly before the spawned actors have a chance to "see" it.

The first switch of the boolean only occurs after the spawning of all the actors is confirmed, so the affected actors will have a self-time of over a second before the first motion begins. (Edit: I just delayed the first boolean switch by 3 seconds to check for sure and still the exact same issue. What particularly confuses me is that the affected actors are some of the earliest to be spawned.)

But lots of good suggestions of things to look at! I'm not rejecting everyone's suggestions, just giving you the information I have now, and will test more extensively, exploring all these possibilities when I have time!

Socks

@Armelline said:
This isn't the first one spawned . . . . So it's probably the 10th-15th actor spawned that the problem occurs in.

Strange !?

colander

I know booleans can cause problems like try putting two of them in a Display Text behaviour and they won't display. I am just taking a stab at it, have you tried using an integer instead of a boolean type attribute?

Armelline

@colander said:
I know booleans can cause problems like try putting two of them in a Display Text behaviour and they won't display. I am just taking a stab at it, have you tried using an integer instead of a boolean type attribute?

Yes. It changes nothing, unfortunately.

(Regarding the display text issue, that's a limitation of Lua, the programming language GameSalad is built on top of, not an issue with GameSalad itself. One of the GS staff addressed it recently but I don't have the link to hand.)

The_Gamesalad_Guru

Curious puzzle for sure. Many of my thoughts on it have already been suggested. How about breaking the spawning logic into two different actors as I imagine your looping over a table. I found that breaking loops like that into two different actors on scene sped things up quite considerably.

Armelline

@The_Gamesalad_Guru said:
Curious puzzle for sure. Many of my thoughts on it have already been suggested. How about breaking the spawning logic into two different actors as I imagine your looping over a table. I found that breaking loops like that into two different actors on scene sped things up quite considerably.

I was going for quick and dirty, so I was using no tables. The spawners were just spawning one row, then the next, then the next etc. basing the spawn positions of row/column and grid size. That said, I am spawning a horizontal and a vertical line on each pass.

Now that things will start calming down a bit and now that I don't have a Jam deadline to meet I'll perhaps try starting over and doing it properly, rather than fast, and see if the problem repeats. If not, then I'll hopefully be able to pin down the shortcut I took that causes it, and if so, well we'll still be able to rule out a ton of potential causes.