I’m extremely excited to use this. But, I’m also skeptical of it:
Does it provide value.
and how will this impact future additions.
Value
It is pretty limited right now so I can’t say for sure (like traditional version control). The biggest advantage of version control is that it keeps software in sync with a team of developers. But Roblox does not get this advantage, as it already had it before.
Even in an Agile development workflow with version control that handles merging, people are usually discouraged from working on the same file. It just leaves too high of a potential for conflicts and bugs being introduced in the merging process.
If this is the feature on the roadmap (Script Collaboration), I can’t say this was what I was expecting (thought it would be more like Microsoft LiveShare). I definitely wanted version control for Roblox places, but more so for version history and revision support.
If no one can see your changes (source code, not results) until after you’ve commited to them, is it even collaborative?What is the point?
Future Potential
Considering Roblox allows clients to send several events, seconds apart, using a RemoteEvent, I don’t think it is too improbable for Roblox to distribute clusters of text to studio instances that aren’t running the game. At first, thinking about it, I didn’t think Roblox could support both workflows going forward. But thinking about it, Visual Studio Code is a good example of how to support this. Editors just have to be invited to work on a single copy and the host has to commit it.
As for place-level version control, don’t think this changes anything. Just changes how the server receives changes.
Very sorry for the long reply, but I feel it is important to consider and entirely related.
This is amazing, can’t wait to try it out. I still prefer having a full repository external from Roblox, but I can definitely see people building better code with these improvements.
Other people have already provided answers to this comment, but here’s another thing, and this may be a bit off topic but it’s also relevant:
[A] Stop complaining about new features. NOTHING is going to be perfect, at least this is an improvement.
[B] The entire point of this update was to be able to collaborate but ALSO to ensure that there’s an extra cushion against someone deleting your scripts. Now, you can see WHO deleted your scripts and then re-add them without a hassle. PLUS, you now have the chance to stop a developer you just fired from destroying your work by seeing what they did and then reverting it.
Sorry, this is due to a limitation of not having access to keyboard modifiers in Lua widgets. We support multiselect (shift/ctrl) in the drafts window, but we are still working on improving our input pipeline so Lua code in plugin widgets can know when you have a modifier pressed.
This is a bug, and we are tracking it internally. Thanks!
Got approval from Design for the commit option and are looking into the indicator. Thanks for the suggestion!
Supplanting git and rojo was not the goal of this project. For starters, this alleviates the problem of being locked out of scripts when someone else is editing them, and not being able to sign off for the day with pending edits to a script without 1) submitting your half-working changes, 2) keeping studio open, or 3) extending how long you work so you can unlock the script.
Between drafts and a Google docs-like approach, the latter did not put us in a state that provided significant benefit over the existing one. Before being able to test your changes, you must first wait for every developer modifying the script to get it to a working state, and you do not get a holistic view of how your changes are impacted and affect other developers’ work since it is all happening in realtime (compared to drafts in which you can review interim changes with diffs or the merge window before committing). At this point, we would just be trading some problems with script locking for some new ones with realtime collaboration.
Realtime collaboration does have its benefits, as mentioned by previous users. If you would like us to support it as well, please make a feature request.
We are aware there are many ways we can expand collaborative editing. That said, we had two options:
Wait a year or few until we have a fully-featured set of collaborative editing tools to release any of it
Iteratively release pieces as we are able
We chose the latter, as it allows us to both alleviate existing pain points more quickly, and get feedback on the feature early and act on community thoughts & ideas as we continue work. Had we chose the former, you would be stuck with script locking for a much longer time, and we would have had to guess what developers wanted without asking their input for years.
Yes, this is collaborative and mirrors the same behavior you get from other source control like Git and Perforce. You are unable to see other developers’ local changes in a Git source controlled project until they are committed from their local machine to their branch, just as with Collaborative Editing. Likewise, local changes to a Perforce source controlled project are not visible to anyone else until they are committed or shelved.
It is not really possible for us to apply this kind of feedback towards future iterations. If you are looking to shape the future of Collaborative Editing, it is more effective to provide feedback on what the feature has done / should do, rather than whether particular business requirements were fulfilled. We have a Post_Approval team that can provide pointers, should you need any.
I am kind of curious, is the draft UI written in Lua? If so, I think that, unfortunately, the Lua implementation is causing more problems than it’s worth. The fonts are stylistically inconsistent with most non-lua studio widgets, and I’m also seeing some other side effects of lua-implemented widgets—for example, when you do commit a draft, there are frames in which things are a bit flashy since state changes quickly; it makes me think that this was made with Roact (UI updates are throttled at the Redux level for some godforsaken reason, which is why Rodux is not suitable for use anywhere outside of Roact). I also see some lua widget-specific bugs, like how if a plugin changes your mouse icon, that icon stays the same when you hover over lua widgets, but not most other widgets.
An example of the flashiness (it's very quick but disorienting)
Assuming this is Roact/Rodux, it looks to me like each entry has a “committed” state, which is sort of redundant because immediately after an action is dispatched to commit an entry, another one is dispatched to remove it from the list.
I didn’t notice the drafts button in the “View” tab before, but it seems like this widget can only appear in Team Create places, and only when you’ve explicitly opened it or changed a script. This means that, if you exit studio, or open up any non-team create places, the widget disappears from the dock, making it so you have to manually re-open it.
In my opinion, making something like this a lua widget isn’t a great idea, when it primarily interfaces with something at a non-lua layer; you’re running into the problem of leaky abstractions, but I know roblox people are sticklers for lua implementations and roact.
Yes, the Draft widget is written in Lua. Lua UI and input is definitely not where we want it right now, but the goal of dogfooding it for internal use is that these problems get resolved. There would be no text selection in TextBoxes, no rbxthumb thumbnail loading, and no ViewportFrames, among others, had we avoided Lua because it was imperfect in those areas at the time. Using Lua for internal projects results in some shorter-term inconveniences, but has and will continue to result in major improvements that the community can make use of as well.
I will file a bug for the flickering and make sure that gets fixed. In response to your comments about Roact/Rodux, we are keeping an eye on the technologies we use. Roact/Rodux provide a sense of order to the free range of UI development at scale in Lua, but we are also aware they have downsides such as those you have already mentioned, and that there are other options. For now they are sufficient enough, but we are open to looking at alternatives in the future should the need arise.
I thing, that better change will be, to make auto apply edits when publishing, because its terrible, when I have game, that is untesteble in studio, publish it, click play, than teleport to another server and after some time, i see, that it same, so i go to studio, apply edits, publish, rejoin, wait for the teleport delay, and then i find, that its ok
Is there also a way to get it back to the “apply edits” method?
I’m always the only one editing scripts in a TC so I’d prefer my edits to be published directly, not having to commit them all manually
