Capacità di script è un sistema che offre il controllo sulle azioni che gli script possono eseguire all'interno del DataModel sottotratta.Fornisce un migliore controllo sugli script dell'esperienza piuttosto che essere un sistema "tutto o niente" in cui qualsiasi script può fare qualsiasi cosa gli altri script possono.
- Questo sistema ti consente di limitare ciò che i modelli presi dalla toolbox possono fare e rende più facile includere contenuti generati dagli utenti all'interno dell'esperienza, anche quelli che contengono script.
- Può anche aiutare a garantire una migliore sicurezza delle esperienze che consentono ai giocatori di eseguire il proprio codice, che viene spesso eseguito in un Ambientelimitato o emulato.
- Può essere utilizzato anche per condividere librerie che limitino ciò che possono fare da sole.Ad esempio, una libreria che fornisce metodi matematici aggiuntivi può essere limitata al più piccolo set di capacità di cui ha bisogno in modo che gli altri sviluppatori che utilizzano quella libreria non debbano validare l'intero codebase per assicurarsi che non includa codice dannoso.
Abilita le capacità dello script
Per abilitare questa Proprietà, cambia la impostazione SandboxedInstanceMode da Default a Experimental nell'esploratore.
Quando il test beta del cliente è completato, questo passo non sarà più richiesto.
Contenitore sandboxato
Questo sistema introduce un concetto di un contenitore sandboxato **** .Un'istanza di tipo Model , Folder , Script , o discendenti di qualsiasi di quelle classi hanno una proprietà Sandboxed disponibile nella finestra Studio Proprietà , sotto la sezione Permessi .

