[slscripters] LSL animation questions

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[slscripters] LSL animation questions

Ziggy Puff
Hi,

I might be getting back into doing some SL scripting after several years away, and I have a couple of questions:
  • I remember there was talk of adding features that would remove the need for a polling AO like ZHAO. Looking through the LSL wiki, I see some new functions for setting animation overrides. I also found some discussions of these having been rolled back. What's the state of the animation override functions? Are they stable and generally deployed across the grid?
  • I thought at one point there was talk about change event notifications if the avatar's animation stage changed, but I couldn't find anything like that. If an avatar attachment wanted to perform some other function (besides change the animation) based on the avatar's animation state, is polling still the only available option?
Thanks,
Ziggy


_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] LSL animation questions

Darien Caldwell-2
Hi Ziggy,

  I'm not sure where you read the functions had been rolled back, that's not the case. They are released and fully functional on the main grid for some time now. Perhaps the rollback was during the Release Candidate phase.

As for Polling vs Changed event, sadly Polling is still the only way to go. Of course that's one of the big reasons behind the new AO functions as it moves the animation changing to the server and no polling is necessary (except for swimming).

Good luck. :)
                                      - Dari


On Sun, Jan 26, 2014 at 7:57 AM, Ziggy Puff <[hidden email]> wrote:
Hi,

I might be getting back into doing some SL scripting after several years away, and I have a couple of questions:
  • I remember there was talk of adding features that would remove the need for a polling AO like ZHAO. Looking through the LSL wiki, I see some new functions for setting animation overrides. I also found some discussions of these having been rolled back. What's the state of the animation override functions? Are they stable and generally deployed across the grid?
  • I thought at one point there was talk about change event notifications if the avatar's animation stage changed, but I couldn't find anything like that. If an avatar attachment wanted to perform some other function (besides change the animation) based on the avatar's animation state, is polling still the only available option?
Thanks,
Ziggy


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

[slscripters] llSetMemoryLimit() question

Glen Canaday
In reply to this post by Ziggy Puff
Hey all,

Does llSetMemoryLimit() actually work? I just took a small hud object I
made years ago and recompiled the scripts to mono. I also added
llSetMemoryLimit(1024) to each of them since they're small and all
they're mostly for is old-style hud buttons. Script memory usage
reported in the UI (Land->Script Usage->Avatar) actually *grew*. I was
under the impression that limiting them .. well, limited them? I seem to
be getting the full 64kb reported in the UI and I get the same result
from Firestorm's LSL bridge (right-click avatar -> script info).

I checked the return value on the function call and I get STATUS_OK. The
function call fails properly if the limit is set too low. Here is the
test script:

default{
     state_entry(){
         integer limit = 1024;
         if(llSetMemoryLimit(limit) == STATUS_OK){
             llOwnerSay("Limit properly set to "+(string)limit);
         }else{
             llOwnerSay("Limit set failed.");
         }
     }

     touch_start(integer total_number){
         llMessageLinked(LINK_ROOT, 1, "", "");
     }
}

If the contents of state_entry() are removed I'm seeing no difference in
the reported memory usage in the UI. When set to LSL, it works at 16k as
expected.

When the same script is copied into multiple objects, the sim is
supposedly going to only load the 1 necessary copy of the bytecode into
memory, while setting aside a proper amount of memory for each instance
to use independent of one another. Or so I've read and have seen work
properly on many occasions. However, this does not, and an object with 6
buttons grows to 6 * 64k for these alone - so, neither behavior is as I
expect.

Any ideas? Is there a reserve amount of memory I don't see in the docs
I've read? Am I seeing something that should be reported somewhere as
either an LSL bug or as a viewer reporting issue? Sim reporting issue? I
have no idea what's up, so I'm putting it out here.

--GC

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] llSetMemoryLimit() question

Stickman-2
On Thu, Jan 30, 2014 at 7:19 PM, GC <[hidden email]> wrote:
> made years ago and recompiled the scripts to mono. I also added
> llSetMemoryLimit(1024) to each of them since they're small and all

If the limit is too small, it is ignored.

Mono scripts tend to be 4-5k minimum.

You can use llGetUsedMemory() to get a hand-wavy number of the current
memory usage the script is using. I generally use this number and add
a kilobyte or so for safety.

