I want several GUI elements to update their contents when the Data loaded by ProfileService becomes available. I tried to achieve that with the following function:
-- SERVER Data manager script
function OnPlayerAdded(Player)
local PlayerProfile = ProfileStore:LoadProfileAsync("Player_"..Player.UserId)
if PlayerProfile then
PlayerProfile:AddUserId(Player.UserId)
PlayerProfile:Reconcile()
PlayerProfile:ListenToRelease(function()
Profiles[Player] = nil
Player:Kick()
end)
if Player:IsDescendantOf(game.Players) then
Profiles[Player] = PlayerProfile
-- Profile has successfully been loaded and cached here!
InitializeLeaderstats(Player)
LoadGamepassData(Player)
-- This should fire in all the UI handler scripts giving them the Data to work with.
Remotes.Events.UpdatePlayerData:FireClient(Player, PlayerProfile.Data)
else
PlayerProfile:Release()
end
else
-- Profile couldn't be loaded
Player:Kick()
end
end
The issue I’m having is that not all GUI scripts have been loaded in when that UpdatePlayerData event gets fired, making it so that some GUI elements don’t get the Data when the Data becomes available.
I tried making a workaround that looks like this:
-- CLIENT WindowHandler script
-- If there is no data to be found, keep trying to fetch it until it succeeds
while not Data do
Data = Remotes.Functions.GetPlayerProfileData:InvokeServer()
if Data then
UpdateGUI(Data)
end
task.wait(0.5)
end
-- This should get the data as soon as it is available but it doesn't fire sometimes
-- due to the GUI not being loaded when that RemoteEvent gets fired from the server
Remotes.Events.UpdatePlayerData.OnClientEvent:Connect(function(NewData)
local Data = NewData
UpdateGUI(Data)
end)
This workaround works but it doesn’t feel right to keep spamming the server with a data request until it decides to finally give it out, because sometimes the GUI’s load BEFORE the Data is available.
I feel like this can be fixed by waiting for the Player’s GUI element to fully load and THEN give out the data from the server if it’s available but I haven’t been able to succeed with that.
The script/GUI hierarchy looks like this to anyone wondering:
I’d suggest rethinking your project structure. If you’re frequently sending requests to the server at that rate, it might be time to reconsider your approach. Consider having a single script dedicated to receiving data and spreads the right data per module that manages/updates their respective UI components. I might have misinterpreted your question, so please correct me if I’m wrong. I’m still learning too, so I appreciate your understanding. I also think ReplicaService is good for this kinda thing.
That’s indeed what I’m trying to prevent from happening and I put that in the question to prevent assumptions like that, yeah.
This workaround works but it doesn’t feel right to keep spamming the server with a data request until it decides to finally give it out, because sometimes the GUI’s load BEFORE the Data is available.
I feel like this can be fixed by waiting for the Player’s GUI element to fully load and THEN give out the data from the server if it’s available but I haven’t been able to succeed with that.
Everytime the data updates on the server, it sends it out to the respective player’s client, but it doesn’t do that if the GUI isn’t loaded before the data is sent out, which is the problem I’m having.
It only loops for the Data if the client doesn’t have any data, since it needs to initialize the GUI with stuff from the playerdata. Any other time, it relies on remote events.
Have you tried using ReplicaService for this kind of thing? I think that’s what it was made for to be honest. But if that doesn’t interest you I think waiting till all UI elements have fully loaded then getting data would make sense I suppose.
I would prefer waiting for the GUI to load, so indeed your second option. I vane;t been able to figure out how to do that though. Would you know a way to achieve that?
In the meantime I’ll look into ReplicaService, I haven’t heard of that before.
Consider structuring your UI management with a single script dedicated to receiving and distributing data to module scripts, each handling their respective UI components. For example:
UI-Core -> initializes WindowUpgradeHandler (waits for window-upgrade based UI to exist -> UI-Core waits for replicate signal -> updates WindowUpgradeHandler)
