Destroying an object does not affect FIRST save input

Your username: Dog Icing

What kind of device are you using?: iPad 7th Gen ios 15.0.1

Steps that the Hopscotch team can take to reproduce my problem every time:

  1. Add an object
  2. When game starts destroy, save input

I expected this to happen: object destroy and not ask for input

But instead this happened: it asked for input but it destroyed

Here’s a sweet screenshot:

Strangely this only happens for the first save input


Hmm… that is strange! I’m gonna have a go at repeating that…


Ok, I tried and I got the same result.

Anyone else?


correct me if i’m wrong but i believe it’s because the first two blocks load before stuff actually starts - and so values can be changed regardless of the fact that the object should be deleted first. a quick test does that third works for setting regular values as well, and presumably anything else, although you just won’t be able to see it since the object is deleted.

nice bug report, this is pretty interesting. :D


It is actually possible, and it could very well be the case.

Perhaps it could be fixed with some clever conditionals (in JS, obviously) to test if the destroy block was executed and cancel the execution of the next block if it was.

And it definitely loads the first two blocks, as adding a wait 0 (before the destroy block) prevents the set input block below the destroy block from running.


intriguing! that would allow us to preserve the usefulness of the two-frame rule (as i’ve been calling it) while still allowing the use of this specific structure of code until we have an actual on play rule or something similar


The old When Game Starts Rule used to be called “When the play button is tapped” (like when the code interfaced looked different, like a lot different). On iPad, at least…

I found this out on Wikipedia, which is very outdated now.


Ooh yes indeed


no kidding- I just looked it up


Hmm maybe i should update it.

1 Like