Script, LocalScript und ModuleScript in Roblox Studio richtig platzieren

Zuerst die ausführende Seite bestimmen #

Gib jedem kleinen Codebereich eine klare Aufgabe. Belohnungsregeln brauchen eine Serverprüfung; die lokale Darstellung der Oberfläche gehört zum Client. Eine gemeinsame Funktion kann in einem Modul liegen, das die passende Seite aufruft. Bestimme den Einstieg vor dem Anlegen im Explorer.

Typ, Ort und bei normalen Scripts RunContext beeinflussen die Ausführung. Gleicher Text kann in anderen Containern anders wirken. Die Übung erzeugt getrennte Server- und Clientmeldungen und lädt ein kleines Modul. Ein eigenes Übungsprojekt hilft, jede Meldung ihrem Beispiel zuzuordnen.

1. Ein normales Server-Script starten #

Füge in ServerScriptService ein normales Script namens ServerStart ein. Wähle in Properties den RunContext Server. Der Standard Legacy funktioniert hier ebenfalls, doch Server zeigt die Absicht ausdrücklich. Prüfe, dass das Script aktiviert ist.

Ersetze den Inhalt durch das erste Beispiel. Öffne Output und starte Test mit einem Spieler. Erwartet wird SERVER: ready im Server-Kontext. Das bestätigt das Erreichen von print(), keine fertige Belohnungslogik. Bei fehlender Zeile prüfe Filter und Ort, bevor du den Code änderst.

print("SERVER: ready")

2. Ein Client-Script starten #

Lege in ReplicatedStorage ein normales Script namens ClientStart an. Setze RunContext ausdrücklich auf Client und füge das zweite Beispiel ein. Ein normales Script mit Legacy wird allein durch die Ablage hier kein Client-Einstieg.

Starte einen neuen Test. CLIENT: ready gehört zum Client, SERVER: ready zum Server. Die aktuelle Dokumentation empfiehlt ReplicatedStorage für diesen Client-Einstieg. Verschiebe das Script mit Client-Kontext nicht nach StarterPlayerScripts: Original und Kopie können laufen und unerwünschte doppelte Ausführung erzeugen.

print("CLIENT: ready")

3. Bei LocalScript die Kopie beachten #

LocalScript läuft auf dem Client und hat keinen RunContext. Stoppe für eine getrennte Übung den Test, deaktiviere ClientStart vorübergehend und erstelle LocalStart als LocalScript unter StarterPlayer → StarterPlayerScripts. Verwende print("LOCAL: ready").

Suche nach Test die Clientmeldung. Starter-Inhalte werden zum Spieler kopiert, deshalb kann die Quelle Players → Spielername → PlayerScripts zeigen. Der Laufzeitpfad unterscheidet sich damit vom ursprünglichen Ort. Ein LocalScript, das nur in ReplicatedStorage liegt, startet dort nicht automatisch.

4. ModuleScript aus einem Einstieg laden #

Stoppe und erstelle in ReplicatedStorage ein ModuleScript mit dem exakten Namen PracticeModule. Füge das erste der beiden Beispiele dieses Abschnitts ein. Es gibt eine Tabelle mit start() zurück. Das Anlegen des Moduls ruft die Funktion nicht auf; laufender Code muss es laden.

Ersetze ServerStart durch das zweite Beispiel: Es findet das Modul, erhält seinen Rückgabewert über require() und ruft start() auf. Ein neuer Test sollte MODULE: started im Server-Kontext zeigen. WaitForChild wartet auf den angegebenen Namen. Ein Tippfehler erzeugt kein fehlendes Modul; vergleiche Explorer und Code.

local PracticeModule = {}

function PracticeModule.start()
    print("MODULE: started")
end

return PracticeModule

print("SERVER: ready")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local practice = require(ReplicatedStorage:WaitForChild("PracticeModule"))
practice.start()

5. Container nach Zweck auswählen #

Die Tabelle bietet eine Ausgangsstruktur. ServerScriptService eignet sich für Server-Einstiege, ReplicatedStorage für den empfohlenen Client-Kontext und gemeinsame Module. Ein reines Servermodul kann in ServerScriptService bleiben, wenn der Client es nicht braucht.

Ort und Sichtbarkeit sind getrennte Fragen. ReplicatedStorage wird an Clients übertragen: gemeinsame Module dürfen keine Geheimnisse enthalten oder Serverprüfungen für Käufe und Belohnungen ersetzen. ServerStorage lagert Serverobjekte; normale Scripts starten dort nicht automatisch. Platziere den Einstieg im Ausführungscontainer statt zwischen gespeicherten Modellen.

6. Bei fehlendem Start vier Dinge prüfen #

Prüfe den genauen Typ, den Explorer-Pfad, RunContext soweit vorhanden und die Aktivierung. Finde bei einem Modul außerdem das laufende Script mit require(). Ähnliche Symbole und gleiche Namen belegen keine gleiche Ausführungsumgebung.

Setze am Einstieg ein kurzes print, entferne den Output-Textfilter und zeige den passenden Kontext. Erscheint nur die erste Markierung, lies den Code dazwischen. Fehlen beide, prüfe zuerst Start und Anzeige. Lies Laufzeitfehler anhand ihrer Quelle. Zufälliges Verschieben aller Dateien erschwert das Eingrenzen.

7. Den ursprünglichen Code speichern und prüfen #

Stoppe vor der endgültigen Änderung. Hast du während des Spiels die LocalScript-Kopie in PlayerScripts bearbeitet, übertrage die Korrektur in den ursprünglichen LocalScript in StarterPlayerScripts. Testobjekte werden nach Stop zurückgesetzt; eine Änderung nur an der Kopie kann beim nächsten Lauf fehlen.

Aktiviere für die Hauptübung ClientStart wieder und deaktiviere den nicht mehr benötigten LocalStart. Prüfe im neuen Test SERVER: ready, CLIENT: ready und MODULE: started aus dem Serveraufruf. Speichere. Benenne anschließend Typ, Pfad, Kontext und Aufrufer jeder Meldung, bevor du echte Funktionen einzeln umordnest.