Re: [opensource-dev] Script Memory Limits UI

2010-03-07 Thread Tony Dodd
May I ask a probably dumb question here? It's probably been answered but I
can't find the answer now.
 
Presumably a script uses two resources, the byte code in its assembly and a
slab of memory allocated for its stack/heap. And am I right that the former
can be shared between multiple copies of a script whereas the latter would
have to be allocated separately to each script?
 
OK, the question is, does the 64K limit refer to both of these together or
just to the stack/heap? If I have a mono script that is quite large but
doesn't allocate any lists, will each instance of that that runs be using up
64K of memory?
 
If there's an obvious place I should look I apologise but without knowing
this I find it hard to assess how much impact memory limits will have on my
own scripts.
 
Maldoror Bowman
 

 

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Removal of the "MultipleAttachments" debug settings ?

2010-08-27 Thread Tony Dodd
Are we saying it will actually be impossible for a scripter to prevent users
attaching other objects at the same point as the object being scripted? Or
even detect that another attachment is using the same point? Combat systems
tend to rely on that to enforce 'one weapon per user' rules. 

> -Original Message-
> From: opensource-dev-boun...@lists.secondlife.com 
> [mailto:opensource-dev-boun...@lists.secondlife.com] On 
> Behalf Of Francesco Rabbi
> Sent: 27 August 2010 13:57
> To: Aleric Inglewood
> Cc: opensource-dev
> Subject: Re: [opensource-dev] Removal of the 
> "MultipleAttachments" debug settings ?
> 
> Maybe i not understand well, now if i want i can wear a 
> collar from a creator on a shirt made by somebody else, if 
> viewer lock me on a fixed wearing strutture imho is a 
> pain IF a user want create fast combination of clothes 
> and attachments without waste time clicking one per time each 
> item can use outfits folders, without overload viewers with 
> code than limit residents creativity in outfit composing.
> 
> If i want wear me undie ON my jeans i must be free to do it :)
> 
> --
> Sent by iPhone
> 
> Il giorno 27/ago/2010, alle ore 14:48, Aleric Inglewood 
>  ha scritto:
> 
> > I fail to see how your example could undermine the bits-proposal.
> > For a start, the bits *only* add possibilities (254 per object!).
> > Currently the ONLY existing behavior is as if my bits are 
> already in 
> > place, but set to  when you 'wear' something, and 
> to  when you 'add'
> > something. Adding the bits will just open up a whole scala 
> of control 
> > over how your attachments replace other attachments (and clothing?).
> >
> > On Fri, Aug 27, 2010 at 2:20 PM, Francesco Rabbi 
>  wrote:
> >> You lost quite all good taste of this feature Ppl 
> should be free 
> >> to add everything in funny/weird way, and creators cannot 
> be limited 
> >> matching which bit another creator use...
> >
> > The possibilities only increase, as I just explained. You can still 
> > add anything in every way possible. I specifically said 
> that each user 
> > should be able to change the bits of objects even if those 
> objects are 
> > no modify. You can always just set all bits to 0, then you can wear 
> > anything and everything at the same time.
> >
> >> The solution is resident side: outfits folders, may be interesting 
> >> mark boxes or vendors to create automatically outfit folders maybe
> >
> > Lets look at your example. I added comment on the right.
> >
> >> Example:
> >> -outfit "naked"
> >> Hair   <--- Head attachament
> >> SHAPE NO bits (or all 0)
> >> Skin NO bits (or all 0)
> >> Genitalia   <--- Pelvis attachment
> >>
> >> -outfit "sport"
> >> All above but genitalia
> >> Jeans<--- covers genitalia
> >> Shirt
> >> Shirt collar <--- Chest attachment
> >> Necklace   <--- Chest attachment
> >> Shoes   <--- Feet attachments
> >
> > Ok, so a user could set the same bit on the Genitalia 
> object as on the 
> > pants. Then they would become mutual exclusive, which is 
> what you want 
> > apparently (and which makes sense since pants cover 
> genitalia. Pants 
> > that don't should just NOT set that bit).
> >
> > Assuming that it looks good if you wear the necklace and the shirt 
> > collar at the same time: put them in different classes so 
> they won't 
> > replace each other when worn.
> >
> >> "replace" outfit should revert from to other, without got creators 
> >> crazy
> >
> > "replace outfit" is an entirely different thing than "wear" 
> attachment/clothing.
> > The usual meaning is that EVERYTHING is removed and then 
> things in the 
> > folder are added.
> >
> >> If a vendor or box can be enganced with "outfit" (over buy content 
> >> and buy copy)
> >
> > I think daily outfit management by the users is more important than 
> > the urge to control how and what the users wear by vendors.
> > If things bought by users don't work out of the box, then they will 
> > have to manually remove a few things, just like now. But at least 
> > they'll be able to automate that and not have to worry about having 
> > the add and remove attachments/clothing EVERY time, when 
> wearing stuff from inventory.
> >
> > Any change to wearing a new outfit that is in a just-bought box is 
> > orthogonal to my proposal.
> >
> >> ( all this marked with a giant IMHO)
> >>
> >> --
> >> Sent by iPhone
> >>
> >> Il giorno 27/ago/2010, alle ore 14:11, Aleric Inglewood 
> >>  ha scritto:
> >>
> >>> The following has been proposed before:
> >>>
> >>> * Add new bits to each object (all existing objects 
> should act as if 
> >>> all bits are set).
> >>> * Give the bits a default meaning (read: human readable 
> word, which 
> >>> can be different per attachment point),  but allow each user to 
> >>> override those descriptions locally.
> >>> * Allow users to change the bits for each of the