Relationship Between Clones and Lists?

CantStopWishiwashi

Hi there!

I'm working on a grid based game at the moment that uses a list to determine the position of various cars (clones) on a 6x6 grid. I seem to be having some issues, however, with the clones reading the list, and as such my collision sensing is messed up. What's confusing me is the fact that one clone (the first created) is reading the list perfectly fine. The list is not local (meaning it is accessible to all sprites in the project), and all the list blocks the clones use are underneath a custom block. I have also determined that all clones are able to call the custom block itself, so the issue does appear to be reading the list.

As of right now, my best guess is that only one clone can read the list at a time (which makes no sense at all). If this is the case, can someone tell me how to work around it (preferably while still using a list system)? If not, can someone tell me exactly how clones read and modify lists, and how many of them can do it at a time.

I've included a link to the project here.

And I don't think this is going to help at all, but just in case here's my tech info:

*My browser / operating system: MacOS Macintosh X 10.13.5, Chrome 70.0.3538.102, Flash 32.0 (release 0)*

Thanks in advance,
-CSW

Last edited by CantStopWishiwashi (Dec. 23, 2018 18:49:31)

deck26

Can you share it on Scratch so we can actually look at it? There should be no issue in clones accessing a global list. Scripts run one at a time so there is only ever one clone modifying the list.

CantStopWishiwashi

deck26 wrote:
Can you share it on Scratch so we can actually look at it? There should be no issue in clones accessing a global list. Scripts run one at a time so there is only ever one clone modifying the list.

Here's the incomplete glitchy version.

Last edited by CantStopWishiwashi (Dec. 23, 2018 18:48:50)

deck26

So please tell us how to replicate the problem.

deck26

If I was you I'd use a list to represent the whole grid rather than the occupied spaces. Set a cell to 0 if the square is empty and 1 if it is occupied. For any vehicle store the leftmost or highest cell number depending if horizontal or vertical and also store the length.

So, for example to move a 2-cell car right when the leftmost cell is cell 5 we perhaps need to check if cell 7 is empty. If it is empty we can change the car's leftmost cell number to 6 and set cell 5 to 0 and cell 7 to 1.

CSW_Alt

deck26 wrote:
If I was you I'd use a list to represent the whole grid rather than the occupied spaces. Set a cell to 0 if the square is empty and 1 if it is occupied. For any vehicle store the leftmost or highest cell number depending if horizontal or vertical and also store the length.

So, for example to move a 2-cell car right when the leftmost cell is cell 5 we perhaps need to check if cell 7 is empty. If it is empty we can change the car's leftmost cell number to 6 and set cell 5 to 0 and cell 7 to 1.

The issue with representing the whole grid is that the list is constantly refreshing. This means that more than 30 times per second (due to running w/o screen refresh) the entire list is being deleted and refilled with new values (which may or may not have changed in the last fraction of a second) which are placed in a random order. For me to get everything added in the right order would require re-writing pretty much all scripts related to the process and replacing them with scripts that control the order in which the coordinates are added, resulting in a massive loss of speed due to waiting for other clones to add their value.

I'd rather not have to replace a lot of scripts if I can help it, I'm looking for a way to fix the ones I have right now.

deck26 wrote:
-snip- There should be no issue in clones accessing a global list. Scripts run one at a time so there is only ever one clone modifying the list.

I need the clones to be able to read the list, not modify it. And I need to have a lot of them (half a dozen or more in some cases) reading it at the same time. I've confirmed on my own that the clones are capable of reading a list, I just need to know how many of them can do it at the same time.

Last edited by CSW_Alt (Dec. 24, 2018 16:13:38)

deck26

Can you explain what happens to the list when one vehicle moves? How does it know which list items to change?

Only one script is running at any one time so there is never a case of things happening at the same time. Even things like gliding happen in sequence with other scripts - move the sprite a bit, do other things, move the sprite again and so on. So I repeat, there is no problem multiple clones reading the list ‘at the same time’.

