HS Version: 3.38.0
Player Version 1.3.3
I hatė to be the bearer of bad news, but as I was trying to use immediate calculations in a project it became apparent (after hours of troubleshooting) that the immediate calculations are still broken. In one case the sequential conditional doesn’t execute in the same frame. In the other case, the sequential conditional executes incorrectly
This results in “1” as expected
However when the conditional is changed to include a variable the code gets delayed. This results in “2”
In this scenario the conditional is inside a custom rule.
This results in “1” as expected
However when the conditional is changed to include a variable the code executes incorrectly. This results in “Doesn’t Work”
Note: The variable ‘Frame Count’ is incremented once per frame in the “1st object”
So basically reopen “zero frame order”
@ThinBuffalo, can you give a screenshot of what it looks like in the game?
The bugs shown above are slightly different than what you showed in the Zero frame order topic. The code you showed now returns a green 10 as expected.
The player just shows the output of the Set Text, which I already stated so I don’t think adding those screenshots will add value. But thank you for the suggestion.
Right, but I do remember having the same issue where putting it in ability changes it. It is the same type of bug though.
@AwesomeOnion, just want to make sure you saw this? since in case 2, the Player does not work correctly…
@ana @awesomeonion @nazari
Any projection for a fix (or even acknowledgement of the problem), at least for ‘case 2’ where the player executes code incorrectly?
Isn’t this a big deal to THT? You make a product that’s supposed to teach kids how to program, so not even considering the quality expectations of paying customers, shouldn’t it be imperative that your product work correctly?
This is definitely important. One of my projects I was making a while ago was broken because of this. Luckily I remembered that this bug exists but if I hadn’t it would’ve taken me a lot longer to fix it.
I have three tips to help you.
There’s a glitch where you go into edit, don’t do anything to the code, and then it will repeat things twice to try and fix the broken code. Sometimes it takes the number value. Each time you increase it, it will increase the number by 1. In this glitch, it will increase it by random through 0.5 to 2. So, sometimes when you set the variable to 10, it might actually be equal to something other than 10. So it’s not a problem with the code. If the monkey switches to doesn’t work, the player looked into the code and activated the glitch. So if The player thinks they executed the code incorrectly, they might have done it right, but have made hopscotch think they edited the code but actually didn’t.
(The quote usage ends here)
As the previously described glitch above says, the monkey might say doesn’t work. Also, it might still stay as a monkey, or turn completely invisible. Hopscotch will “forget” that you told it to set the text to doesn’t work, and won’t change to doesn’t work. If it changes to the frame rate x2, the previous glitch’s first part has come into use. Sometimes it does the thing where it takes it x2, but doesn’t get a chance to change the variables, because it figured out you didn’t edit the code. So basically, it would be a better idea if the monkey was just a blank text.
If you press or click or tap or whatever on the restart button, it is a 12 out of 1000 chance that some of the objects on the screen will not do what the code says. This is because you pressed or clicked or tapped or whatever the restart button too slowly, and the restart button changes its code from Tapped to Pressed, and the objects try and run its code the first time you tap, but realizes the restart button is still in use, so cancels its code till next time. When you stop pressing restart, the objects “get bored” and fall asleep, so they don’t know that they are supposed to run the code. Sometimes they “wake up” later, and run their code late.
I found another bug similar to the second one.
When you have start sound blocks waiting for a variable they will not wait correctly unless there’s a block between them and the variable being set
I published this simple project to inform more of the community as I’m sure there are plenty of confused Hopscotchers that don’t understand why their code isn’t working…
I tried this out and it did work for me. I used an iPhone X and the iPad Air 3 simulator.
Here’s a video of what I did: https://we.tl/t-qEqszvTiio
- What device were you using?
- does it only break if you are using the “game starts” rule or for anything?
- can you show the code where you set “frame count”?
when I try this project on my desktop it works fine. And here’s a video on my iPhone: https://we.tl/t-jT3klkCjkJ
It could be because the older versions of the player have not been updated in a while
idk @ThinBuffalo did you try it in a new draft?
First & foremost I want to thank you for taking the time to look into this.
I tested some more yesterday and today. Looks like the issue with the variable not being set correctly (case 2 in the original post) was recently fixed. I never tested with Player version 1.4.0 as you’d previously mentioned that Nazari wasn’t able to look into this as he was busy with fast collisions. Oddly though it not only works on 1.4.0 but my published test project (post 13 above) also now works, which should only utilize the latest minor version upgrade or 1.3.x. So a fix was also recently rolled into 1.3.x. In any case, it’s great that that’s fixed!
Now that said, there’s still an issue. Case 1 of the original post (which the “fixed” execution of Case 2 also now falls into). However, that at least doesn’t result in incorrect code execution. The immediate calculations are “just” inconsistent.
This is all I’m doing to count the frames (and the When with the counter, of course, has to be first)
So then if we change “Everything’s fine” to the variable ‘Frame Count’ we see it results in 2
But it should be 1. So there’s an artificial delay before the Check If Else
We can further show the artificial delay in the execution of the code above by looking at this which also results in 2 (this time as expected)
ah, I see.
Whether or not a block will take a full tick is not very consistent.
I made this project with lots of different options–some take 1 tick, some take 2!
Exactly. In fact your later cases, shown above, are what caused me to initially think this had been fixed the first time you worked on problems with “immediate” Set blocks a number of months ago (I only had evaluated with When 7=7)
There are several other known instances of what I’ve been calling “null frames”, but when they involve setting variables (and the potential resultant timing problems) it makes using Hopscotch particularly difficult (and confusing for the uninformed).
Understanding you’re unlikely to be able to make a firm commitment, is this remaining issue of inconsistency with Set blocks something that you might be able to addresś sometime soon?
(and anytime you want addresś the other instances of null frames, I’m happy to help with those as well. But I suspect they may have been intentional due to performance concerns)