Okay, ive recently started to use VSCode to rewrite my games old code, but i keep coming across my instances being deleted. In my InputController i put the controls under it, and everytime i run rojo, its deleted, same with my effect replicator, and my utility functions.
How do i fix this, i have used the ignoreunknowninstances and its not working.
Rojo’s a bit finicky. What I do is create a file named init.meta.json in VSCode and parent it to wherever you need instances. Inside of that, add the following:
{
"ignoreUnknownInstances": true
}
Technically, you should be able to do this to the overarching ancestor and have it affect all descendants, but that usually doesn’t work so you have to repeat the same thing under every parent of a file you need in studio but not Rojo.
stop using rojo and use azul instead
Azul is fine if you want more overhead, but it does not solve the underlying workflow issue. If your .meta.json files are already set up correctly and Rojo is still wiping things, you probably have a sync conflict or a misconfigured file tree in your project root.
As far as I understand, you want to get your Script out of Studio, and into your filesystem.
There’s a few ways to do this.
The Rojo team recently added rojo syncback, which is their solution for importing Studio places into Rojo. However, note that afaik it isn’t perfect and may have issues. Try it out, it may work just fine.
There’s also the older rbxlx-to-rojo, which syncback aims to replace. It has been broken & unmaintained for a while, but it’ll still work with my patch.
If you think Rojo’s proposed syncback workflow is convoluted (I wouldn’t blame you), follow this advice and try out Azul.
It’s essentially the true reverse of Rojo, where the “source of truth” is Studio, so it’ll mirror that instead of your filesystem. This has the added benefit that it works out of the box with any game.
If you mean the overhead is in the language used (Rojo is Rust, Azul is TypeScript), I haven’t found any significant bottlenecks/performance issues or excessive overhead from using TypeScript. While TS will obviously never be as fast as a compiled language, you’d be surprised at how well it gets the job done!
The overhead isn’t about execution speed, it is about the complexity of the toolchain itself. Adding a TypeScript transpilation step to a project that doesn’t need it just adds more moving parts to manage and more ways for things to break during a build.
What are you talking about? Azul doesn’t transpile Luau to TypeScript.
It’s a sync tool, like Rojo, except Studio is the source of truth.
I am talking about the extra tooling required to make TypeScript work in a Luau environment. Even if Azul is just a sync tool, you are still bringing in a Node/npm-based ecosystem and a package manager into a workflow that could otherwise stay much simpler.
One could argue the same about bringing in Rojo, which is Rust-based tooling that uses the Cargo package manager. Even if you manage your environment with rokit or aftman, point still stands. I don’t think it adds as much complexity as you make it seem.
Cargo is a single binary installation for most people, whereas npm/node environments tend to bloat much faster with nested dependencies and configuration drift. It is still more complexity regardless of how you manage the versioning.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.