Huh this is weird- Argon is trying to delete some instances inside a tool, even though the instances are things like sounds, models and parts- it’s in only code mode, shouldn’t it ignore these? Synced to the server using client initial sync once, switched to server initial sync and this.
Oh, and another finding: parts and models still replicate to VSCode with only code mode on if they are added in Studio
Yep, nothing changes- if I change it to non-only code and sync to server using client, then switch back to server, Argon wants to uh change everything “54 additions 54 removals 54 changes” and if I turn non-only code with only code data on the server it tries to remove the same stuff as simply turning only code mode off
Only code mode isn’t meant to have Argon interact with anything that’s not a parent object or scripts, right?
I misunderstood you last time and this is intended behavior. Only code mode only affects syncback - two-way sync or initial sync (if set to client). If you want to keep these instances you either have to create Data File with keepUnknowns set to true or enable Keep Unknowns plugin setting but the second option affects the whole place.
Yes, it turns out this always happens when I have more than 1 children with the same names, under the same parent.
This always happens with ModuleScripts. Most of the time this happens because when I’m trying to create a new module script, I clone an existing one and it mass clones these instances.
I also use GitHub in my workflow, if that makes any difference.
Yes, it is! Make sure to set Initial Sync Priority of your plugin to Client so that every time you connect you have the latest copy of your place on your filesystem. You can also enable Two-Way Sync to sync changes made by others in real-time. If you want to code collaboratively in VS Code I recommend using the Live Share extension.
It should just add that UUID suffix to the duplicate instances. This is the only way to keep two or more instances with the same name on your filesystem, so that’s actually intended. If you rename that duplicated instance, it should remove the UUID on the filesystem (unless there is another instance with the same name).
If it’s not working that way could you provide reproduction steps or a quick video showing the issue?
I keep getting the following error whenever I try to connect to VSCode on Roblox since today (the plugin is on v2.0.14 and the VSCode extension is on v.2.0.15) :
-- Promise.Error(ExecutionError) --
The current thread cannot access 'StreamingService'
(lacking capability Assistant)
user_Argon.rbxm.Argon.Core.Processor:114 function hydrate
user_Argon.rbxm.Argon.Core.Processor:44 function init
user_Argon.rbxm.Argon.Core:105
user_Argon.rbxm.Argon.Packages._Index.evaera_promise@4.0.0.promise:172 function runExecutor
user_Argon.rbxm.Argon.Packages._Index.evaera_promise@4.0.0.promise:299
Promise created at:
user_Argon.rbxm.Argon.Core:83 function run
user_Argon.rbxm.Argon.Core:401 function connect
user_Argon.rbxm.Argon.App:423
user_Argon.rbxm.Argon.Packages._Index.evaera_promise@4.0.0.promise:172 function runExecutor
user_Argon.rbxm.Argon.Packages._Index.evaera_promise@4.0.0.promise:181
I tried reverting to a previous version of the extension but that did not solve the issue, nor did reinstalling the plugin or Roblox Studio.
EDIT: After looking on the DevForum, it looks like it will be fixed in next week’s Studio release according to this post. There is also a possible workaround to this problem, so future versions of Argon could perhaps account for issues like this.
While I don’t use these kinds of tools due to productivity issues, I like the work that’s gone into this and how it addresses issues I have with considering and adopting Rojo. You’ve done really well with Argon! I love seeing the additional settings, two-way sync and everything in between that you’ve added.
I hope that there can exist a solution (or update to Argon/Rojo) that lets me keep ROBLOX’s Explorer navigation features for objects and scripts (dropdowns to show children, click to show properties, double click to open scripts) so that I can hide the nitty-gritty imperfections of the file structure caused by how OSes handle files and folders.
Thank you for the explanation. I added a video.
It looks like the enabled state of the plugin is being switched, so that may be why the docking state is being reset.
Is it supposed to work without any problems in a Windows environment?
It might be a Windows only issue then. Will make sure when I have access to my Windows machine. Anyway, I don’t think I can do anything to fix this problem at the moment as Argon doesn’t even handle widget position or docking state.
I’ve discovered something. Even when I turn off the Argon plugin and then playtest, the Argon plugin menu still frequently appears in the center. This leads me to believe that rather than undocking, a separate Argon plugin instance is launching during playtest. As a result, the plugin menu is displayed in the default position. I’d appreciate it if you could investigate this. Thank you for your development efforts.
Upon testing briefly, it seems that the Argon plugin’s App.new() is being called twice during PlayTest. Since the plugin doesn’t seem necessary during PlayTest, I tried preventing App.new() from being called during the test, and the widget display no longer appeared. I hope this information is helpful.