Add Request Data API #6

Closed
opened 2025-10-29 15:53:44 +00:00 by Eldritch-Oliver · 0 comments
Eldritch-Oliver commented 2025-10-29 15:53:44 +00:00 (Migrated from gitea.com)

Sometimes systems require group rolls where it would be convenient to query all users to make a roll that only fully resolves once all users have finished it.

The way I imagine this working is a helper method within the DialogManager that accepts the same sort of structure as the ask helper, plus the users that it should prompt (defaults to all connected except the requesting client), the manager should also broadcast a persistent notification across clients to show how many have finished it or not, as well as some sort of state to show the finished clients that are finished that they needn't do anything else yet (could be a success notification or something in the chat, not sure)


While a request is waiting for players, an application should show up on the GM's screen that shows which players have submitted data, which are completed, and a way to cancel the request.

If a player rejects the request by closing the application on their side (or by refreshing), it would be a good idea to have some way for the requestor to resend the request prompt just to that player.

If possible, a window close event listener to cancel or submit active requests would be good


Sockets needed:

  • receive request (on player client)
    • payload of the ask modal configuration
  • submit data (on GM client)
    • payload of the data returned from the ask dialog
    • should have some way of also cancelling from the player side (submitting empty data)
  • cancel request (on player client)
    • to handle closure of dialog and removal of chat message
    • payload of nothing
  • create chat notification (on player client)
    • payload of the chat message content to put in the message

Order of operations:

  • GM sends socket to players, display status application
  • For each player:
    • player fills out data
    • player sends data back to GM
  • GM receives a data packet:
    • perform whatever callback desired to get outcome
    • update status application with the result
    • send result to the player
  • Player receives result packet:
    • create a self chat message with the result
  • once all players submitted:
    • send a combined chat message with all user's results in it
    • close status application

A randomly generated request ID will be required for all of the socket communication in order to manage the state of each request and update everything as required.


Because of the complex state management for this, I'll need some sort of data store available that will let me maintain the current state of every ongoing request (both sent and received) so that they can be cancelled or updated as required

Sometimes systems require group rolls where it would be convenient to query all users to make a roll that only fully resolves once all users have finished it. The way I imagine this working is a helper method within the DialogManager that accepts the same sort of structure as the ask helper, plus the users that it should prompt (defaults to all connected except the requesting client), the manager should also broadcast a persistent notification across clients to show how many have finished it or not, as well as some sort of state to show the finished clients that are finished that they needn't do anything else yet (could be a success notification or something in the chat, not sure) --- While a request is waiting for players, an application should show up on the GM's screen that shows which players have submitted data, which are completed, and a way to cancel the request. If a player rejects the request by closing the application on their side (or by refreshing), it would be a good idea to have some way for the requestor to resend the request prompt just to that player. If possible, a window close event listener to cancel or submit active requests would be good --- ## Sockets needed: - receive request (on player client) - payload of the ask modal configuration - submit data (on GM client) - payload of the data returned from the ask dialog - should have some way of also cancelling from the player side (submitting empty data) - cancel request (on player client) - to handle closure of dialog and removal of chat message - payload of nothing - create chat notification (on player client) - payload of the chat message content to put in the message ## Order of operations: - GM sends socket to players, display status application - For each player: - player fills out data - player sends data back to GM - GM receives a data packet: - perform whatever callback desired to get outcome - update status application with the result - send result to the player - Player receives result packet: - create a self chat message with the result - once all players submitted: - send a combined chat message with all user's results in it - close status application --- A randomly generated request ID will be required for all of the socket communication in order to manage the state of each request and update everything as required. --- Because of the complex state management for this, I'll need some sort of data store available that will let me maintain the current state of every ongoing request (both sent and received) so that they can be cancelled or updated as required
Oliver added the
Kind
Feature
Priority
High
labels 2025-11-06 05:21:25 +00:00
Oliver added reference feat/data-requests 2025-11-06 05:42:07 +00:00
Oliver self-assigned this 2025-11-20 02:35:37 +00:00
Oliver added this to the v2.4.0 milestone 2025-11-21 05:52:00 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Foundry/taf#6
No description provided.