I was working on my rhythm game engine last night and I hit the Save button. It threw an error. Today: error. What is happening?
Well, first of all, right away, in the Open dialog choose your project and then click Recover to get an older version.
What was the error? Either you can't connect to our cloud server, or your project is too big to save, depending on the error message you got.
You can always save locally by choosing "Export project" from the File menu.
The error log shows that your project is too big. Snap! should be reporting something similar in an error dialog:
client intended to send too large body: 26019861 bytes
(...)
request: "POST /projects/craterize/RHYTIM HTTP/2.0"
Your project weighs 26Mb, while the project size limit is of 10Mb. We may increase it in the future, but that will ramp up server costs so we need to be very careful.
If I have an 18 Mb project could that cause the program to not work correctly. I have a program that does quite a bit and it is not working correctly even though it should be, could it be overloading the server and skipping parts of the program.
The server is not involved in the running of your project; that happens entirely in your own computer. But there is a 10Mb limit for saving projects to the server. You can either save locally, with "export project," or don't save media with the project.
Ok, I have no idea why it isn't working then could someone try and look at it, I will include comments to explain everything in the program. I can't upload it to the cloud because it is 18 Mb and I don't have a way to reduce it. It is a program that so far is supposed to lay out the cards for a solitaire game and something isn't working, I will explain that in the comments. I have been downloading the program to save it and tell me however you want me to get it to you.
If your project is 18Mb there's nothing to figure out; you can't save it because it's too big. Is there another problem for me to debug?
Yeah, its part of the program itself. When I say program I mean the stuff I made, the blocks
I'd say "email it to me" but it's probably too big for that, too. Can you remove the media, save under a different name, share it, and post or email me the URL?
Do you mean the Sprite costumes by media, in which case, you need them to debug the program. I can probably email it to you, via google drive if you have and account.
I sent it, did you get it? The title of the message is Solitaire
Yeah, I'm downloading it now. It was in my spam folder (sigh).
I have discovered that it is also having a problem where it is turning cards face up in the deck pile when it shouldn't be. Also there are cards going to the position one spot and then disappearing and going to the correct spot. I don't know why they are going to position one. If you have any questions just ask because I know I didn't explain the whole thing very well. If you look at what the blocks themselves do you should get a pretty good gist of what's happening.
OK. I was in a meeting all day so I might not get to this until tomorrow evening.
Okay. The immediate cause of your problem is that in SOLITAIRE CARD LAYOUT you assume that RANDOMIZE LAYER LIST is called before any of the cards are added to the layout. But there's no guarantee that the two of hearts will be the first sprite to run this script. So what happens is that partway through placing cards, you (effectively) shuffle the deck. (The block that's called SHUFFLE CARDS doesn't seem to have any purpose; the ordering it creates is never used.)
But this business of parsing the name of a card is way too complicated. Sprites are first class. Get that sprite called COMPUTER to call MY [OTHER SPRITES] to get a list of the 52 cards, in some order or other. You don't care about the order, because once you have the list you're going to shuffle it.
About shuffling: Don't keep picking random numbers hoping to get one you don't already have in a list! At best that will take quadratic time (i.e., 52^2 steps); at worst it will never finish running because, especially when almost all the values have been chosen, you'll keep getting random numbers that are already in the list. Instead, use the standard shuffling algorithm. Note that you use random numbers to choose items from your list of cards, but the list items are sprites, not index numbers.
Now you deal the cards, the same way you'd deal physical cards: You take the first card in the list and put it in the first stack. You take the next two cards and put them in the second stack. "Take" means this:
This simultaneously removes the top card from the deck and reports that card. You position them in the layout by TELLing them where to go.
Saying this another way, parallelism is not your friend when you're trying to deal a hand of cards. You just want one sprite (or Jens likes to use scripts on the stage for this sort of thing) that's in charge.
After you deal 28 cards, what's left is your hand. You're not going to bother layering the remaining cards on top of each other; you'll just have a single clickable card back representing the hand, and when you click it, it pops three cards off the hand onto the discard pile.
Then you can play the game. 
how would you get the computer sprite to make a list of the sprites in order, I see the call block and the my other sprite block, but how do you use the call block, I have no experience with that.
I wasn't exactly sure how to build the Fisher–Yates shuffle in Snap! so I looked it up on scratch and built this.
. Is that what you mean't?
Also how would you use the pop deck block you built. It just reports card, how is that helpful
No, I mean
Don't just blindly copy this; go back to the Wikipedia article and convince yourself that this code implements that algorithm.
As for how to use pop, it doesn't report the word "card"; it reports the card it popped off the deck.
