Inplace object update script?

[Corvan-3]

Hi Folks,

I'm working on an update to an existing product as well as a couple of  
additional products and there's a feature I've seen on a lot of  
products in-world that i would really like to have myself: in-world  
script/contents updates.

Currently, I am using a HippoUpdate server to deliver updates. This is  
fine for objects that are copy-perm, and/or objects that are  
removable, but not so good for no-copy objects and objects that are  
locked onto an avatar.

I know this is a solved problem, and I suspect that there is someone  
who sells an update system because I've seen different makers using  
techniques that appear to be based around the same base object/
technique.

Can anyone either provide pointers to where I could purchase a drop-in  
self-update system or failing that provide pointer on how these  
systems work?

Thanks very much!
Corvan.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Tigro Spottystripes]

the basic idea is to have a server in-world the customer's copy of the
product contact, and if the version the customer has is older than what
the server has,  the server sends a new copy of the latest version to
the customer. If you are dealing with no-trans items, whoever owns the
server must have trans permission on the items, but the item should be
no-trans for the next owner.

Corvan escreveu:

> Hi Folks,
>
> I'm working on an update to an existing product as well as a couple of  
> additional products and there's a feature I've seen on a lot of  
> products in-world that i would really like to have myself: in-world  
> script/contents updates.
>
> Currently, I am using a HippoUpdate server to deliver updates. This is  
> fine for objects that are copy-perm, and/or objects that are  
> removable, but not so good for no-copy objects and objects that are  
> locked onto an avatar.
>
> I know this is a solved problem, and I suspect that there is someone  
> who sells an update system because I've seen different makers using  
> techniques that appear to be based around the same base object/
> technique.
>
> Can anyone either provide pointers to where I could purchase a drop-in  
> self-update system or failing that provide pointer on how these  
> systems work?
>
> Thanks very much!
> Corvan.
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>
>  

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Corvan-3]

Right, that's what I have now with the HippoUpdate server.

What I want to be able to do though is be able to update the object's  
contents in-place.

For instance, let's say I'm wearing a collar and it's locked on. I'm  
in RLV so I cannot remove it.

A new version of the collar's scripts is available I want to be able  
to load the new scripts into the collar in-place.

Presumably I'd need to stop the currently running scripts (except for  
whatever script is coordinating the update), receive inventory with  
the new contents, delete the old contents and then start the other  
scripts back up.

I believe this is doable, certainly the in-place script update is  
doable because several designers I can think of off the top of my head  
support it already: MoDesigns, Marine's RealRestraints, T&T, Mesmerize  
Dungeon, just to name a few. Before I reinvent this wheel (and  
hopefully avoid the potholes that I'm sure exist) I'd really rather  
find an existing, tested solution.

Thanks!
Corvan.

On Sep 9, 2009, at 11:36 AM, Tigro Spottystripes wrote:

> the basic idea is to have a server in-world the customer's copy of the
> product contact, and if the version the customer has is older than  
> what
> the server has,  the server sends a new copy of the latest version to
> the customer. If you are dealing with no-trans items, whoever owns the
> server must have trans permission on the items, but the item should be
> no-trans for the next owner.
>
> Corvan escreveu:
>> Hi Folks,
>>
>> I'm working on an update to an existing product as well as a couple  
>> of
>> additional products and there's a feature I've seen on a lot of
>> products in-world that i would really like to have myself: in-world
>> script/contents updates.
>>
>> Currently, I am using a HippoUpdate server to deliver updates. This  
>> is
>> fine for objects that are copy-perm, and/or objects that are
>> removable, but not so good for no-copy objects and objects that are
>> locked onto an avatar.
>>
>> I know this is a solved problem, and I suspect that there is someone
>> who sells an update system because I've seen different makers using
>> techniques that appear to be based around the same base object/
>> technique.
>>
>> Can anyone either provide pointers to where I could purchase a drop-
>> in
>> self-update system or failing that provide pointer on how these
>> systems work?
>>
>> Thanks very much!
>> Corvan.
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>>
>>

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Tigro Spottystripes]

