A method to ensure a server script runs before any other?

For local scripts, you can just place it in ReplicatedFirst and it will run before all other local scripts but is there some way or another to achieve the same result but with serverside scripts?

What do you need the server script to do first before others?

You can just take an event-based approach.

If the script does something regarding players in the game. Then you can listen to the CharacterAdded or PlayerAdded event. The way I usually do this. I have a module that listens to PlayerAdded and then fires a “Bindable” or “Remote” event. Other modules listen to that event instead of Roblox’s API events.

The flow goes from there.

1 Like

I thought of a similar approach but was looking for something easier I guess

What is your use case here? If you want something “easy” you can add a wait(n) statement at the beginning of scripts you want to start later, but that would be a pretty hacky solution. But you really should be doing something like what @T0ny suggested.

1 Like

There’s no reason for this to happen to begin with. If you need this behaviour, you’re expected to organise your code such that you control the predictability and flow of code. This is typically why some games might use a framework or single-script architecture, so they can determine when code runs.

What’s your use case for trying to define the running order of scripts? Sounds like you have some race conditions going on with your code; and if that’s the case, then you’re solving this the wrong way. The key is to fix your organisation instead or make it so that some script is controlling execution flow.

ReplicatedFirst exists so the client can run initialising code before the DataModel snapshot finishes replicating, it’s necessary in the client’s case for loading procedures. Not for the server.

5 Likes

I also thought of this and so far I think this is the best method of doing this.

The same thing can be said towards ReplicatedFirst. If you need certain bits to run before the rest then you can organize your game to work with a single-script architecture so you can control the flow yourself. Initializing code exists both backend and frontend. if anything it happens backend more than frontend so it would make much much more sense to have a similar service for serverside scripts over local scripts. The only unique use case for ReplicatedFirst is to run loading screens, anything else can be done using different methods. So yes there is a reason for this to happen.

1 Like

There’s a different case for the client than there is for the server, so the same isn’t applicable.

The server’s code always runs at the moment the game starts up and it implicitly has access to all of the resources it needs. A ReplicatedFirst equivalent for the server isn’t required because it has no need to draw up any processes. The server is spawned and code is ran.

In the client’s case, it is responsible for most of the game’s functionality - rendering, client-side code, connecting and whatnot. The distinction between standard code and that in ReplicatedFirst is that you can have code running before any downloading or processes attaching. This is required or highly recommended in various cases, including loading screens and client initialisation (e.g. ChatService settings to control predictability of hooking an event).

The primary difference to understand here is that there is a legitimate reason for ReplicatedFirst to exist, which is to ensure prioritised replication for initial game content. There’s actual functionality to the client for having it. The server does not need to have it and it therefore just becomes an organisation issue, not a functional one. That’s why the client requires something to start code before any snapshots begin replicating, but the server doesn’t.

You can control flow in both standard client code, ReplicatedFirst code and server code. There’s a functional need to have a distinction between standard client elements and prioritised replication. The server doesn’t need that, so it’s just an organisation factor. Having a server equivalent of ReplicatedFirst is unnecessary API bloat.

2 Likes

for example, i might want putting all GetService() calls into the _G global variable in my Init script (which gets executed before everything else), so that all other scripts have less boilerplate code in them