I think it’s if you put the user id/auth token/ api token in the /users/id with it. It’s also in projects. I’m not sure if it’s in the published projects tab though. So maybe have it save join date and avatar type from the projects in the username in your web explorer.
Ok I’ll try that/
Currently, I have it read from the previous url
api token did not work, and published projects won’t work if they haven’t published anything.
it is in search, though that doesn’t mean much
Does the 3rd part of the Player Version update automatically? I.e., the x in 1.3.x
I updated a project when the latest version was 1.3.2. Now I see the latest version is 1.3.3, but the app doesn’t show that the project can be updated.
Yes, the minor version used when playing is the newest. 1.3.0 in json does play as 1.3.2 or whatever the latest is.
this is really helpful. thank you!
@AwesomeOnion, quick question.
I noticed that on iOS the project no longer goes full screen, and I assume this is intentional. Out of curiosity, was it to avoid the fake keyboard warning from iOS? Personally, I have not had the issue [of the fake keyboard popup] (still on iOS 11, the iOS warning was introduced in iOS12), but when playing my project on another device, I noticed that as well.
I like how it still grows in size though, so nice job there. Also, on other devices, a similar behavior might be nice – currently, iPhone projects get stretched, so if the player could fill the space with black borders instead I think that would be better.
Wow that was very poorly worded
Edit with pictures (@nazari)
This happens on iOS when a project has an aspect ratio totally off. sometimes it does go to full screen, but either way the aspect ratio still works. I believe the second one is intended behavior.
On a PC, it stretches the width and fills the entire screen, like this:
That’s not particularly ideal for iPhone-made projects
Demo project: Fire Fingers 1.1 by Fun Pixel
@nazari is taking a look.
If you made a save block, I think you could put this in the json file for the project. I mean, when you play it, the app reads the data from the file and creates the project, right? Couldn’t you add a extra spot the project reads that you can save variables in? Each separate iPad would have a different save file, rather than the json file holding every save, because that would be ridiculous.
Why would every device need to store the entire project?
Good point. What device stores all the projects?
The server, can’t tell if that was a rhetorical question or not.
Anyone know why this doesn’t work?
Search results seem to update very infrequently.
Like, when GCC changed his username temporarily, I still had to search SportyGeographer to find the account.
And sometimes the search result just doesn’t exist, as you said. That was the longest time with my iPhone account until I simply changed my name once then changed it back.
And what’s even funnier is that I never changed my iPad’s account name after I created my iPhone account (changed once or twice when transferring accounts).
Actually, I might have just explained myself. Try changing your username then reverting the change. Then search and it might show up. wait, that still doesn’t explain GCC.
@AwesomeOnion @Nazari - I’m curious, if you don’t mind sharing, what approach is used with the HS Player to prevent complications with floating point arithmetic error? Did you implement a library like bignumber.js so numbers would have additional precision and then truncate or round back to a certain number of digits during comparison operations?
Thought the explanation would be appropriate for “How Hopscotch Works”…
If you want the topic back I can reopen.
Just figured a clive would be fine since it’s solved.
Hi!
Float point precision is a known and annoying issue for developers since ever haha. Libraries like bignumbers.js add some overhead (for the application, not for the user) and are better suited for applications that deal with money, where do you need a long number of decimals and don’t want to lose any of them.
We’re still figuring up what is the best approach to deal with them for Hopscotch but for our case, we want that the webplayer will be as fast as possible doing calculations, and we can afford to lose some precision dealing with floats. So, right now, we’re rounding them to 5 decimals (should be enough precision for games) to compare them, and internally we use Number.EPSILON as offset, so two floats will be equal if a-b <= offset
.
Looks like this is a good way for us to deal with them, but this may change if we discover some edge cases where this doesn’t fit well.
If anybody wants to know more about float point this website is great
Thank you for the explanation. Just to note, sometimes the Player is rounding x.xxxx5 up as it should while other times it rounds down.
E.g.,
.123449 = .123455 evaluates to true
It’s rounding to
.12345 = .12345 {true}
instead of
.12345 = .12346 {false}
So the Player really only has 4 decimals of precision for comparison operators…
Nice catch! It’ll be fixed by the next release. Thanks