2 quick Questions

Is there a limit to the number of scripts in a prim and can that then be extrapolated such that Total scripts = Scripts per prim * Number of prims? Not that I’m out to create a Lag monster It's more to do with an idea I have that may become feasible under MONO, but would be far too slow at the moment.

Second Question

Can LSL detect the resolution of the client window, so that HUD's can dock themselves relative to window size?

Thanks

1:
You can stuff in more scripts than is healthy for the sim.


2:
Nope.

Though HUDs are automatically scaled to fit the set screen resolution.

You will, however, find, that on widescreen resolutions the HUD will generally tend to be more "centered".

Thanks Squirrel


Yes, I suspected that, but wondered if there was actually an upper bound.
I am currently working on 16 but may have to push to 64. (and if MONO correctly handles time slicing and memory management I may be tempted to go higher)
.

That is where my problem arises, it appears to scale horizontally but not vertically.
So a HUD created at 1024x768 resolution is not too bad at 1152x864 or at 1280x768, but any other settings and it appears stretched vertically relative to the system buttons and is also to high on the screen (I'm attaching to bottom center).

Anyone like to hazard a guess at the common resolutions? I could then provide a set of skins and or HUD's to fit the resolution of the users preference.

Not sure there's really a common resolution, but the two most common proportions are 4:3 and 16:9

HUD attachments shouldn't disproportionately "stretch" at different resolutions, just be differently placed. As I mentioned in another thread, 1 screen unit (meters are meaningless in this context) is the height of the rendered window. So a 1x1x1 cube attached to the HUD should be square no matter what resolution (assuming it's orthogonally oriented), and exactly as tall and wide as the rendered window is tall (though not necessarily centered, so you might not see all of it.)

Thanks Bezzel, I think that should be the key i need
And thanks Deanna, yes that is what is happening, but in my case that makes it "appear" to be stretched vertically, as the Buttons in the viewer interface scale vertically but the HUD doesn’t.
I could try post an image of what I'm trying to achieve, but if I can’t detect the resolution in LSL anyway, it would be pointless. I will just have to give different versions to suit different resolutions.
As it is I already have versions to suit the main viewer, the release candidate and the “Dazzel” preview skin It’s a pity we can’t do viewer plugin’s rather than having to create HUD’s.

on the number of scripts you can pile in a single prim... others have put in THOUSANDS... I don't think 64 will be a problem... I have at least one that stacks 21 in a single prim with no ill effects.

Playing around a couple of weeks ago and put 1360 scripts in one prim with 60 listens each and they all worked. It isn't really the nicest thing to do to a sim but, you get the idea. Per Jana, you can put 50k+ in a single prim.

A sim has limited memory ressources so keeping the number of scripts LOW is KEY.

4096 scripts will eat up 64MByte on the LSL VM and 256MByte on Mono.

A normal healthy sim has roughly 500MB of RAM available for its use.

...and probably quite a bit of swap space and decent paging. Yes, it is probably a good idea to not squander resources needlessly, but whether it is a good idea probably depends a lot on the application. If you were doing something pretty ground-breaking on your own estate, for example, it might be worth it. Just keep an eye on sim performance and stress test it as well as you can.

Thanks all, just to clarify on the scripts issue.

I need it for data storage, and off world storage is not practical at this time, though I may use it for backup. However my plan is that the unused scripts are *not* running.
One or more scripts will become File Alocation Tables (for want of a beter description) and any script requiering data will pass an OpenFile(name) request, the fat will then find which scripts are associated with that file, set them to running state and return a file handel. In theory no more than 4 or 5 scripts out of 64 or whatever, will be running at a given time. Once the script is finished, or on a time-out bassis, a CloseFile(handel) command will set the state of the effected scripts to not running.

My early experiments are working ok, hence my questions on scalability. In theory, with the speed and extra heep/stack space in mono it should be posible to do in fewer scripts and with less impact on the sim, and being able to keep it all in one prim is an added bonus.

you don't even have to preload the storage scripts if their code is identical, just have one and have it give a copy of itself to the prim it's in when you need more space. you can even differentiate between them up to 100 by grabbing the last 2 charaters of the script name and converting to integer (because new copies will recieve an incremental number after them). I do believe you need to use remoteloadscriptpin to make it work, and it might help if you have a clean-up script or codes that disposes of the extra scripts if the object is reset

I don't think that'll work Void. llGiveInventory() turns scripts off (in such a way that they can only be turned on manually, not by script) in the receiving prim, and llRemoveLoadScriptPin() replaces an identical script rather than creating another copy. Nice thought though.

Thanks Void, but I found a few problems with that approach, not that I tested it - the WIKI put me off.

But thanks Hewee for pointing out that the alternative would not work either.
It is a pity really that there is no llSetScriptName(), because if it existed then Voids Idea would be perfect in a 2 prim object. The root could handle all the control scripts and spawn data slices in the child prim. Then the llGetStartParameter could be used to rename the slice script sequentially.

*Edit - spelling

jesus a server with 2gb ram ( 4 sims per machince at 500mb = 2gb)? Would hope to least be 4gb and running 64 bit.