Then have the server send a updater obejct that the person should rez,
and use remote load to overwrite the script (perhaps with an auxiliary
script to keep all the settings while the main script is updated)

Though changes to attachments don't always get saved properly, there is
the risk that next time the thing is worn an older version of the
attachment will load.

Corvan escreveu:

> Right, that's what I have now with the HippoUpdate server.
>
> What I want to be able to do though is be able to update the object's
> contents in-place.
>
> For instance, let's say I'm wearing a collar and it's locked on. I'm
> in RLV so I cannot remove it.
>
> A new version of the collar's scripts is available I want to be able
> to load the new scripts into the collar in-place.
>
> Presumably I'd need to stop the currently running scripts (except for
> whatever script is coordinating the update), receive inventory with
> the new contents, delete the old contents and then start the other
> scripts back up.
>
> I believe this is doable, certainly the in-place script update is
> doable because several designers I can think of off the top of my head
> support it already: MoDesigns, Marine's RealRestraints, T&T, Mesmerize
> Dungeon, just to name a few. Before I reinvent this wheel (and
> hopefully avoid the potholes that I'm sure exist) I'd really rather
> find an existing, tested solution.
>
> Thanks!
> Corvan.
>
> On Sep 9, 2009, at 11:36 AM, Tigro Spottystripes wrote:
>
>> the basic idea is to have a server in-world the customer's copy of the
>> product contact, and if the version the customer has is older than what
>> the server has,  the server sends a new copy of the latest version to
>> the customer. If you are dealing with no-trans items, whoever owns the
>> server must have trans permission on the items, but the item should be
>> no-trans for the next owner.
>>
>> Corvan escreveu:
>>> Hi Folks,
>>>
>>> I'm working on an update to an existing product as well as a couple of
>>> additional products and there's a feature I've seen on a lot of
>>> products in-world that i would really like to have myself: in-world
>>> script/contents updates.
>>>
>>> Currently, I am using a HippoUpdate server to deliver updates. This is
>>> fine for objects that are copy-perm, and/or objects that are
>>> removable, but not so good for no-copy objects and objects that are
>>> locked onto an avatar.
>>>
>>> I know this is a solved problem, and I suspect that there is someone
>>> who sells an update system because I've seen different makers using
>>> techniques that appear to be based around the same base object/
>>> technique.
>>>
>>> Can anyone either provide pointers to where I could purchase a drop-in
>>> self-update system or failing that provide pointer on how these
>>> systems work?
>>>
>>> Thanks very much!
>>> Corvan.
>>>
>>> _______________________________________________
>>> Click here to unsubscribe or manage your list subscription:
>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>>>
>>>
>>>
> 0
>

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Domchi Underwood]

On Wed, Sep 9, 2009 at 8:25 PM, Corvan <corvan@...> wrote:

Currently, I am using a HippoUpdate server to deliver updates. This is
fine for objects that are copy-perm, and/or objects that are
removable, but not so good for no-copy objects and objects that are
locked onto an avatar.

Can anyone either provide pointers to where I could purchase a drop-in
self-update system or failing that provide pointer on how these
systems work?

I scripted such a system for my own needs, but only for use on my products, so I don't have any references to give you.

However, basically it works like this (focusing on no-copy objects):

0. Customer must have modify permission for product.

1. You (or your update server) give customer updater object.

2. Customer rezzes updater object near the product that will be updated.

3. Updater object gives no-copy objects to rezzed product via llGiveInventory() - llGiveInventoryList() cannot give no-copy items.

4. Updater object loads no-copy scripts via llRemoteLoadScriptPin()

5. Updater no longer holds no-copy items, and can thus llDie() or something.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Glen Canaday]

That's the main issue there. His item must have an updater script inside
of it, perhaps one that saves settings, with a method of giving those
updates scripts their settings back.

