Yellow-Dog-Man
Ability to change the authority of initial value when stopping the drive of a `FieldHook` node
Is your feature request related to a problem? Please describe.
Currently, whenever StopDrive is pulsed for a FieldHook<T>, the authority for what the value becomes after the field is unlinked is the host. In some cases, this might not be entirely desirable, and you would want another user to be able to have authority over what the initial value is when breaking the link.
Describe the solution you'd like
A User input to the FieldHook<T> node that specified who should have authority for the initial synced value after StopDrive is pulsed.
Describe alternatives you've considered
For my use case, if the generalized idea wouldn't work out, having a boolean that makes the user that pulsed StopDrive be the authority would suffice as well.
Additional Context
No response
Requesters
yosh, brecert
I believe this is a general mechanism that will be implemented when the data model is re-worked.
I believe this is a general mechanism that will be implemented when the data model is re-worked.
I don't doubt it, but I still think this specific request should be tracked :P
Since field drives are local (I believe?), it seems a bit tricky for this to work properly as described. Consider the case where users A and B are running field hooks. Both of them stop the hook at around the same time.
- Let's say Users A and B both specify B as the authority. What value does user A use while they wait for B to send their final value? Does user C (who never hooked the field) see that value in the interim?
- What if B does not stop their hook locally? What value does user A see? What if user B disconnects before ending the field drive?
- What if user A and B both specify each other as the authority? What if they specify a user who does not hook the field?
To have a consistent result, I think what you'd want is 1) a way to set the value that is currently shadowed/hidden by the field hook before stopping the hook drive, and then 2) a way to stop the drive without overwriting the shadowed value. This would result in a consistent result without glitching as things unhook.
You can sort of achieve this already, by replicating a separate data model value that you switch over to driving before unhooking everyone, but that does require a wide time window for everyone to process the unhook, during which any other changes might be overwritten.
Since field drives are local (I believe?)
If a field is driven (purple), the value of the field may be local to each individual user. However, the state of a field being linked in general is not something that can be localized. You can find more information about this on the field linkage page on the wiki. As such, all the "what if" scenarios regarding "what if user X hasn't hooked the field"/"specify a user who does not hook the field" are not really applicable.
Let's say Users A and B both specify B as the authority. What value does user A use while they wait for B to send their final value?
As-is, fields become "unlinked" immediately for the local user that caused the field to be unlinked, in the interim between that happening and the host receiving the information/sending their value back, the value is simply the last value that the local user saw. I don't see how this could be any more of a problem if the host is replaced by any arbitrary user.
Ramble alert:
Right now, when a drive is released, it calls SyncElement.UpdateLinkHierarchy(ILinkRef changedLink), which in turn calls World.LinkManager.DriveReleased(ILinkable linkable). This function is run by everyone updating the world, but it explicitly checks if you're the world authority, in which case it adds the released drive to an internal releasedDrives list. During the synchronization loop in SessionSyncManager, GenerateCorrectionsAndSend() handles releasing links via World.LinkManager.GetReleasedDrives(list) and syncing the values, which is also run by everyone but only does something on the host.
I don't think it's entirely unreasonable to have a bit of metadata stuffed up in the message for the user that's supposed to handle releasing the drive and syncing a value. There's a lot of room to be flexible with this model in a potential rework scenario.
We will not be offering this functionality. The authority of the value is a very low level operation of the data model synchronization and not something that could be just exposed.
The plan is for the drive release to use the value of the user who released the drive. This is relatively reasonable addition to the underlying data model - the user already has that value, because it's theirs.
Being able to select arbitrary user would complicate things by at least by an order of magnitude - maybe two. If the releasing user is different from the user who has the value, that value would need to be obtained from them first - but that has network latency, meaning the drive can't be released immediately - which would break a lot of things, since right now it assumes that when it's released, it's released right away.
Best approach for you would be to instrument your code to release the drive on the user whose value you want to keep.
But for specifying specific user, we won't provide that unfortunately.
The plan is for the drive release to use the value of the user who released the drive. This is relatively reasonable addition to the underlying data model - the user already has that value, because it's theirs.
As I noted in the "Describe alternatives you've considered" section, for my specific use case, this is perfectly fine and actually what I was only wanting in the first place--I didn't need the arbitrary authority selection. I was proposing a general idea to see how it'd stick, though.
Should I edit the issue to reflect this, or will it be closed as it'll be implicitly covered by the data model rework anyway?