Alternatively, you could call llScriptProfiler(PROFILE_SCRIPT_MEMORY)
to enabled accurate memory counting (but slow down the script, so
don't use during normal operation) and then call llGetSPMaxMemory()
after your script has used it's most memory intensive actions to get
the accurate maximum memory used. It's useful if you have a script
that wildly varies in the memory it uses.

Though in the end, the primary purpose of llSetMemoryLimit() is to
avoid witch hunts against you. A Mono script that uses 5k will report
64k even if it's only actually using 5k. Unlike LSO, Mono only uses
what it needs. So until we can use it to set the limit above 64k, it's
just to tidy things up and make it look pretty.

Slightly related: As far as I know bytecode sharing is also not
reflected in any memory reporting. (Two scripts with identical UUIDs
share executable code.)

Stickman
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] llSetMemoryLimit() question

Darien Caldwell-2
In reply to this post by Glen Canaday
The function works. But due to technical limitations, the viewer reports the full 64k of memory that a Mono script could potentially use. I see the wiki falsely states the limited memory limit will appear in viewers, this is incorrect. I'll Fix the wiki.

- Dari


On Thu, Jan 30, 2014 at 7:19 PM, GC <[hidden email]> wrote:
Hey all,

Does llSetMemoryLimit() actually work? I just took a small hud object I
made years ago and recompiled the scripts to mono. I also added
llSetMemoryLimit(1024) to each of them since they're small and all
they're mostly for is old-style hud buttons. Script memory usage
reported in the UI (Land->Script Usage->Avatar) actually *grew*. I was
under the impression that limiting them .. well, limited them? I seem to
be getting the full 64kb reported in the UI and I get the same result
from Firestorm's LSL bridge (right-click avatar -> script info).

I checked the return value on the function call and I get STATUS_OK. The
function call fails properly if the limit is set too low. Here is the
test script:

default{
     state_entry(){
         integer limit = 1024;
         if(llSetMemoryLimit(limit) == STATUS_OK){
             llOwnerSay("Limit properly set to "+(string)limit);
         }else{
             llOwnerSay("Limit set failed.");
         }
     }

     touch_start(integer total_number){
         llMessageLinked(LINK_ROOT, 1, "", "");
     }
}

If the contents of state_entry() are removed I'm seeing no difference in
the reported memory usage in the UI. When set to LSL, it works at 16k as
expected.

When the same script is copied into multiple objects, the sim is
supposedly going to only load the 1 necessary copy of the bytecode into
memory, while setting aside a proper amount of memory for each instance
to use independent of one another. Or so I've read and have seen work
properly on many occasions. However, this does not, and an object with 6
buttons grows to 6 * 64k for these alone - so, neither behavior is as I
expect.

Any ideas? Is there a reserve amount of memory I don't see in the docs
I've read? Am I seeing something that should be reported somewhere as
either an LSL bug or as a viewer reporting issue? Sim reporting issue? I
have no idea what's up, so I'm putting it out here.

--GC

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] llSetMemoryLimit() question

Darien Caldwell-2
In reply to this post by Stickman-2
Stickman, I'm afraid you have it a bit wrong. Mono scripts allocate the full 64k of memory no matter how much they actually use. llSetMemoryLimit() actually reduces this to a real limited value. It's not "hand wavey".  Sadly it does *not* avoid witch hunts because to viewer it still reports 64k of usage even though in reality it's using less.

- Dari


On Thu, Jan 30, 2014 at 7:46 PM, Stickman <[hidden email]> wrote:
On Thu, Jan 30, 2014 at 7:19 PM, GC <[hidden email]> wrote:
> made years ago and recompiled the scripts to mono. I also added
> llSetMemoryLimit(1024) to each of them since they're small and all

If the limit is too small, it is ignored.

Mono scripts tend to be 4-5k minimum.

You can use llGetUsedMemory() to get a hand-wavy number of the current
memory usage the script is using. I generally use this number and add
a kilobyte or so for safety.

Alternatively, you could call llScriptProfiler(PROFILE_SCRIPT_MEMORY)
to enabled accurate memory counting (but slow down the script, so
don't use during normal operation) and then call llGetSPMaxMemory()
after your script has used it's most memory intensive actions to get
the accurate maximum memory used. It's useful if you have a script
that wildly varies in the memory it uses.

Though in the end, the primary purpose of llSetMemoryLimit() is to
avoid witch hunts against you. A Mono script that uses 5k will report
64k even if it's only actually using 5k. Unlike LSO, Mono only uses
what it needs. So until we can use it to set the limit above 64k, it's
just to tidy things up and make it look pretty.

Slightly related: As far as I know bytecode sharing is also not
reflected in any memory reporting. (Two scripts with identical UUIDs
share executable code.)

Stickman
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] llSetMemoryLimit() question

Darien Caldwell-2
In reply to this post by Darien Caldwell-2

Hi Jack,

  Yes, you're right about that part. I was making the same mistake he initially did, and set it to 1024 bytes. If the limit is too low it is ignored.  So the viewer and llGetObjectDetails will show the reduced limit when it successfully applies.

