How to best create an AGF project Controller LocalScript in ReplicatedFirst in VS Code (or otherwise)?
And
How to add Controllers (LocalScripts), Services (Scripts), and Modules into ServerStorage inan AGF project in VS Code (or otherwise)?
Only mention I could find of ReplicatedFirst in AeroGameFramework was a year old post
How do you create an AGF Controller in ReplicatedFirst such as a TitleScreenBootstrapper? In other words a Loading Screen LocalScript that programatically generates a Loading Gui and possibly other primary Client Init tasks.
AGF’s default.project.json points ReplicatedFirst to src/_framework but that folder doesn’t appear in VS Code Explorer tab or Visual Studio AGF Plugin tab.
AGF Docs do not mention ReplicatedFirst but do describe Forcing Init Order using MyServic.__aeroOrder = 1 but that first Service would need to Clone or re-Parent a Controller (LocalScript) from [SOMEWHERE] to ReplicatedFirst.
Do you create a LoadingScreen.lua in src/_framework outside of VS Code?
Have you tried contacting the developer of the Aero Game Framework?
I just looked at the setup instructions on github and they seem straight forward.
Are you following those and got stuck?
My post is detailed enough to show that I have read and searched the AGF Docs, and have a specific question about a use case after successfully setting up and using the framework.
By tagging the developer, I have provided the option for them to respond.
The framework does not support ReplicatedFirst at the moment. There is a loading script added, but that’s just to serve as an example. Scripts running within ReplicatedFirst are being run before the AGF lifecycle kicks off. If you need code to run in ReplicatedFirst, just drop a LocalScript in there and edit it from Studio.
The documentation shows how to use the AGF extension for VS Code to do this. Please watch the tutorial videos for a more visual example.
Understood, thanks. ReplicatedFirst would be nice to have in AGF for a fully managed code base. Understandable that VS Code Sidebar AGF view shows Client, Server, and Shared when ReplicatedFirst is not supported. Not clear why VS Code Explorer view hides _framework folder though?!
My mistake was in forgetting that within the AGF development context, AeroServer is the only Roblox Script running in ServerScriptService, while all AGF Services and AGF Server Modules are Roblox ModuleScripts stored in the ServerStorage.Aero folder. I kept thinking of AGF Services as though they were Scripts (when they are actually ModuleScripts).
I have previously watched all the tutorial videos you linked to.
For anyone (me included) browsing this in the future, here’s more specific detail:
ServerStorage in AGF
AeroGameFramework Roblox Structure (AGF Documentation) lists all AGF Server-side code including AGF Services and AGF Server Modules as being stored in the Aero Folder.
If you want to just store arbitrary stuff inside Roblox ServerStorage, you can:
Use AGF Services with empty :Start() methods (and possibly empty :Init() methods, if they really are just being stored). Follow the Invoking another service documentation to call methods in these stored Services from other Services or Server Modules. No option for storing AGF Client Controllers or Roblox LocalScripts.
Use Roblox Studio to manually add instances into ServerStorage. Any code attempting to use these instances should include checks for their existence and somehow either fail or yield gracefully. This would all be completely custom to your project and could break easily.
Using an editor of your choice, add *.client.lua, .server.lua,.lua files to your Rojo ServerStorage folder. These files would be outside of AGF, but still in the same Rojo project and therefore the same repository for code management.
It’d be very difficult to support the full extent of AeroGameFramework for ReplicatedFirst without an isolated system (which would just be equivalent to writing your own loaders for the client) because everything starts at the machine’s run time: for the server this is when the new instance is created and started, and for the client this is when game.Loaded fires because StarterPlayerScripts is protected from running before then. Cases like this are why _G is a secondary accessible point for items not run with the framework and why the ReplicatedFirst sample code use(d) _G to access a controller.
LocalScripts in ReplicatedFirst start before anything else has been replicated to the client, meaning that it won’t have full availability to AeroGameFramework’s components. It would be nice to have support, sure, but the replication behaviour serves as a blocker for being able to do this completely. AGF provides the _G fallback so that you can effectively still access the framework the same way.
That being said, I don’t develop AGF, so what I’m saying could be wrong. Consider this more my take on the situation than anything factual.
Update for the record, the specific solution I settled on was:
Custom Loading Screen with AGF, Rojo and VS Code
In VS Code remove unhide the src/_framework folder (WARNING editing contents can break AGF)
Switch from AGF Plugin view to Explorer view
In Explorer view under src/_framework/rep_first add a file named LoadingScreen.client.lua or something else ending in .client.lua for Rojo to treat as LocalScript.
This keeps your custom loading screen managed in the same code repository and automatically updates Roblox Studio exactly the same way as the rest of your AGF project does. AGF doesn’t manage it, but Rojo does.
Unhide the src/_framework folder in VS Code:
VS Code > Preferences > Settings > Text Editor > Exclude
Remove the entry listed as **/src/_framework or **/_framework
(whichever one has _framework, there is probably only one such entry)
Yup that’s a viable workaround. BTW the only reason I hide _framework is to prevent people from accidentally messing with the core of the framework and breaking it and then blaming me But for your use-case, that works fine. Your point about Rojo managing it and not AGF is spot on.
If you need to access the framework within ReplicatedFirst, it should be done using the _G.Aero global, which is documented here. In the case of ReplicatedFirst w/ AGF, the logical flow should look like this:
Do your own loading FX (e.g. throw in your own UI and remove the default loading screen)
Wait for game to load: if not game:IsLoaded() then game.Loaded:Wait() end
Wait for Aero: while not _G.Aero do wait() end
Freely access _G.Aero for anything else
I use this flow personally. I will then typically talk to AGF to fade in/out the screen from the loading UI to my main game UI.
But for your use-case, that works fine. Your point about Rojo managing it and not AGF is spot on.