Is it a problem if I use serverscript for init design the UI?

Help and Feedback Scripting Support
#1

I made a checkpoint system and it uses the checkpoint models from the workspace and contains a lot of code, then sends some information about the checkpoint + checkpoint settings through the fireclient(checkpointName,description,height,etc.) function with the code so that it can design the gui. But I feel like something is wrong, it seems better to do this from localscript (get checkpoint height etc.), but it is the serverscript that receives the checkpoints.

also other serverscripts uses checkpoint system (modulescript)
and 2 checkpoint setting scripts looks bad to me. (one for clientside, one for serverside)

code example:

-- ServerScript
function module.new(checkpointModel)
    local self = {...,height=checkpointModel.WorldPivot,settings=Settings[checkpointModel.id.Value]}
    -- ...
    return self
end
function onPlayerAdded(player: Player)
    RemoteEvent:FireClient(player, "InitCheckpointsGui", guiArgs)
end

-- Init Checkpoints
for _,checkpointModel in ipairs(workspace.Checkpoints:GetChildren()) do
    module.new(checkpointModel)
end

game:GetService("Players").PlayerAdded:Connect(onPlayerAdded)

-- LocalScript
function OnClientEvent(state: string, ...)
    if state == "InitCheckpointsGui" then
        local guiArgs = ...
        for _,info in ipairs(guiArgs) do
            local checkpointFrame = checkpointTemplate:Clone()
            checkpointFrame.Name = info.Name
            checkpointFrame.Description = info.Description
            -- ...
        end
    end
end
#2

From my understanding, your current implementation has the server sending checkpoint data to the client, which then constructs the GUI?

I don’t see a problem with this. It could be optimized a little, but other than that, unless you’re running into any problems, you should be fine.

#3

yes you got it right.

Since I didn’t do it from localscript, I thought it doesn’t optimized enough or it would just be inappropriate because there isn’t much to hide in checkpoint information. also I send gui-specific only informations from the server. but storing checkpoints information from clientside is seems ridiculous to me because it seems like the clientside’s settings module is writing information about a checkpoint that it does not know.

#4

While it’s generally fine to send non-sensitive data from the server to the client, I would always be cautious about what information you share. If the data is purely for display purposes and does not impact game logic or security, then it’s usually okay.

It’s generally a good idea to keep the client-side logic related to UI updates on the client. The server should handle game state, while the client handles the presentation. This separation makes it easier to manage and debug each part.

#5

Yes, you are right, but in my last message:

What is your comment to the message? In general, it makes more sense to me to store gui-specific only data such as ‘Name, Description, Height, GradientColor’ in the clientside, but it seems absurd to keep them without knowing which checkpoints exist in the clientside. and alose, it seems absurd to me to get the information to be stored in the clientside via serverscript.

Do you think using serverscript for that is the most logical thing right now?

#6

I don’t quite understand.

If you are able to pre-define Name, Description, Height, GradientColor and it does not change, it should be fine. If the checkpoints don’t change either, then those are fine on the client too. But it doesn’t really matter since there isn’t really any performance or security implications.

#7

If the information in those settings is independent of the existence of the checkpoint, then if I delete the checkpoint and replace it with a different checkpoint and forget the settings on the client side, it will cause problems.

But now it comes to my mind, if I make the information specific to only those with the same checkpoint name, the problem will be solved.