Page 1 of 2

Detect interface unlock / action queueing

Posted: 30 August 2020, 18:00
by quietmint
I want to send an AJAX action to the server immediately in response to a state transition. If I call checkAction() directly inside onUpdateActionButtons(), the interface is still locked at this time.

Is there any standard way to queue up an action or detect when the interface unlocks? Reversing ly_studio.js, I see a function isInterfaceUnlocked() to query the current status and another function unlockInterface() to handles the change, but both are undocumented. Looks like I need to save the queued action myself and override unlockInterface() with my own version that runs the queued action?

Re: Detect interface unlock / action queueing

Posted: 30 August 2020, 18:07
by RicardoRix
..but a state transition is triggered server side, so aren't you already there?

Re: Detect interface unlock / action queueing

Posted: 30 August 2020, 18:16
by quietmint
I am considering a user preference to skip end-of-turn confirmations. The state machine on the server won't change (too complicated, and because most users will want the current behavior). I don't see how to access the user preference directly from the server? I don't want to create it as a game option because:
  • It clutters up the table/lobby screen. Majority of users will not change the default option.
  • Each user should decide themself, not just the table admin.
  • Options cannot change within the game after it's started, but preferences can change.

Re: Detect interface unlock / action queueing

Posted: 30 August 2020, 18:30
by RicardoRix
hmmm...

at the time of the 'end of an action' with or without confirmation can you also send a parameter which is the preference to skip.

i don't really know, maybe instead you could send back the preference selection and save this server side yourself if you can't get to it.

Re: Detect interface unlock / action queueing

Posted: 30 August 2020, 19:36
by fafa-fr
Hi,
quietmint wrote: 30 August 2020, 18:16 I am considering a user preference to skip end-of-turn confirmations.
I think this would be really useful for games in general (I totally agree with the three reasons you give), and I think it would be great to have a standard and documented way to do this. It would allow to use more confirmations in game without annoying players that don't want them.
RicardoRix wrote:at the time of the 'end of an action' with or without confirmation can you also send a parameter which is the preference to skip.
This is what I would do at the moment, but I'd like to know if there's another way to know of user preferences server-side, or if developers have used this way in their games without problem. (I can't think of anything that could cause a problem, but I would feel better with a confirmation.)

(Sorry quietmint, not an answer to your original question, but personally I wouldn't venture to do things like that.)

Re: Detect interface unlock / action queueing

Posted: 30 August 2020, 20:26
by quietmint
In my game, the client side never knows in advance when it is the end of turn ... it would only know this by getting the state transition. A "turn" could be any number of moves, and players have variable powers.

For now, I went with override_unlockInterface. Poke around this commit for what I implemented: https://github.com/AntonioSoler/bga-san ... 4cf60b28e6

This one just joins my list of undocumented overrides we're already using :lol:
  • override_setLoader (to detect loading completed)
  • override_adaptStatusBar (to detect change of #page-title from relative to fixed position, we also need to reposition some elements)
  • override_onPlaceLogOnChannel (to detect when a new log message is created, so we can change it later to strikethrough style upon "undo turn")

Re: Detect interface unlock / action queueing

Posted: 30 August 2020, 20:39
by RicardoRix
quietmint wrote: 30 August 2020, 20:26 In my game, the client side never knows in advance when it is the end of turn
The client in any game never knows if it's the end of a turn, that justification is for the server to decide and then act upon.

Re: Detect interface unlock / action queueing

Posted: 30 August 2020, 20:44
by quietmint
RicardoRix wrote: 30 August 2020, 18:30 at the time of the 'end of an action' with or without confirmation can you also send a parameter which is the preference to skip.
...
RicardoRix wrote: 30 August 2020, 20:39 The client in any game never knows if it's the end of a turn, that justification is for the server to decide and then act upon.
So I guess you meant: Send the preference to the server with EVERY action, just in case this is the end of the turn? That also adds a lot of complication to the server code, because now every action needs to take this parameter and pass it through, and the state machine needs to change to allow bypassing the state entirely (new transitions). An optional preference that only a few people will use is definitely not worth this extra complexity on the server side.

Re: Detect interface unlock / action queueing

Posted: 30 August 2020, 21:53
by fafa-fr
quietmint wrote: 30 August 2020, 20:26 (to detect when a new log message is created, so we can change it later to strikethrough style upon "undo turn")
Oh, this would interest me (but only with an official Yes from the admins, and some feedback that it works without problem -- is it in Santorini, or in another game?)

Re: Detect interface unlock / action queueing

Posted: 30 August 2020, 22:03
by RicardoRix
I don't know how much it will effect, but yes, it sounds like a extra transition per state. But this transition decision could be handled with a simple function, maybe for all different actions.
OR you could pass back the preference to avoid it needing being passed each action.

If it's a variable number of moves, how do you do this without having a 'I'm done now' confirmation button?
This is starting to sound like a pure client side problem, why does the server need to know? just send back the actions when the player is happy with or without a confirmation button step.

I really don't know you're game or what kind of problem you're exactly dealing with so you'll have to take my next statement with a pinch of salt, but it sounds like you're far more comfortable with JS rather than PHP. I certainly wouldn't be comfortable overriding undocumented features. And you're looking for alternatives, so I'm simply just poking around and trying to provide some food for thought.