Can use llSetScriptState() to set the updated scripts to running or not
running, etc. The updated scripts must already have been compiled and
probably set to not running in the updater object. Use llGiveInventory()
to update. Can be done on worn attachments, but Tigro's right about the
old-version issue. Can happen, and has happened to me many, many times
when I use "replace outfit" after editing the scripts inside the
attachment. That's why I always copy script and notecard contents before
removing an item I'm wearing after I've edited or updated them. I've
trashed many hours of work because of this.

On the other hand... the updater script can check for this easily if you
just include the version number in the name of the updating scripts!
Just check whenever the object TPs, is attached, rezzed, or whatever.
Then it can hit a server that will send the user an updater object, they
rez it, it broadcasts using llWhisper (to stay inside the 10M
llGiveInventory limit) that it has version "blah blah blah" of the
scripts in an item, and the updater script has a listen for that and it
tell the user "don't move" while it updates.

There is no pre-made inworld solution for that. It will need to be
custom, especially when you need to use link messages to reinstate
settings. It's been done many many times though, and fairly soon I'll be
having to do the exact same thing.

--GC

Tigro Spottystripes wrote:

> Then have the server send a updater obejct that the person should rez,
> and use remote load to overwrite the script (perhaps with an auxiliary
> script to keep all the settings while the main script is updated)
>
> Though changes to attachments don't always get saved properly, there is
> the risk that next time the thing is worn an older version of the
> attachment will load.
>
> Corvan escreveu:
>  
>> Right, that's what I have now with the HippoUpdate server.
>>
>> What I want to be able to do though is be able to update the object's
>> contents in-place.
>>
>> For instance, let's say I'm wearing a collar and it's locked on. I'm
>> in RLV so I cannot remove it.
>>
>> A new version of the collar's scripts is available I want to be able
>> to load the new scripts into the collar in-place.
>>
>> Presumably I'd need to stop the currently running scripts (except for
>> whatever script is coordinating the update), receive inventory with
>> the new contents, delete the old contents and then start the other
>> scripts back up.
>>
>> I believe this is doable, certainly the in-place script update is
>> doable because several designers I can think of off the top of my head
>> support it already: MoDesigns, Marine's RealRestraints, T&T, Mesmerize
>> Dungeon, just to name a few. Before I reinvent this wheel (and
>> hopefully avoid the potholes that I'm sure exist) I'd really rather
>> find an existing, tested solution.
>>
>> Thanks!
>> Corvan.
>>
>> On Sep 9, 2009, at 11:36 AM, Tigro Spottystripes wrote:
>>
>>    
>>> the basic idea is to have a server in-world the customer's copy of the
>>> product contact, and if the version the customer has is older than what
>>> the server has,  the server sends a new copy of the latest version to
>>> the customer. If you are dealing with no-trans items, whoever owns the
>>> server must have trans permission on the items, but the item should be
>>> no-trans for the next owner.
>>>
>>> Corvan escreveu:
>>>      
>>>> Hi Folks,
>>>>
>>>> I'm working on an update to an existing product as well as a couple of
>>>> additional products and there's a feature I've seen on a lot of
>>>> products in-world that i would really like to have myself: in-world
>>>> script/contents updates.
>>>>
>>>> Currently, I am using a HippoUpdate server to deliver updates. This is
>>>> fine for objects that are copy-perm, and/or objects that are
>>>> removable, but not so good for no-copy objects and objects that are
>>>> locked onto an avatar.
>>>>
>>>> I know this is a solved problem, and I suspect that there is someone
>>>> who sells an update system because I've seen different makers using
>>>> techniques that appear to be based around the same base object/
>>>> technique.
>>>>
>>>> Can anyone either provide pointers to where I could purchase a drop-in
>>>> self-update system or failing that provide pointer on how these
>>>> systems work?
>>>>
>>>> Thanks very much!
>>>> Corvan.
>>>>
>>>> _______________________________________________
>>>> Click here to unsubscribe or manage your list subscription:
>>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>>>>
>>>>
>>>>
>>>>        
>> 0
>>
>>    
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>
>  

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Corvan-3]