However, the 'hand waving' part being false still stands.

- Dari


On Thu, Jan 30, 2014 at 8:06 PM, Jack Abraham <[hidden email]> wrote:

On Jan 30, 2014, at 10:48 PM, Darien Caldwell <[hidden email]> wrote:

> The function works. But due to technical limitations, the viewer reports the full 64k of memory that a Mono script could potentially use. I see the wiki falsely states the limited memory limit will appear in viewers, this is incorrect. I'll Fix the wiki.
>
> - Dari

Dari, at least in my experience the viewer does report it correctly. As Stickman points out, GC was probably settting the limit below the script's current size and it was being ignored.

--
Jack Abraham
Where'd my .sig go?



_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] llSetMemoryLimit() question

Kelly Linden
Stickman has the most correct information.
* Mono scripts always use only the memory they need and report their
'limit'. They do not allocate their limit.
* Lowering the limit will reduce what is reported to viewers and to
llGetObjectDetails. It also means if your script actually uses more
than what you set then the script will crash.
* No mono script can run at 1024. The smallest useful size I have
found to be around 4k, maybe higher.
* Use the llGetUsedMemory and llScriptProfiler/llGetSPMaxMemory to
find how much memory your script uses.
* Specifically: if the value you pass to llSetMemoryLimit is less than
what llGetUsedMemory reports then the call will have no effect.
* Bytecode sharing is not reported regardless of using or not using
llSetMemoryLimit.

Examples:
llSetMemoryLimit(1024); // This will be ignored, your script is using
more memory than this.
llSetMemoryLimit(llGetUsedMemory()); // Almost guaranteed to crash your script
llSetMemoryLimit(llGetUsedMemory() + 1024); // If no string or list
manipulation then this may work.

 - Kelly

On Thu, Jan 30, 2014 at 8:19 PM, Darien Caldwell
<[hidden email]> wrote:

> Hi Jack,
>
>   Yes, you're right about that part. I was making the same mistake he
> initially did, and set it to 1024 bytes. If the limit is too low it is
> ignored.  So the viewer and llGetObjectDetails will show the reduced limit
> when it successfully applies.
>
> However, the 'hand waving' part being false still stands.
>
> - Dari
>
>
> On Thu, Jan 30, 2014 at 8:06 PM, Jack Abraham <[hidden email]> wrote:
>>
>>
>> On Jan 30, 2014, at 10:48 PM, Darien Caldwell <[hidden email]>
>> wrote:
>>
>> > The function works. But due to technical limitations, the viewer reports
>> > the full 64k of memory that a Mono script could potentially use. I see the
>> > wiki falsely states the limited memory limit will appear in viewers, this is
>> > incorrect. I'll Fix the wiki.
>> >
>> > - Dari
>>
>> Dari, at least in my experience the viewer does report it correctly. As
>> Stickman points out, GC was probably settting the limit below the script's
>> current size and it was being ignored.
>>
>> --
>> Jack Abraham
>> Where'd my .sig go?
>>
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] llSetMemoryLimit() question

Darien Caldwell-2
Thanks Kelly,
  Over the years Things get blurred as many people cite different authorities about how things work. Initially I too believed Mono only allocated what was needed (as I had participated in the Mono Beta and that's what Babbage had said). But years later so many were insistent that that was no longer the case that I took it to mean things had changed. It's good to hear things from a source of authority from time to time to disambiguate the fact from the fiction. Thanks for setting the matter (and me) straight.

   - Dari


On Thu, Jan 30, 2014 at 8:42 PM, Kelly Linden <[hidden email]> wrote:
Stickman has the most correct information.
* Mono scripts always use only the memory they need and report their
'limit'. They do not allocate their limit.
* Lowering the limit will reduce what is reported to viewers and to
llGetObjectDetails. It also means if your script actually uses more
than what you set then the script will crash.
* No mono script can run at 1024. The smallest useful size I have
found to be around 4k, maybe higher.
* Use the llGetUsedMemory and llScriptProfiler/llGetSPMaxMemory to
find how much memory your script uses.
* Specifically: if the value you pass to llSetMemoryLimit is less than
what llGetUsedMemory reports then the call will have no effect.
* Bytecode sharing is not reported regardless of using or not using
llSetMemoryLimit.

Examples:
llSetMemoryLimit(1024); // This will be ignored, your script is using
more memory than this.
llSetMemoryLimit(llGetUsedMemory()); // Almost guaranteed to crash your script
llSetMemoryLimit(llGetUsedMemory() + 1024); // If no string or list
manipulation then this may work.

 - Kelly

On Thu, Jan 30, 2014 at 8:19 PM, Darien Caldwell
<[hidden email]> wrote:
> Hi Jack,
>
>   Yes, you're right about that part. I was making the same mistake he
> initially did, and set it to 1024 bytes. If the limit is too low it is
> ignored.  So the viewer and llGetObjectDetails will show the reduced limit
> when it successfully applies.
>
> However, the 'hand waving' part being false still stands.
>
> - Dari
>
>
> On Thu, Jan 30, 2014 at 8:06 PM, Jack Abraham <[hidden email]> wrote:
>>
>>
>> On Jan 30, 2014, at 10:48 PM, Darien Caldwell <[hidden email]>
>> wrote:
>>
>> > The function works. But due to technical limitations, the viewer reports
>> > the full 64k of memory that a Mono script could potentially use. I see the
>> > wiki falsely states the limited memory limit will appear in viewers, this is
>> > incorrect. I'll Fix the wiki.
>> >
>> > - Dari
>>
>> Dari, at least in my experience the viewer does report it correctly. As
>> Stickman points out, GC was probably settting the limit below the script's
>> current size and it was being ignored.
>>
>> --
>> Jack Abraham
>> Where'd my .sig go?
>>
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] llSetMemoryLimit() question