I found a way to impliment Void's sugestion, that altough not automatic, certanly speeds up the building process, It is easyer to show the code than explain.

// data slice - A subscript of the DASD/ISAM module of VK-Net
// Very Keynes - February 2008

integer minmem =1000;
integer slice=1;
integer stride;
integer x;
list data;
list args;
string cmd;

default
{
	state_entry()
	{
		//if the script is reset report slice name and memory then turn off
		string name=llGetScriptName();
		slice=(integer)llGetSubString(name,llStringLength(name)-2,-1);
		llMessageLinked(LINK_THIS,-slice,name,(string)llGetFreeMemory());
		llSetScriptState(name,FALSE);
	}
	link_message(integer sender_number, integer num, string val, key arg)
	{
		if(num!=slice)return;//This command is not addressed to me so ignore it
		//decode the command string
		args=llCSV2List(arg);cmd=llList2String(args,0);x=llList2Integer(args,1);
		if("mem"==cmd)//mem return free memory (note not updated by delete)
		{llMessageLinked(LINK_THIS,-slice,(string)llGetFreeMemory(),cmd);}
		else if("new"==cmd)//Flush the slice and initalise table
		{data = llCSV2List(val); stride=llGetListLength(data);}
		else if("add"==cmd)//add a record to the table
		{data = (data=[]) + data + llCSV2List(val);}
		else if("put"==cmd)//put (replace) a record in the table
		{data = (data=[]) + llListReplaceList(data,llCSV2List(val),x=x*stride,x+stride-1);}
		else if("del"==cmd)//del (Delete a record) use with care if table is indexed
		{data = (data=[]) + llDeleteSubList(data,x=x*stride,x+stride-1);}
		else if("get"==cmd)//get a record and return it as CSV
		{llMessageLinked(LINK_THIS,-slice,llList2CSV(llList2List(data,x=x*stride,x+stride-1)),cmd);}
		else if("col"==cmd)//get a column and return it as CSV (use with care if script is low on memory)
		{llMessageLinked(LINK_THIS,-slice,llList2CSV(llList2ListStrided(llList2List(data, x, -1), 0, -1, stride)),cmd);}
		//if slice is full after executing commands send a warning
		if(llGetFreeMemory()<minmem)
		{llMessageLinked(LINK_THIS,-slice,"Warning Slice Full","Error");}
		return;
	}
}

Now all I need to do is drag the script to contents and it sets its own slice number.
As i have the code out in the open, if any one has further sugestions I will be glad to hear them, and will publish the FAT script if there is intrest (once it is debugged).

try this workflow

two scripts
script A is the extension controller
script B is your copiable memory storage (using the llGetScriptName numbering method)

Script A gets a command that it need more memory,
Script A gives it's prim a copy of script B using llGiveInventory
_this copy is correctly numbered, but inactive
Script A detects the new copy (via CHANGED_INVENTORY)
Script A gives the newly detected copy to it's prim using llRemoteLoadScriptPin
the newly regiven script 'B 1' is now active

requires a double give logic, but I believe that'll work... not inworld to test, have fun.

Hmm. Or, up to a point you could rez a new prim and link it to the object...maybe 20 new scripts per prim or something. When they aren't needed, either disable them, or unlink the prim and let it llDie() again....