L'abilitazione della proprietà Sandboxed designa l'istanza come un container sandbox all'interno dell'albero DataModel, che limita le azioni che gli script all'interno di tale container possono eseguire in base al set di valori della ProprietàCapabilities.
Capacità
La proprietà Capabilities è un insieme di valori che controlla diversi aspetti dell'esecuzione, divisi in quattro gruppi:
- Controllo di esecuzione - Specifica se uno script può essere eseguito sul client o sul Server
- Controllo dell'accesso all'istanza - Specifica quale DataModel parti uno script può interagire
- Controllo funzionalità dello script - Specifica quali script di funzioni Luau possono chiamare
- Controllo dell'accesso all'API del motore - Specifica quali parti dell'API del motore Roblox possono essere utilizzate
Quando uno script tenta di eseguire un'azione che non è nel set delle capacità per lo stato di esecuzione attuale, viene segnalato un errore.Gli errori includono tipicamente l'azione che viene tentata, il bersaglio di un'azione e la prima capacità che manca, ad esempio:
The current thread cannot modify 'Workspace' (lacking capability AccessOutsideWrite)The current thread cannot call 'Clone' (lacking capability CreateInstances)The current thread cannot call 'GetSecret' (lacking capability Network)
Controllo dell'esecuzione
Questo set include due capacità:
- Esegui script cliente - LocalScript o Script con un valore di RunContext di Client è consentito di eseguire sul client
- Esegui script del server - Script con un valore di RunContext di Server è consentito di eseguire sul server
Se lo script è Enabled , ma la capacità corrispondente alla posizione in cui tenta di avviarsi non è disponibile, viene visualizzato un messaggio di avvertimento nella finestra Output .Se uno script non doveva essere eseguito in quel contesto, disabilitalo o eliminalo.
Si noti che ModuleScripts non sono richiesti per avere queste capacità di esecuzione richieste.
Quando uno script non riesce a iniziare perché manca la capacità di controllo dell'esecuzione, viene segnalato come avviso nell'Output, ad esempio:
Cannot start server script 'Script' (lacking capability RunServerScript)
Controllo dell'accesso alle istanze
Questo set include solo una singola capacità:
- AccessOutsideWrite - Lo script è autorizzato a recuperare e ricevere istanze da fuori il contenitore sandboxato
Quando la capacità non è disponibile, lo script può solo cercare istanze che sono all'interno del proprio contenitore sandboxato.Ad esempio, se lo script viene posizionato direttamente nel contenitore sandbox, script.Parent.Parent restituisce nil .
Inoltre, qualsiasi evento API Roblox che passa in un Instance invece passa in nil per qualsiasi Instance al di fuori del contenitore sandbox.Ad esempio, se il BasePart.Touched è segnalato da un tocco da un'istanza al di fuori del contenitore sandboxato, l'evento viene ancora ricevuto, ma l'argomento è nil .
Evita di impostare questa capacità; le garanzie di sabbiera sono più deboli quando gli script possono interagire con qualsiasi istanza in un'esperienza.
Accesso ai servizi
Anche senza AccessOutsideWrite , gli script nel contenitore sandbox possono ancora accedere a game , workspace e servizi.Questo accesso è fornito in modo che gli script possano ancora chiamare metodi utili di quei globali, come DataModel.GetService , ma l'accesso alle loro istanze figlie è ancora validato.
Istanze internamente passate
Se un'istanza viene passata attraverso una chiamata funzione che non passa attraverso le API di Roblox, il riferimento viene preservato.Tuttavia, se un ModuleScript viene passato in questo modo, non può essere richiesto senza AccessOutsideWrite .Questo perché il ritorno del ModuleScript è spesso mutabile e può essere modificato da uno script in un contenitore sandboxato.
Controllo della funzionalità degli script
Questo insieme di capacità controlla alcuni aspetti generali degli script:
- AssetRequire - Lo script è autorizzato a chiamare require con un ID di risorsa
- CaricaString - Lo script è autorizzato a chiamare loadstring
- Creare istanze - Lo script può creare nuove istanze utilizzando Instance.new, Instance.fromExisting o Instance:Clone()
Tieni presente che le restrizioni funzione predefinite sono ancora applicabili.Anche se CaricaStringa è abilitato, l'esperienza deve ancora attivarlo in ServerScriptService e è ancora disponibile solo sul Server.
Per creare nuove istanze, oltre a CreateInstances , è necessaria un'ulteriore capacità dell'API Engine che fornisca l'accesso a quell'istanza.
Controllo dell'accesso API del motore
Questo ultimo gruppo di capacità controlla l'accesso agli script a diverse API del motore:
- Basilare - Accesso a semplici istanze e blocchi di costruzione essenziali
- Audio - Accesso alle istanze relative alle API audio
- DataStore - Accesso alle API del deposito di dati e del deposito di memoria
- Rete - Accesso alle API di rete HTTP
- Fisica - Accesso alle istanze relative alla fisica
- UI - Accesso alle istanze relative alle interfacce utente
- CSG : accesso alle istanze e alle funzioni relative alla geometria solida costruttiva (CSG (Geometria costruttiva dei solidi))
- Chat : accesso alle istanze relative alla chat in-experience
- Animazione : accesso alle istanze relative alle animazioni
- Avatar : accesso alle istanze relative agli avatar
- Input : accesso alle istanze relative all'input dell'utente
- Ambiente : accesso alle istanze relative al controllo di come l'ambiente viene visualizzato
- RemoteEvent : accesso alle istanze per le operazioni di rete interna
Ci sono anche istanze che sono disponibili senza alcuna capacità a parte l'esecuzione degli script.Questi includono i seguenti metodi HttpService :
Se una proprietà o un metodo dell'istanza viene acceduto senza una capacità richiesta, viene segnalato un errore che descrive la capacità mancante.
Infine, le capacità non coprono ogni istanza nell'Engine Roblox di oggi.Le istanze non elencate in questa sezione o nella seguente non sono disponibili per l'interazione da un container sandbox e lanciano un errore che dice che una capacità non assegnata non è disponibile per lo script attuale .
Una limitazione aggiuntiva è che le funzioni getfenv e setfenv non sono disponibili per gli script in un contenitore sandboxato.
L'accesso solo dello script alle istanze è limitato.Le istanze stesse possono ancora esistere e operare da sole all'interno di un container sandboxato.Le luci continuano a brillare, le interfacce utente sono ancora visibili e le configurazioni audio che sono già cablate riproducono suoni.
Assegnazioni della capacità dell'API del motore
Ecco l'elenco delle istanze e dei metodi (se diversi dalla capacità dell'istanza) per ciascuna capacità API del motore:
Basilare * Attachment
Magazzino dati * DataStore , OrderedDataStore , GlobalDataStore
Fisica * AlignOrientation , AlignPosition , DynamicRotate
UI * BasePlayerGui , PlayerGui , BillboardGui , GuiBase , GuiBase2d , GuiBase3d , LayerCollector , ScreenGui , SurfaceGui , SurfaceGuiBase , UIBase
- UIComponent , UICorner , UIDragDetector , UIFlexItem , UIGradient , UIGridLayout , UIGridStyleLayout , UILayout , UIListLayout , UIPadding , UIPageLayout , UIScale , UIStroke , UITableLayout
CSG * GeometryService
- IntersectOperation (richiede anche Basic ), NegateOperation (richiede anche Basic ), PartOperation (richiede anche Basic ), UnionOperation (richiede anche Basic )
Animazione * Bone (richiede anche Base )
Ambiente * Atmosphere , Clouds , Lighting , Sky
Evento remoto * BaseRemoteEvent , RemoteEvent , UnreliableRemoteEvent
Interazioni tra container
Contenitori annidati
Quando un contenitore sandboxato è annidato all'interno di un altro, le istanze del contenitore interno sono accessibili all'esterno.
Le capacità del contenitore interno sono limitate dalle capacità di quello esterno.Ad esempio, se il contenitore esterno ha capacità di Basilare , Audio e CSG , mentre il contenitore interno ha Basilare e Rete , solo le capacità Basilare sono disponibili al contenitore interno in Tempo esecuzione.
Se non ci sono capacità in comune tra i contenitori interni e esterni, il set di capacità risultante è vuoto.
Funzioni e eventi legati
BindableEvent e BindableFunction forniscono il modo migliore per comunicare con il container o consentirgli di eseguire richiami con capacità che non è consentito utilizzare direttamente.
Quando viene eseguito un evento o una funzione, le connessioni vengono eseguite nel contesto della funzione che li ha registrati.Questo significa che se l'evento o la funzione di richiamo viene registrato dal container sandboxato, viene chiamato con le capacità di quel container.Se il richiamo viene registrato dal codice all'esterno, quando vengono invocati gli script del contenitore in sandbox, eseguono le tue funzioni con le capacità disponibili per le tue funzioni.
È importante notare che anche con la capacità AccessOutsideWrite , gli script nei contenitori sandboxati non possono invocare eventi o funzioni al di fuori dei loro contenitori se hanno un set di capacità più ampio rispetto al contenitore stesso.
Modulo Richiesto/a
L'interno ModuleScripts può essere richiesto dal container sandboxato come al solito.Tuttavia, se l'istanza target è al di fuori del container, il ModuleScript può essere richiesto solo se il set di capacità disponibile è più piccolo o uguale alle capacità disponibili al container.
Questa limitazione non si applica a RunClientScript e RunServerScript capacità.Se il ModuleScript è posizionato in un container con solo RunClientScript ma è richiesto da uno script che ha la capacità RunServerScript , è consentito riuscire ed eseguire quelle funzioni sul Server.
Funzioni chiamate direttamente
Se un ModuleScript in un contenitore sandbox è richiesto da fuori del contenitore, alcune delle protezioni non sono disponibili.In particolare, la funzione target è in grado di accedere a tutte le istanze disponibili per il chiamante.Se il chiamante non è in un contenitore sandboxato, la chiamata funziona come se AccessOutsideWrite sia disponibile per esso.
Altre restrizioni di capacità sono ancora applicate.Se hai una capacità di accesso DataStore , ma il modulo target non lo fa, non è in grado di chiamare DataStore.Tuttavia, se passi la tua funzione lavorando con DataStore, il bersaglio può eseguirlo durante quella chiamata.Se il bersaglio programma un thread utilizzando metodi come quelli da task , quei thread perdono la capacità di chiamare quella funzione.
Le istanze possono essere passate al modulo target o assegnate ai campi del modulo.
Se necessario, si consiglia di assegnare i membri della tabella utilizzando rawset per evitare di eseguire __index / __newindex metodi metametodici che potrebbero essere impostati sulla tabella.
La raccomandazione generale è comunicare con BindableEvent e BindableFunction ogni volta che possibile.
Movimento delle istanze
La maggior parte delle istanze non ha restrizioni sul movimento tra container.Le istanze di script, tuttavia, possono essere spostate solo in un container che ha lo stesso insieme di capacità o un sottinsieme di quelle capacità.
Questo significa che il container sandbox con AccessOutsideWrite non può semplicemente ri-genere uno script all'interno di sé stesso per l'esterno e ottenere più capacità.