Glen Canaday
In reply to this post by Kelly Linden
On 01/30/2014 10:42 PM, Kelly Linden wrote:
> Stickman has the most correct information.
> * No mono script can run at 1024. The smallest useful size I have
> found to be around 4k, maybe higher.
What I've found is that 1024 returns STATUS_OK. It returned the same
value with 16k, as well, with the same script. That may need to fail
better but that would be something for jira rather than the list.

         if(llSetMemoryLimit(2) != STATUS_OK) llOwnerSay("failed to set
limit");

This line above doesn't give the message that it had failed, which is
what was leading me to believe that the bytecode might not be included
in the original 64k block.

That would explain much. 4096 works well with the script I posted
earlier. Thx all.

--GC

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] llSetMemoryLimit() question

Argent Stonecutter
In reply to this post by Ziggy Puff
I wish you could do this for LSO scripts, I bet a 1k LSO script would be viable for something simple like a sitter.
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

[slscripters] WTF is going wrong. Objects disappear in 14 seconds after sim crossing.

AnnMarie Otoole
I filed JIRA bug 5120 but Maestro has been unable to reproduce.
But I can reproduce easily.
Elementary situation.
I have a rezzer that creates a cube.
Cube has one or two lines of code, both llSetPos (or llSetRegionPos).
First line puts it within 5 m of sim boundary on a SL road.  Scripts
enabled, ample prims available, object return 5 or 10 minutes, both
sides of sim line.
Second line of script moves it over sim boundary.
Objects disappear after 14 seconds, not returned to L&F, no error messages.
I have some live demos set up, full permissions so you can see code
and/or experiment.

These ones rez on a timer every 15 seconds.
Dauphin 245,200
Putiki Fold 50 120Putiki Fold 248,35 (This one does a couple of extra
llSetPos after crossing the boundary.)
Crumbi 230,3,33 (This one moves back to the originating sim as a test
but still dies.)
Snicket 249,115,48
Putiki Fold 248,35

This one touch to rez, rezzer at Sabre 75 50 35.  Watch sim crossing to
South East.
I'm stumped, please tell me I've overlooked some elementary setting???

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] WTF is going wrong. Objects disappear in 14 seconds after sim crossing.

adeonwriter
Does anyone have your mod rights? Vanishing without a trace sounds like llDie();. So either your script contains it or perhaps there is someone on the grid that does not like your cars.

---
[End of Message]

> On Feb 19, 2014, at 4:21 AM, AnnMarie Otoole <[hidden email]> wrote:
>
> I filed JIRA bug 5120 but Maestro has been unable to reproduce.
> But I can reproduce easily.
> Elementary situation.
> I have a rezzer that creates a cube.
> Cube has one or two lines of code, both llSetPos (or llSetRegionPos).
> First line puts it within 5 m of sim boundary on a SL road.  Scripts
> enabled, ample prims available, object return 5 or 10 minutes, both
> sides of sim line.
> Second line of script moves it over sim boundary.
> Objects disappear after 14 seconds, not returned to L&F, no error messages.
> I have some live demos set up, full permissions so you can see code
> and/or experiment.
>
> These ones rez on a timer every 15 seconds.
> Dauphin 245,200
> Putiki Fold 50 120Putiki Fold 248,35 (This one does a couple of extra
> llSetPos after crossing the boundary.)
> Crumbi 230,3,33 (This one moves back to the originating sim as a test
> but still dies.)
> Snicket 249,115,48
> Putiki Fold 248,35
>
> This one touch to rez, rezzer at Sabre 75 50 35.  Watch sim crossing to
> South East.
> I'm stumped, please tell me I've overlooked some elementary setting???
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] WTF is going wrong. Objects disappear in 14 seconds after sim crossing.

