0

Scripting: change from a file-based model to a class-based model

Mia Grace

February 17, 2018 06:49

None

Follow

Currently in order to add a script to a scene object, the process is as follows:

1. Upload a single .cs file or download one from the store into inventory
2. Drag .cs file from inventory to a scene object to attach it
3. Repeat for each object, even if you're re-using the same script for multiple objects.

This has some drawbacks:

• What if I want to sell a large script in the Sansar store, with a library of different behaviors. This is not possible. I have to separate each behavior into their own script.
• Sharing code between behavior scripts involves error prone copy/paste of large blobs of code into every script file, which I'm assuming ends up being duplicated in the experience.
• See https://help.sansar.com/hc/en-us/community/posts/115018674343-Suggestion-Multi-source-script-bundles-script-assemblies?input_string=Scripting%3A%20attach - The file-based script attachment model doesn't fit well when you're uploading assemblies or bundles of scripts, which is something I still would love to see happen.

From my past experience with Second Life scripting, it seems like this file-based model is somewhat of a holdover from that era, only instead of linden script files it's C# files. But this has some limitations, and causes some friction with more complicated scenes.

So how to improve? I think first of all, we need to switch from a file-based script attachment model to a class based model. Instead of dragging the script from your inventory to an object, you would instead add the script to the scene itself, as a kind of shared asset. Then, once the script file is an asset, you can attach a class (as long as it derives from one of the core script behavior base classes) from any script in the experience's assets to any object. One script file, multiple behaviors, multiple objects.

Than as a bonus, make it so all scripts in an experience's assets can automatically reference each other. And bingo, shared library of common functionality is now very simple. No reflection needed. No huge copy/pasted glob of code in every script file. Just add the common code library as script files in an experience's assets, and then just reference the common library code directly from any other script in the scene's assets.

 

7 comments

• 0
  
  Gindipple February 17, 2018 11:18

  I do wish it was as simple as adding a Using statement to the top of my file and a reference to my already compiled and uploaded assembly.

  Could be an almost seamless transition from VS to Sansar

   

• 0
  
  Galen February 17, 2018 14:22

  I actually think the system Kelly has been developing may be better for a few reasons. For one, I don't want to expose all the classes in the scripts I sell. They are trade secrets. I certainly don't want you being able to reverse-engineer them via Reflection.

  For another, what if two scripts contain a class named "Calculator"? Will the scene not compile? Which one will your script use? The current model wipes away this problem.

  Have you heard of "DLL hell"? In the old Windows programming days we would install shared libraries of DLLs to save disk space. But then it became apparent that different programs needed different versions of each DLL they bought or downloaded, which created a huge mess. Many programs would simply crash because they were not built to use the latest versions of those DLLs. These days, many Windows programs instead include copies of each DLL they need, thus eliminating DLL hell. The equivalent of that is uploading single scripts or self-contained assemblies. The benefit is that you can guarantee that all the classes you directly consume are compatible with your script.

  To be sure, you don't fully escape the compatibility problems by hiding cooperating scripts behind Reflective interfaces. I think we should get in the habit of making our Reflective interfaces identify the manufacturer, product, and version number and letting consumers check them for compatibility, but that won't likely happen soon. Still, the Reflective model is much more in line with the loose coupling concept and all of its benefits.

  Edited by Galen February 17, 2018 14:23
• 0
  
  Galen February 17, 2018 14:30

  I would also argue that scripting in Sansar is not intended to become a full-fledged application development system with complexities approaching those of typical ERMs or service providers like Facebook. Instead, the scripting system here is intended to be oriented toward creating fairly simple behaviors, like walk near a door and it opens.

  Assuming LL eventually lets us make HTTP requests out to our own servers, we will likely offload most of the larger system complexity we want to them.

  I'm probably creating some of the most complicated scripts in Sansar right now. I'll admit that I wish I could create libraries of functions. I hate having to copy and paste reusable code into 30 different scripts. However, my solution to that probably wouldn't involve uploading library files to Sansar. Instead, I'd sooner build and upload whole assemblies from my source file sets, including their libraries.

• 0
  
  Gindipple February 17, 2018 16:37

  The reflection Sansar doesn't expose everything, it exposes what you want it to expose. It is viable to use for libraried coding, I do it now.

  Uploading assemblies would be an even better advancement, kelly I'm sure would agree.

  But they aren't doing anything that isn't fully secure first.

  HTTP is going to be wildy different than I think you expect

  Pretty sure Mia's heard of DLL Hell, as have I...and loose coupling...

  FindReflective returns an enumeration, So if it returns 2 Calculators you can decide on the fly which one is the one you want if you happen to have 2 on a region. I do this with some of my stuff.

  If walk near a door and it opens is the best expectations you have from a game engine, then it's DOA lol

   

• 0
  
  Mia Grace February 17, 2018 17:18

  Good points. Please allow me to address:

  DLL Hell:

  This phenomenon applies to system level Win32 DLLs in Windows. .NET solved DLL hell in a couple of ways. First, assembly references are versioned. If you write a .Net 3.5 application, your application loaded the 3.5 version of the base class library, even if it ran on the .net 4.5 runtime. Secondly, any dependency outside of the versioned base class library was bundled with your application. Using NuGet to manage your dependencies, you have full control over versioning of those dependency assemblies. I feel in Sansar you would have similar control over versioning of your "dependencies", and doing so at the experience level as opposed to the individual object level isn't an unmanageable process (we do it all the time at the application level in .Net development - this is similar).

  Namespace conflicts:

  C# and .NET has the concept of namespaces, which generally are the solution to name conflicts in most cases. Two scripts can expose a Calculator class, but as long as they're under unique namespaces, it's OK. Maybe we can require all public types to be under a unique namespace when on the Sansar store.

  Exposing too much:

  Very good point. Maybe the runtime can use the "internal" designation to denote types private to the script or assembly. If a class is internal, you can use it in your script, but other scripts can't. Note: we don't necessarily need to compile each script into its own assembly, though that would work, we can just enforce it when verifying the script at upload.

  Loose coupling:

  Loose coupling is a good thing, but it's not mutually exclusive with this proposal. You can still use dependency injection and other higher-level patterns as appropriate. But it's overkill for things like math libraries and string utilities and such. You wouldn't want to have to use loose coupling systems for System.String classes and the base class library.

• 0
  
  Galen February 17, 2018 21:21

  You guys both seem to be arguing for the system Kelly has designed for us instead of a "class-based model" as originally discussed.

• 0
  
  Mia Grace February 18, 2018 02:17

  The system Kelly has designed is a runtime reflection based model for loose coupling between scripts. I'm in support of that, especially as it enables progressive enhancement scenarios in scripts sold on the store (i.e. bonus or extra functionality on condition that some other script is available in the scene).

  It's not a silver bullet though. You can't expose enums or structs through that API and interfaces are duplicated.

  Those issues aside, I still think a class based model for script-object attachments makes sense even without the other stuff in this suggestion, including shared script assets and 'using' support. Even if it's just an extension of the current system, in the form of "drag a script to an object, then if it has more than one script class defined, prompt to select a class from a list of those defined in the script" sort of deal. That would let script-writers create more compelling scripts to sell in the store.