-
Notifications
You must be signed in to change notification settings - Fork 177
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
Play Solo Auto Connect #468
Conversation
Co-authored-by: boyned//Kampfkarren <boynedmaster@gmail.com>
Co-authored-by: boyned//Kampfkarren <boynedmaster@gmail.com>
* Implement ChangeBatcher * Use ChangeBatcher for two-way sync * Pause updates during patch application * I can English good * Break after encountering a nil Parent change This prevents __flush from erroring out when an instance's Parent is changed to nil and it has other property changes in the same batch. * Update rbx_dom_lua * Don't connect changed listeners in a running game #468 made me realize how bad of an idea this is in general... * Update TestEZ and fix sibling Ref reification test * Add ChangeBatcher tests * Test instance unpausing by breaking functionality out to __cycle * Break up the module a bit and improve tests * Shuffle requires around and edit comment * Break out more stuff, rename createChangePatch -> createPatchSet * Make ChangeBatcher responsible for unpausing all paused instances This somewhat improves the situation (of course, it would preferrable to not have to hack around this problem with Source at all). It also sets us up nicely if we come across any other properties that do anything similar. * Remove old reference to pausedBatchInstances * Use RenderStepped instead of Heartbeat and trash multi-frame pauses I probably should have done this in the first place... ChangeBatcher still needs to unpause instances, but we don't need to hold pauses for any longer than one cycle. * Remove useless branch * if not next(x) -> if next(x) == nil * Add InstanceMap:unpauseAllInstances, use it in ChangeBatcher * Move IsRunning check to InstanceMap:__maybeFireInstanceChanged
Other than merge conflicts, is there anything else this PR needs to get merged? |
In general, yeah! There's a bit of feature design work that I think we need to do, especially around making sure Rojo won't try to overwrite stuff that changes at runtime. I've tagged PRs on the repo to try to indicate what their current status is. |
* Implement ChangeBatcher * Use ChangeBatcher for two-way sync * Pause updates during patch application * I can English good * Break after encountering a nil Parent change This prevents __flush from erroring out when an instance's Parent is changed to nil and it has other property changes in the same batch. * Update rbx_dom_lua * Don't connect changed listeners in a running game rojo-rbx#468 made me realize how bad of an idea this is in general... * Update TestEZ and fix sibling Ref reification test * Add ChangeBatcher tests * Test instance unpausing by breaking functionality out to __cycle * Break up the module a bit and improve tests * Shuffle requires around and edit comment * Break out more stuff, rename createChangePatch -> createPatchSet * Make ChangeBatcher responsible for unpausing all paused instances This somewhat improves the situation (of course, it would preferrable to not have to hack around this problem with Source at all). It also sets us up nicely if we come across any other properties that do anything similar. * Remove old reference to pausedBatchInstances * Use RenderStepped instead of Heartbeat and trash multi-frame pauses I probably should have done this in the first place... ChangeBatcher still needs to unpause instances, but we don't need to hold pauses for any longer than one cycle. * Remove useless branch * if not next(x) -> if next(x) == nil * Add InstanceMap:unpauseAllInstances, use it in ChangeBatcher * Move IsRunning check to InstanceMap:__maybeFireInstanceChanged
I'm curious what's blocking this feature from happening. This is something I am looking for! Would save me a decent chunk of time when testing. |
I don't see a reason this is blocked beyond the fact that I've not reviewed this PR and it's old. I've asked @boatbomber to take a look since he's more in tune with Rojo's plugin source. We could solve this in a few ways and this is just one of them, but I'd like his opinion since it'll inevitably be him that maintains any code for it we add (unless something critical breaks). |
Since writing this, and having some experience using it in my own local fork of Rojo, I ran into some issues and weird behaviors. It's been too long since I've used this feature personally to remember what those issues are, so I can't provide much insight into solutions. I wonder if other approaches to solving the problem would be more reliable. |
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.
I have some concerns about implementation, and I'm not sure if we ever addressed LPG's note about avoiding overwriting dynamic content? We might need to force ignoreUnknownInstances
on everything during a Play Solo connection.
This PR is also 3 years old and out of date, it might just be easier to start a new one.
return nil | ||
end | ||
|
||
function PlaySoloAutoConnector:didMount() |
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.
I'm not a big fan of this architecture, as it uses prop drilling and a component that just calls a function for the app. Instead, we can use the architecture that we now use for many other features- a call from App:init()
that uses self:startSession()
local address = ("%s:%s"):format(host, port) | ||
|
||
if RunService:IsClient() and RunService:IsServer() and not RunService:IsRunning() then |
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.
Isn't this just RunService:IsEdit()
?
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.
TIL lol
|
||
settings:set("activeConnections", activeConnections) | ||
|
||
workspace:SetAttribute("__RojoConnectionId", connectionId) |
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.
This is putting temporary data into a permanent location- could we use a non-Archivable Instance for this, or do they disappear when you press Play Solo? It might simplify the cleanup logic.
Edit: non-Archivable Instances don't persist when running
table.remove(activeConnections, 1) | ||
end | ||
|
||
settings:set("activeConnections", activeConnections) |
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.
I don't understand why we have this array and write it to settings.json
.
You're creating a GUID to key the host/port/sessionId within this array, then sharing the GUID via the Attribute, then linearly searching the array to find the host/port/sessionId with this GUID when play solo.
(Why do a linear search? You can turn this array into a dict using the GUID as a key.)
I think this array and disc write is totally avoidable though, unless there's something I'm missing.
You can write the connection info to an easily parse-able string in the Attribute, so that the server window of the test can grab the host/port/sessionId without having to search through other connections from other projects in other windows.
IE:
-- When connecting
workspace:SetAttribute("__RojoConnectionInfo", host .. "|" .. port .. "|" .. details.sessionId)
-- When in play solo
local connectionInfo = workspace:GetAttribute("__RojoConnectionInfo")
if not connectionInfo then return end
local host, port, sessionId = table.unpack(string.split(connectionInfo, "|"))
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.
I agree that the disc write isn’t the way to go. It felt shaky even when I implemented it.
As for the rest of your questions— I don’t have good answers for those, mostly because I can’t remember and I’d need to read back through the whole PR, which I’m not really interested in doing right now. (nor am I interested in continually addressing those issues in this PR)
I think it would be better for you to take over the PR and implement the suggestions you’ve put forward
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.
Yup, I opened #840 for that. Thanks for getting this started though!
Implemented in #840 |
Adds a setting to automatically re-connect to the rojo server when entering play solo