Jump to content

Revived JIRA for increase in memory limit


Arduenn Schwartzman
 Share

You are about to reply to a thread that has been inactive for 1858 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

8 minutes ago, Gabriele Graves said:

Never only means never until it means now.

It's a fair point.

 

They said no to lowering land costs, but here we are.

They said no to teleportation via scripts, they even stated they were concerned about the griefing potential, but here we are.

They said no to animated mesh, I have had Jira's closed and refused for requesting that exact feature, but here we are.

They said no to increasing land count, again Jira's have been closed and refused, but here we are.

They said no to increasing object scale beyond 10x10x10 but then they gave us 64x64x64.

 

Just because they say no to something now doesn't mean they they won't say yes in the future.

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

31 minutes ago, chibiusa Ling said:

It's a fair point.

 

They said no to lowering land costs. My reply. Because they are losing money as resident are leaving and the sever renters demanded a reduction.

They said no to teleportation via scripts. My reply. Has been that since 2006.

They said no to animated mesh. My reply. No because home comps could not handle the load or the BB.

They said no to increasing land count. My reply. Money again.

They said no to increasing object scale beyond 10x10x10 but then they gave us 64x64x64. My reply. Well, it was already being done so LL just made it oficial.

 

Just because they say no to something now doesn't mean they they won't say yes in the future. LL are not going to increase the kb for scripts. PERIOD. Use an external server if that amount of data is needed. LL have already given you that option.

 

Edited by steph Arnott
Link to comment
Share on other sites

9 minutes ago, chibiusa Ling said:

Would appreciate it if you learned to respond to a post correctly. You have made it look like I stated your response in my own post.

I corrected all your errors. What has your post got to do with script size when LL has already locked it at 64kb and are not going to change it?

Edited by steph Arnott
Link to comment
Share on other sites

This proposes only 128 KB, merely a doubling of the current limit, so I suspect it actually has better prospects without the elaborate permissions and payment restrictions. It's not as if this will suddenly cause all scripts to double in size; the vast majority of scripts currently are nowhere near the 64K limit and having 128K available won't cause scripters to make those any less memory efficient than they already are.

I especially doubt a pay-per-script thing will appeal to the Lab; making it available only to some level of Premium might, because Ebbe seems to like that direction and they may be having trouble dreaming up benefits to slot into those Premium levels. If it requires developing a whole new way of limiting access to certain users, though, that may be a deterrent; it may fare better if it can somehow piggyback on whatever "Experiences" are becoming.

Also, the pose-engine example is... complicated. It's true that AVsitter at some point split its per-avatar script and this, combined with other script-level modules, makes a lot of scripts doing nothing most of the time yet using scheduler slots (and potentially boosting Land Impact for some furniture). Other engines (e.g., nPose) work and scale differently although they also have more scripts than would be necessary to custom-script a static set of furniture animations. And yet even a simple custom script will end up using two scripts for two sitters.* Anyway, the point is that larger memory limit might recombine AVsitter's basic per-avatar script for some very small reduction in overhead, but it won't revolutionize anything.

One place where I personally would use this immediately is to expand pages served by llHTTPResponse(). I have no idea if this is a common usage or has any appeal to the Lab, but it's one application for which I've never found a practical, stable solution using multiple in-world scripts, and using external servers adds complexity and failure points.

One difference between this application and the pose engine: The HTTP server script is limited by the size of a single string argument to a function call, whereas the pose engine script uses memory in lots of little references, and could in theory access the data elsewhere; nPose, for example, keeps less stuff in script memory and more in read-on-demand notecards. I've lately been tempted to hack the AVsitter source to migrate its preloading from notecards to Experience KVP store, just to circumvent the 0.1sec delay per llGetNotecardLine() with the much faster llReadKeyValue(). One can imagine instead directly accessing KVP for pose and menu data, not even preloading it into script memory (or maybe no more than a few menu pages cache). 

That rambling is to suggest that maybe there's some way to piggyback on (more available?) Experience KVP store to get much of the benefit of expanded script memory. But not all.

___________
* Using a script per sitter is not absolutely necessary, but it's simpler and (probably?) more time-efficient to retain permissions, one avatar per script. Back in the day it was also better at stopping animations for a no-longer-seated avatar, but I think it's been years since that actually mattered.

  • Like 3
Link to comment
Share on other sites

23 hours ago, Rolig Loon said:

