Arduenn Schwartzman

I do think it's accurate enough to convey most mechanics concepts. And with a bit of scripting on the side, the tool becomes even more powerful. But then again, I understand that in the US, education is in such a state that teachers have to sacrifice a significant portion of their personal and not so impressive income to buy school supplies for their students--basic things such as pencils and paper (and not even get reimbursed), making the original question sound a little like "would you let them eat cake?" https://nces.ed.gov/pubs2018/2018097.pdf

Number one would be Newtonian physics, imho. Physics prims are an excellent visual aid. They would help develop a better understanding of the relation between inertia and mass, applying forces, linear and angular momentum and potential and kinetic energy. Add a little llSetBuoyancy(1); to those prims and they can simulate floating stuff in zero gravity. Astrophysics and cosmology would probably be another great one. Ad hoc rezzing heavenly bodies in SL for size and distance comparison seems more fun than boring Powerpoint slides, and clumsily handling oranges and paper mache props IRL. Although, I'm definitely not against letting students craft stuff IRL. As far as teaching social subjects is concerned: it would be interesting to compare virtual social interactions with real-life ones. To me, it seems interactions escalate more often in flame wars online than that they do IRL, due to the lack of non-verbal communication and the tendency of online-communities to harbor a larger proportion of people lacking social skills.

Thanks for rubbing it in the bear's nose, Qie. I really appreciate it.

This is the key part. You're not allowed to (wittingly) interact with a minor by posing as a minor. It is very unlikely that you will ever interact with a minor on SL for the following reason: Minors aren't allowed in SL. Hence, they aren't allowed to buy your products. There's always a chance that you may unwittingly interact with a minor. This chance is very very small for the following reasons: A fraction of the total SL population may actually consist of minors posing as adults. A small fraction of these minors in SL may actually be able to purchase products in SL. One level deeper, a small fraction of the minors that are able to purchase things may pose as minors and buy child-related products--theoretically-- we're already in the realm of the astronomically unlikely here. And then there's this: even if a minor, who has the wit and motivation to gain access to SL, and is able to get their hands on their parents' credit card or obtain L$ by other means, and somehow decides to pose as a minor and buy children's objects and finds their way through the multitude of kids' stores to yours, you still will not be able to tell if it's a minor. Because your 'interaction' only consists of a little cash register sound and a popup window. If an actual minor bought your products, you are not to blame. The only person violating the ToS will be the kid who poses as an adult who poses as a child. Unless you KNOW it's an actual minor. If you ever meet someone and suspect beyond reasonable doubt that they are a minor, (i) ask them if you can talk/type to their parents and (ii) AR them. If they don't comply, (i) tell them they are breaking the law and they need to log off and (ii) AR them. If you sell childs' stuff in SL to someone and you can't tell if they are an actual minor IRL, it's not your problem. * Minor beyond reasonable doubt = human being with a squeaky voice calling you a ***** (rhymes with lag) on Voice and threatening to perform lewd acts with your mother

You'll need a footstool, though. Because you'll be too small for most furniture. Or a marble slab like in the picture, what they call 'Westheimer'-style. Oh God I feel old.

I don't understand the problem here. Why can't you just choose both?

I'm pretty sure you can think of ways to not lose the code.

You got a valuable point there. Upon finalize, all copies and forks of that first emerged script must become either No Mod or non-finalizable (and thus remain No Trans), except for that one finalized version, or the whole point of pay per script won't work. Or, alternatively, do the transaction every time the script gets finalized, instead of paying to emerge a script. In fact, that's a better alternative, making the whole process simpler as well. I'm adjusting the proposal. Checking a 128 kB checkbox on the script window enables 128-kb and turns the script No Trans to the creator. Clicking a 'Finalize' button on the script window brings up a payment dialog. Payment irreversibly turns the script No Mod/Copy/Trans to the creator.

Likes in the form of white hearts on blue disks and thanks and all kinds of emojis to you all so far for the discussion and insights, peeps.

@Rolig Loon Your example definitely suffers less from script splitting side-effects than mine. They're opposites on a spectrum of different strategies and needs, all of which, nonetheless, will benefit from the ability to exist in a single script.

or, alternatively, I'm proving that there's a dire need for memory increase that allows simpler and more efficient scripts. That's just scraping for a few measly bytes. Perfect for optimizing an almost finalized product and decreasing the chance of getting a stack heap collision. But it's a far cry from freeing up space for extra functionality.

Congratulations and thank you for being so script-aware with your interior. I genuinely and wholeheartedly applaud you for that. However, I just jumped into SL and sampled some bleeding edge furniture at an interior decoration event called The Boardwalk, http://maps.secondlife.com/secondlife/Von Strauss/67/28/24 , go see for yourself. The results were even worse than I thought. My rough estimate of average of 3 scripts per furniture was very conservative: That was an honest, unbiased sample of the latest in furniture in just 4 or 5 booths directly around me at the landing point.

You should be extremely impressed by each single piece of furniture of the hundreds of thousands of furnitures out there on the grid then. If you open up the average piece of furniture in SL, be it single- or multi-user, you'll see that the number of scripts related to sitting is at least three. That alone should be a strong indicator of the demand for more memory per script, which could, overall, save significant overhead.

