|
llTargetOmega ?
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi - I am using llTargetOmega to rotate an object which is associated with another object (The "main" object). It can't be linked to the main object, but I'd like it to act like it is. The move_start() and move_end() events are flakey, so I can't use them to detect when the main object moves, so the rotating object knows to move too. Making them physical and using the physics routines does not seem like a good idea. Is the only way to do it using a timer to test for movement every tenth of a second or something like that?
Frank L.
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
|
|
Re: llTargetOmega ?
I'd say move_start() and move_end() are your best bet. Whenever
possible, using an event rather than polling is ideal.
What's flaky about them? If they don't work right, submitting a Jira
with enough details to get it fixed before pursuing alternate paths
would be how I vindicate myself for polling.
-Stickman
On Thu, Oct 1, 2009 at 6:32 PM, Cisco Lane < travlorf@...> wrote:
> Hi - I am using llTargetOmega to rotate an object which is associated with
> another object (The "main" object). It can't be linked to the main object,
> but I'd like it to act like it is. The move_start() and move_end() events
> are flakey, so I can't use them to detect when the main object moves, so the
> rotating object knows to move too. Making them physical and using the
> physics routines does not seem like a good idea. Is the only way to do it
> using a timer to test for movement every tenth of a second or something like
> that?
>
> Frank L.
>
>
> _______________________________________________
> 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
|
|
Re: llTargetOmega ?
llTargetOmega is a smooth client-side effect while the moves will be server-based and so subject to lag. Could this be why you see them as flakey..?
An alternative might be to link the "child" object and rotate it using llSetRot on a timer? Again a server-based operation but might possibly look better.
Or better still, if the "child" object happens to be spherical and single-prim, then just rotate its texture instead! ;)
Sent from my iPhone Hi - I am using llTargetOmega to rotate an object which is associated with another object (The "main" object). It can't be linked to the main object, but I'd like it to act like it is. The move_start() and move_end() events are flakey, so I can't use them to detect when the main object moves, so the rotating object knows to move too. Making them physical and using the physics routines does not seem like a good idea. Is the only way to do it using a timer to test for movement every tenth of a second or something like that?
Frank L.
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
|
|
Re: llTargetOmega ?
On non-physical objects, llTargetOmega() produces a continuous smooth
spin, which is done client-side, and will in general look different to
different people looking at it; in particular you have no control over
the phase. Depending on what you mean by "act like it is",
llTargetOmega() may not be able to do what you want at all.
But that aside, if you control the main object as well, you could have
it announce when it moves (at the same time that it decides to move),
and have the secondary object react to that announcement. If that's
possible, it'll probably be more reliable and more efficient than
trying to detect the movement...
> On 2 Oct 2009, at 02:32, Cisco Lane < travlorf@...> wrote:
>
> Hi - I am using llTargetOmega to rotate an object which is associated with
> another object (The "main" object). It can't be linked to the main object,
> but I'd like it to act like it is. The move_start() and move_end() events
> are flakey, so I can't use them to detect when the main object moves, so the
> rotating object knows to move too. Making them physical and using the
> physics routines does not seem like a good idea. Is the only way to do it
> using a timer to test for movement every tenth of a second or something like
> that?
>
> Frank L.
>
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
|
|
Re: llTargetOmega ?
There are a number of ways you can approach this -
If the non-rotating object's (the base) movement is within a certain
area, you could setup prims that the base collides with or moves
along and use collision events to detect the change (call these the
detecting prims). The detecting prims could announce the base's new
position using llSay, llRegionSay, etc - have the rotating object
listen for updates from the detecting prims and have the rotating
object move accordingly.
If it's not practical to have something else detect the base's
movement, you could have either the rotating object or the base use
llSensorRepeat to detect the other. Using the llDetected* functions,
determine that the other moved and again announce the change using
llSay, etc and have the other move to match position.
If a user is moving the base, a less elegant solution could have the
user click the base to delete the rotating object, move the base, and
click it again to rez a new rotating object in the right position.
All three of these approaches assume that you have two distinct
objects that need to move. Can you instead simulate the movement of
the two objects? Make it appear that there are two objects when
there's really one.
For example if this is a desk fan, use a texture on a linked prim and
rotate a texture of fan blades to give the illusion of movement - this
approach would eliminate your problem altogether.
I'm sure that there are other ways. Personally I prefer the last
approach (simulating the effect) since it leaves everything on the
server and doesn't contribute (much) lag.
Let us know how things work out! -2fast
(same name in-world)
On Fri, Oct 2, 2009 at 3:07 AM, Tim Shoebridge < tim.shoebridge@...> wrote:
> llTargetOmega is a smooth client-side effect while the moves will be
> server-based and so subject to lag. Could this be why you see them as
> flakey..?
> An alternative might be to link the "child" object and rotate it using
> llSetRot on a timer? Again a server-based operation but might possibly look
> better.
> Or better still, if the "child" object happens to be spherical and
> single-prim, then just rotate its texture instead! ;)
>
> Sent from my iPhone
> On 2 Oct 2009, at 02:32, Cisco Lane < travlorf@...> wrote:
>
> Hi - I am using llTargetOmega to rotate an object which is associated with
> another object (The "main" object). It can't be linked to the main object,
> but I'd like it to act like it is. The move_start() and move_end() events
> are flakey, so I can't use them to detect when the main object moves, so the
> rotating object knows to move too. Making them physical and using the
> physics routines does not seem like a good idea. Is the only way to do it
> using a timer to test for movement every tenth of a second or something like
> that?
>
> Frank L.
>
> _______________________________________________
> 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
|
|
Re: llTargetOmega ?
On Fri, Oct 2, 2009 at 4:10 AM, Stickman < stickman@...> wrote:
> I'd say move_start() and move_end() are your best bet. Whenever
> possible, using an event rather than polling is ideal.
>
> What's flaky about them? If they don't work right, submitting a Jira
> with enough details to get it fixed before pursuing alternate paths
> would be how I vindicate myself for polling.
The biggest problem with those two events is that they don't register
rotation, and there is no way for an object to detect that it has been
rotated short of polling its rotation.
Submitting JIRA's does now always help as we all know, there has been
a jira for adding this missing feature that will stop objects (this is
quite often used in scripted doors) from polling for more than two
years ( http://jira.secondlife.com/browse/SVC-446).
-- L
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
|
|
 Re: llTargetOmega ?
So if you're not using the edit arrows, it should work fine. Are you
always going to be moving it via edit arrows, or is it going to happen
via script? Moving only via edit arrows sounds like you can just
select both objects and move them together.
Test it in the environment you're going to be using it in and see if
it works. Sounds like moving_start/end should work just fine for you.
-Stickman
On Fri, Oct 2, 2009 at 10:24 AM, Cisco Lane < travlorf@...> wrote:
> Sorry about that half baked message.
>
> Anyway, looking at the lsl wiki on moving start at
>
> http://lslwiki.net/lslwiki/wakka.php?wakka=moving_start>
> there is a message near the bottom that says "2009-06-15: Note that at
> present this event is not reliably fired as a result of manual move in edit
> mode." and that matches my experience. So I guess what you are saying is,
> use polling and submit a JIRA reports. Ok, good. Thanks for your help.
>
> Frank L.
>
> ________________________________
> From: Stickman < stickman@...>
> To: Cisco Lane < travlorf@...>
> Cc: secondlifescripters@...
> Sent: Thu, October 1, 2009 10:10:23 PM
> Subject: Re: llTargetOmega ?
>
> I'd say move_start() and move_end() are your best bet. Whenever
> possible, using an event rather than polling is ideal.
>
> What's flaky about them? If they don't work right, submitting a Jira
> with enough details to get it fixed before pursuing alternate paths
> would be how I vindicate myself for polling.
>
> -Stickman
>
> On Thu, Oct 1, 2009 at 6:32 PM, Cisco Lane < travlorf@...> wrote:
>> Hi - I am using llTargetOmega to rotate an object which is associated with
>> another object (The "main" object). It can't be linked to the main object,
>> but I'd like it to act like it is. The move_start() and move_end() events
>> are flakey, so I can't use them to detect when the main object moves, so
>> the
>> rotating object knows to move too. Making them physical and using the
>> physics routines does not seem like a good idea. Is the only way to do it
>> using a timer to test for movement every tenth of a second or something
>> like
>> that?
>>
>> Frank L.
>>
>>
>> _______________________________________________
>> 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
|
|
Re: llTargetOmega ?
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi - thanks for all the input. To clarify, what I want to have is a rotating object in a box. The rotation need not match for each observer. I want to open the box, see the rotating object, and close the box. I want to move the open or closed box manually anywhere, by any means, edit arrows, grab, etc. and have the object stay in its proper position. (It should not be considered an error to move the open box alone, without selecting the object as well.)
Please let me know if this summary is correct: we can link the object to the box or not. Linking it means rotation is a server side effect and we must use llSetRot on a timer to rotate the object. I have not tried it yet, but in my experience this results in jerky motion, especially in laggy situations. If we don't link the
object, then we can use the smooth client-side rotation of llTargetOmega, but now the object has to be repositioned when the box is open and moved. (closed and moved is no problem). This means sensing motion. Two methods: using moving_start (or end) or using llSensorRepeat to sense motion. (Forget using timed channel communication of position to sense motion.) Moving_start etc. is demonstrably flakey. Therefore we must use llSensorRepeat, either in the box or the object, and the response to detected motion is either for the object to move or to llDie while the box re-rezzes a rotating object. Thats four possibilities total.
I don't like the motion option, I favor the llDie and llRezObject method, because the effect is quicker.
If the box senses motion and tells the object to llDie, if theres any problem you will wind up with a box, an object, and a displaced object. If the object senses the motion and llDies on its own, and there is a
problem, you will wind up with a box with no object.
I favor the latter, so right now I am leaning towards the object doing the sensing and when the box moves, the object shouts that it is llDie-ing and then llDies.
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
|
|
Re: llTargetOmega ?
Interesting! I assume the object is multi-prim itself? (If it was a
single prim, you could just make it a child of the box, and rotate it
using llTargetOmega on the child.)
I'd originally misinterpreted you as saying that you wanted the
*rotation* of the object to match that of the box; but it's the
position that you want to match, correct? I am lazy myself :) what I
would probably do is have the object llDie when the box is closed, rez
a new object when the box is opened, and tell people not to move the
box with the top open. :)
On Sat, Oct 3, 2009 at 5:53 AM, Cisco Lane < travlorf@...> wrote:
> Hi - thanks for all the input. To clarify, what I want to have is a rotating
> object in a box. The rotation need not match for each observer.
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
|
|
Re: llTargetOmega ?
Some parts of this message have been removed.
Learn more about Nabble's security policy.
How about llDie()ing the object when they close the
box, and when they open, rez a new one, delay the lid for long enough, then open
to see it in place?
----- Original Message -----
Sent: Saturday, October 03, 2009 5:53
AM
Subject: Re: llTargetOmega ?
Hi - thanks for all the input. To clarify, what I want to have is a
rotating object in a box. The rotation need not match for each observer. I
want to open the box, see the rotating object, and close the box. I want to
move the open or closed box manually anywhere, by any means, edit arrows,
grab, etc. and have the object stay in its proper position. (It should not be
considered an error to move the open box alone, without selecting the object
as well.)
Please let me know if this summary is correct: we can link
the object to the box or not. Linking it means rotation is a server side
effect and we must use llSetRot on a timer to rotate the object. I have not
tried it yet, but in my experience this results in jerky motion, especially in
laggy situations. If we don't link the object, then we can use the smooth
client-side rotation of llTargetOmega, but now the object has to be
repositioned when the box is open and moved. (closed and moved is no problem).
This means sensing motion. Two methods: using moving_start (or end) or using
llSensorRepeat to sense motion. (Forget using timed channel communication of
position to sense motion.) Moving_start etc. is demonstrably flakey. Therefore
we must use llSensorRepeat, either in the box or the object, and the response
to detected motion is either for the object to move or to llDie while the box
re-rezzes a rotating object. Thats four possibilities total.
I don't
like the motion option, I favor the llDie and llRezObject method, because the
effect is quicker.
If the box senses motion and tells the object to
llDie, if theres any problem you will wind up with a box, an object, and a
displaced object. If the object senses the motion and llDies on its own, and
there is a problem, you will wind up with a box with no object.
I favor
the latter, so right now I am leaning towards the object doing the sensing and
when the box moves, the object shouts that it is llDie-ing and then
llDies.
_______________________________________________
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
|
|
Re: llTargetOmega ?
Hi
> Hi - thanks for all the input. To clarify, what I want to have is a rotating object in a box. The rotation need not match for each observer. I want to open the box, see the rotating object, and close the box. I want to move the open or closed box manually anywhere, by any means, edit arrows, grab, etc. and have the object stay in its proper position. (It should not be considered an error to move the open box alone, without selecting the object as well.)
>
> Please let me know if this summary is correct: we can link the object to the box or not. Linking it means rotation is a server side effect and we must use llSetRot on a timer to rotate the object.
AFAIR the wiki/portal does not mention this effect for linking. Only a
Physical object involves the server, as it makes regular updates to the
physics; non-physical objects.are handled entirely client-side, whether
link-sets or not.
> I have not tried it yet, but in my experience this
> results in jerky motion, especially in laggy situations. If we don't
> link the object, then we can use the smooth client-side rotation of
> llTargetOmega, but now the object has to be repositioned when the box is
> open and moved. (closed and moved is no problem). This means sensing
> motion. Two methods: using moving_start (or end) or using llSensorRepeat
> to sense motion. (Forget using timed channel communication of position
> to sense motion.) Moving_start etc. is demonstrably flakey. Therefore we
> must use llSensorRepeat, either in the box or the object, and the
> response to detected motion is either for the object to move or to llDie
> while the box re-rezzes a rotating object. Thats four possibilities total.
>
> I don't like the motion option, I favor the llDie and llRezObject method, because the effect is quicker.
>
> If the box senses motion and tells the object to llDie, if theres any problem you will wind up with a box, an object, and a displaced object. If the object senses the motion and llDies on its own, and there is a problem, you will wind up with a box with no object.
>
> I favor the latter, so right now I am leaning towards the object doing the sensing and when the box moves, the object shouts that it is llDie-ing and then llDies.
>
>
>
>
Ima Mechanique
Check List
1) Check the documentation.
2) Drink coffee.
3) Check the documentation again, to see what I missed first time.
4) If I still can't solve it, ask if anyone else has the answer.
ima.mechanique(at)blueyonder.co.uk
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
|
|
Priorities for return of objects when prim limit is exceeded.
Some parts of this message have been removed.
Learn more about Nabble's security policy.
This was a disaster. I've made SVC-4881 on
which you can vote if inclined.
Here is the content of hte problem.
Give priority to landowner objects when returned due to exceeding prim
limits.
Despite having 2,600 unused prim capacity, items recently started getting
returned rapidly to L&F. No explanation was found for the glitch. When it
started to happen again 12 hours later the sim was restarted and it has not
happened since.
The return of objects selection appears to be random. The problem I had was
that many of the objects were still owned by the previous landowner since they
were not transferrable when I purchased the land. That person no longer has an
SL account.
When objects owned by the previous landowner were selected for return they
were lost permanently leaving an irrepairable disaster that should not have
happened.
Irrespective of how it happened, priority should be give to objects owned by
the current land-owner for return to Lost and Found so the damage can be
repaired. _______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
|
|
Re: Priorities for return of objects when prim limit is exceeded.
Ah, that's a really bad idea in other circumstances.
Give priority to the landowners stuff so if someone manages to find somewhere to rez-grief your stuff gets returned and all the crap they want to rez takes over. I sometimes have land with rez-rights left on so people can show me stuff or similar. I really don't want to come home and find I've left it home and some jerk has just returned my house.
I'm sorry for your problem but there's no "one size fits all" here.
El. This was a disaster. I've made SVC-4881 on which you can vote if inclined. Here is the content of hte problem. Give priority to landowner objects when returned due to exceeding prim limits. Despite having 2,600 unused prim capacity, items recently started getting returned rapidly to L&F. No explanation was found for the glitch. When it started to happen again 12 hours later the sim was restarted and it has not happened since. The return of objects selection appears to be random. The problem I had was that many of the objects were still owned by the previous landowner since they were not transferrable when I purchased the land. That person no longer has an SL account. When objects owned by the previous landowner were selected for return they were lost permanently leaving an irrepairable disaster that should not have happened. Irrespective of how it happened, priority should be give to objects owned by the current land-owner for return to Lost and Found so the damage can be repaired. _______________________________________________ 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
|
|
Re: Priorities for return of objects when prim limit is exceeded.
Ann,
I seem to recall there being _something_ posted on the sldev or
scripting list about the order in which objects are returned. However,
my searches aren't turning up anything useful. Currently, they're
returned in such a way that the seemingly most important objects are
the ones that stay behind. That is, newest non-group first, then
newest group, and finally newest owner.
I believe you're in an edge-case there. Something that, ideally, would
never happen. And something that's easier handled individually, rather
than changing the rules for everyone else. Did you contact support?
It's possible they could rollback the sim if the problem is severe
enough.
I think what you want is the "random returning" bug fixed, not the
return order changed. You'd have better luck with that anyway.
-Stickman
On Sat, Oct 3, 2009 at 1:29 PM, < AnnMarie@...> wrote:
> This was a disaster. I've made SVC-4881 on which you can vote if inclined.
>
> Here is the content of hte problem.
>
> Give priority to landowner objects when returned due to exceeding prim
> limits.
>
> Despite having 2,600 unused prim capacity, items recently started getting
> returned rapidly to L&F. No explanation was found for the glitch. When it
> started to happen again 12 hours later the sim was restarted and it has not
> happened since.
>
> The return of objects selection appears to be random. The problem I had was
> that many of the objects were still owned by the previous landowner since
> they were not transferrable when I purchased the land. That person no longer
> has an SL account.
>
> When objects owned by the previous landowner were selected for return they
> were lost permanently leaving an irrepairable disaster that should not have
> happened.
>
> Irrespective of how it happened, priority should be give to objects owned by
> the current land-owner for return to Lost and Found so the damage can be
> repaired.
>
> _______________________________________________
> 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
|
|
Re: Priorities for return of objects when prim limit is exceeded.
I've never understood this behavior at all. Normally when you try to
rez something and the parcel is full, the rez just fails. Why does it
sometimes instead cause things already rezzed in the parcel to be
returned? It seems pretty obvious it's going to be impossible to do
that right (whatever algorithm is chosen's going to be wrong
sometimes). Isn't the right thing to do to just not allow the new
rezzing attempt to succeed, always, and leave what's there there?
On Sat, Oct 3, 2009 at 5:50 PM, Stickman < stickman@...> wrote:
> Ann,
>
> I seem to recall there being _something_ posted on the sldev or
> scripting list about the order in which objects are returned. However,
> my searches aren't turning up anything useful. Currently, they're
> returned in such a way that the seemingly most important objects are
> the ones that stay behind. That is, newest non-group first, then
> newest group, and finally newest owner.
>
> I believe you're in an edge-case there. Something that, ideally, would
> never happen. And something that's easier handled individually, rather
> than changing the rules for everyone else. Did you contact support?
> It's possible they could rollback the sim if the problem is severe
> enough.
>
> I think what you want is the "random returning" bug fixed, not the
> return order changed. You'd have better luck with that anyway.
>
> -Stickman
>
> On Sat, Oct 3, 2009 at 1:29 PM, < AnnMarie@...> wrote:
>> This was a disaster. I've made SVC-4881 on which you can vote if inclined.
>>
>> Here is the content of hte problem.
>>
>> Give priority to landowner objects when returned due to exceeding prim
>> limits.
>>
>> Despite having 2,600 unused prim capacity, items recently started getting
>> returned rapidly to L&F. No explanation was found for the glitch. When it
>> started to happen again 12 hours later the sim was restarted and it has not
>> happened since.
>>
>> The return of objects selection appears to be random. The problem I had was
>> that many of the objects were still owned by the previous landowner since
>> they were not transferrable when I purchased the land. That person no longer
>> has an SL account.
>>
>> When objects owned by the previous landowner were selected for return they
>> were lost permanently leaving an irrepairable disaster that should not have
>> happened.
>>
>> Irrespective of how it happened, priority should be give to objects owned by
>> the current land-owner for return to Lost and Found so the damage can be
>> repaired.
>>
>> _______________________________________________
>> 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
|
|
Re: Priorities for return of objects when prim limit is exceeded.
Wouldn't the best algorithm simply be to return whatever was more
recently rezzed when the parcel goes beyond it's prim quota? (Though
avoiding having to return anything to start with by simply not allowing
things to be rezzed if they don't fit on the parcel would be better of
course)
Dale Innis escreveu:
> I've never understood this behavior at all. Normally when you try to
> rez something and the parcel is full, the rez just fails. Why does it
> sometimes instead cause things already rezzed in the parcel to be
> returned? It seems pretty obvious it's going to be impossible to do
> that right (whatever algorithm is chosen's going to be wrong
> sometimes). Isn't the right thing to do to just not allow the new
> rezzing attempt to succeed, always, and leave what's there there?
>
>
> On Sat, Oct 3, 2009 at 5:50 PM, Stickman < stickman@...> wrote:
>
>> Ann,
>>
>> I seem to recall there being _something_ posted on the sldev or
>> scripting list about the order in which objects are returned. However,
>> my searches aren't turning up anything useful. Currently, they're
>> returned in such a way that the seemingly most important objects are
>> the ones that stay behind. That is, newest non-group first, then
>> newest group, and finally newest owner.
>>
>> I believe you're in an edge-case there. Something that, ideally, would
>> never happen. And something that's easier handled individually, rather
>> than changing the rules for everyone else. Did you contact support?
>> It's possible they could rollback the sim if the problem is severe
>> enough.
>>
>> I think what you want is the "random returning" bug fixed, not the
>> return order changed. You'd have better luck with that anyway.
>>
>> -Stickman
>>
>> On Sat, Oct 3, 2009 at 1:29 PM, < AnnMarie@...> wrote:
>>
>>> This was a disaster. I've made SVC-4881 on which you can vote if inclined.
>>>
>>> Here is the content of hte problem.
>>>
>>> Give priority to landowner objects when returned due to exceeding prim
>>> limits.
>>>
>>> Despite having 2,600 unused prim capacity, items recently started getting
>>> returned rapidly to L&F. No explanation was found for the glitch. When it
>>> started to happen again 12 hours later the sim was restarted and it has not
>>> happened since.
>>>
>>> The return of objects selection appears to be random. The problem I had was
>>> that many of the objects were still owned by the previous landowner since
>>> they were not transferrable when I purchased the land. That person no longer
>>> has an SL account.
>>>
>>> When objects owned by the previous landowner were selected for return they
>>> were lost permanently leaving an irrepairable disaster that should not have
>>> happened.
>>>
>>> Irrespective of how it happened, priority should be give to objects owned by
>>> the current land-owner for return to Lost and Found so the damage can be
>>> repaired.
>>>
>>> _______________________________________________
>>> 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
|
|
Re: Priorities for return of objects when prim limit is exceeded.
On Sat, Oct 3, 2009 at 4:05 PM, Dale Innis < daleinnisemail@...> wrote:
> I've never understood this behavior at all. Normally when you try to
> rez something and the parcel is full, the rez just fails. Why does it
> sometimes instead cause things already rezzed in the parcel to be
> returned? It seems pretty obvious it's going to be impossible to do
> that right (whatever algorithm is chosen's going to be wrong
> sometimes). Isn't the right thing to do to just not allow the new
> rezzing attempt to succeed, always, and leave what's there there?
https://lists.secondlife.com/pipermail/sldev/2009-July/014729.htmlFollow that thread to see the problem and proposed solutions. Maybe
you could add something to a Jira if someone never got around to it?
Andrew and Simon Linden are the public-facing server devs that would
be related to this, I believe, so you could attend their office hours
and point it out, if you really wanted.
-Stickman
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
|
|
llBreakAllLinks() not working
Some parts of this message have been removed.
Learn more about Nabble's security policy.
This script USED to WORK to crash the
building but now fails.
PERMISSIN_CHANGE_LINKS has been granted and
acknowledged.
I own the building. I have edit permissions on the
building. It is not locked. No error messages are received.
The paramater setting work but Links wont
Break.
Any ideas why it has started to fail?
Jira is down for maintenance at the moment so I've
not checked there yet.
listen(integer channel, string
from, key id, string msg){
if(msg ==
"START"){
llSetPrimitiveParams([PRIM_PHANTOM,FALSE, PRIM_PHYSICS,TRUE,
PRIM_TEMP_ON_REZ,TRUE]);
llBreakAllLinks();
}
}
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
|
|
Re: llBreakAllLinks() not working
Fond memories!
Physics is one of the funnest things to play with in games. I remember
exploding many-a-thing back in the day.
As for why it won't work, I'm not sure. I know that
llSetStatus(STATUS_PHYSICS, TRUE) does (or did) work years ago, as I
used that in my boats and customers would turn them on while rezzed
inside the dock and lock up the sim.
If links aren't breaking at all, I can only guess that LL put in some
kind of safeguard to prevent people like us from having fun. Or
probably to try to prevent physics griefers -- but that would kind
defeat the whole purpose of making Havok 4 stable, in my opinion. You
lock it down, or you build it like a tank. If it's strong enough, let
the people have their fun, even if it lets griefers slow down sims now
and then.
I'd be interested to know if this is intentional, a bug, a temporary
condition brought on by a sim's insanity, or something else. I'd be
sad to see physics unable to be played with like this. With Red
Faction not having an SDK, SL remains the best physics sandbox short
of Garry's Mod.
-Stickman
On Wed, Oct 7, 2009 at 11:31 PM, < AnnMarie@...> wrote:
> This script USED to WORK to crash the building but now fails.
> PERMISSIN_CHANGE_LINKS has been granted and acknowledged.
> I own the building. I have edit permissions on the building. It is not
> locked. No error messages are received.
> The paramater setting work but Links wont Break.
>
> Any ideas why it has started to fail?
> Jira is down for maintenance at the moment so I've not checked there yet.
>
>
> listen(integer channel, string from, key id, string msg){
> if(msg == "START"){
> llSetPrimitiveParams([PRIM_PHANTOM,FALSE, PRIM_PHYSICS,TRUE,
> PRIM_TEMP_ON_REZ,TRUE]);
> llBreakAllLinks();
> }
> }
> _______________________________________________
> 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
|
|
Re: llBreakAllLinks() not working
|
