Scripttypes en locaties

Voor veel ontwikkelaars is de fundamentele uitdaging van het aanpassen aan Roblox-scripting het belang van de bestandslocatie en de Script.RunContext-eigenschap. Afhankelijk van het type script, de locatie in de Explorer en de uitvoeringscontext, kunnen scripts heel verschillend gedrag vertonen. Bepaalde methode-aanroepen kunnen mislukken, objecten in je spel kunnen ontoegankelijk zijn, of scripts kunnen helemaal niet draaien.

De reden voor deze complexiteit is dat Roblox-spellen standaard multiplayer zijn. Scripts moeten de mogelijkheid hebben om alleen op de server te draaien, alleen op de client, of gedeeld te worden tussen beide. De evolutie van het Roblox-platform in de loop der tijd heeft de situatie verder gecompliceerd.

Scripttypes

Roblox heeft drie soorten scripts:

• Script - Code die draait op de server of de client, afhankelijk van de locatie en de Script.RunContext-eigenschap.
• LocalScript - Code die alleen op de client draait. Heeft geen uitvoeringscontext.
• ModuleScript - Code die je kunt hergebruiken in andere scripts. Heeft geen uitvoeringscontext.

Wanneer je een Script aanmaakt, is de standaard uitvoeringscontext Legacy, wat betekent dat het a) een server-side script is en b) alleen draait als het zich in een servercontainer bevindt, zoals ServerScriptService of Workspace.

• Als je de uitvoeringscontext van het script wijzigt naar Server, kan het nu ook draaien in ReplicatedStorage, maar we raden dit niet aan. De inhoud van die locatie wordt gerepliceerd naar clients, dus het is een slechte locatie voor server-side scripts.
• Als je de uitvoeringscontext van het script wijzigt naar Client, kan het draaien in ReplicatedStorage. Het kan ook draaien in StarterCharacterScripts en StarterPlayerScripts. Startercontainers worden gekopieerd naar clients, dus het originele script en de kopie draaien, wat niet wenselijk is.

Om de uitvoeringscontext van een script te wijzigen, selecteer je het in de Explorer en wijzig je de waarde in het Properties venster.

Aanbevelingen

• Plaats een enkele Script met een RunContext van Client in ReplicatedStorage.

• Plaats een enkele Script met een RunContext van Server in ServerScriptService.

• Gebruik ModuleScripts voor zoveel mogelijk client- en servercode. Vereis deze modules vanuit je clientscript en je serverscript.

  Deze aanpak geeft je code een enkel toegangspunt aan de client- en serverzijde, wat de organisatie vereenvoudigt en het gemakkelijk maakt om problematische modules te isoleren of uit te schakelen. Voeg een start()-functie toe aan elke ModuleScript, zodat alle modules kunnen laden voordat je begint met het uitvoeren van hun code:

  Voorbeeld server script

  --!strict
  local ServerScriptService = game:GetService("ServerScriptService")
  local SampleModule = require(ServerScriptService.SampleModule)
  local AnotherSampleModule = require(ServerScriptService.AnotherSampleModule)
  SampleModule.start()
  AnotherSampleModule.start()

  Voorbeeld module

  --!strict
  local CollectionService = game:GetService("CollectionService")
  
  local NPC_TAG = "npc"
  
  local SampleModule = {}
  
  local function setUpNpc(npc: Instance)
      -- initialiseer elke NPC
  end
  
  local function cleanUpNpc(npc: Instance)
      -- voer uit wanneer het evenement afgaat
  end
  
  function SampleModule.start() -- voeg de functie toe aan de tabel
      -- voorbeeld lus voor setup op basis van tags
      for _, npc in CollectionService:GetTagged(NPC_TAG) do
          setUpNpc(npc)
      end
  
      -- voer functies uit wanneer evenementen afgaan
      CollectionService:GetInstanceAddedSignal(NPC_TAG):Connect(setUpNpc)
      CollectionService:GetInstanceRemovedSignal(NPC_TAG):Connect(cleanUpNpc)
  end
  
  return SampleModule

• Om code te delen, gebruik ModuleScripts in ReplicatedStorage en vereis ze in zowel je clientscript als je serverscript.

• Indien nodig voor je spel, herhaal hetzelfde patroon in ReplicatedFirst met een enkel clientscript en een minimaal aantal ModuleScripts om een laadscherm te implementeren. Om meer te leren over ReplicatedFirst, zie Replicatievolgorde.

• Gebruik LocalScripts spaarzaam. Als je ze moet gebruiken, plaats ze dan in StarterCharacterScripts, StarterPlayerScripts, StarterGui of StarterPack.

  Scripts in deze containers worden gekloond naar spelerscontainers in plaats van dat ze vanuit één locatie draaien, wat het debuggen kan compliceren. Het gebruik van ReplicatedStorage voor clientcode stelt je in staat om regels in het Output venster aan te klikken en naar ReplicatedStorage.YourScript (de stabiele locatie van het script) te gaan in plaats van Players.YourName.PlayerScripts.YourLocalScript (de vluchtige locatie waar het script tijdens runtime naartoe is gekopieerd).

• Vermijd het direct aanhechten van scripts aan instanties in Workspace. Tag in plaats daarvan instanties en gebruik CollectionService om met hen te werken vanuit een enkele ModuleScript.

  De belangrijkste uitzondering is als je modellen of pakketten op de Creator Store distribueert. In dat geval moet je mogelijk scripts binnen de instantiehiërarchie opnemen; specificeer een RunContext voor elk script om ambiguïteit over hoe het draait te verwijderen. Het expliciet instellen van deze eigenschap maakt modellen en pakketten waarschijnlijker om goed te functioneren vanuit verschillende locaties.

Voorbeeld projectstructuur

Het Plant referentieproject toont hoe je je code in een groot, complex spel kunt organiseren. Het slaat het grootste deel van zijn code op als herbruikbare ModuleScripts.

Scriptlocaties

Deze afbeelding toont welke locaties in het Explorer venster client scripts kunnen bevatten. Vergeet niet dat ReplicatedFirst en ReplicatedStorage Scripts kunnen bevatten met een RunContext van Client, terwijl de Starter[] containers LocalScripts zouden moeten gebruiken.