Scene locked with Combination Padlock


(Mark Hunte) #1

This is another simple password page ( I password is not meant to be robust)

The difference is the Staging Scene is a Combination Padlock.
To set the code you will see a code text box out of scene in the project. It is set to 614 in this template.
Each tumbler is from 0-6

The Tumblers drag up or down to set the numbers.
And there is a lock button under them to submit the current code.

If the right code is entered the Lever will raise and and enter button will show, which you can click to continue to the next scene.

Padlock.hypetemplate.zip (103.6 KB)


Event Based Animation
(a_brougher) #2

Hey, this is cool stuff. I like it. Have you built any locks that open when objects or images are dragged to a specific location or placed in a specific order? Like dragging some circles from a pile into the correct order. Right to Left: red circle, blue circle, white circle= opens the lock.

EDIT:

Oh! I see. You’re using the timeline time as the numbers for the code!


(Mark Hunte) #3

Hi,

I have built some pages which have hidden scenes. The only way to get to them is to drag a bit of page decoration to a certain spot.

I use the time line in this example as a way of getting feedback of what the tumblers values are. Each tumbler number has a pause action on its timeline corresponding with the matching tick time.


(Nick ) #4

That is so cool!! Love it! lots of possibilities.


(Joe Moretti) #5

Hi. I’ve looked at this code and tried your 614 example. Am I doing something wrong? I’ve run it and moved the tumblers to 614 and it does not work? If I change the 3 number code in Hype to anything, 2 2 2, for example. It doesn’t work.


(Mark Hunte) #6

What Browser you using.

I just re tested it in Safari and Chrome and it works with no issues.

In Firefox the graphics do not line up as expected so does not work in FF.
Not sure why FF is not displaying the tumblers correctly…


Force Browser to go to Full Screen via JavaScript
(Joe Moretti) #7

Thanks for replying so quickly - that was exactly the problem. How weird it doesn’t work in FF!


#8

MarkHunte’s scene really helped me. I was heading pretty much along the same lines but it taught me a couple of key things that would have made my life much more difficult. So, thumbs up to Mark.

So, I built my combo lock (mine has 5 tumblers) and it worked fine in the browser. However, I’m using it in iBooks and, once it gets into there, things go awry when the widget activates.

All the numbers are off and for some reason the first tumbler differs from the others in this. That might prove to be a clue, but I’ve not figured out why so far. Dragging the numbers doesn’t behave on the iPad anything like it behaves in the browser (Chrome). When I preview in Safari, I get the same issues as on the iPad (another clue), but I’ve no idea what might be different between Chrome (and Hype) and Safari that makes this happen.

Here’s what it’s supposed to look like:
43

But here’s what it ends up looking like:
IMG_3285A4812BD6-1

I’ve attached a Hype doc which has my combo lock in exactly the same x/y location that it is in my project.
combinationLock.hype.zip (236.4 KB)

I’ve also attached the iBooks file so you can see what happens.
combinationLock.ibooks.zip (489.9 KB)


(Jonathan Deutsch) #9

The cause is the Head HTML font-size CSS property… for some reason the metrics are different on WebKit-based browsers (including ibooks) vs. Chrome. You may be able to correct for this via a line-height property, or by setting the font to bold and the height you want on the text object. Alternatively, you could make individual text objects for each number and group them to ensure their top/left placement is at least the same.


#10

really appreciate you putting me on to that difference between browsers. Been working with webkit for nearly five years and never come across that causing an issue like this before. You learn something new …

Looking at your suggested fixes, my heart sank thinking of the labour I’d have to put in to fix this. Even a css reset file didn’t work. However, tinkering around in Safari dev tools, I discovered that it is really very easy.

Seems like every font has a max font-size value at which this will break in Safari. I hadn’t specified a font so it was substituting Helvetica and with a 28px value, it was broken. Setting it to 25px fixed it. There’s hardly any noticeable difference in appearance, so that’ll do for now.

Thanks again for looking into this.


(Jonathan Deutsch) #11

I’m glad you were able to find a good workaround for it.

There are definitely a lot of browser rendering differences (even device rendering differences), but usually it is more between WebKit-inherited browsers like Chrome+Safari vs Firefox. Hype tries to take care of some of them, but sometimes they are beyond what we should be reasonably controlling for.