Preserving settings is trivial for me, I've got all settings stored  
offworld in a MySQL database.

I think this gets me pretty close though. Thanks a bunch!

Corvan

On Sep 9, 2009, at 2:28 PM, Glen wrote:

>
> That's the main issue there. His item must have an updater script  
> inside
> of it, perhaps one that saves settings, with a method of giving those
> updates scripts their settings back.
>
> Can use llSetScriptState() to set the updated scripts to running or  
> not
> running, etc. The updated scripts must already have been compiled and
> probably set to not running in the updater object. Use  
> llGiveInventory()
> to update. Can be done on worn attachments, but Tigro's right about  
> the
> old-version issue. Can happen, and has happened to me many, many times
> when I use "replace outfit" after editing the scripts inside the
> attachment. That's why I always copy script and notecard contents  
> before
> removing an item I'm wearing after I've edited or updated them. I've
> trashed many hours of work because of this.
>
> On the other hand... the updater script can check for this easily if  
> you
> just include the version number in the name of the updating scripts!
> Just check whenever the object TPs, is attached, rezzed, or whatever.
> Then it can hit a server that will send the user an updater object,  
> they
> rez it, it broadcasts using llWhisper (to stay inside the 10M
> llGiveInventory limit) that it has version "blah blah blah" of the
> scripts in an item, and the updater script has a listen for that and  
> it
> tell the user "don't move" while it updates.
>
> There is no pre-made inworld solution for that. It will need to be
> custom, especially when you need to use link messages to reinstate
> settings. It's been done many many times though, and fairly soon  
> I'll be
> having to do the exact same thing.
>
> --GC
>
> Tigro Spottystripes wrote:
>> Then have the server send a updater obejct that the person should  
>> rez,
>> and use remote load to overwrite the script (perhaps with an  
>> auxiliary
>> script to keep all the settings while the main script is updated)
>>
>> Though changes to attachments don't always get saved properly,  
>> there is
>> the risk that next time the thing is worn an older version of the
>> attachment will load.
>>
>> Corvan escreveu:
>>
>>> Right, that's what I have now with the HippoUpdate server.
>>>
>>> What I want to be able to do though is be able to update the  
>>> object's
>>> contents in-place.
>>>
>>> For instance, let's say I'm wearing a collar and it's locked on. I'm
>>> in RLV so I cannot remove it.
>>>
>>> A new version of the collar's scripts is available I want to be able
>>> to load the new scripts into the collar in-place.
>>>
>>> Presumably I'd need to stop the currently running scripts (except  
>>> for
>>> whatever script is coordinating the update), receive inventory with
>>> the new contents, delete the old contents and then start the other
>>> scripts back up.
>>>
>>> I believe this is doable, certainly the in-place script update is
>>> doable because several designers I can think of off the top of my  
>>> head
>>> support it already: MoDesigns, Marine's RealRestraints, T&T,  
>>> Mesmerize
>>> Dungeon, just to name a few. Before I reinvent this wheel (and
>>> hopefully avoid the potholes that I'm sure exist) I'd really rather
>>> find an existing, tested solution.
>>>
>>> Thanks!
>>> Corvan.
>>>
>>> On Sep 9, 2009, at 11:36 AM, Tigro Spottystripes wrote:
>>>
>>>
>>>> the basic idea is to have a server in-world the customer's copy  
>>>> of the
>>>> product contact, and if the version the customer has is older  
>>>> than what
>>>> the server has,  the server sends a new copy of the latest  
>>>> version to
>>>> the customer. If you are dealing with no-trans items, whoever  
>>>> owns the
>>>> server must have trans permission on the items, but the item  
>>>> should be
>>>> no-trans for the next owner.
>>>>
>>>> Corvan escreveu:
>>>>
>>>>> Hi Folks,
>>>>>
>>>>> I'm working on an update to an existing product as well as a  
>>>>> couple of
>>>>> additional products and there's a feature I've seen on a lot of
>>>>> products in-world that i would really like to have myself: in-
>>>>> world
>>>>> script/contents updates.
>>>>>
>>>>> Currently, I am using a HippoUpdate server to deliver updates.  
>>>>> This is
>>>>> fine for objects that are copy-perm, and/or objects that are
>>>>> removable, but not so good for no-copy objects and objects that  
>>>>> are
>>>>> locked onto an avatar.
>>>>>
>>>>> I know this is a solved problem, and I suspect that there is  
>>>>> someone
>>>>> who sells an update system because I've seen different makers  
>>>>> using
>>>>> techniques that appear to be based around the same base object/
>>>>> technique.
>>>>>
>>>>> Can anyone either provide pointers to where I could purchase a  
>>>>> drop-in
>>>>> self-update system or failing that provide pointer on how these
>>>>> systems work?
>>>>>
>>>>> Thanks very much!
>>>>> Corvan.
>>>>>
>>>>> _______________________________________________
>>>>> Click here to unsubscribe or manage your list subscription:
>>>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>>>>>
>>>>>
>>>>>
>>>>>
>>> 0
>>>
>>>
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>>
>>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Tigro Spottystripes]

