Validation / Retake process
Last updated
Last updated
Our emote validation / retake system allows users to upload a new video if they are unsatisfied with the generated emote or if the process fails, without creating a new emote process.
This system ensures a smooth user experience by adding an extra step where the client must validate or reject the generated emote before it is included in the user's bag.
Players reject a process, not an emote. The emote will only exist for the user once a process is validated.
When a process is in the done status, and the user is satisfied, you need to call the validation route:
This will automatically add the emote to the user bag, making it immediately playable in-game.
If a user is not satisfied with the emote, you need to retake the process:
A new token will be generated, allowing the user to create a new emote. This new process will be linked as a child of the rejected one, with the rejected process flagged as 'rejected' and considered 'dead'.
You can reject a process multiple times if required (e.g., if the user did not finish the PWA flow of the new emote). The child process is attached only if it has been created.
The Settings page of Game/App Space allow you to customize the number of allowed retakes for an emote, leading to the creation of a process hierarchy.
Kinetix ensures there is only one 'living' process in any hierarchy. There are two ways to handle the retake process:
Retake the root process: Will invalidate and attach a new process to the latest child.
Retake the child process: Will invalidate it and attach a new process.
Retaking any process in the chain will invalidate the latest child and attach a new process to it. The choice depends on which process you want to display to the user.
When requesting a process from the server, you will have a hierarchy field describing recursively the whole process history, including a count of children and parents, and the detailed UUIDs in the order of creation. When displaying the process, you can choose to display only the relevant processes to the user.
When the validation flow is activated, this will make emote available to the user
The process uuid returned by the POST /v1/process route.
When the validation flow is activated, this will reject the process and return a new generation token to let the user retry
The process uuid returned by the POST /v1/process route.