Rojo 7.5 Roadmap #856
Replies: 4 comments 19 replies
-
|
extra chorelist for docs |
Beta Was this translation helpful? Give feedback.
-
|
Excellent suggestions, I've linked to this issue to the Docs section |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to add Headless API to 7.5 as well. It's nearly complete already so it should be straightforward to get into 7.5, and it'll be a big help in simplifying the |
Beta Was this translation helpful? Give feedback.
-
|
Agree, I'll look into this shortly and write a summary for the reasons we want it and why it should be in 7.5 |
Beta Was this translation helpful? Give feedback.
-
|
Is |
Beta Was this translation helpful? Give feedback.
-
|
I would really like for |
Beta Was this translation helpful? Give feedback.
-
|
With the planned reduction in scope around the setup experience, I think it's doable now - especially with another set of hands to help! |
Beta Was this translation helpful? Give feedback.
-
|
Alright, both
I'm not sure why I asked this, considering that I already mentioned it under |
Beta Was this translation helpful? Give feedback.
-
I agree with this 100%. I haven't explored this beyond theorizing on how it'd be possible, but I think it may genuinely be possible to complete the mythical two way sync using the work I've done with syncback since the hardest part (deciding where things go and making files from Instances) is done now. I'm not sure if two way sync is something we can reasonably fit into 7.5 though, since it'd be another large-ish project. It's perhaps worth exploring if we can get script sync working using the syncback middleware though, once it's merged.
I think pages of those types are important, so we should try to have something akin to spec sheets. They should probably live on their own pages (and maybe even as markdown files in Rojo's main repo instead of on the doc site), but we definitely should keep a detailed breakdown of each of the formats we have. Maybe it's worth having a part of the site that houses spec files and schemas, akin to
I don't think Ref properties are in a state I'd feel great about releasing right now! Having to use attributes even in JSON files feels hacky. I mentioned it in that PR but I'd like to also allow setting properties directly. However, it involves rewriting property resolution to an extent so I want to keep it separate from that PR so that it doesn't complicate it even more.
I will make no secret of it: I think us shipping an installer would be a waste of resources. I completely understand where you are coming from, because it is a lot of friction for Roblox devs, but I don't think an installer is at all worth it. We should instead have actual tutorials for people who are new to this. If someone's struggling with adding things to their PATH, we should seek to educate them on what a PATH is and how to add things to it. If people need help with Luau LSP, we should have pages on how to get it working well with Rojo. It's just as much work to write these pages as it is to make an installer and then maintain it. However, tutorials and documentation comes with the added benefit that we're actually teaching our users. Yes, it's more work for an end user. However, please consider: adding a folder to your path and setting a few VSCode settings is not rocket science. If it's beyond someone to do this with a well-written tutorial, they are probably beyond our target audience. Final ThoughtsFor user facing features, I think this roadmap is good. Coupled with Boatbomber's headless API, and I think we're setting up for a really impactful Rojo release. Writing blog posts for major features sounds suspiciously like it'll just be me writing several blog posts about things like sync rules, ref properties, syncback, and unscriptable properties, but I do like the idea of it. I think we should also look towards fixing things like the Also... Can we add developer-facing documentation to the roadmap at least to some degree? We should work towards lowering the bus factor for Rojo's development, and part of that means writing things down, even if it's just general "for this part of Rojo, look here" notes. |
Beta Was this translation helpful? Give feedback.
-
|
I typed up a really long response to this which went through every paragraph and expressed my response but they all boiled down to the same thing: my opinion has not changed and I do not support us even trying to ship an installer with Rojo, let alone committing to doing it in 7.5. If people can't get through 3 steps to install Rojo (make a folder, add folder to path, add Rojo to folder), they are not a target audience of Rojo's CLI. If they also can't install an extension in VSCode, I don't know what to tell them. As we have both recognized, it is not rocket science. Part of this can be making the VSCode extension not suck. I am open to that being on the roadmap, because it's honestly frustratingly bad. Imagine if you will, a world where the extension just installed Rojo if you didn't have it installed instead of yelling about Aftman. And one where it had a GUI for editing and viewing projects. I feel it'd make a lot of things easier to do. I want to give special attention to the section of your reply on businesses though: you should remember that we do not cater to them. They're the one most suited to actually solve onboarding, so I don't really care about their experience with installing Rojo. At Uplift Games, as an example, we have an engineer onboarding process that goes through how to install things like Rojo (we actually just use Aftman) and some internal tools we made to smooth over things like CLI flags. It's really simple, and we rarely have problems. A small team or an individual is the one that's likely to struggle to install and debug Rojo. They're the ones we need to help. I don't think an installer will help them because installing Rojo is generally the easiest part of using Rojo. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I anticipated that we would not be able to come to an agreement here. But the discussion is still valuable! For now, I agree we can change the content of the setup experience section to focus on Rojo's VS Code extension. Is rojo-rbx/vscode-rojo#73 more or less the improvement that you mentioned? I'll gladly take any other suggestions, as well. This also reminds me that we'll need to determine if we have the ability to actually get PRs merged there, and publish to the current extension on the Visual Studio Marketplace. If we can't, then I suppose we may have fork and have it under a different publisher... |
Beta Was this translation helpful? Give feedback.
-
There is Filip Tibell's roblox-ui: https://github.com/filiptibell/roblox-ui. Maybe we can recommend this extension in our documentation? Or maybe even look at merging the two extensions? |
Beta Was this translation helpful? Give feedback.
-
Yes. Though upon rereading that exchange, I'm kinda unhappy with how it went and I think we might be better off just killing support for Aftman and Foreman directly. We can probably check for multiple installation sources and warn if there's multiple, presenting which version is being used. We can also just avoid installing it unless users opt into that. But I'm kinda not thrilled with recommending or supporting a tool that we don't make and maintain so prominently. |
Beta Was this translation helpful? Give feedback.
-
Merging the two seems like it's asking a lot if Filip, but I definitely think suggesting it is a good idea. I have a few vscode extensions I want to make too (mainly to provide utilities for visualizing and editing rbxm/rbxmx files and diffing them) and the tooling recommendations page is due for a refresh anyway. |
Beta Was this translation helpful? Give feedback.
-
|
I've added a section about using msgpack instead of JSON for transport and the plugin's reflection database... I'm not sure at this point if the scope is too large, but I think it will be a necessary change |
Beta Was this translation helpful? Give feedback.
-
|
Intuition tells me that adjusting our network protocol and property resolution will be smaller scope than reimplementing them. I'm open to adopting msgpack but the question is mostly how much work it'd be. If it's too much, we should try to shim a fix until 7.5 releases. |
Beta Was this translation helpful? Give feedback.
-
|
@nezuo did some exploration in this area a while back. They think the amount of work is manageable, and have offered to help out: |
Beta Was this translation helpful? Give feedback.
-
With the release of Rojo 7.4, users were finally able to get their hands on a host of improvements (especially to the plugin UI - thanks @boatbomber!). We should aim to make Rojo 7.5 even better. I think we will want a plan, as it will be much easier to succeed in a timely manner if we determine the key deliverables, break them up into sub-tasks, and put them on a schedule. I'll leave out things that have already been merged since 7.4, since those changes are already locked in for 7.5.
In this discussion, I'll make some suggestions for which changes we should prioritize, and together we can work out just how important each one is, fit them into a rough timeline, and perhaps come up with some that I haven't thought of.
rojo syncbackFirst, the elephant in the room - IMO syncback sets the tone for the entire release. Using this feature, it will be far easier and involve much less manual work to fully manage a Rojo project, and also be a viable way to migrate existing games to Rojo. It probably will cause users to exercise parts of Rojo they haven't before, lead to much larger projects, and perhaps increase adoption. I think we must be proactive about the ramifications.
There is currently ongoing work occurring for this feature on Uplift Games'
syncback-incrementalbranch, and there is also a prerelease available for early adopters. We don't yet have a timeline for when a PR will be opened against mainline Rojo for this.Unscriptable property fallback
The Rojo plugin's current inability to sync MeshParts is one of its biggest drawbacks right now, and it will loom even larger once fully managed games become more common. This feature not only addresses MeshParts, but also the problem of unscriptable properties (and uncreatable instances!) in general. I think it's a must-have for 7.5. We already get plenty of support requests and confusion about MeshParts, and will only get more once fully managed becomes more common.
We currently have an issue and a pull request open for this feature:
GetObjects#786There's not a lot of work left here, but it's going to require more testing before I'm personally comfortable shipping it. The last time we tried to implement this feature (#401), there were some strange issues that were never properly tracked down.
Docs, docs, docs
Rojo's documentation needs some work. The main problem is that it sorely lacks a "big-picture" view of the software. It mentions that it's possible to use some other tools by adopting Rojo, but fails to give a good idea of what benefit this actually gives developers. I think the following changes would improve the situation:
Provide worked examples that are drag-and-droppable. It would help newcomers immensely if the documentation gave them more concrete examples that show how the project format actually works in practice, demonstrate what sorts of interesting or useful things they can do with Rojo, and provide a starting point for experimentation.
Document all features that have not yet been documented. There are several important things that are not explained at all on rojo.space, such as:
Rewrite parts of the documentation so that they read more like a story and less like a specsheet. The biggest offenders are the following pages:
The project format and sync docs that everyone sees first should be more like tutorials with plenty of screenshots and explanatory text to both show and explain to them what's going on. These existing pages are good references, but they don't do a good job of building up the knowledge of new users in a gradual, guided way. While purely informational references are good for users who already have some idea of what they're doing, they shouldn't be front and center.
There's also a nice list of suggested improvements at rojo-rbx/rojo.space#114 on the rojo.space repository.
Full support for
Refproperties in the project formatRight now,
Refproperties are only representable in Rojo via place and model files. This is a problem mainly because place and model files do not allow cross-model Refs (e.g. aRefproperty that points to an instance contained in a different place or model file). It also makes Rojo more feature complete, and is a hard requirement forrojo syncback. There is currently an issue and a PR open for this feature:Most of the work is done, but there are some straggling bugs unrelated to the implementation in the above PR left that we need to address. The UX of this approach is also not great and feels like a workaround. However it could be improved by altering the resolution of
Refproperties. IfRefproperties are to make their way into Rojo 7.5, we should consider implementing this behavior.Updateable reflection database
Currently, Rojo's reflection database is statically included in the plugin and the binary. This means that a new release needs to be made for Rojo to have first-class support for new properties, even when they don't implement new datatypes. We have the required changes in rbx-dom already:
So we'll just need to merge them, figure a way to publish databases, then give Rojo the means to pull them in.
Headless API
The headless API is a feature that allows companion plugins to interact with Rojo's Roblox Studio plugin. This enables extension of the Rojo plugin to support customized workflows. There are a couple examples of what companion plugins are capable of already:
Studio Wally
Studio Wally allows users to install and update Wally packages from inside Roblox Studio.
Rojo Scanner
Rojo Scanner allows users see all the projects that their Rojo server is serving and choose which session to connect to.
The headless API will also make it easier to implement
rojo open, which is described in the next section.I'm thinking that we should probably name this feature differently. It's not obvious to everyone what is meant by the name "headless API" or what value it provides.
We currently have a couple issues and an in-progress pull request open for this feature:
The work is essentially done, but we should spend a little more time to search for possible security holes.
Initial sync performance
Rojo can take a long time to sync a large project into Roblox Studio. Performance is a feature! A responsive experience makes the software feel polished and "pro." In some of my discussions with developers who haven't yet adopted Rojo, one of the main complaints is that there's "too much friction." It definitely won't help if the software even feels slow.
One possible way to speed up the initial sync without making any actual optimizations to existing code is the
rojo opencommand. We currently have an issue and an in-progress pull request open for this feature:rojo open#622This won't speed up large changes to the tree during a serve session, but since the main pain point right now seems to be the initial sync, we can probably get away with it. It's definitely still worth doing proper optimizations, but first we'll need to run some torture tests and collect profiles to track down the major bottlenecks.
Switch to msgpack for plugin's reflection database and transport
JSON is not appropriate for representing some property values. JSON cannot represent infinities or NaN, leading to Rojo being unable to properly sync some properties, and the database specifying
nullfor some property default values . This has been a longstanding problem in Rojo for a while now:With
rojo syncbackI think it will be important to properly fix this. There's a pretty good library available for encoding/decoding msgpack at https://github.com/cipharius/msgpack-luau/. This will likely improve performance and finally solve the infinity/NaN issues, as msgpack is much smaller in size than JSON and is able to represent infinities and NaN.To use msgpack for the reflection database, Rojo will need to gain the ability to place binary data into
StringValues. This will require some changes to rbx-dom, which we've had a bit of discussion about at rojo-rbx/rbx-dom#313.An alternative approach to solving the inf/NaN issues is to use some special strings to represent infinities and NaN in JSON (there is an example of Roblox doing this in their API dump - properties that have infinity as their default value use the string
INF). This would be much less work, but would not have any performance benefits.rbx-dom improvements
There are some missing features in rbx-dom that should probably make it into Rojo 7.5:
rbx-dom doesn't care about select properties important for correctness and least surprise rbx-dom#385
Some Roblox features don't work properly if some properties are absent in place/model files. This issue proposes populating these properties, solving the problem.
Add support for
Enum-typed attributes rbx-dom#383Roblox added support for
Enumattributes last year. These do exist in the wild now, and users will be displeased if Rojo chokes on them.rbx_dom_weak should have a concept of "proxy properties" rbx-dom#277
Some properties are "proxied" to each other. This becomes a problem when a proxy property is not serialized, because users can set one of these properties in a Rojo project and then be foiled when their desired property is not reflected in
rojo buildresults. This isn't as big a problem for Rojo as it is for Lune, but it'd be great to resolve!Setup experience
A common way to install Rojo is through the VS Code extension. This should work smoothly, but unfortunately things still do go wrong. At least one reason why is that the extension is oddly insistent about exactly how Rojo is installed, as described in these issues:
I've also seen some reports here and there about the install process failing for one reason or another - this needs more investigation. We should look to improve Rojo's VS Code extension to ensure the install experience has zero sharp edges. It represents users' first contact with the software, so special care must be taken.
Next steps
I want the core contributors to Rojo to agree to a subset of this changeset, a rough timeline for the work, and a tentative release date. Once we do all that, we should publish the finalized roadmap to the rojo.space blog, and also post updates as we complete each item. This should be pretty easy and should essentially amount to summarizing discussions from PRs and issues. It's good to give users insight into what we're doing, and an active blog can increase engagement. I'm also eager to hear feedback from the wider community - we're doing all this for them, after all!
Beta Was this translation helpful? Give feedback.
All reactions