set script state won't work on scripts that were given, llGiveInventory
skips the compilation part for scripts, the script must be put on the
inventory and then re-rezzed before it can be compiled (I'm not sure if
manual compilation works, but even if it did, it would involve letting
the customers read and modify the script code), I'm not sure how this
would work with attachments that can't be detached, perhaps the script
will start running on the next login, or perhaps never. To be sure
scripts will be running you need to use remote load, and that only works
for objects of the same owner, that is why there would be the need to
send an updater object that the customer must rez.

Corvan escreveu:

> Preserving settings is trivial for me, I've got all settings stored  
> offworld in a MySQL database.
>
> I think this gets me pretty close though. Thanks a bunch!
>
> Corvan
>
> On Sep 9, 2009, at 2:28 PM, Glen wrote:
>
>  
>> That's the main issue there. His item must have an updater script  
>> inside
>> of it, perhaps one that saves settings, with a method of giving those
>> updates scripts their settings back.
>>
>> Can use llSetScriptState() to set the updated scripts to running or  
>> not
>> running, etc. The updated scripts must already have been compiled and
>> probably set to not running in the updater object. Use  
>> llGiveInventory()
>> to update. Can be done on worn attachments, but Tigro's right about  
>> the
>> old-version issue. Can happen, and has happened to me many, many times
>> when I use "replace outfit" after editing the scripts inside the
>> attachment. That's why I always copy script and notecard contents  
>> before
>> removing an item I'm wearing after I've edited or updated them. I've
>> trashed many hours of work because of this.
>>
>> On the other hand... the updater script can check for this easily if  
>> you
>> just include the version number in the name of the updating scripts!
>> Just check whenever the object TPs, is attached, rezzed, or whatever.
>> Then it can hit a server that will send the user an updater object,  
>> they
>> rez it, it broadcasts using llWhisper (to stay inside the 10M
>> llGiveInventory limit) that it has version "blah blah blah" of the
>> scripts in an item, and the updater script has a listen for that and  
>> it
>> tell the user "don't move" while it updates.
>>
>> There is no pre-made inworld solution for that. It will need to be
>> custom, especially when you need to use link messages to reinstate
>> settings. It's been done many many times though, and fairly soon  
>> I'll be
>> having to do the exact same thing.
>>
>> --GC
>>
>> Tigro Spottystripes wrote:
>>    
>>> Then have the server send a updater obejct that the person should  
>>> rez,
>>> and use remote load to overwrite the script (perhaps with an  
>>> auxiliary
>>> script to keep all the settings while the main script is updated)
>>>
>>> Though changes to attachments don't always get saved properly,  
>>> there is
>>> the risk that next time the thing is worn an older version of the
>>> attachment will load.
>>>
>>> Corvan escreveu:
>>>
>>>      
>>>> Right, that's what I have now with the HippoUpdate server.
>>>>
>>>> What I want to be able to do though is be able to update the  
>>>> object's
>>>> contents in-place.
>>>>
>>>> For instance, let's say I'm wearing a collar and it's locked on. I'm
>>>> in RLV so I cannot remove it.
>>>>
>>>> A new version of the collar's scripts is available I want to be able
>>>> to load the new scripts into the collar in-place.
>>>>
>>>> Presumably I'd need to stop the currently running scripts (except  
>>>> for
>>>> whatever script is coordinating the update), receive inventory with
>>>> the new contents, delete the old contents and then start the other
>>>> scripts back up.
>>>>
>>>> I believe this is doable, certainly the in-place script update is
>>>> doable because several designers I can think of off the top of my  
>>>> head
>>>> support it already: MoDesigns, Marine's RealRestraints, T&T,  
>>>> Mesmerize
>>>> Dungeon, just to name a few. Before I reinvent this wheel (and
>>>> hopefully avoid the potholes that I'm sure exist) I'd really rather
>>>> find an existing, tested solution.
>>>>
>>>> Thanks!
>>>> Corvan.
>>>>
>>>> On Sep 9, 2009, at 11:36 AM, Tigro Spottystripes wrote:
>>>>
>>>>
>>>>        
>>>>> the basic idea is to have a server in-world the customer's copy  
>>>>> of the
>>>>> product contact, and if the version the customer has is older  
>>>>> than what
>>>>> the server has,  the server sends a new copy of the latest  
>>>>> version to
>>>>> the customer. If you are dealing with no-trans items, whoever  
>>>>> owns the
>>>>> server must have trans permission on the items, but the item  
>>>>> should be
>>>>> no-trans for the next owner.
>>>>>
>>>>> Corvan escreveu:
>>>>>
>>>>>          
>>>>>> Hi Folks,
>>>>>>
>>>>>> I'm working on an update to an existing product as well as a  
>>>>>> couple of
>>>>>> additional products and there's a feature I've seen on a lot of
>>>>>> products in-world that i would really like to have myself: in-
>>>>>> world
>>>>>> script/contents updates.
>>>>>>
>>>>>> Currently, I am using a HippoUpdate server to deliver updates.  
>>>>>> This is
>>>>>> fine for objects that are copy-perm, and/or objects that are
>>>>>> removable, but not so good for no-copy objects and objects that  
>>>>>> are
>>>>>> locked onto an avatar.
>>>>>>
>>>>>> I know this is a solved problem, and I suspect that there is  
>>>>>> someone
>>>>>> who sells an update system because I've seen different makers  
>>>>>> using
>>>>>> techniques that appear to be based around the same base object/
>>>>>> technique.
>>>>>>
>>>>>> Can anyone either provide pointers to where I could purchase a  
>>>>>> drop-in
>>>>>> self-update system or failing that provide pointer on how these
>>>>>> systems work?
>>>>>>
>>>>>> Thanks very much!
>>>>>> Corvan.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Click here to unsubscribe or manage your list subscription:
>>>>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>> 0
>>>>
>>>>
>>>>        
>>> _______________________________________________
>>> Click here to unsubscribe or manage your list subscription:
>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>>>
>>>
>>>      
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>>    
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>
>  

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Domchi Underwood]

