Nice, thanks! :D
Apparently, ”is Pressed” does not work as other whens:
This should show 1 when ”iPad is pressed” and 0 when not. This has worked in projects made with prior updates, did anything change? @awesomeonion
@ThinBuffalo, do you know what is going on?
TBSr's General Hopscotch Coding Topic
I was wondering when someone was going to ask about this
To first comment on the question you asked of awesomeonion. The result you’re seeing is the same as prior behavior.
If you search for the topic I made about the drawing pad with Undo, you’ll see that I commented on When pressed not running at the same FPS as the other Rules. However, my conclusion at that time wasn’t right. I had observed that the When Pressed rule was only executing at 30 fps while the other rules were at 60. While the observation was accurate, I’ve since found that the When Pressed rule has a null frame at the end of the rule before it will execute again. If the When Pressed has only one block then in effect it is only running at 30fps, since it runs the block, has a null frame, runs the block, has a null frame, etc.
That’s what creates the behavior you’re observing.
In your When Pressed = 1 rule, insert a Wait 0 before the Set Pressed to 0 block. This will sync that rule with the When Pressed rule and it’ll work as expected.
Here’s a project to demostrate/visualize the null frame:
Here’s an example of how to exploit this understanding:
Since drawing pads obviously use When Is Pressed, they only draw at 30fps (the Draw a Trail block with just one Set Position inside it executes in a single frame, so it’s the same as having only one block in the When Pressed rule) . By interlacing 2 asynchronous drawing rules, a “HD drawing pad” can be created that will draw segments twice as often.
Edit: @CreationsOfaNoob Instead of two asynchronous rules, it’d be much easier to just have a variable indicating the Pressed state and then have a rule for When “Pressed” = 1 (which would run without the ending null frame). Not sure why I was over complicating it.
I made one of these a few weeks back, but didn’t bother to publish as the effect was only really noticeable when drawing very quickly & most Hops wouldn’t have understood or seen an added value in the extra complication.
@awesomeonion @liza Is it possible to design out the “null frame” (discussed above) at the end of the When ___ is Pressed rule? That would make it easier for users to understand the timing of their project’s code
a “HD drawing pad” can be created that will draw segments twice as often…
…it’d be much easier to just have a variable indicating the Pressed state and then have a rule for When “Pressed” = 1 (which would run without the ending null frame).
For the record, this () doesn’t work as expected either.
A Draw a Trail block also creates a null frame following a When (conditional) rule. …but only if it’s the last block in the rule
Yeah, I noticed this too. It’s pretty annoying.
By the way, thanks for explaining the null block in when is pressed, it explained a reason one of my projects is acting weird.
You’re welcome. I’m glad it was helpful!
Cool. I recently noticed that When pressed only runs at 30 fps and then did some testing.
Following a When meaning what? There can’t be a When rule before it? Wouldn’t that make drawing pads run at only 15 FPS, since it’s the last block in the rule? Or since there’s already a null frame in the When pressed rule, that does not apply.
Meaning following the execution of blocks in the rule before the rule will start again.
I was only referring to a When (conditional) rule as opposed to a When (pressed) rule. E.g., When (7=7)
The Draw a Trail block doesn’t add any additional delays to a When (Pressed) rule that I’ve noticed.