I'm making this unit defense game and I've encountered an issue. I'm trying to make unit 1 clone itself and move according to itself on ScrollX. It doesn't work; I used my friends script. I need some general help in making a clone system that makes a unit move on the scroll.

https://scratch.mit.edu/projects/92132220/

MathlyCat wrote:

asivi wrote:

My post were helpful.
Please report me if it weren't.

I won't report you just because you patronize me to. I think your posts are fine and you made a mistake.

It is either one or the other. Asivi has not made any “mistake” you are simply calling xer post “disrespectfu” because you felt that a pointer was disrespectful. Xe was just trying to help yi=ou get your post the best quality responses. I mean no disrespect in this post, but I would prefer you don't take pointers as disresectfulness. My phrasing may have been bad, as it is late in the UK, but if this wasn't hrased kindly, could you rephrase it in a kind way, and then read it again.

[/offtopic rant]

In generl, a scrolling game with clones would have the clones hide/deleted when they are off the screenn, and then set their x to the variable that you are using to scroll minus a constant to get a value between -240 and 240.

^^^^

</endofargument>

I get the general idea, but I'm still having trouble wrapping my head around it.

Okay, I was reading your code, and though I haven't tried the clones yet (you don't have code for creating them), it would benefit if it were rewritten using “tick” broadcast instead of concurrent forever loops, because the latter would cause race conditions.

Put this in a sprite which you would like to use for main control (of the backdrop!):

when green flag clicked
broadcast [tick v] and wait

Instead of operating on their own forever loops, the other sprites would run the code when the “tick” message is received.

when I receive [tick v]
doStuff::grey
//instead of

when green flag clicked
forever
    doStuff::grey
end

To expand my point about race conditions, I noticed that your clones use two forever loops. They should use one, so you, as the programmer, are sure in what order commands are being executed.

Chibi-Matoran wrote:

Okay, I was reading your code, and though I haven't tried the clones yet (you don't have code for creating them), it would benefit if it were rewritten using “tick” broadcast instead of concurrent forever loops, because the latter would cause race conditions.

Put this in a sprite which you would like to use for main control (of the backdrop!):

when green flag clicked
broadcast [tick v] and wait

Instead of operating on their own forever loops, the other sprites would run the code when the “tick” message is received.

when I receive [tick v]
doStuff::grey
//instead of

when green flag clicked
forever
    doStuff::grey
end

To expand my point about race conditions, I noticed that your clones use two forever loops. They should use one, so you, as the programmer, are sure in what order commands are being executed.

I'll try the tick trick (oh rhyme!) and the extra forever was a leftover script from my friend; I already looked at it suspiciously.

Oh yeah, how exactly would I use the tick? As a green flag replacement? Little fuzzy there.

No, tick would be used as a replacement for the forever loop. Only one forever loop would exist in the project, which would broadcast “tick” and wait, and all other sprites would respond to it in sync (instead of having multiple forever loops at different points of execution).

For more information, search up “game loops.”

Chibi-Matoran wrote:

No, tick would be used as a replacement for the forever loop. Only one forever loop would exist in the project, which would broadcast “tick” and wait, and all other sprites would respond to it in sync (instead of having multiple forever loops at different points of execution).

For more information, search up “game loops.”

I'm one for seeing examples

If you can get an example I'd love to see! I'll try to do what you asked.

For examples, see inside Griffpatch's games, which often use the game loop. Let's look at Geometry Dash:
https://scratch.mit.edu/projects/105500895/#editor

The “Player” sprite broadcasts “tick,” and the other sprites respond to it. Griffpatch explain the concept well in this other project: https://scratch.mit.edu/projects/23134940/#editor

Notice that this script has “pre animate” and “animate” broadcasts, instead of one “tick” broadcast. Sometimes, the values are recalculated (such as new coordinates) before the sprites update their appearances on the screen.

Zro716 also uses the game loop, in his “Dogfight” project: https://scratch.mit.edu/projects/107641809/#editor . The broadcast for recalculating values is called “Update” and the broadcast for changing the sprite appearances is called “Render.” Zo716's game loop is in the backdrop, rather than the first sprite.



EDIT: You ninja'd me, but in the post, you were asking for examples, so…

Chibi-Matoran wrote:

For examples, see inside Griffpatch's games, which often use the game loop. Let's look at Geometry Dash:
https://scratch.mit.edu/projects/105500895/#editor