On Wed, Sep 9, 2009 at 11:28 PM, Glen <gcanaday@...> wrote:

Then it can hit a server that will send the user an updater object, they
rez it, it broadcasts using llWhisper (to stay inside the 10M
llGiveInventory limit) that it has version "blah blah blah" of the 

Sorry, I'm missing someting - what llGiveInventory() 10M limit?

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

Is maintaining the object and updating in situ so imporant?
I just put a small HTTP script that checks with the data base each time the
item is rezzed or at least once a day to see if it is the latest version.
If it is not, the data base tells an in-world warehouse to llGiveInventory
the latest version.  A doomsday script in the old one renderes it useless,
after giving them an IM explaining they are getting an updated version.
Nice and simple and no problems about starting scripts or permissions.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Corvan-3]

Where it becomes an issue is with items that because of RLV  
restrictions cannot be taken off. If possible it would be nice to be  
able to update these sort of items without needing to unlock and  
remove the item first.

Cheers,
Corvan

On Sep 9, 2009, at 3:32 PM, AnnMarieSLFBI wrote:

> Is maintaining the object and updating in situ so imporant?
> I just put a small HTTP script that checks with the data base each  
> time the
> item is rezzed or at least once a day to see if it is the latest  
> version.
> If it is not, the data base tells an in-world warehouse to  
> llGiveInventory
> the latest version.  A doomsday script in the old one renderes it  
> useless,
> after giving them an IM explaining they are getting an updated  
> version.
> Nice and simple and no problems about starting scripts or permissions.
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Tigro Spottystripes]

