Game stucks on "opening game box" screen on setup

[KuWizard]

Hi everyone.
I have a weird bug here and I don't know where and how to start my investigation
My game (Martian Dice) randomly stucks at "opening game box" screen while setting up. It doesn't happen ever if I run it at Studio with "Express start" and I can't reproduce it at Studio while I do a normal game start with my 2 fake accounts. Also sometimes it happens on production and I've seen this couple of times by myself but I have zero ideas of how to reproduce it. Any advice? Where can I take a look?

[Een]

Hi, game hanging there is usually a javascript error. So when encountering this you should open the web developer tools and check the error for a clue to what's happening. If players have opened a bug about this, you can set the bug to infoneeded and ask them to do the same, maybe a tech savvy user will help.

[RavingWanderer]

EEN, see also bug 36980, reported against Hand and Foot. Player reported (on multiple occasions) the game startup sticking on the premium banner timer. This appeared to happen in the BGA infrastructure, i.e. before the transition to the game itself.

[Een]

EEN, see also bug 36980, reported against Hand and Foot. Player reported (on multiple occasions) the game startup sticking on the premium banner timer. This appeared to happen in the BGA infrastructure, i.e. before the transition to the game itself.

Yes, this might be a cause, but was not mentioned by OP.
An issue with the premium waiting screen has also been reported recently for another game (Yin Yang). In last week's release, we have added a possibility to activate this waiting screen on the studio so that developer can check their games for this (and debug on the studio if needed). Documentation has been updated, please check it out: https://en.doc.boardgamearena.com/Pract ... ing_screen

[RavingWanderer]

The studioLockingDuration option has proven useful to me, I believe I've tracked down the cause of the Hand and Foot bug. Thanks for providing it!

[Een]

The studioLockingDuration option has proven useful to me, I believe I've tracked down the cause of the Hand and Foot bug. Thanks for providing it!

Good to hear! Don't hesitate to share the issue and solution in case it may help other devs

[RavingWanderer]

The issue goes like this. I recenly added states to the game startup to make it possible for the table creator to set up teams before play starts (this is a friendly play option). So instead of setupGame -> nextRound, I have setupGame -> pickTeams -> processTeamSelection -> nextRound. The pickTeams state is active, with the table creator as the active player. However, depending on the game options chosen and the number of players at the table, there might be nothing for her to do (prime number of players, or other partnership options chosen). The state method stPickTeams makes this decision, immediately transitioning away if it makes the team/individual selections automatically. The pickTeams state is now the first activePlayer state.

When the premium banner is active, the table creator's browser is forced into pickTeams after the timer expires, *even if the state transition happened automatically*. This does not happen without the banner (as browser log entries show), and does not occur on later loading players either. The table creator is marked as active, and my Javascript was incorrectly (with predictable breakage) trying to setup the team selection interface as a result. Refreshing the page clears the problem, because the offending state transition doesn't happen.

What this means for others is: if your first activePlayer state is only conditionally active, you have to have a means for checking whether the player is transiently passing through the state or not. In my case, I am able to check the state args, and ignore the state depending on their configuration. I suppose it is also possible that there would be other state transitions, into rapidly followed by out of if the premium banner is present.

[Een]

Thanks for the clear explanation!

[Tisaac]

The issue for YinYang was the following one :
- at the start of game, every players is multiactive
- my first state is a multiactive state, so in the onEnteringState, everyone is already active, even if the state action has not been called yet
- with the lock screen on, the game go through a special gameSetup state which make all players inactive (so that their clock won't go down during the ad)
- after the lock screen, onEnteringState is called with inactive players which made my previous code fails

Workarounds :
- use an intermediate game state that set everyone active
- OR use onUpdateActionButtons, but I personnaly prefer the first one

Thanks Een for the feature, it's perfect for debugging !

[Een]

Thanks Tisaac for the fix and feedback! I actually was curious and checked on one of my games that starts with a multiactive state (Tokaido) and I had the same issue... That went unnoticed / unclearly reported for soooo long

I'll add testing the waiting screen to the pre-release checklist now that we have this feature!