Where did you get that from?

If you'd be selling something like AVSitter scripts, would you store the positions and rotations of individual animations and user IDs of all the AVSitter-like furniture that's out there on the grid on your server? Right now, the average sofa needs four scripts to handle and keep the data in-world, Also, less than 1% of all furniture owners probably backs up their data in notecards. And definitely no sit system reads notecard data on the fly for each animation change. It totally lacks the dynamic capabilities and speed.

How is that relevant to the request for more memory? It's not about using more of the same scripts sharing the same byte code. This request is about putting more unique code and unique data in a single script.

I don't mind quick at all. But to which of the two of the following does sloppy apply? In two 64-kb scripts: Step 1: Script 1 dumps parameters into request string Step 2: Script 1 sends request string to Script 2 Step 3: Script 2 parses request string into parameters Step 4: Script 2 extracts or processes data from list using said parameters Step 5. Script 2 sends data or confirmation feedback signal to Script 1 Step 6. Script 1 parses the response and acts accordingly In one 128 kb-script: Step 1: Script 1 pulls data from list and acts accordingly

Hence the 'less and pay 0, or more and pay L$500' I would not mind LL charging L$20 oh heck, L$40, for uploading 1024-textures either, btw. But that's in hindsight. The grid would revolt for sure.

The situation now is: Have two 64-kb scripts and it will take even longer. In two 64-kb scripts: Step 1: Script 1 dumps parameters into request string Step 2: Script 1 sends request string to Script 2 Step 3: Script 2 parses request string into parameters Step 4: Script 2 extracts or processes data from list using said parameters Step 5. Script 2 sends data or confirmation feedback signal to Script 1 Step 6. Script 1 parses the response and acts accordingly (Events triggered: 2--actually 4--Scripts also receive their own llMessageLinked) In one 128 kb-script: Step 1: Script 1 pulls data from list and acts accordingly (Events triggered: 0) Other example: One script has a minimal CPU time, say .001 ms. Ergo, two 64-0kb scripts have at least .002 ms. Conversely, a single 128-kb script has a minimal CPU time of .001. Same line of reasoning is valid for average CPU time.

I disagree for many reasons (also stated in that first JIRA, https://jira.secondlife.com/browse/BUG-134167 - please people, read it first, before coming up with arguments here). The biggest reason being the practice of many scripters circumventing memory limit by using multiple scripts and using llMessageLinked and link_message to transfer data from one to the other, resulting in less efficient and therefore laggier scripts, less reliable scripts due to asynchronicity between scripts, more complex script design and increasing the potential to introduce bugs, more time and energy wasted in developing a complex communication structure between scripts and more scripts to be transported across regions, each with their own CPU overhead. Briefly stated, one 128-kb script is dramatically superior to two 64-kb scripts having to work in concert. Personally, the 64-kb limit forces me to omit features in many products that I make, (to many customers' grief). They do. Al lot. Financially, they take a lot of risks introducing many new features in SL. For instance, I'm pretty sure that, so far, LL hasn't gotten any ROI on Pathfinding. Nonetheless, I find it very comforting that LL puts implicit selfless effort in new ideas by taking these risks. One thing that they get back for it is confidence in the SL platform by the consumer and the creator. At least, by yours truly.

I am so for that too. Totally agree. Or limit 128-kb scripts to non attached objects only. But limiting attached script memory seems a more elegant and better idea in general, even regardless of script memory increase.

Arguments for generating less lag by increasing memory limit can be found in the first link. Generating less lag is actually one of the reasons for the feature request.

@Gabriele Graves Remember that the JIRA proposing increased memory for Premium users was already rejected by LL. My pay-per-script is kind of a last attempt to motivate LL to implement it anyway. I'm not sure if it will either. It's more intended as a means to limit abuse.

Hi folks, I just reissued a (slightly altered) feature request involving increased memory for scripts. Most of you will probably be able to imagine the potential and benefits for memory increase. The old JIRA (closed, unimplemented) can be found here: https://jira.secondlife.com/browse/BUG-134167 As a solution to potential abuse of high-memory scripts, a way of pay-per-script is proposed, as follows: A creator pays 500 L$ for a 128-kb script to emerge in their inventory (L$ 2000 for a 256-kb script, etc?). This script remains No Trans to the creator (albeit Copy and Mod) until a 'finalize' feature is activated by menu or check box and confirmation dialog. Upon 'finalize', the script becomes Copy/Trans, yet No Mod to the creator and anyone else. The creator can set to either No Copy or No Trans. Optionally, limit this feature to Premium members. Simplifying it, eliminating a flaw that enables copying the script without payment, as pointed out by @Innula Zenovka: Checking a 128 kB checkbox on the script window enables 128-kb and turns the script No Trans to the creator. Clicking a 'Finalize' button on the script window brings up a payment dialog. Payment irreversibly turns the script No Mod/Copy/Trans to the creator. The new JIRA is here: https://jira.secondlife.com/browse/BUG-226311 Any suggestions for or against it in this thread (since not every scripter visits the JIRA site on a regular basis)?

Oldest elf in the Tolkien universe gets 2 seconds of screen time in Pete Jackson's movie trilogy. The humanity.