It doesn't fit the original poster's desire for a single prim, but I think it is pretty scalable and works well within the boundaries of LSL (doesn't require a hack). In fact, it can be more efficient to communicate between scripts when they are distributed between multiple prims if you can handle the logic and not send to the whole link set: it means every link message doesn't get processed/queued by every currently active script in the whole object.

hmm but rezzing has limitations that the give workaround doesn't, both are viable though, but I think the logic proccessing for both is pretty intensive... you could combine both ideas and pass the copies to other prims in the same same linkest. granted i don't think you'd hit the grey goo fence on either if it was just pure storage.

Well, you certainly know how to keep me busy on my day off Void
Here is a working version of your suggestion.

First script “inventory control script” goes in the storage prim.

// inventory control script - A subscript of the DASD/ISAM module of VK-Net
// resides with Data Slice scripts to control updates
// Very Keynes - February 2008

key target;
integer pin = 12345;
integer fstpass=TRUE;
string newname;
default
{
	state_entry()
	{
		llSetRemoteScriptAccessPin(pin);
	}
	link_message(integer sender_number, integer number, string message, key id)
	{
		if("init"==message)
		{
			target=id;
			llMessageLinked(LINK_ROOT,pin,"init",llGetKey());
		}
	}

	touch_start(integer total_number) //request a new slice
	{
		llGiveInventory(target,"slice");
	}
	changed(integer change)
	{
		if (change & CHANGED_INVENTORY)
		{
			newname=llGetInventoryName(INVENTORY_SCRIPT,llGetInventoryNumber(INVENTORY_SCRIPT)-1);
			if(llGetScriptName()==newname)return;//prevent loop when editing prim
			if("slice"==newname)return;//prevent loop when editing prim
			if(fstpass)//the script has been renamed return it to redirector
			{
				llGiveInventory(target,newname);
				fstpass=!fstpass;
			}
			else fstpass=TRUE;//script has been set to running, get ready for next script
		}
	}
}

Second script goes in the Redirector Prim.

// inventory redirector - A subscript of the DASD/ISAM module of VK-Net
// resides in a different object/prim to Data Slice scripts to control updates
// Very Keynes - February 2008

key target;
integer pin;
integer parm=1;
string newname;

default
{
	touch_start(integer total_number)
	{
		llMessageLinked(LINK_ALL_CHILDREN,0,"init",llGetKey());
	}
	link_message(integer sender_number, integer number, string message, key id)
	{
		if("init"==message)
		{
			target=id;
			pin=number;
		}
	}
	changed(integer change)
	{
		if (change & CHANGED_INVENTORY)
		{
			newname=llGetInventoryName(INVENTORY_SCRIPT,llGetInventoryNumber(INVENTORY_SCRIPT)-1);
			if(llGetScriptName()==newname)return;//prevent self distruct when editing prim
			if("slice"==newname)
			{
				llGiveInventory(target,"slice");//if we recived a new slice ask DASD to rename it
				llRemoveInventory(newname);//delete copy to prevent renaming
			}
			else //we receved a renamed slice return it in a running state
			{
				llRemoteLoadScriptPin(target,newname,pin,TRUE,parm);
				llRemoveInventory(newname);//delete copy
			}
		}
	}
}

It is working well next step is to try linking the 2 prims and using LinkMessages to communicate the Key and PIN numbers to automate it. I am happy with a 2 prim solution, especially with this added functionality (Thanks Void), as the Redirector prim can handle the higher-level scripts and leave the data storage prim dedicated to one function.

EDIT - Linked prims and Updated scripts to use LinkMessages, Redirector is root prim and storage prim is child prim. It uses touch events to initalise and request a new slice for testing. Once the FAT script is compleat these will be replaced by LinkMessages too.

just wanted to post back after extensive frustration trying to automate this.... it just won't work automatically without limits.

the logic works well but there were a few pitfalls, the first being that llRemoteLoadScriptPin will not give a copied script to the prim it's in. ok fine, PITA, but I worked around it by combining the controller script and the copy script into one, then placing a copy both in the root and another prim, with a start up that put it in the controller state when in the root, and memory state elsewhere.

the memory state set the access pin when new memory was needed, and messaged the controller with the pin, and the controller gives a copy of itself to the sub prim, on startup the access pin is cleared.

now I could have prepped the sub prim with a access pin, but that leaves it open to invasion, and we don't want that, so setting it as needed and then clearing it was a good solution, though it required a script in place. all that's needed is a prior llGiveInventory which will renumber the new script to be transfered...

but yay problem solved, right?

wrong.

llGiveInventory, and llGiveInventoryList do NOT behave the same as dragging and dropping an item into a prims inventory. specifically if the items is the same as one already in inventory, rather than adding it with a new number behind it, they IGNORE it... that's right, no new script, no new name, and no way to add said script to another prim, without it overwiting the original.....

the big problem here is naming, if you can't rename the new script, you can't create NEW copies to extend the memory. since there is no way to rename a script programatically, there is no way to build a dynamic memory extension.

conclusion:
it can still be hard wired, with limits, adding copies by hand, and setting them all to not running, then starting them up as needed.

this lacks the finess of the dynamic approach, and means a lot of work to add all those scripts by hand (the only way the naming convention will work to make the same script behave differently) and puts a hard cap on the amount of storage one can use (basically however many scripts one adds)

I'm really disappointed I couldn't make this work, since it'd have been great for things like uncapped dance floors, or chimeras, which currently run a script for every slot in their capacity, this would have allowed them to operate more effeciently and with the only limit being the av's standing around.

You could still try the solution where you rez a new prim, add the helper scripts to it, and link it in. It could use a lot of prims, but SHOULD work....

for which the only thing needed is a rez and link...

actually my target for this wasn't so much memory, as it was permissions... memory constraints will be much lighter come mono, bu permission contraints are still limited by the number of scripts.... and items like chimeras are limited in the avs they can handle by the number of scripts available... rezzing another prim isn't the safest method to deal with an attachment, so I was trying to avoid rez solutions.

now I can do a petite run of my initial idea, with a script in each prim, and a whole mess of scripts in one prim, giving copies of those to the others as needed to cut down on prep time, and increase my effective load out. (although still capped) for efficiency it would have logic that decides how to act based on it's link number. either activating the next numbered script, or giving a new copy to another prim.

the negatives are that you are still preloading lots of scripts, although not as many as you can theoretically use (load is X + prims - 1, use is X * prims). and you still have a cap on how many you can use, which you need to be aware of in your addressing of them.

reset logic becomes nearly as painful since some can be destroyed, but the initial set must only be deactivated. nevermind all the extra controls for setting pin #'s for multiple prims. (not so much an issue for the rezzor example)

don't get me wrong, both those approaches would work, and have their benefits... but neither has the effeciency or scalability of the original self give concept

and I'm just really disappointed it couldn't be made to work as envisioned