if all there is to be updated are scripts and things scripts can change,
an updater object that does remote load when rezzed, if you make sure to
take in consideration things like keeping settings, and be prepared for
things to go wrong as well as be undone next time the thing is attached,
it should be ok

Corvan escreveu:

> Where it becomes an issue is with items that because of RLV  
> restrictions cannot be taken off. If possible it would be nice to be  
> able to update these sort of items without needing to unlock and  
> remove the item first.
>
> Cheers,
> Corvan
>
> On Sep 9, 2009, at 3:32 PM, AnnMarieSLFBI wrote:
>
>  
>> Is maintaining the object and updating in situ so imporant?
>> I just put a small HTTP script that checks with the data base each  
>> time the
>> item is rezzed or at least once a day to see if it is the latest  
>> version.
>> If it is not, the data base tells an in-world warehouse to  
>> llGiveInventory
>> the latest version.  A doomsday script in the old one renderes it  
>> useless,
>> after giving them an IM explaining they are getting an updated  
>> version.
>> Nice and simple and no problems about starting scripts or permissions.
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>>    
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>
>  

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Glen Canaday]

Right that is. I totally forgot about having to recompile. I had to do
this for a "script proliferator" i wrote. Have to use
llRemoteLoadScriptPin instead.

Yeah... there is a limit on how close an object can be in order to give
inventory to another object, unless I'm seriously mistaken and confused
it with another function. I might have. There was a limit somewhere on
this... gah I can't remember where. The hippo servers could sync with
each other if they were within 10M only. That might have changed somewhere.

--GC

Tigro Spottystripes wrote:

> set script state won't work on scripts that were given, llGiveInventory
> skips the compilation part for scripts, the script must be put on the
> inventory and then re-rezzed before it can be compiled (I'm not sure if
> manual compilation works, but even if it did, it would involve letting
> the customers read and modify the script code), I'm not sure how this
> would work with attachments that can't be detached, perhaps the script
> will start running on the next login, or perhaps never. To be sure
> scripts will be running you need to use remote load, and that only works
> for objects of the same owner, that is why there would be the need to
> send an updater object that the customer must rez.
>
> Corvan escreveu:
>  
>> Preserving settings is trivial for me, I've got all settings stored  
>> offworld in a MySQL database.
>>
>> I think this gets me pretty close though. Thanks a bunch!
>>
>> Corvan
>>
>> On Sep 9, 2009, at 2:28 PM, Glen wrote:
>>
>>  

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Stickman-2]

> this... gah I can't remember where. The hippo servers could sync with
> each other if they were within 10M only. That might have changed somewhere.

Probably due to the method of exchanging a handshake to open the pin.

llGiveInventory() works in any object within the sim, and any avatar
in the grid.

llGiveInventoryList() only works on an avatar that's in (or has
recently been in, though I haven't tested that) the current sim.

-Stickman
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters