Scratch

chriskneller; a simple solution to your problem would be to add a forever block surrounding the script that causes it to move up if touching green at the beginning. For example,

forever  

if <touching color [#00FF52]?> 

change y by (10)
end

end

Last edited by zubblewu (2012-10-20 14:36:48)

zubblewu wrote:

chriskneller; a simple solution to your problem would be to add a forever block surrounding the script that causes it to move up if touching green at the beginning. For example,

forever  

if <touching color [#00FF52]?> 

change y by (10)
end

end

Does this make sense? Basically, it would cause the sprite to move up if it was touching the green. This is the solution I see that would least modify the scripts. You could rescript the whole thing, but that would ruin the point of them creating it. When I tested this, it worked consistently, and you could still jump.

But the problem with that is that walls couldn't be added to the game later on. And your solution would only affect the green platform, not the others.

To chriskneller:
I finally decided to use a sensor to solve your problem and I also cleaned up some of your scripts. Here it is:
(link to project)

Last edited by ErnieParke (2012-10-20 15:40:53)

zubblewu wrote:

ErnieParke wrote:

zubblewu wrote:

chriskneller; a simple solution to your problem would be to add a forever block surrounding the script that causes it to move up if touching green at the beginning. For example,

forever  

if <touching color [#00FF52]?> 

change y by (10)
end

end

Does this make sense? Basically, it would cause the sprite to move up if it was touching the green. This is the solution I see that would least modify the scripts. You could rescript the whole thing, but that would ruin the point of them creating it. When I tested this, it worked consistently, and you could still jump.

But the problem with that is that walls couldn't be added to the game later on. And your solution would only affect the green platform, not the others.

To chriskneller:
I finally decided to use a sensor to solve your problem and I also cleaned up some of your scripts. Here it is:
(link to project)

But, considering what is in the project, what i posted is the least modification possible. Those are the scripts that their student made, and they probably don't want to change them.

Yes, I know that this requires less modification, but does it solve the problem? I just redownloaded chriskneller's project and did exactly what you recommended chriskneller to do. Now you can jump through the bottom of green platforms, you can still walk through any platform, Mario is jittery, and jumping only works half of the time.

Last edited by ErnieParke (2012-10-20 17:28:47)

zubblewu wrote:

ErnieParke wrote:

zubblewu wrote:

But, considering what is in the project, what i posted is the least modification possible. Those are the scripts that their student made, and they probably don't want to change them.

Yes, I know that this requires less modification, but does it solve the problem? I just redoenloaded chriskneller's project and did exactly what you recommended chriskneller to do. Now you can jump through the bottom of green platforms, you can still walk through any platform, Mario is jittery, and jumping only works half of the time.

Let me stress least modification. I'm not saying it's perfect, or even good, but it works, and it's the least modification probably. Do you think I should rescript it like this or something? ...

No, but when you try and fix a glitch, you shouldn't introduce several other glitches. Look, I'm not criticising the way you fix glitches; I was trying to point out that your idea introduced new glitches which orignally souldn't have been there.

Last edited by ErnieParke (2012-10-20 18:11:45)

zubblewu wrote:

ErnieParke wrote:

zubblewu wrote:

Let me stress least modification. I'm not saying it's perfect, or even good, but it works, and it's the least modification probably. Do you think I should rescript it like this or something? ...

No, but when you try and fix a glitch, you shouldn't introduce several other glitches. Look, I'm not criticising the way you fix glitches; I was trying to point out that your idea introduced new glitches which orignally souldn't have been there.

Well, I'm thinking this is a special case since it isn't a random user, but rather a student in a class. We should, IMHO,give the least possible modification for them.

True, but then agian, these modifications could help teach the student a thing or two about Scratch. Also, if they don't want the modifications, they aren't forced to use them.

Last edited by ErnieParke (2012-10-20 18:47:04)

JH1010 wrote:

ErnieParke wrote:

zubblewu wrote:

Well, I'm thinking this is a special case since it isn't a random user, but rather a student in a class. We should, IMHO,give the least possible modification for them.

True, but then agian, these modifications could help teach the student a thing or two about Scratch. Also, if they don't want the modifications, they aren't forced to use them.

Please don't start a flame war.

Sorry. I didn't even notice that it was going that direction, so thanks for catching it. I really do need to be more careful next time.

Wernich wrote:

hello

i am working on an project and i am stuck. how do you throw or shoot an object relative to the scrolling? i want the object to go towards where i click on the screen relative to the scrolling sprite?? so if the player sprite moves in the game the projectile will not move slower or faster it will move like in real life. currently i just moves 4 steps in the direction of the mouse and if i move back it goes slower because of the scrolling and forward it goes faster.

Please I am a rookie still in school and it is my passion please help me.

I am going to assume that you have a scroll x variable. Just put this script on the projectile:

When I receive [insert broadcast name here v]
forever
change x by <(0)-(scroll x)>

Last edited by JH1010 (2012-10-21 13:29:29)

Hey Wernich, I answered that question in both of your posts.

genxjin wrote:

hi, I'm a newbie and  i have been working on my game for a project for a week now but i can't come up with the following:
a.) how to come up with a YOU WIN & GAME OVER ending.
b.) my sprites end up moving around in limbo despite my timer hits 0. once the timer continues to show -1 it keeps on playing the game     can you please help me?

I assume that once the timer goes below 0 that the game ends, right? Well then, this isn't the best method, but you could use this in your You Win/You Lose sprite:

when gf clicked
hide
set [timer v] to (1)//To make sure that the game doesn't end the game early.
forever
 if <not <(timer*) > (0)>>//Ignore the *.
  if (winning?)//Whatever you use to know if you're winning.
   switch to costume [You win! v]
  else
   switch to costume [You lose! v]
  end
  show
  go to front
  stop all//Stops the game and all sprites.
 end

Last edited by ErnieParke (2012-10-21 21:06:52)

Can you give me code for all the scratch blocks?

JH1010 wrote:

Wernich wrote:

hello

i am working on an project and i am stuck. how do you throw or shoot an object relative to the scrolling? i want the object to go towards where i click on the screen relative to the scrolling sprite?? so if the player sprite moves in the game the projectile will not move slower or faster it will move like in real life. currently i just moves 4 steps in the direction of the mouse and if i move back it goes slower because of the scrolling and forward it goes faster.

Please I am a rookie still in school and it is my passion please help me.

I am going to assume that you have a scroll x variable. Just put this script on the projectile:

When I receive [insert broadcast name here v]
forever
change x by <(0)-(scroll x)>

OMG New Scratchblocks look!

They're back to normal now.

Seil wrote:

I would be interested in signing up. 

I'm not a great Scratch programmer and I find bugs in my programs all the time. But I can extricate them relatively quick though. Sometimes 

You are in!

leewyndelf wrote:

I just made a separate thread with this question, but in case this is faster - I'm making a game with a sprite with one "costume."  I'd like something different to happen when another sprite is touching the front of him versus the back of him.  Is that doable?

Thanks!

Yes, but I am not sure exactly how, you would need to use the layers block, the sensing blocks and the effect blocks (so that there is still only 1 costume).

TheSupremeOverLord wrote:

Can you give me code for all the scratch blocks?

What do you mean?

Nodrogchavez wrote:

I have a script built, but the file opens with the numerous sprites showing until the Start flag is clicked. When it is clicked they all Hide. How can I start with a blank page, or alternately, one that has a brief one-line comment or an arrow moving on an angle to the Start flag in the upper right corner?

This will not be a problem online because it presses the green flag as soon as it loads.

genxjin wrote:

ErnieParke wrote:

genxjin wrote:

hi, I'm a newbie and  i have been working on my game for a project for a week now but i can't come up with the following:
a.) how to come up with a YOU WIN & GAME OVER ending.
b.) my sprites end up moving around in limbo despite my timer hits 0. once the timer continues to show -1 it keeps on playing the game     can you please help me?

