Destroy makes "object is tapped" rule behave like "device is tapped"

1 sentence description of the problem: When an object is destroyed and another object has a when the first object is tapped block, the second object will perform that code when anywhere on the screen is tapped after the first object is destroyed.

Steps to reproduce the problem every time:
(Start in a blank draft if possible)

  1. Put in any object. Let’s say Octo. :hs_octo:
  2. In Octo’s code, put in a When Self is Tapped block. In that, put a destroy block.
  3. Put in another object. Let’s say Bear. :hs_bear:
  4. In Bear’s code, put a When Octo is Tapped block.
  5. In that block, put any code that shows that Bear is doing something. Maybe you would put in Move Forward 100.
  6. Tap Octo, and Bear will move forward 100. Octo will also delete himself.
  7. But then, tapping anywhere on the screen will cause Bear to move again. You can keep tapping, and he will keep moving.

I expected this to happen: Bear doesn’t do anything after Octo is destroyed

**But instead this happened:**Bear moves when anywhere is tapped after Octo is destroyed.

Screenshots/video:
(Include project link if relevant)

(I would put a video in but I’m screen recording on iPad, and when I try to put one of those in it says it isn’t an authorized format or something. You can go look at the linked project, its really simple.)


Your username: _ Alboy_
Except without the space in between the first underscore and the A, it italicizes it and I don’t know how to do the box thing that the special text doesn’t work in.

Device type, iOS version: iPad, here:

Hopscotch version & player version:
(you can go to :gear: > “About”, and take a screenshot)
image

I think this is a pretty minor bug, but I reported it here so you know about it. Thanks!

7 Likes

This is intentional by design.

When you delete an object that another object is referencing, it’ll automatically update its reference to “When device is tapped” to prevent any further issues or crashes.

7 Likes

Hmm. I really thought that was a bug, it just doesnt make sense to me. I would expect it to just not do anything.

7 Likes

For future reference, you can create a game variable to check if the object no longer exists (by setting the variable to 1 right before the object is destroyed. Then you can add a check in the when object is tapped rule, so once the object is gone, the variable is set to 1, which would make the check fail, and thus, prevent the object from moving unexpectedly.

6 Likes

This seems confusing. I feel like they should change this behaviour.

7 Likes

There’s not much they can do without causing the project to crash due to a null (deleted) object…

And disabling the rule ain’t an option since they want to ensure the object can still do the actions even after the object it referred to was destroyed.

6 Likes

I imagine a check if exists at the beginning of event blocks would be possible to prevent a crash when referencing something that no longer exists

I agree, perhaps keeping the block but add a deleted tag next to the deleted object’s name in the block to show that what it’s referencing isn’t in the project anymore?

5 Likes

I think that if an object being referenced gets deleted, that “is tapped” rule should never be able to occur since that object is not able to be tapped. It wouldn’t make sense to change the behavior of the rule based on something that happens within another object.


I’m also going to unmark this as the solution because (1) it doesn’t solve the problem and (2) it looks like the issue has been acknowledged as a bug (hence the #officially-reproduced tag) without being marked as #intentional-by-design.

7 Likes

i agree - intentional by design makes absolutely no sense. the correct way prevent a crash is to fix it, not by putting a weird behaviour on top of it

6 Likes

Yeah I think this is a bug.

From what I’ve seen the current behaviour seems intentional in the webplayer (probably so that kids don’t think their code is broken when it doesn’t run after an object is destroyed). But I agree that it doesn’t make much sense, and it can be changed.

Here are some examples that I thought about:

  • say you have a score go up when a character bumps an enemy, and the enemy is destroyed after the character bumps it. You don’t want your score to keep going up whenever the character now bumps anything.
  • or say you have a score to go up when a player taps a coin to collect it, and the coin is destroyed after. You also don’t want your score to keep going up whenever the player taps anywhere on the screen.
5 Likes

For this, you could do


When (self) is Tapped {
    Increase ((player) score) by 1
    Destroy
}

Then you won’t run into that problem with the score increasing unexpectedly, since the event itself will be destroyed as well…

3 Likes