Is it possible to make classes in general 'libraries' that you can use in different objects in your experience? In my question, a general library is not nessesary a dll and not some classes that comes from internet, but is code in the most basic sense; some code lines with some reusable classes that you want to keep in one place and not copy everywhere?
Date
Votes
10 comments
-
Gindipple Not as of yet, we're missing the capability to cast a known type from another object.
-
Jorik Not sure typecasting is actually relevant to the intended question. Unless I'm misunderstanding that answer somehow...
That link pretty much covers how a library basically works in C#. I just started looking into creating on Sansar and the documentation this morning after my first look in yesterday so I'm not sure if code library functionality is in at this point. Would not be shocked if it isn't, but it would be absolutely fantastic if there was a way to drag scripts into some sort of system object that allows you to compile them into a named dll, then some configuration data you can put into other scripts so the compiler knows where to find the relevant code so you can access it elsewhere by name. The idea of being able to do stuff like this is why I was so excited that they said they're ditching LSL in favor of C#.
-
Gindipple If only Sansar gave us our own independent GAC lol
I'd feature request it, but I doubt they'd do for it :P
Would be sweet though to just add a reference in the edit window
-
Mia Grace GAC is obsolete in the .net ecosystem. CoreCLR and Xamarin apps, for example, are self contained, with all dependencies downloaded from NuGet.
This doesn't work for C# scripting systems (or "trusted C# compiler" systems if you prefer). What is needed is a new concept similar to an assembly but with source code instead of .net bytecode assemblies. If Sansar added support for importing assemblies that would work, otherwise the community would have to come up with it's own multi-source C# script concatenation tooling. It's not a simple file concatenation though, for example you'd need to merge using statements across multiple files and fix using aliases when there is a conflict.
-
Gindipple GAC is obsolete now?
Didn't know that.
They do ship the client files with a gac directory embedded in it.
Several Havok dlls in it.
But honestly I wouldn't care what approach they took for it, so long as I don't have to continuously patch classes into files on my end the way I have been. It's insane.
If I change something in one of my classes, I have to go find every file that uses that class and repair it in each file. That is so counter to the way it's supposed to work.
But since you mention it, file concatenation might be a solution to that for me at home in the meantime lol
Archaic in nature, but would save me from the current copy paste method that is so error prone.
They seem to move very slow in development on this front sadly.
-
Galen In making my Reflex script suite, I had to first come up with a shared library. I had tried a bunch of tricks for doing this with Sansar and ultimately gave up on an elegant solution. You can't even reliably create a base class derived from SceneObjectScript with shared settings without it behaving improperly. I resorted to just creating a class template with a #region at the bottom containing all the shared code and creating 13 scripts based on it.
Like Gindipple pointed out, if I wanted to make a change to the template, I'd have to copy and paste the changes to all of them and then delete all the Marketplace products in order to create new ones for the newly uploaded versions. And then what about my customers who have older versions? What if I charged them for a version and then wanted to give them free upgrades?
On the other hand, there's a hidden virtue to making scripts self-contained: loose coupling. Microsoft learned the lesson from "DLL hell" that it's better overall to just deliver an entire program with all the assemblies it needs instead of counting on the right versions of the required DLLs already being installed on the target machine, even if it means software installers are massively bloated. (The GAC is a throwback to DLL hell ... and DLL heaven?)
I'm a religious framework creator; a bullish reuse advocate. I'm all for some notion of libraries in Sansar. But there is a risk. Fixing some feature in a library shared by a bunch of my scripts could break a bunch of them. I'd be responsible for testing all of them. By forcing us to upload each script separately, Sansar kinda forces us to encapsulate and minimize library bloat, too.
And what gets delivered to a customer? If I made a change to my library, would all my customers inherit it? Would a bug in it break all their copies of my script that they bought a few years ago? Does LL need to version control copies of our libraries the way it verions almost everything in SL? Or would Sansar compile our libraries into every script that gets uploaded and distribute the final compiled script, like now? Would uploading a new version of one library script forcibly cause a recompilation of all scripts that use it? Would they have new assets and would we have to go create new Marketplace products for them? See the cascade of problems that can come from these ambiguities?
It would be interesting if we could upload some sort of project composed of several classes at once and have Sansar use it to create all the user-visible scripts at once. Someone editing an object would still see all the public classes in it that inherit from SceneObjectScript (and not tagged with some attribute like [HideFromScene]) as though they were separate scripts. That way we could deal better with larger projects and code reuse while still benefiting from loose coupling of scripts.
-
GranddadGotMojo @Galen - good points all. I was a software architect before I retired so I was all about frameworks (i.e. it helped justify my job :) ). I have started playing with your Reflex Framework for Sensor - Effector communication. I plan on building more effectors for the framework. My software background over the last few years was Python, Java, Ruby and ABAP (for SAP). So, I am new to C# although I am finding it fairly straight forward in terms of syntax and functionality. The few days I have been scripting for Sansar, I don't have problems with C# although it is new to me, but, I am constantly getting stuck on the API. In other words, my code compiles, but, often does react in Sansar as I would expect it to.
So, would you or for that matter any other scripters that have been successful in building the various scripts I have seen working be willing to help me. I understand that I can always just post to the forum and ask for help with my code. If that is acceptable to everyone I will start doing this, although it may result in a lot of Granddad Got Mojo posts as I work through my understanding of the API. If anyone would be willing to share outside of the forums you can contact me at Mike.j.sutton@tx.rr.com with your contact information.
Thanks for the reflex framework and your commitment to making scripting easier for everyone else in Sansar.
-
Galen BTW, Kelly responded to the subject of uploading assemblies and such yesterday with great insights in another thread:
-
Galen @GranddadGotMojo: My pleasure. I'm glad it helps.
I would suggest that people interested in talking with other Sansar scripters join the "Sansar Project: Content Creators" server on Discord and the #programming channel specifically:
This has become a de facto standard while Sansar ramps up its own Discord server.
-
GranddadGotMojo Thanks for the invite to the discord server
Please sign in to leave a comment.