AnnMarie Otoole
Thanks.  We have progress.

It is something much more basic, however intriguingly complex.
The Lindenites finally started believing it.  I can understand their
disbelief at first since objects crossing boundaries under script
control happen millions of times a day without problems.

As far as can be seen so far, the basic cube I was using in all the live
demo sites were all direct or indirect decedents (copies) from an
original diseased cube I had created that caught some kind of cancer
which causes them to disappear 10 to 15 seconds after crossing a sim
line under (any) script control.  When testing with a fresh cube the
problem was gone and that is why they had problems reproducing it.  The
virus is insidious and passes to all offspring.  Infected cubes given to
the Lindens are exhibiting the problem for them.

The cancer is some kind of parametric characteristic of the object,
independent of script, creator, owner, how rezzed, land settings,
server,  physics, inventory storage, TOR, phantom, permisions, shape,
size, UUID, etc.  The only way you can identify that it is cancerous is
to have it move across a sim line and see if it vaporizes in 10 to 15
seconds.  I need to check my inventory and quarantine any objects that
are infected.

To solve my problem I need to find a way to cure any of my objects
(vehicles) that have the cancer short of rebuilding completely from
scratch with new prims.

In addition I'm going to do some experiments to try and replicate
whatever happened to the original cube that spawned the cancer. At the
time it was created and infected I was doing testing on the known bug
that causes objects to ignore the first touch event after crossing a sim
line under script control.  It has similarities in that there are no
discernible characteristics that a given cube "remembers" that it
crossed a sim line.

If there is interest I will post updates here however the support I
needed has arrived.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] WTF is going wrong. Objects disappear in 14 seconds after sim crossing.

Andromeda Quonset-2
Anne,

I'm always interested in this kind of strange occurrence.  I have had
the occasional odd prim that wouldn't perform the way it should, or
the way I wanted it to perform, and found that if I started with a
new prim  the problem disappeared.  This seems to me to be a similar
anomaly.   Also, I sell a TP system which works on a basis of pausing
at sim borders, crossing the borders, then pausing again, and it
could potentially suffer from a cancer or other infection in a similar manner.

Regards,
Andro

At 08:15 PM 2/19/2014, you wrote:

>Thanks.  We have progress.
>
>It is something much more basic, however intriguingly complex.
>The Lindenites finally started believing it.  I can understand their
>disbelief at first since objects crossing boundaries under script
>control happen millions of times a day without problems.
>
>As far as can be seen so far, the basic cube I was using in all the live
>demo sites were all direct or indirect decedents (copies) from an
>original diseased cube I had created that caught some kind of cancer
>which causes them to disappear 10 to 15 seconds after crossing a sim
>line under (any) script control.  When testing with a fresh cube the
>problem was gone and that is why they had problems reproducing it.  The
>virus is insidious and passes to all offspring.  Infected cubes given to
>the Lindens are exhibiting the problem for them.
>
>The cancer is some kind of parametric characteristic of the object,
>independent of script, creator, owner, how rezzed, land settings,
>server,  physics, inventory storage, TOR, phantom, permisions, shape,
>size, UUID, etc.  The only way you can identify that it is cancerous is
>to have it move across a sim line and see if it vaporizes in 10 to 15
>seconds.  I need to check my inventory and quarantine any objects that
>are infected.
>
>To solve my problem I need to find a way to cure any of my objects
>(vehicles) that have the cancer short of rebuilding completely from
>scratch with new prims.
>
>In addition I'm going to do some experiments to try and replicate
>whatever happened to the original cube that spawned the cancer. At the
>time it was created and infected I was doing testing on the known bug
>that causes objects to ignore the first touch event after crossing a sim
>line under script control.  It has similarities in that there are no
>discernible characteristics that a given cube "remembers" that it
>crossed a sim line.
>
>If there is interest I will post updates here however the support I
>needed has arrived.
>
>_______________________________________________
>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
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] WTF is going wrong. Objects disappear in 14 seconds after sim crossing.

AnnMarie Otoole
In reply to this post by AnnMarie Otoole
On 2/20/2014 3:39 AM, lee wrote:
> This reminds me of 1927 which still hasn´t been fixed after almost a
> year, and of pathfinding objects which venture off into the ocean
> where they disappear without any trace or notice unless they get stuck
> somewhere. Do your objects also disappear when they use kfm to cross
> sim borders, and do they still disappear when you use llSetRegionPos()
> with a distance of more than 10m?

