Add Request Data API #6
Labels
No labels
Compat
Breaking
Compat
Compatible
Foundry/v14
Kind
Bug
Kind
DevOps
Kind
Documentation
Kind
Enhancement
Kind
Feature
Kind
Security
Kind
Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Status
Unable to Complete
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Foundry/taf#6
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
Order of operations:
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