deck26

Have to say I'm finding it almost impossible to follow your code but it looks to me as if the horizontal vehicles move OK but the vertical ones don't. That would suggest either a difference between Set yPos and Set xPos or CheckPos not being general enough to code both types of movement.

But if you're going to code individual clones and different layers separately you're really going to end up with a nightmare to manage. You should always try to generalise your code as much as possible. In this type of project the scripts shouldn't need to change from one level to the next, all you need is to use lists recording starting positions.

It may seem like more work to start again and code things the way I suggested but in the long run you'd actually be quicker doing so.

Last edited by deck26 (Dec. 24, 2018 17:22:38)

CantStopWishiwashi

deck26 wrote:
Only one script is running at any one time so there is never a case of things happening at the same time. Even things like gliding happen in sequence with other scripts - move the sprite a bit, do other things, move the sprite again and so on. So I repeat, there is no problem multiple clones reading the list ‘at the same time’.

Okay but it still seems that only one clone is reading the list and acting accordingly. And about multiple scripts running at the same time: I misunderstood what you meant, I know the basics of how computers work and how one core can do one thing at a time.

deck26 wrote:
Have to say I'm finding it almost impossible to follow your code but it looks to me as if the horizontal vehicles move OK but the vertical ones don't. That would suggest either a difference between Set yPos and Set xPos or CheckPos not being general enough to code both types of movement.

But if you're going to code individual clones and different layers separately you're really going to end up with a nightmare to manage. You should always try to generalise your code as much as possible. In this type of project the scripts shouldn't need to change from one level to the next, all you need is to use lists recording starting positions.

It may seem like more work to start again and code things the way I suggested but in the long run you'd actually be quicker doing so.

The vertical ones don't? Hmm… I'll have a look at that right away. The main thing I need help with though is getting the cars to have hit detection. And I know about generalization, that's why I tried to make the Set x/y Pos blocks work for every type of car (and same for the Check Pos block).

deck26 wrote:
Can you explain what happens to the list when one vehicle moves? How does it know which list items to change?

There are 36 clones that use the ghost effect to remain hidden that represent the grid on which the cars move. Each clone represents one tile and has an ID (for example, the one in the very top left is 11, to its is 21, etc.) Every fraction of a second (around 30 times per second, varying slightly because of FPS) the parent sprite deletes the list while the clones check to see if they are touching a vehicle. If they are, they add their position to the list. If not, they do nothing. Thus, roughly 30 times each second, a list filled with the coordinates of all cars refreshes.

Last edited by CantStopWishiwashi (Dec. 27, 2018 15:42:06)

deck26

Sorry, but it really just doesn't seem like a sensible approach. Deleting and recreating a list every frame and managing clones to only do things at the right time just seems so unnecessary and overly complex. Only one item can be moving at a time so you really don't need to be doing that amount of work. The clones are moving in response to the mouse being on them so I'm not sure you're in control of when the clones try to move in relation to everything else you're trying to do.

As far as I can see you're not actually controlling the order in which things happen - the SqDetect clones are adding themselves to the list in a forever loop but that could happen before the sprite has cleared the list so that entry may not be in the list when a vehicle tries to move. It might be OK but depends on the layering of the sprite and clones being correct.

Some vehicles move OK and some don't is my impression. The first clone in particular doesn't seem to move - I disabled the ice cream van and played with the repeat block creating clones and it is consistently the first clone that can't be moved. The others may be OK.

If I then swap the contents of the if blocks so clone 1 is created where clone 2 is and vice versa it is the horizontal clone 1 which now doesn't work. So that looks to me as if it is the first clone that is created that is the problem rather than its position or direction. Which suggests some sort of timing issue - eg clone 1 runs a script before something is ready and thus fails but the other clones timing is OK. That brings me back full circle to the things I said above!

