After “Bring to Front” block, (self)( x position) is stored as zero

Your username: AlbertEinlime

When game starts, I’ve been saving the starting locations of sprites so they can return “home”, but if I change the z order before that happens, the x and y positions are saved as zero

Steps to reproduce my problem every time:

  1. I place a shape on the stage. It has a position that is not zero, like (258, 437) or whatever.
  2. This code puts the shape exactly where it was in the editor:
when game starts
    Set (self)( Home X ) to (self)( X Position)
    Set (self)( Home Y ) to (self)( Y Position)
    Send to Back
    Bring to Front

When game is running
    Set Position (self)( Home X ), (self)( Home Y)
  1. This code puts the shape at (0,0):
when game starts
    Send to Back
    Bring to Front
    Set (self)( Home X ) to (self)( X Position)
    Set (self)( Home Y ) to (self)( Y Position)

When game is running
    Set Position (self)( Home X ), (self)( Home Y)

If I place “send to back” and “bring to front” after saving the x position, but before saving the y position, the x position is saved correctly, but the y goes to zero
Size as a percent is not affected


I expected this to happen:

I expected both programs have the same result: that the x and y position traits would remain stable regardless of z-order changes.

But instead this happened:

They didn’t!
If I shuffle them, They return some value that gets interpreted as zero.

Here’s a sweet screenshot:

I published this project under my profile AlbertEinlime named “The Forgetful Sisters”

Huge Fan!


welcome to the forum:)

that happens because the “when game is running” rule runs twice before the variables are set, meaning that when they are set they will be equal to 0 since the position is set while they do not have a value (in other words it equals 0,0)

when that code is run, it runs kind of like this:

when game starts 
  send to back 
  set position self(home x) self(home y) // 0,0 since they do not have values
  bring to front 
  set position self(home x) self(home y) // 0,0 since they do not have values
  set (self) home x to self x position // 0 because the x position of the object is 0
  set self home y to self y position // also 0
  // then it keeps setting position to 0,0

does that make any sense? someone else can definitely explain it better


One, welcome to the forum!

Two, this is a very interesting glitch. I don’t really have an answer, but I guess just look here ^^


Welcome to the forum, and I think @/Nobody has already explained the bug.


I see what you’re saying, but the code does store the correct non-zero value unless it pops back or forth. Only then does it store zero.


I am not sure if you’ve used other platforms to code before, but the way Hopscotch works is each movement and appearance block (red and green) take one frame (1/60 of a second) to execute.

So, this is what happens in your project:

  1. You press play.
  2. First frame: the first block in “game starts” is run (send to back), then the first block in “game is playing” is run.
    At this point, HomeX and HomeY are both zero, so the game playing “set position” will set the object’s position to (0,0) BEFORE the variable gets saved.
  3. Second frame: bring to front is run. “game is playing” also triggers again, so the set position occurs again
  4. Third frame: set self Home X and set self Home Y are run (variables don’t take a full “frame”). Then, set position from “game playing” runs again. By this time, Set Home X and Home Y will set those to zero because the object is already at x0 y0.

So, what you’d want to do is either set variables first, or, you can put the “set position” block in a repeat forever that goes inside of “game is playing”.


Thank you!

It took me a while to wrap my head around the fact that “when game starts” and “when game plays” can be running concurrently, and may be interleaving commands.

So every red or green block takes its own frame to execute? Do other things continue to execute before the next frame is called, or does every “thread” pause?

Is there more documentation for this type of thing? “What is hopscotch doing and when?” type stuff?

This explains a lot of the oddities In things I’ve made in hopscotch, like how when you clone something it always flashes in the original position.

My son and I have been working on a little game together. I don’t have a lot of experience coding, but I have spent some time using Codea and processing.js, so I am most familiar with a “Setup → Draw” paradigm (or “Setup → Update <-> Draw”)

I do really like the flavor of hopscotch’s design philosophy. I like how you can create behaviors and apply them. Reminds me a bit of macromedia director or HyperCard.

I would love to see more details on execution order, when frames are triggered, etc, if anyone has them!

Thanks Awesome_E and everyone else!


Welcome to the forum, AlbertEinlime!

There is some more information on that part here (though it relates more to the runtime of individual blocks and not in relation to When containers)

For the When containers, the idea in theory is that each is simultaneously checking whether its condition is met and running the code inside — though in practice, there is an order of execution which tries to replicate that

ThinBuffalo made some pretty helpful diagrams here which go through execution order for Whens. (This is from an older post which I think was a draft, and unfortunately the archive/deprecated category is restricted to trust level 2 and above, but I have quoted parts of the post)


Thanks! Great Stuff!


This topic was automatically closed after 3 days. New replies are no longer allowed.