I assume that once the timer goes below 0 that the game ends, right? Well then, this isn't the best method, but you could use this in your You Win/You Lose sprite:

when gf clicked
hide
set [timer v] to (1)//To make sure that the game doesn't end the game early.
forever
 if <not <(timer*) > (0)>>//Ignore the *.
  if (winning?)//Whatever you use to know if you're winning.
   switch to costume [You win! v]
  else
   switch to costume [You lose! v]
  end
  show
  go to front
  stop all//Stops the game and all sprites.
 end

I hope that this helps!

--------------------------------------
Hi Ernie, first of all thank you very much for your reply. Appreciate it very much.  While waiting for your help, i tried working on several scripts how to solve my problem but i always end having my sprites freeze up like crazy and unable to respond to my script for the you win / game over sprite    i know i may lack or oversee something on the script but i can't figure it out until now. here is the original script i wrote for:

YOU WIN Sprite

when gf clicked
hide
forever <(score) > [50]>
    show
end
stop all

GAME OVER Sprite

when gf clicked
hide
forever <(score) <  [50]>
    show
end
stop all

STAGE Sprite

when gf clicked
set [score v] to (0)
set [time v] to (10)

when gf clicked
forever
   wait (1) secs
   change [time] by (-1)
   play sound [cave] until done
end

P.S. my other sprites works well on the stage however when i make the scripts for you win / game over, my other sprites over laps the background for you win/game over and freezes.

JH1010 wrote:

TheSupremeOverLord wrote:

Can you give me code for all the scratch blocks?

What do you mean?

I think TheSupremeOverLord is talking about the scratchblocks code.

To TheSupremeOverLord:
I could give you every scratch block there is in scratch, but do you know how long that would take to type? Instead, I'll tell you a different way. To make a scratchblock, put it between [scratchblock] [/scratchblock] tags. Then, type what you would see in Scratch. For example, in scratch, the green flag hat block has "when gf (green flag) clicked", so that's what you would type. The one exception to this are the c-blocks (repeat, if, ect.. Excluding forever and forever if.) which you'll have to put "end" where you want the c-block to end. Also, there should only be one block per line.

Now into the finer deatails:
If you want to add a drop down menu, use [ v]. If you want to add a place where you can type, again use ( ) or [ ]. And if you want to add arrows, type cw (clockwise) or ccw (counter-clock wise). Finally, if you want to leave a comment, use // after a scratchblock and type your comment after the two dashes.

Into conditionals/variables (mouse down?, touching [Sprite1 v]?, ect...): Basically, they follow the same rules as above, except variables should have parentheses around them. Also, conditionals (the blocks with green, pointy ends) should have < and > surrounding them.

Here's a sample code:

when gf clicked
set [pie v] to (98)
if <not <(pie) = (5)>>
 repeat (5)
  turn cw (5) degrees
  say [Pie!] for (5) secs//This is a comment.
 end
end

[scratchblocks]
when gf clicked
set [pie v] to (98)
if <not <(pie) = (5)>>
 repeat (5)
  turn cw (5) degrees
  say [Pie!] for (5) secs//This is a comment.
 end
end
[/scratchblocks]

Now that you know the code, you could practice making scratchblocks here.

I hope that this helps!

Last edited by ErnieParke (2012-10-26 15:41:56)