mirror of
https://github.com/rojo-rbx/rojo.git
synced 2026-10-23 05:51:39 +00:00
093e62af8e
- Updated CloneCommand to support multiple place IDs, allowing the creation of multi-place projects with individual project files for each place. - Refactored the initialization logic in InitCommand to streamline project setup and ensure proper handling of project templates. - Added a new function to fetch place names from the Roblox API, improving the user experience during project creation. - Updated TODO.txt with a new entry for fixing the luau-lsp sourcemap generator command.
105 lines
No EOL
6.5 KiB
Text
105 lines
No EOL
6.5 KiB
Text
[vscode extension]
|
|
get the schemas for everything into cursor somehow
|
|
|
|
[merging]
|
|
we should make the property diffs have arrows next to eachother so you can like "undo" certain things
|
|
need proper merging support in this UI.
|
|
make sure for fully deleted/added files we can use the merge UI as expected.
|
|
|
|
[syncback]
|
|
maybe make syncback automatically create a branch and merge it in, rather than overwriting your project files?
|
|
in order to do this, we must make dedup work flawlessly.
|
|
|
|
[Move tests to dedicated location]
|
|
Right now we have a severe amount of tests in the actual implementation files. I'd like to move those to a dedicated location because it's bloating the implementation files.
|
|
|
|
[Make instance creation/syncing more consistent and levelled up with how rbxsync does it]
|
|
* Terrain syncback / sync
|
|
* Order of operations (e.g. applying the Tag after full-sync routine complete so that things listening for tag updates get updated after it has been fully constructed, including it's children)
|
|
* CSG parts - requires very special handling to reproduce
|
|
* MeshPart creation must be done via CreateMeshPartAsync https://create.roblox.com/docs/reference/engine/classes/AssetService#CreateMeshPartAsync
|
|
* Special handling props (e.g. Skybox, ColorMap/ColorMapContent stuff)
|
|
* MeshId swaps for updates, need to re-create via CreateMeshPartAsync
|
|
* Queueing up material updates to properly support MaterialService changes so they appear correctly in studio without having to reboot
|
|
* Refer to rbxsync D:\UserGenerated\rbxsync\plugin\src\Serializer.luau and D:\UserGenerated\rbxsync\plugin\src\Sync.luau for reference, this system works correctly for the above use cases.
|
|
* You can search that whole rbxsync project for details/information.
|
|
|
|
[reify]
|
|
I noticed that in the reify/encodeInstance/decodeInstance/diff etc system we are not applying tags? Should the tag application / update behavior not be in here?
|
|
Tags should be applied once ALL updates have been performed on the instance
|
|
Tags should not be applied until EVERYTHING, including refs/attributes/properties are set.
|
|
Also, I noticed that attributes were not being doing in that system either, that should be done there I think?
|
|
Also, I noticed that it can fail to create an Instance - do we properly handle creating MeshPart's using InsertService?
|
|
Do we handle rebuilding CSG parts appropriately?
|
|
Do we handle swapping MeshId properly?
|
|
Are we performing operations in the correct order?
|
|
I feel like we added a lot of sync-logic that was supposed to be in these systems, but was placed elsewhere..
|
|
Refer to rbxsync D:\UserGenerated\rbxsync\plugin\src\Serializer.luau and D:\UserGenerated\rbxsync\plugin\src\Sync.luau for reference, this system works correctly for the above use cases.
|
|
You can search that whole rbxsync project for details/information.
|
|
|
|
[--!strict the plugin and make it --!native in hotpaths]
|
|
Need to get stuff inlined...
|
|
the entire syncing system needs to have it's types corrected and use strict,native,optimize.
|
|
we need to optimize the matching system heavily, it's so slow...
|
|
|
|
[Always mode]
|
|
MEDIUM - Issue 5: Ongoing "Always" mode patches don't support per-item selections yet
|
|
The existing code at ServeSession.lua line 311-314 explicitly says:
|
|
> "Table-type responses from the selection-based UI are not yet handled here. Ongoing WebSocket patches with per-item selections would need the same logic."
|
|
So in "Always" mode, ongoing patches currently only support "Accept"/"Abort"/"Skip" -- not per-item push/pull/ignore. The git defaults would be set in the PatchTree but the user can't act on them for ongoing patches. This is a pre-existing limitation, not introduced by us, but worth noting.
|
|
|
|
[two-way sync-back non scripts with a checkbox?]
|
|
we should just two-way sync everything backwards property wise, its really about not forward-syncing properties when that scripts only mode is on..
|
|
|
|
[testing which actually runs studio, syncs, etc]
|
|
we could make an automated testing system which truly simulates opening a place file and syncing to a running server automatically
|
|
this would close the gap on testing HEAVILY
|
|
use run-in-roblox utility like we use everywhere else.
|
|
so this expands beyond just that TestEZ system, where it tests spec files. this is separate from that, but same idea, just expanded upon.
|
|
|
|
[two way sync]
|
|
Make the two-way sync system respect the syncback configuration fully
|
|
ensure that live-syncback respects the syncback configuration fully
|
|
|
|
[refs]
|
|
-- Ref properties cannot be encoded during instance addition because the
|
|
-- target instance has no server ID yet. They are handled separately by
|
|
-- encodePatchUpdate.lua via the InstanceMap.
|
|
if descriptor.dataType == "Ref" then return end
|
|
I thought we were supposed to generate a uid and then send that table to the server so it can resolve those based on like a client uid?
|
|
|
|
[cli inspection]
|
|
we should make commands for inspecting .rbxl and .rbxm files for ai agents
|
|
even inspecting ones from the website directly
|
|
could we find an endpoint for downloading the "client side" of any game on the platform for context?
|
|
|
|
[Crates]
|
|
publish as a crate https://crates.io/crates/rojo
|
|
|
|
[vscode file watcher]
|
|
Also, we need to explore how VSCode deals with this. They seem to have ZERO issues.
|
|
Maybe we can have a mode to tie into the vscode file watcher ourselves? luau-lsp does this.
|
|
|
|
[fix dedup]
|
|
dedup is broken due to relying on sort order
|
|
recreate broken state by forcing random order in all matching dedup systems of the incoming children list
|
|
if it cannot match correctly with randomization, then it is inherently broken
|
|
in all 3 matchers, simply randomize the order of the children - this will break the tests.
|
|
|
|
[syncback via extension]
|
|
can we allow the terminal to stay so i can like run some git commands myself without having to make a whole new terminal?
|
|
i also want to just cleanup terminals / use one terminal for syncback and serve...
|
|
|
|
[multi place clone]
|
|
make clone support multi-placeids like we did with defend-67 in D:\UserGenerated\place-for-defend-67 (i did this manually)
|
|
see specifically game/ and game.project.json5, lobby/ and lobby.project.json5.
|
|
atlas clone PLACEID1 PLACEID2 .....
|
|
This is extremely helpful for games that have diverged places within the same game, e.g. a lobby and an actual game place
|
|
we will probably have to start dynamically generating the x.project.json5 rather than using a template file now though, which is fine..
|
|
|
|
[syncback]
|
|
optimize syncback like we did serve.
|
|
|
|
[sourcemap / luau-lsp]
|
|
we need to fix "luau-lsp.sourcemap.generatorCommand": "atlas sourcemap default.project.json5 --output sourcemap.json --include-non-scripts --watch",
|
|
and make luau-lsp actually use the 'atlas' cli... |