Add the missing other half of IPC, enable proper unit testing, and get SL taken more seriously by game devs: Synchronous script-to-script method calls, in addition to link messages.
Huns Valen
You're already working on a major overhaul with Lua. NOW is the right time. It will NEVER, EVER be easier than RIGHT NOW. You will NEVER be able to reduce future capex on inefficient scripting overhead more easily than RIGHT NOW.
Link messages:
- Good for broadcasting messages between scripts where it doesn't matter much if it takes a few milliseconds to arrive, and you don't mind scripting some asynchronous handler to respond if necessary.
- Doesn't do a good job at supporting proper organization of software in accordance with modern standards any developer expects. OK for the the Single Responsibility Principle and to some extent the Interface Segregation Principle. Does absolutely nothing to help with unit or integration tests.
- No serious programmer is looking at this and saying, "yes, this is good and cool."
Direct, synchronous calls to public interfaces between objects:
- Java, TypeScript, C#, Lua (not mentioning this by accident), Python, and any other serious programming language you can mention, supports this natively. This was introduced in Simula 67 in 1967, and has been INDUSTRY-SANDARD ever since, because it's awesome and it rules.
- We get to call public methods on other objects (scripts) synchronously, just as fast, or nearly so, as we would call a function in the same script.
- You DON'T have to engineer a massive comprehensive interface mechanism between scripts, or build an include mechanism. You add ONE transmitting function to the LL library, back-end routing between Luau states in the back-end, and an in-script state handler which receives and responds to these messages. That's it!
- We don't have to engineer extremely hacky workarounds that force an asynchronous mechanism to serve for what would be VASTLY improved if it was synchronous.
- We get to write unit and integration tests without cramming them into the same file as production code, where they take up valuable RAM.
- We feel like we're using a real programming language, one which allows us to use the same patterns and techniques as ANY serious programming language from the last 58 years.
Real Example (my aircraft physics system):
- A Weight & Balance script scans the linkset to determine where all the components are, their volumes and orientations. These are mapped to inertia proxies (cuboid, flat plate, thin hoop, etc) and used to calculate the inertia tensor. The airfoil prims are then split into segments (blade element theory) and have control surface information assigned.
- Linear force physics script has to obtain a full copy of all the airfoil parameters and segments from W&B.
- Moments (angular force) physics script has to do the same thing, and spend the same memory. Now the object has three independent copies of the same data.
- There are a ton of copy-pasted functions between these scripts because there is no #include method. This requires more storage for the script source, compiled bytecode, stack and heap segments as well. Not just for airfoil parameters, but for MANY, MANY other things that Linear and Moments both have to know about.
- If Linear and Moments both run timers, then LL pays for CPU for that. They are only in separate scripts to work around RAM limitations! If they could call a shared lib script in near-real-time, they could be in ONE script with ONE timer.
- LL is paying for all that overhead. I am losing huge amounts of time dealing with it. Everybody loses, and it sucks.
- Every other day I'm fighting stack-heap collisions, and wishing I had some way to effectively write unit tests. The constant discouragement is dragging me down unnecessarily.
With direct inter-script calls:
- llInvoke(link, scriptKey, "method", args...) -> Luau back-end routes call from one Lua state (script) to the other, then returns whatever needs to be returned. (Just an example.) You can make this only work in the link set, or make it work sim-wide. (Sim-wide would enable a lot of cool stuff that relies on llRegionSay() now.)
- Transmitting script blocks until response received.
- If access control is desired on the receiving end, you can add a pin to the invoke message (a la the existing "remote load script PIN"), or whatever.
- In my project, Linear and Moments can just ask W&B for airfoil data in near-real time, and get an answer back in microseconds.
- Functions for calculating rho, tangential velocity, dozens of aeronautical equations, etc. can be in a standard library. Scripts can call that library, again, getting answers back in microseconds, instead of all that copy-pasted code gobbling up space on YOUR servers. You don't have to provide an #include mechanism, further conserving space.
- I can write UNIT AND INTEGRATION TESTS!!! and stop relying on horrid llOwnerSay() spam for everything. I can stop feeling so EXHAUSTED while trying to do serious innovation in SL.
- More efficient scripts from now on -> reduced capex for LL.
LL wins, SL developers win, users win, EVERYBODY WINS. What's not to like?
Log In
Huns Valen
To add some more context to this.
There's another proposal which talks about using require(). AFAIK Lua scripts act like singletons, so the require() mechanism would essentially allow different scripts to run in their own memory space, and talk to each other, like in any regular programming language, DIRECTLY via method invocation. You would get the full package: proper interfaces, functions with arbitrary signatures.
require() would NOT be like an #include mechanism, which frankly is great, as it's a much bigger win for scripts to be able to talk to each other, than to copy code directly out of each other. You get MASSIVELY greater ability to use proper design patterns this way.
(Not that I hate #include or anything.)
LL would have to gate the require() mechanism on linkset, as by default the require() mechanism is per-VM (and presumably you have one VM running in the sim, not one VM per linkset.)
My proposal above ("invoke") is not as sophisticated (you don't get the same level of granularity, to where you are directly calling a function with its named, typed args; it's more like a synchronous, blocking link message that DOESN'T use a queue) -- BUT, it's probably a lot quicker to implement than require(), AND could be easily back-ported to work in LSL, thus supporting the vast library of existing LSL scripts.
My new flight physics scripts have tons of new physics code, but build on infrastructure (basically everything EXCEPT physics, which is a surprisingly large amount of code) that I developed form 2004-2010. Rewriting all that in Lua would be excruciating. Multiply this by thousands of other developers who are deeply invested in their LSL scripts going back however many years.
My recommendation: Do both! :)