-
Notifications
You must be signed in to change notification settings - Fork 1
BooTS Boo for TShock
The Boo scripting system has been moved into its own assembly now, so can now be the base of a scripting system for any plugin or external code. It no longer relies on CustomNpcs, but is still part of the same vs sln and code repository for the time being.
CustomNpcs2 now uses the Boo language for its scripting duties. So why Boo?
-
Safety
-
Threading:
Hard to debug threading issues have been present since the beginning. This appears to be synchronization issues between our code running on the CLR, and then on Lua. Debugging this would be a nightmare. Now everything sits in the same runtime, which provides excellent error reporting and debugging capabilities.
-
Compile time error checking:
Its now possible to get error information during compilation, instead of waiting for an error to arise at runtime. ( Though, runtime errors will still happen, obviously ).
-
-
Performance
-
Compiled code:
Boo doesn't use a true interpreter. Instead, it always compiles down to IL, and is then JIT'd to native code at runtime( Same as C# and VB.NET. ). Generally, you can expect similar performance to any other compiled code running on the CLR.
-
Strongly typed( except when we want dynamic types ):
Dynamic types/dispatch is convienent, but slow. Boo uses type inference to figure out types where it can, and we only have to specify types where needed. But for those places where ease of use trumps performance, Boo supports dynamic dispatch.
-
Marshalling overhead:
Moving data between the CLR and Lua's runtime, and calling into functions in each other's runtime isn't free. There is additional pressure by keeping a whole separate runtime loaded in the process as well. By using a single runtime, these costs disappear.
-
-
Ease of use
-
Customizable compiler:
One of Boo's driving goals was flexibility. It features an open compiler, which is customizable through various means.
-
Directly interact with the .NET BCL ( and Terraria):
As a native CLR language, Boo can make use of all .NET Api's. It can also directly call into Terraria, OTAPI, and TShock if CustomNpcs2 exposed functions are not enough.
-
DuckTyping is enabled by default, so anything typed as object, will use dynamic dispatch.
Scripts are compiled into in-memory assemblies, grouped by their purpose.
- ScriptedInvasions.dll
- ScriptedNpcs.dll
- ScriptedProjectiles.dll
These assemblies are "collectible", meaning that they can be unloaded by the runtime, when they fall out of use.
Keep in mind that it is currently not supported to have 2 scripts of the same name. You may have multiple custom types use the same script, but pointing to multiple scripts with the same filename will NOT work.
ScriptPath: "npc\easy\BadGuy.boo"
...
...
ScriptPath: "npc\hard\BadGuy.boo" #module resolution is basic, and doesn't support this! This would try to create 2 BadGuy modules.
All functions that were present in the utils.lua file have been converted to C#, and are imported by default into your boo scripts. Specifically, here's what is imported by default, so you don't have to:
import System
import System.Collections.Generic
import Microsoft.Xna.Framework
import TShockAPI
import Corruption.AreaFunctions
import Corruption.EmoteFunctions
import Corruption.TimeFunctions
import Corruption.TileFunctions
import Corruption.PlayerFunctions
import Corruption.PlayerCommandFunctions
import CustomNpcs
import CustomNpcs.Invasions
import CustomNpcs.Npcs
import CustomNpcs.Projectiles
import CustomNpcs.NpcFunctions
import CustomNpcs.ProjectileFunctionsThe tweaked compiler will look for the predefined hook points in your scripts, and if found, set the appropriate types if they are missing.
In short, it converts this:
def OnCheckSpawn(player,x,y):
passInto:
def OnCheckSpawn(player as TSPlayer, x as int, y as int) as int:
passThis avoids the performance penalties from duck(dynamic) typing, and provides better error checking at compile time.
Note that any variables of type object you declare, will still be duck typed.