All my vehicles are physical so I don't use kfm.
Both llSetPos and llSetRegionPos cause the problem if they cross a sim
boundary independent of distance.
Crossing under physics engine motion seems to be immune, still testing.
On my elementary test with a cube and llSetPos,  creating a virgin cube
and using the same script fixed the problem but there is no obvious prim
property that is evident in the infected prim except its response to sim
crossings.
However on my more complex vehicles I've not yet been able to find a way
to "cure" them once they are infected.
If you sit on it before moving, or quickly sit on it after the sim
crossing, it doesn't disappear and so far that is the only way I've
found to stop it.
Recent experiments suggest it doesn't disappear if BUILD is enabled in
the destination sim, I've been testing on SL roadways.

If anyone would like a copy of the infected prim, drop me an IM.  It
retains its infection with transfer.
Just add this script:-

default{
     state_entry(){
     }

     touch_start(integer t)  {
         llSetPos(llGetPos()+<-10,0,0>);
     }
}

But adjust the offset vector to cross the sim line where you test it.

Any feedback is greatly appreciated.
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] WTF is going wrong. Objects disappear in 14 seconds after sim crossing.

Harold Brown
I wonder if this is any relation to the bug where high-prim count attachments will ghost on teleport.  (ie the object appears to be attached to the wearer, no scripts run and others can not see it)



_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] WTF is going wrong. Objects disappear in 14 seconds after sim crossing.

AnnMarie Otoole
In reply to this post by AnnMarie Otoole
Thanks Lee.

On 2/25/2014 4:45 AM, lee wrote:
> With my vehicle, I´m using kfm to get over the sim border slowly
> because otherwise chances are too great to be thrown off so badly that
> I´m stuck somewhere (i. e. cannot move and cannot teleport at all) and
> must relog to get unstuck. Physics is simply disabled for the crossing
> and switched back on after. It´s not a good solution because the
> vehicle is on autopilot during the crossing. It´s only the most
> reliable one I could find.
I've had up to 200 vehicles running 24/7 for 5 years "physically"
crossing sim lines up to 30 million times per month and this is the
first time this problem has happened.
>
>> Both llSetPos and llSetRegionPos cause the problem if they cross a sim
>> boundary independent of distance.
> My understanding is that neither are supposed to be used to cross sim
> borders.  KFM is supposed to work for this.
Not correct, in fact if you look up llSetRegionPos it specifically
specifies the 10 meter range OVER a sim line that is acceptable.
>
>> <SNIP>
> Are you using llSetPos() and llSetRegionPos() for vehicles nobody sits
> on and which are supposed to cross sim borders?  They have to be
> non-physical for this, so you might be able to use kfm instead.
Not correct, my unoccupied physical vehicles have been "physically"
crossing sim lines for 5 years with no problems.
>> Recent experiments suggest it doesn't disappear if BUILD is enabled in
>> the destination sim, I've been testing on SL roadways.
> Perhaps the object is not supposed to be able to enter the other sim (or
> thereby parcel) in the first place.  When you have a physical object and
> object entry for your objects is disabled on the destination parcel,
> your object cannot enter.
>
> I´d expect to get the trespassing object returned.

<SNIP>

All tests were on SL roads with object entry enabled, scripts ON, and
ample prims available.
Currently objects get returned to L&F but that is not always the case.
An infected prim returned to L&F is still infected.
They all survive for 10 to 15 seconds then disappear.  The 10 to 15
seconds is very strange, it is independent of prim prior history and not
consistent with any other built in time delays.

>> If anyone would like a copy of the infected prim, drop me an IM.  It
>> retains its infection with transfer.
>> Just add this script:-
>>
>> default{
>>      state_entry(){
>>      }
>>
>>      touch_start(integer t)  {
>>          llSetPos(llGetPos()+<-10,0,0>);
>>      }
>> }
>>
>> But adjust the offset vector to cross the sim line where you test it.
> How did you get the objects infected?
>
>
I don't know.  I was experimenting with the bug that causes the first
touch event to be ignored after a sim crossing using script controls.  
The symptoms are related in that there is no way of telling that the
first touch will be ignored until you test it and it is infected under
similar circumstances.

The problem has been verified and reproduced by Maestro, it is now in the Maintenance Jira although I don't know how much attention it will get. My problem was to get my damaged objects working.  I'm resigned to the fact I have to delete them and rebuild with virgin prims.

Its virus is independent of physical status and independent of how it crossed the sim line so long as it was not in edit mode, unoccupied (unsatupon) and moved under script control.

I have not yet been able to re-infect a virgin prim but the infection is quite persistent and a property of the prim that cannot be detected.  The only way I can identify infected prims is to set them up on a sim boundary and move across with a simple llSetPos, then wait 15 seconds to see if it disappears.

