I hope this is the right forum for my question.
I am working on a project and have been encountering some rather serious bugs that I am having difficulty fixing.
My working hypothesis is that my scripts for an individual sprite have gotten much too long and are the source of my bugs.
What is happening is that I have specific events that occur when a certain action takes place. In this particular case, when the "spacebar" is pressed. The problem is that when the "spacebar" is pressed, the correct action that should happen as a result, will take place for one sprite, but will only occasionally take place for the other sprites.
Sometimes all sprites will act as they are supposed to, but not always.
My best guess is that because of the length of the scripts, that when I press the spacebar, depending on where the computer is executing a script, by the time the computer gets around to the sprite that "should" be reacting, the sprite has moved on and the condition is not met.
Has anyone else experienced significant lag and bugs because of the length of their scripts? And if so, what is the optimal length of a script within a sprite to minimize this effect?
Here is a link to the project containing said bugs.
If you look at my other project, specifically Quidditch0.2, the bugs are not present.
Any ideas or thoughts would be greatly appreciated.
Thanks
Offline
That is a very intriguing discovery.
I am surprised that it would do that... from what I've seen of the source code, long scripts should not interfere with events.
One thing I have found is that long scripts are sometimes cut off at the bottom, or the sides. This is an essential limitation that squeak places on morphs, to conserve memory. What you can do to break them up is to use broadcasts. Like this:
<when green flag clicked>
execute code block 1...
<broadcast[ 1 ]]
<when I receive[ 1]]
Code block 2
<broadcast[ 2 ]
[/blocks]
and so on.
You can also put reporters into the broadcast block.
(unfortunately not the when I receive block. This feature will be in Streak 0.2, and once you have embedded a reporter into the when I receive block in streak, you can switch to compatible mode, and save to scratch format! (*.sb). Now, the reporter works in scratch, too!)
Anyhow, you can use variables to make life a bit easier:
<when green flag clicked>
<set{ var }to( 1
CODE BLOCK 1
<broadcast[ <{ var }>
<when I receive[ var
<change{ var }by( 1
CODE BLOCK 2
<broadcast[ <{ var }>
etcetera.
Offline
Yeah I get that bug too. Sucks when you spend so much time making a script to see that scratch uses it to slow you down.
It creates a ton of lag in the editor so trying to move blocks is a pain.
Last edited by archmage (2009-07-27 19:57:57)
Offline
Yes. One thing that helps is to edit portions of script, and when it is complete snap it onto the main one.
Offline
I will need to experiment with the broadcasts. I have suspected that they will be a more efficient way for me to accomplish some of the things I am trying to do. I particularly like your idea of setting broadcasts up as a variable, which allows me to adjust the broadcast more fluidly.
I have to admit that it seems very odd that the length of scripts should have such a noticable impact upon the speed of my project. We are talking about modern computers and not the dinosaurs I was using in the late '80s.
But what do I know. I have just been using the program for a little over a week.
Thanks.
Offline
RoyandAnna wrote:
I will need to experiment with the broadcasts. I have suspected that they will be a more efficient way for me to accomplish some of the things I am trying to do. I particularly like your idea of setting broadcasts up as a variable, which allows me to adjust the broadcast more fluidly.
I have to admit that it seems very odd that the length of scripts should have such a noticable impact upon the speed of my project. We are talking about modern computers and not the dinosaurs I was using in the late '80s.
But what do I know. I have just been using the program for a little over a week.
Thanks.
Well, I must commend you. It took me months before I could comprehend scripts longer than the script pane!
As well, those must contain a lot of control bars. Those only confuse newbies further!
And also, it is not the computers, it is just the way smalltalk works. But, with time, I think that that will improve, too.
Offline
billyedward wrote:
Well, I must commend you. It took me months before I could comprehend scripts longer than the script pane!
As well, those must contain a lot of control bars. Those only confuse newbies further!
And also, it is not the computers, it is just the way smalltalk works. But, with time, I think that that will improve, too.
I would not say it because of any skills I might possess but rather a testament to the ease of Scratch. I have little to no programming experience but I found Scratch very easy to use. The length of the scripts in my project (because at this point I only have one) is due to the fact that since there are 14 players and 4 balls in Quidditch. Each one has to be able to interact with the others.
If I was starting my first project over, I don't think I would have picked something quite as complicated as Quidditch.
I working on changing the passing scripts to use the broadcast function now over my lunch break. I will try and post it once it actually works.
Thanks.
Offline