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
Drafts is just about the worst thing you could have done for the co developing community. It’s terrible hard to use, and I have been sitting here for half an hour trying to even find the drafts tab because it’s not on my studio and my script isn’t updating. Terrible…
This is absolutely amazing. I love how we can edit scripts at the same time are our friends and/or other developers. This makes it much easier for people to correct errors and easier to help people fix the errors. @Roblox Your a genius! Keep up the good work!