I've not tested the KFM sim crossing but I feel confident the infected object would disappear.

*** JUST THIS MINUTE I DID AN INTERESTING EXPERIMENT. ***
I changed an infected cube to a sphere, set it physical and dropped it on a sloping ramp or just pushed it so it rolled over the sim line with no scripts.  It disappeared in 14 seconds.
Some testing with linking:  If an object is linked to the infected prim the whole object disappears.
If the infected prim is linked to a virgin prim it does not disappear and if unlinked the infected prim is no longer infected. (Might be a way to disinfect simple objects.)

I'm being careful to name and quarantine my infected prim however only descendents or linked children appear to be infected.

Again, if anyone wants a copy of the infected prim for testing send an IM to AnnMarie Otoole.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

[slscripters] Update on prim with virus that causes it to disappear on sim crossings.

AnnMarie Otoole
If you remember previous posts, I had a problem with objects being
returned to L&F after script caused sim crossings.
It turned out that the objects were all children copies of a prim that
appeared to have some kind of communicable virus.
Although Maestro verified the bug, it appeared to be an isolated case so
I doubt any action will be taken.

BUT, the problem is getting worse and driving me nuts.  Perhaps it is my
account that has the virus so I would like others to see if they can
reproduce it.

I can now create virus infected prims and unfortunately one of my
projects is in trouble because it gets infected.

Only certain sim crossings have the problem and the problem has
different symptoms.  I'm unable to determine related factors.  For a
while I thought it was a function of sim server types but that didn't
prove consistent.  On some sims they get returned to L&F, on some they
fail to cross the sim line.  Some have the problem with virgin prims,
some need prims that have crossed once.  It varies with TIME.  A site
that has the virus at one time may work fine at others.

I've been UNABLE to find any way to "cure" an infected prim, if anyone
can do this it will save my project.

HOW TO MAKE AN INFECTED PRIM.
Always create a "virgin" prim for testing.  That way you know it is
always new and uninfected.  Just saving in inventory can infect them.  
Create a cube and load and compile this script.  When testing, touching
it will turn it RED so you can isolate infected prims.  Saving a copy of
the compiled script in inventory can facilitate making virgin prims.

