Hello everyone, today we will talk about some typical bugs we encountered in programming using Scratch, I believe you have encountered them, the name I mentioned here is a little more professional, but I hope you can read the entire article , maybe you have encountered it, give the author a follow and praise!
first
In order to ensure that the bug is not caused by your own carelessness, you have to do this:
1: Reread the code to ensure that the logic is correct
2: Read the return part , for example, to see if the first n in [list] will be written as {the first n in [list] of [list]
Then, it's a question of knowledge
Frequently Asked Questions for Scartch Beginners
size limit
You may find at some point that if you set the character size to a super large number, the size of the character will not be set according to your ideal, then you can choose to create a blank shape at this time.
This shape does not need to be drawn, just leave it empty, then you first switch the shape to this blank shape, and set the size you want at this time, and then switch the shape to the shape of your character, and you will Found that you set up successfully.
movement restrictions
Sometimes we find that the character cannot move out of the stage area no matter how we move it. This is a very troublesome thing. We cannot hide the character outside the stage area. A particularly large shape, the shape size of this shape needs to be larger than the shape size of our original character shape, and it is much larger, and then we repeat the execution, first switch to the larger shape, and then execute the movement code (for example, x Increase by 10), and finally switch to the original shape of our character, and then you keep moving, until you move out of the stage area, it proves that you have succeeded.
clone restriction
In the original version of Scratch, the number of clones in a game cannot exceed 300, that is to say, the total number of clones of all characters cannot exceed 300, because if there are more than 300, Scratch will not clone for you. It is the 301st clone, so we need to reduce the use of clones, and try to find ways to make works that do not exceed 300 clones and do not affect the player experience
brush limit
Sometimes we will find that after we draw a shape with the brush, and then move the character above the shape drawn with the brush, we will find that the character completely blocks the shape drawn with the brush, so how to solve it? I'm really sorry, this problem can't be solved, you can only try to synthesize it as much as possible, either use brushes to make games (HPP works are pure brushes), or don't use brushes to make games.
Scratch multithreading limitations
I'm testing in the new version of Scratch (Scratch3.29.1), if there are some special codes in the program (I don't know what the special code is), Scratch can't run too many programs, for example, if I send a broadcast, If you have enough receivers, there will definitely be a situation where the receiver does not receive the message. I call this situation the Scratch multi-thread limit.
So, how to reduce the interference of Scratch multi-threading restrictions on us?
broadcast less, use clones
As we all know, the number limited by Scratch's multi-threading limit is very small, but our clones can clone 300! This means we can execute 300 programs with the clone! This perfectly solves the limitation problem that we have occurred. How to implement this operation?
We only need to clone a character, and then put the code of this character under the code of "when the clone starts", this perfectly solves the problem, and we have freed up a space for multi-threading. So, it's not over here, what do we do if we want to make broadcasts? When our clone receives the broadcast, we need to make a judgment whether it is a clone, but you have to pay attention, our broadcast is sent to all units, this unit includes the body and the clone, that is to say, our body It will also receive this broadcast and make a judgment to judge whether it is a clone. This is very bad. The execution code of the ontology will occupy the multi-thread space, so how can we solve this problem at this time?
It's very simple, using variables, for example, we set the variable to 0, and then the clone waits for this variable = 1 when cloning, that is to say, wait until the variable is equal to 1 to execute the code, and then if we want to broadcast, we can Set this variable to 1, and the clone receiving the broadcast can know what to do next, just add the program we want to carry out after the "wait" code, if you want the clone to detect every moment , that is to say, you can receive this broadcast more than once, then you can use the following program:
when the clone starts
If <the current clone is the recipient of this broadcast>
Repeat
wait <(variable)=1>
Code to be executed after the broadcast is performed
wait < [(variable)=1 false] >
This perfectly solves this problem, that is, wait for the broadcast to be broadcasted, but I still need a setting for this method, that is, when the variable is set to 1, that is to say, when broadcasting, you will have to wait a few more frames Reset the variable to 0 so our above code works
Scratch running speed problem
homemade building blocks
There is a little-known problem with self-made building blocks, such as the following picture:
figure 1
figure 2
Let me introduce to you first, this is a big map engine. It seems that the effect of Figure 1 and Figure 2 is the same, but I can tell you responsibly: the effects of these two are different! Because the self-made building blocks will consume time when reading the "detectable entity", but there is no such step in Figure 1. It turns out that the collision code in Figure 1 is ideal, but the code in Figure 2 is very poor. Therefore, it is more recommended to replace it with the original one when using the self-made building block Boolean value. Generally speaking, it should be used less.
broadcast
For example, a broadcaster sends a broadcast, and the receiver receives the broadcast. Although this step is ordinary, it actually takes time in the middle. That is to say, the broadcasting process takes time, so everyone usually pays more attention to it. This problem, when there is a problem with the broadcast, see if it is the problem.
Scratch shortcomings cause problems
Homemade building blocks do not refresh the screen
If you place a building block that takes time to run under the self-made building block that does not refresh the screen, then your computer will be particularly stuck, because Sc does not care whether you have a waiting time building block, so please pay attention
press a special key
So far, in addition to conventional keys, Sc can detect keys such as enter, shift, etc. (the operation method is to let the return value block return the name of the key, such as connection blocks, variable blocks, etc.), but like some system keys cannot Detection, such as backsapce, esc, tab, etc., so don't try it yourself.
end
I am self-taught programming, and these points are all painstakingly studied by me. Few people will tell you about this, and I hope everyone can give a lot of support to Kaserhama, it is really not easy to do this tutorial. Of course, there are still some features that are not mentioned here, because this tutorial only talks about a few typical problems, I hope everyone can bookmark them for me, thank you!