Yeah, if that's what you're doing it can use up a lot of time and resources.  When I run up against a memory limitation and need to split a script in two, I try to avoid putting myself in the position of having to make the scripts play endless ping-pong.  For example, if I were designing a retexturing system, I would put my menu dialogs and whitelisting code into one script and all of the texture UUIDs and the SLPPF operations that do the actual texturing in a second script.  The first script would handle the access authorizations and simply pass the user's menu choice to the second script.  The second script wouldn't need to send data or confirmation back to the first one at all.  If I were clever enough, I would write that second script to be as generic as possible so that it could receive choices from dialog menus in more than one spot in the first script --- sort of like treating the second script as a large user-defined function that serves the first script.

AFAIK Arduenn scripts the gaming HUDs for Madpea and he needs a lot of html_request communication with external servers (correct me if I'm wrong). I have the same problem with my own game system. Rolig, it's great if your described use case works for you but there are other use cases. What Arduenn describes as his use case makes total sense for a Madpea HUD because only one script should communicate with an external server (or things will not be stable which they need to be). Therefore all the other scripts in a HUD have to report back to the html script which handles the communication to the server.

My problem with your and Steph's answers in this that you seem to suggest that other people don't script elaborate enough. But in reality it is just different use cases with different needs. I can script my HUDs and the html_requests with 64kb scripts, but players (especially when there are many players at a sim) will notice the lag. It creates an unnecessary deterioration of the user experience.

LL wants to improve their platform and HUDs for interactive content have become more and more appreciated and sophisticated over the years. We have hit a ceiling with these HUDs. Either the bar is raised (larger scripts) or the development of more sophisticated interactive content gets stuck at the point that we have reached. I accept that, it's not relevant for you and probably 99,9% of the scripters in SL. But the few who would really need this are the creators that are building the destinations filling the "editors choice" category of the destination guide. Either LL helps these people to make even better content in the future or SL gets stuck where it is now.

Link to comment
Share on other sites

3 minutes ago, CoffeeDujour said:

I'm pretty sure if your 'save' button requires creative thinking, it's not fit for purpose.

I am pretty sure you are talking at cross-purposes. You are not losing the code, but 500LS, if you have "changed the script" to no-mod/copy and then realise that there is still a bug. For this simple reason I would not use 128kb scripts if they would cost 500LS. I am sure that I would still find 10 things to change after the fact and it is not worth paying 10x500LS for bugfixes and updates...  

Edited by Estelle Pienaar
Link to comment
Share on other sites

11 minutes ago, Estelle Pienaar said:

My problem with your and Steph's answers in this that you seem to suggest that other people don't script elaborate enough. But in reality it is just different use cases with different needs. I can script my HUDs and the html_requests with 64kb scripts, but players (especially when there are many players at a sim) will notice the lag. It creates an unnecessary deterioration of the user experience.

I can appreciate that, Estelle.  I rarely have to use HTTP to an external server, but I use KVP in Experiences extensively.  Different application, different solutions.  As I said in my last response, I'm not arguing against increasing script memory limits (in fact, not arguing at all).  It's just that I can easily solve the memory problems that I run up against by scripting things in semi-independent modules.  All I typically have to send from one modular script to another is a simple trigger.  There's no need for me to pass massive amounts of data back and forth, so I can live with a 64K limit, even though I get annoyed by it at times.  I just keep all of those lists of parameter values in the modules where they will be used.

Link to comment
Share on other sites

I'm starting to get lost.  So, if I'm not a premium member, I hire a scripter who is.  He writes a humongous script for me and I want to install it in a dozen objects around my region.  Can he give me a full-perm copy? If I wanted to include it in objects that I sell to other people, will I be able to change the perms to make it no mod/no trans for them?  Or will I need to become a Premium member myself in order to do these things?

Link to comment
Share on other sites

That's the way it looked to me too, Coffee.   That has a potential to discourage a lot of Basic residents like me -- I have never been Premium in all these years -- and to cut out some potential business for scripters.

Edited by Rolig Loon
Link to comment
Share on other sites

20 minutes ago, Kyrah Abattoir said:

Well in my idea the script would stay as a 128k script as long as you don't try to edit and recompile it.

It's literally on compile: "if(premium) maxmem=128"

Similar to what happens with scripts set to a particular experience -- anyone can use (for example) the full-perms AvSitter script that uses the AvSitter experience and is distributed, full perms, to people with paid-for copies of the AvSitter scripts, but  if edited by anyone other than one of the (very few) people with the appropriate role in the AvSitter group, it loses the experience.

  • Like 2
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1858 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...