deck26

Why not do a broadcast and wait after each single block move. The SqDetect clones could then respond to that broadcast instead of running a forever loop. Perhaps deleting the contents of the list before the broadcast is made.

sippingcider

Multiple clones can read a list “at the same time” (not exactly the same time of course, but they can do what you are describing), I am working on a project right now that has clones reading from a list “at the same time” and it works. I suspect the issue is exactly as deck26 says and something like this is happening:

-grid clones that touch a car clone add their position to occupied spaces
-some of the car clones will read from the accurate list
-occupied spaces is cleared
-the other car clones read from an empty list
-grid clones that touch a car clone add their position to occupied spaces, now the list is accurate again

Ideally, at least for scripts that need to be synced precisely, there should only be 1 forever loop running. Using broadcasts in the single forever loop you can control when scripts are run precisely.

That said, we can fix this issue with only a few changes to your script if you are not wanting to do a lot of changes. Instead of the grid clones checking in their “when I start as a clone” forever loop, move that script under a new “When I receive CheckPositions” block. Move the “update occupy list” block out of the forever loop (which can be deleted) and move it under a new “When I receive ClearPositions” block. Then, whenever a car clone moves, all it needs to do is broadcast ClearPositions and then CheckPositions, which is just 2 blocks to add to all that code.

deck26

sippingcider wrote:
Multiple clones can read a list “at the same time” (not exactly the same time of course, but they can do what you are describing), I am working on a project right now that has clones reading from a list “at the same time” and it works. I suspect the issue is exactly as deck26 says and something like this is happening:

-grid clones that touch a car clone add their position to occupied spaces
-some of the car clones will read from the accurate list
-occupied spaces is cleared
-the other car clones read from an empty list
-grid clones that touch a car clone add their position to occupied spaces, now the list is accurate again

Ideally, at least for scripts that need to be synced precisely, there should only be 1 forever loop running. Using broadcasts in the single forever loop you can control when scripts are run precisely.

That said, we can fix this issue with only a few changes to your script if you are not wanting to do a lot of changes. Instead of the grid clones checking in their “when I start as a clone” forever loop, move that script under a new “When I receive CheckPositions” block. Move the “update occupy list” block out of the forever loop (which can be deleted) and move it under a new “When I receive ClearPositions” block. Then, whenever a car clone moves, all it needs to do is broadcast ClearPositions and then CheckPositions, which is just 2 blocks to add to all that code.

Both should ideally be broadcast and wait. That's pretty much along the lines of what I was suggesting.

sippingcider

deck26 wrote:
Both should ideally be broadcast and wait. That's pretty much along the lines of what I was suggesting.

Oh yeah, broadcast and wait should be better (although I fear it might slow down the project?). And it is what you were suggesting, I just thought it might help if two people explained it in different ways since from the looks of this post Can'tStopWishiWashi wasn't believing you.

Last edited by sippingcider (Dec. 28, 2018 14:19:40)

deck26

sippingcider wrote:
deck26 wrote:
Both should ideally be broadcast and wait. That's pretty much along the lines of what I was suggesting.

Oh yeah, broadcast and wait should be better (although I fear it might slow down the project?). And it is what you were suggesting, I just thought it might help if two people explained it in different ways since from the looks of this post Can'tStopWishiWashi wasn't believing you.

No problem at all, just wanted to make it clear.

I tend to take the view that if a broadcast and wait is slowing something down then it is probably required as otherwise the script probably wasn't completing fast enough to reliably let the other code keep running anyway. May be a naive approach. Not sure there's any need for a ClearPositions broadcast - the script that would be broadcasting can just clear the list before making the CheckPositions broadcast.

CSW_Alt

Alright, I'm sure there's something in here that will fix my problem, so thanks. I'll be sure to read it all whenever I get motivation to work on Scratch again, but right now I'm not really feeling anything. So thanks.

Discuss Scratch