Issues with the Ready app on Chromebook

Hello @Ready and Ready dev team,

We started using the Ready Chromebook app this past summer and while overall it’s a godsend (thank you!), we’ve also noticed some issues. These issues are the worst kind for troubleshooting because they are intermittent, but finally today I’ve had a chance to collect three specific examples.

In all cases, the issues appear only on Chromebook. If I log into the exact same ReadyMaker accounts on Mac or ipad using the exact same wifi, the issues do not appear. Note: the below student projects are based on the Maze game on the “learn” page

  • Events not obeyed: “hidden” setting
    I’ve observed numerous cases of events updating the “hidden” property not being obeyed, primarily changing from “hidden on” to “hidden off” but also the reverse. Below is an example of the former: see Event #3 “win”; the neon arrow doesn’t appear.

  • Events not obeyed: “is touching object”
    This is the first time I’ve seen this one. Collisions between the player and the “obstacles” (food items other than toast) are not registered i.e. Event #2 is not obeyed. I tried a number of variations e.g. replace class with an individual sprite, add a brand new sprite, turn up opacity to 100%, make a new Player character etc.

  • This issue relates not to game play but to the Ready IDE itself: the Event Manager button (stoplight) failed to open the Event Manager. The mousedown state (lamp colours) was observed, but nothing else happened.

Any thoughts or ideas or suggestions for workarounds you may have are most welcome; thanks for reading! :slight_smile:


Hi @auntiel! :slightly_smiling_face: Thanks for this report!:+1: We will definitely study this. Although making corrections for the Chromebook will be quite a challenge, it may be possible to find alternative options.:metal:


Here’s another Chromebook-only issue we came across: for games in portrait orientation, for a sprite with control pad or drag behavior, when the game is played, on scene start the sprite immediately moves to the righthand edge of the screen and fails to respond to control pad or drag inputs.

Again, this applies only to Chromebook and only in portrait orientation, but we did observe it in several games on several different Chromebooks. In each case, the game works completely as expected on other platforms (Mac, iPad).

Here’s one of the affected games:


update: today I gained some new insight into the issue relating to portrait orientation. Experimentation revealed that it’s actually the Stay in Frame behaviour that causes the issue, not control pad or drag as I previously thought. This lessens the severity of the issue significantly because in lieu of teh Stay in Frame behaviour, “walls” can be placed around the perimeter of the stage to achieve the same result.