default{
     state_entry(){
     }

     touch_start(integer total_number){
         vector offset;
         vector here = llGetPos();

     //Determine which boundary to cross
         if(here.x < 10) offset = <-10,0,0>;
         if(here.x > 246) offset = <10,0,0>;
         if(here.y < 10) offset = <0,-10,0>;
         if(here.y > 246) offset = <0,10,0>;

         llSetColor(<1,0.25,0.25>,ALL_SIDES); //So you know it may be
infected
         llOwnerSay("Departing "+(string)here+"for destination
"+(string)(here + offset));

         llSetPos(here + offset);

//      if(returned to Lost and found) "Nothing will be heard";
         if(llGetPos() == here) llOwnerSay("Failed to move");
         else llOwnerSay("Survived the move");
     }
}

TESTING SITES.  You need any sim crossing with build enabled on one side
(so you can rez the test prim), and build disabled on the other side
(problem doesn't happen if build is enabled on the destination parcel).  
Try multiple sites, they have different symptoms (at different times).  
Create your test prim within 10m of the sim line and touch.

Scenario 1. It crosses the boundary and gets returned to L&F immediately
so even the virgin prim has the virus and you can't save it.
Scenario 2. More commonly, the prim will cross the line and not
disappear.  You can toggle it back and forth by clicking repeatedly with
no problem (but it HAS usually BEEN infected).  Take it into inventory,
rez it again and test, now you will see the effects of the virus.
Scenario 3. On some sites it just refuses to cross the sim while virgin,
and/or after rezzing an infected prim.
Scenario 4. None of the above, everything behaves normally

Sites. May act differently (or not react) at different times.  About
70%(?) have no problem at all.
1. Kenfield 250 160. (Currently Scenario 1 for me).
2. Ironstorm 15 5. (Rez zone is to the right, slide them onto the road
after creating).  (Scenario 1 but usually 2).
3. Sweetbay 70 5. (Use this vector exactly, it is opposite the SLRR
land).  (Scenario 1)
4. Burnott 65, 5. (Currently scenario 4 but scenario 2 and 3 earlier.)
5. Paranthrene 5, 45. Scenario 4
6. Kaseyo 160, 5.  (Rez in my land just to the west then move to 160,
5). Currently no problem going into Kiuek but once there Scenario 3, it
won't come back.
7. Seopophang 5, 190.  Scenario 4.
8. Semoshi 245 5. Scenario 2.
9. Montlaur 190,5.  Scenario 2 at first but cleared up and worked OK
while I was there.
10. Cheosan 240 5. Scenario 2.

I do hope there is a simple solution or a way to cure infected objects,
I've worked for months on this project.
Thanks everyone.
AnnMarie Otoole.








_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] Update on prim with virus that causes it to disappear on sim crossings.

Ambrosia-2
Have you tried using llSetRegionPos() instead of the old and very limited llSetPos, by the way?

--Chalice Yao


On Mon, Mar 24, 2014 at 6:06 PM, AnnMarie Otoole <[hidden email]> wrote:
If you remember previous posts, I had a problem with objects being
returned to L&F after script caused sim crossings.
It turned out that the objects were all children copies of a prim that
appeared to have some kind of communicable virus.
Although Maestro verified the bug, it appeared to be an isolated case so
I doubt any action will be taken.

BUT, the problem is getting worse and driving me nuts.  Perhaps it is my
account that has the virus so I would like others to see if they can
reproduce it.

I can now create virus infected prims and unfortunately one of my
projects is in trouble because it gets infected.

Only certain sim crossings have the problem and the problem has
different symptoms.  I'm unable to determine related factors.  For a
while I thought it was a function of sim server types but that didn't
prove consistent.  On some sims they get returned to L&F, on some they
fail to cross the sim line.  Some have the problem with virgin prims,
some need prims that have crossed once.  It varies with TIME.  A site
that has the virus at one time may work fine at others.

I've been UNABLE to find any way to "cure" an infected prim, if anyone
can do this it will save my project.

HOW TO MAKE AN INFECTED PRIM.
Always create a "virgin" prim for testing.  That way you know it is
always new and uninfected.  Just saving in inventory can infect them.
Create a cube and load and compile this script.  When testing, touching
it will turn it RED so you can isolate infected prims.  Saving a copy of
the compiled script in inventory can facilitate making virgin prims.

default{
     state_entry(){
     }

     touch_start(integer total_number){
         vector offset;
         vector here = llGetPos();

     //Determine which boundary to cross
         if(here.x < 10) offset = <-10,0,0>;
         if(here.x > 246) offset = <10,0,0>;
         if(here.y < 10) offset = <0,-10,0>;
         if(here.y > 246) offset = <0,10,0>;

         llSetColor(<1,0.25,0.25>,ALL_SIDES); //So you know it may be
infected
         llOwnerSay("Departing "+(string)here+"for destination
"+(string)(here + offset));

         llSetPos(here + offset);

//      if(returned to Lost and found) "Nothing will be heard";
         if(llGetPos() == here) llOwnerSay("Failed to move");
         else llOwnerSay("Survived the move");
     }
}

TESTING SITES.  You need any sim crossing with build enabled on one side
(so you can rez the test prim), and build disabled on the other side
(problem doesn't happen if build is enabled on the destination parcel).
Try multiple sites, they have different symptoms (at different times).
Create your test prim within 10m of the sim line and touch.

Scenario 1. It crosses the boundary and gets returned to L&F immediately
so even the virgin prim has the virus and you can't save it.
Scenario 2. More commonly, the prim will cross the line and not
disappear.  You can toggle it back and forth by clicking repeatedly with
no problem (but it HAS usually BEEN infected).  Take it into inventory,
rez it again and test, now you will see the effects of the virus.
Scenario 3. On some sites it just refuses to cross the sim while virgin,
and/or after rezzing an infected prim.
Scenario 4. None of the above, everything behaves normally

Sites. May act differently (or not react) at different times.  About
70%(?) have no problem at all.
1. Kenfield 250 160. (Currently Scenario 1 for me).
2. Ironstorm 15 5. (Rez zone is to the right, slide them onto the road
after creating).  (Scenario 1 but usually 2).
3. Sweetbay 70 5. (Use this vector exactly, it is opposite the SLRR
land).  (Scenario 1)
4. Burnott 65, 5. (Currently scenario 4 but scenario 2 and 3 earlier.)
5. Paranthrene 5, 45. Scenario 4
6. Kaseyo 160, 5.  (Rez in my land just to the west then move to 160,
5). Currently no problem going into Kiuek but once there Scenario 3, it
won't come back.
7. Seopophang 5, 190.  Scenario 4.
8. Semoshi 245 5. Scenario 2.
9. Montlaur 190,5.  Scenario 2 at first but cleared up and worked OK
while I was there.
10. Cheosan 240 5. Scenario 2.

I do hope there is a simple solution or a way to cure infected objects,
I've worked for months on this project.
Thanks everyone.
AnnMarie Otoole.








_______________________________________________
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
12