-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pinning/Unpinning interaction and media promotion checks for bitECS + entity state API #6092
Conversation
title + started to put permissions into place
Pinned component add and remove now handled by save entity state callbacks
This is ready for review again. It feels a lot cleaner with this approach. Thanks again for the suggestion. PR has a little more added to it in unexpected places now because I removed all use of Pinned and Pinnable components to prevent confusion about source of truth for this state. I folded the unpin legacy components and deactivate files work into this PR. There is one point that I feel mildly uneasy about. I added an inline comment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the one comment about wanting to add a createEntityState
call to where we loadLegacyRoomObjects
(here and in the reticulum PR). Other than that, this looks good to me. Nice work!
}; | ||
|
||
const unpinElement = (hubChannel: HubChannel, world: HubsWorld, eid: EntityID) => { | ||
deleteEntityState(hubChannel, world, eid); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because of the way legacy room objects are handled, I think we should createEntityState
in response to loading legacy room objects. Otherwise, when a client loads a legacy room object and synthesizes a "fake" create entity message for it, if the client moves the entity around, it will send "update" messages to reticulum, and reticulum will reject them (because it would have no stored entity state for it). This might be wasteful, so we may consider making an atomic "move RoomObject to EntityState" method later. But because I am concerned about an error causing us to lose information, I thought to do this non-destructively first. (And then delete both the RoomObject and the EntityState when an element is unpinned.)
2405498
to
33dca22
Compare
This PR ...
To do this, I needed to add properties to theMediaLoaded
component that storesrc
andfileId
values. This was necessary because theMediaLoader
component is removed after load and those values are needed for media promotion. It is not ideal to duplicate the values in order to persist them. I mention possible alternatives in an inline comment.Cases not handled by this PR ...- Attempts to pin an object without being signed in silently reject. This is the existing behavior. This was not handled because (as far as I can tell) the bitECS code path doesn't have a solution for usingperformConditionalSignIn()
. In the previous code path this function was passed as a construction parameter to a class instance ofPinningHelper
which was stored onAPP
. This does not seem appropriate for the new code path and likely exceeds the scope of this PR.This PR is dependent on these changes to Reticulum so I will mark this PR as a draft until those changes are merged.resolves #6086