The “Player” sprite broadcasts “tick,” and the other sprites respond to it. Griffpatch explain the concept well in this other project: https://scratch.mit.edu/projects/23134940/#editor

Notice that this script has “pre animate” and “animate” broadcasts, instead of one “tick” broadcast. Sometimes, the values are recalculated (such as new coordinates) before the sprites update their appearances on the screen.

Zro716 also uses the game loop, in his “Dogfight” project: https://scratch.mit.edu/projects/107641809/#editor . The broadcast for recalculating values is called “Update” and the broadcast for changing the sprite appearances is called “Render.” Zo716's game loop is in the backdrop, rather than the first sprite.



EDIT: You ninja'd me, but in the post, you were asking for examples, so…

So not only is it a lag reduction thing, it's for control, efficiency, and more? Wow… quite the important concept to learn.

Hi, I saw that you updated your project. However, I fear that you may have misunderstood the concept. You replaced the green flag with tick, and still have multiple forever loops. You should constantly broadcast tick and wait from one forever loop, and put the forever loop bodies in your other sprites under the tick broadcast.

That is, unless, you made those changes before you made this post, and I clarified.

Chibi-Matoran wrote:

Hi, I saw that you updated your project. However, I fear that you may have misunderstood the concept. You replaced the green flag with tick, and still have multiple forever loops. You should constantly broadcast tick and wait from one forever loop, and put the forever loop bodies in your other sprites under the tick broadcast.

That is, unless, you made those changes before you made this post, and I clarified.

I did according to the latter; I'll go change it!

After the tick is set up correctly, (or the broadcast that updates positions) you would, in theory (I'm sorry, I struggle to read other's code) you you would want something like this:

(offset) //For this sprite only
(Scroll X) //For all sprites, dictates how scrolled everything is

the reason why “offset” has to be “for this sprite only” is because only local variables create a seperate instance for each clone. Now you can safely do the following without each clone overiding the others with setting “offset”:

 when I start as a clone
set [offset v] to ((Scroll X) - ((x position) + (240))) //Scroll X at the left most position the sprite is visible
 when I receive [tick v]
if <<(offset) > (Scroll X)> and <(Scroll X) < ((offset) + (240))>> then
set x to ((Scroll X) - (offset))
   show
else
hide
end

But the sprite itself will respond to the broadcast, and if you don't want that:

(clone?) //For this sprite only!

when green flag clicked
set [clone? v] to [0]

when I start as a clone
set [clone? v] to [1]
...//The rest of the clone script I showed above

when I receive [tick v]
if <(clone?) = [1]> then
    ...//The rest of my broadcast script (shown above)
end

jokebookservice1 wrote:

After the tick is set up correctly, (or the broadcast that updates positions) you would, in theory (I'm sorry, I struggle to read other's code) you you would want something like this:

(offset) //For this sprite only
(Scroll X) //For all sprites, dictates how scrolled everything is

the reason why “offset” has to be “for this sprite only” is because only local variables create a seperate instance for each clone. Now you can safely do the following without each clone overiding the others with setting “offset”:

 when I start as a clone
set [offset v] to ((Scroll X) - ((x position) + (240))) //Scroll X at the left most position the sprite is visible
 when I receive [tick v]
if <<(offset) > (Scroll X)> and <(Scroll X) < ((offset) + (240))>> then
set x to ((Scroll X) - (offset))
   show
else
hide
end

But the sprite itself will respond to the broadcast, and if you don't want that:

(clone?) //For this sprite only!

when green flag clicked
set [clone? v] to [0]

when I start as a clone
set [clone? v] to [1]
...//The rest of the clone script I showed above

when I receive [tick v]
if <(clone?) = [1]> then
    ...//The rest of my broadcast script (shown above)
end

Thanks! This will help with my second part!

See my most recent shared project, it is an example type thing

jokebookservice1 wrote:

See my most recent shared project, it is an example type thing

I've encountered another issue. The clone moves as if it's controlled by the sensors? I'm confused on what may be causing that.

Zro716's response: https://scratch.mit.edu/users/Zro716/#comments-23773457

Chibi-Matoran wrote:

Zro716's response: https://scratch.mit.edu/users/Zro716/#comments-23773457

Awesome! I love it when the community comes together to help