|
|
|
[
Permlink
| « Hide
]
Arawn Spitteler added a comment - 27/Aug/08 06:33 PM
Some day, I might even learn to use the Jira.
Repro from
vector key2pos(key in_target) touch_start(integer total_number) } } This is confirmed and breaking existing content Raised priority to Critical as it breaks existing content
In Andrew Linden's Office Hour, of 28 August, he seemed to think the SLPP Teleport was a bug, and should remain fixed. We may be in need of more votes.
Some brief history:
Until 1.23, there was no distance limit at all on llSetLinkPrimitiveParams() when moving an avatar. This was a problem, as it meant that an avatar could be sent up to max integer altitude or out into the intersim void. Leaving those problems aside, there needed to be a limit set somewhere, as evidenced by the fact that all other movement functions have limits. Unbounded functions will tend to cause problems, such as the ones I just mentioned. In 1.23, the movement was clamped to <256,256,4096>, which is (usable) area of a region. However, because llSetLinkPrimitiveParams() sets PRIM_POSITION based upon the relative rotation and coordinates of the root prim, this change resulted in very inconsistent behavior in which the distance limit in a given direction depended upon the rotation of the root prim. Thus rotating the prim could result in limits of 4096m in the global X direction and 256m in the global Y and Z axes. The resulting behavior was inconsistent and confusing, and seemed to cause more problems than it solved. The hard limit of 54m combined total distance (rather than per-axis limits) introduced in 1.24 is at least somewhat more consistent than the behavior under 1.23. llSetLinkPrimitiveParams() now limits avatars to the same max linkset distance used for any other child prim. To this extent, the behavior is now not only consistent but fully expected, given that those limits have already been in place for non-avatar child prims. Specifying a single max movement distance is certainly simpler than having one limit for prims and one limit for avatars, especially since avatars are, in theory, supposed to be treated as a child prim in a linkset. That being said, avatars are most definitely different from other child prims, and a good case can be made that there is nothing inherently wrong with treating them differently. Additionally, there are a number of advantages to being able to move an avatar around using llSetLinkPrimitiveParams(). In addition to the possibilities of true sim-wide teleporting, there is also the fact that llSetLinkPrimitiveParams() can move an avatar around multiple times after they sit, unlike llSitTarget(), and can even be used in the control() event to allow an avatar to move themselves around while still remaining seated on a root prim that is not moving. So on the one hand, there need to be limits to the range of this function. However, it is tricky to findlimits that are realistic and that will also result in consistent, expected behavior, while still allowing content creators to take advantage of the potential benefits of this function. Might one option be to add in a calculation step before the avatar is moved, to check the resulting global coordinates of their destination, and only then clamp the movement if it is beyond the 256x256x4096 bounds of the region? This way global limits can be placed on a function that uses local coordinates, without resulting in strange behavior. It prevent abuse while still allowing most of the potential functionality to continue. That being said, apropos of Arawn's last comment, it is important to remember that the main uses for this function were primarily intended for moving child prims within a linkset. Since a linkset cannot exceed 54m, this limit has already been in place for non-avatar child prims. Generally when I use llSetLinkPrimitiveParams(), it is to move a prim a few millimeters or centimeters, such as pulling out the stock on a gun. So given this, I can sort of see why Andrew Linden would consider movement of greater than 54m to be a bug. We were promised that a final destination within the current region would be reachable if the destination was within 256x256x4096. Going by the number of people on the war path today it would appear I am not the only creater to have sold a large number of teleporters that are now 100% useless. Anything that is only 54 meters away is not worth the prim to put in a teleporter! This needs to be fixed because it is far better than warppos for teleporting an avatar. Warppos is very memory hungry, especialy on long teleport distances. It must have 1 or 2 loops build into it. Some versions I have seen even have loops within loops which is insane! Then a huge chunk of data is fed into the llSetPrimitiveParams function to move the prim. On the other hand if you move the avatar as part of the link set it requires a single simple command that is very region resource friendly. Jahar's idea of testing the finaly destination sounds like it would be simple to implement while ensuring the avatars land at a friendly destiantion. I would also suggest that a bad destination should be clamped to the nearest good location. just as llSetPos will move towards the finaly destination and stop at the 10m mark. whoever changed this without warning while contradicting information that was previously given needs to be hit over the nose with a rolled up prim. Now if you will excuse me i hear more IM's comming in from unhappy customers who purchased teleporters in the last few months. Darling Darling wrote: >>We were promised that a final destination within the current region would be reachable if the destination was within 256x256x4096.
Yes. Content is broken. The problem was that llSetLinkPrimitiveParams was misused to orbit avatars to insane heights, and there was a consensus that a limit to 4k meters would be a reasonable fix to prevent the orbitting, but not to break legal usage for teleporters. We need a fix for this issue, please. When the ability to move an avatar as part of a linkset was initially found it was soon removed by the Lindens as it was stated as a bug, it could be used to crash sims, Alot of content creators who had created poseball-less seats got up in arms as their content was broken. It was reinstated.
This looks to be a similar situation. This unintended feature was seen and used to great and valid effect, to state it is a bug and close it without regard to the valid and useful content that sprang it up was unfortunate and should be revisited as the poseball-less chairs were done. In the past, with 768M ceilings, warppos was adequate. Now with 4096M ceilings Warppos (another hack on a bug) is inadequate. Jahar, are you now willing to admit this should have been left alone? Or are you still in favor of randoming breaking other content in pursuit of disabling things you don't like?
I agree with Darling's "clamp illegal values to the closest legal value" principle. If that had been followed with max-push there's be a lot less broken content today waiting for a post-Mono fix. As far i know this is the first time i comment on the jira bug report, (i'm not a scripter)
Sorry i am really upset.... damn lindens, so much things you don't fix, lag, crashes (viewer that just closes it self suddenly) keep adding useless options leaving lots of things unrepaired Avatars are orbited, so what? why don't you just limit everything to unworkable small limits, then people can choose easier to move on to some other 3d worlds, because this way SL is becomming less fun. Damn, i finaly got a good telleporter (darlings one) and now this.. NO FUN ON LAND WERE FLY IS DISABLED Now thia ia really insane. I mean 54 meters come on now . there are many of us that have either homes , clubs or other things in the sky. my club is 240 meters in the sky and this sorry limite has cosr me dearly. this needs to be fixed asap. i mean why limite tpo 54 meters that is truely insane
I think the status change was an error
One thing to remember is that a number of individuals initially found that llSetLinkPrimitiveParams() had no range-check, and instead of reporting on the potentially buggy behavior that this would cause, instead chose to keep it a secret and use it to create "Havok4 orbiters." Had it been reported initially, it is possible that a fix could have been rolled out more slowly and in a more orderly fashion. The moral of the story, such as it is, ought to be that it is important to report buggy behavior rather than try to treat it as a "trade secret."
@ Kabal: In the meantime, you can still use llSitTarget() based teleporters if the distance is less than 300m. It's not as useful a function as llSetLinkPrimitiveParams() for a number of reasons, but it's a good stopgap option until this is fixed. @Maggie: Please keep your JIRA comments civil. If you feel that you cannot comment without disparaging me or making ridiculous accusations, then perhaps you need to take a break from commenting for a while. Oh, and in response to Darling's comment, of course moving the av to the closest "safe" position would make sense, as this would allow for a certain amount of leeway and error correction, especially for situations in which the root prim might also be moving. This would prevent the script from having to do the calculations itself to find where the safe limits are. Pushing the calculation server-side would also probably be a lot more efficient.
Interestingly, one of the initial implementations of 1.23 was somewhat similar to this idea, where moving an av too far in the X or Y axes would result in them being "stopped" at the sim border. Leaving aside the fact that this prevents a good deal of mischief, it also prevents the (far more common) errors that would likely occur from having an object placed too close to the edge of a sim, for instance. The main difficulty, I think, is just reconciling global limits on a locally-calculated function. Adding an extra server-side computation before moving the avatar seems like the best way to reconcile the two different measurement methods, but I'd like some Linden feedback on how feasible that would be. Is Misfix a word?
My teleporter used SLPP to allow people to click on the carpet, or whatever, and then choose the destination. I gave one to torley, and the destinations of Spirit City just didn't exist in Here, so he might of thought it was out of line. I suppose I could use WarpPos, as a means of conveyance, but SLPP was much more elegant. SitTarget creates a linked object, and I even use llGetLinkNumber() in an if statement, to detect if someone's there, and the limit of SitTarget is about half a kilometer, and is usable for penetrating Access Lines, going out of Sim, and I've used that to look into Orientation Island. I don't see any reason to clamp down less than that. When I tested the range of SLPP, it tended to get wonky after the first kilometer, but most of the builds in Spirit City are within that range. I could understand clamping Physical Objects, at something that won't crash sims, and extending this restraint to MegaPrims. I'm just starting my scripting of Vehicles, and one of Twelve 512 meter sit targets, to roll over ban lines and reach between distant sims, might be fun while it lasts, but clamping SLPP to less than that, I just see no explanation. Do I understand someone tried to suppress this issue, as a support call? Let's not complain about Drama, when we use such approaches. This is the standard channel, for reporting Bugs, but a call from a few Concierge Customers effected, might not hurt. Andrew, please investigate. I don't think this is a Mono issue.
@ Andrew Linden
I have sent you an object named "quantum teleporter - SVC-2931". It is one of the commercialy available teleporters that has been effected by this bug. Darling. Jahar, my comment was entirely civil, and what I disparaged was the strategy of flinging content-breaking modifications into the server in a tunnel-visioned pursuit of stamping out griefing.
It's too complex a system for that. I say again: if formal specs are silent on a behavior; calling it "a bug" is at best an opinion, and opinions are debatable....we need to be conservative in "fixing" a behavior because "it's obviously a bug". There's a whole grid full of content out there, and saying "just rewrite it" every time something is "fixed" is not a viable strategy. ( If your skin is so thin that asking you if you now agreed that this change was a bad idea constitutes personal disparagement, maybe you should take a break from reading comments, as I don't plan to stop writing them.) Ok, and as I have pointed out numerous times, I do not put modifications into the server and never have, so I'm really baffled as to why you single me out on this. In any event, whether or not I agree with you is rather irrelevant to the topic at hand.
Linden Labs does not release formal specs for most of their content. The best we can usually hope for is pseudocode such as the Havok4 push code that I linked to in a related ticket, where they mention that they are enacting changes to try to prevent certain types of pushing such as "orbiting." As for this specific situation, all that happened was that people noticed that there was no limit on llSetLinkPrimitiveParams(), and that in the absence of a limit, the function could be abused and used to create the sort of "orbiting" attacks that LL's own H4 pseudocode mentions as being something that they wished to stop, since such attacks force an individual to relog. Involuntary relogs are generally considered to be unwanted features in any system, so I don't think that this should be difficult to comprehend as to why it was desirable to fix. In any event, Linden Labs chose to implement a fix to the problem by placing limits on llSetLinkPrimitiveParams(), so clearly Linden Labs thinks that the prior behavior was buggy. If the prior, unlimited behavior of llSetLinkPrimitiveParams() was the intended behavior, then why did Linden Labs implement limits on it in 1.23? In any event, your comments are not very helpful to the topic at hand. What actions do you propose that Linden Labs take? It sounds, to me, as though you are simply using the JIRA pages to let off frustration (and taking it out on me for some reason) rather than offer constructive suggestions for how to deal with the situation. So do you want to go back to unbounded llSetLinkPrimitiveParams() calls for avatars? For avatars and prims? Or do you think (as I do) that there is a place where we can set reasonable limits for avatar movement using this function, and it's simply a matter of finding the best way to implement it? In speaking with Andrew, at his office hours of 2 Sept, he'd appearently reset the functionality to H1 levels, but Content Creation happened since, that he's rethinking link distances in general. I don't know if it's soon enough to get this show stopper into 1.25, but I hope it isn't waiting on getting the link distances increased in 1.26
When I first discovered the distances that SLPP could move an avie, it tended to get a bit wonky, between one kilometer and one mile, such that I wouldn't want to move an avatar with any precision beyond that range, but it was working okay for TPs until 1.24. Have we a link to the Forum discussions of Link distances? I've seen something on their limits, but not on their reasons. Any link beyond its sim, will tend to be phantom to the neighboring sims, but Andrew didn't seem to think there was any real limit needed. I wonder if this might be usable in a cross sim telephone system or security scanner. for the moment, we seem to have a show stopper. Maybe 1.25.1 could be asked for, on a sim by sim basis. I was ready to downgrade this issue to Nice To Have, last week, when I found someone else had upgraded to Critical. I don't read Jira well enough, to see who closed this issue but, Call Support was sufficiently off the wall, that it probably was an actual error. There's nothing wrong, with being teleported off sim, since I did plenty when developing this, so I don't know the constraints. It's more elegant than WarpPos, though, and a 4 kilometer horizontal freedom would make it very handy in Burning Life. I confirm that is for me a critical issue as it breaks existing content (sim range teleporters) and I think that :
I hope the <256,256,4096> limit can be restored soon This 'bug' is actually working as designed. In the Havok4 transition a bug was introduced where avatars could be moved to arbitrary distances via llSetLinkPrimitiveParams(). The bug was discovered internally, a misunderstanding was made and the bug was "fixed" to stay within the region boundaries. The original reporter declared it re-open – it should behave like Havok1, and I fixed it properly – forcing the avatar to stay within linkable distance.
Unfortunately the bug became a 'misfeature' since it was out for so long and people found it useful. Meanwhile there is the llSitTarget() feature that can bypass the linkability rules (but only on initial sit – it cannot move the avatar after sit is complete). Perhaps the design needs some review – I'll bring it up with the involved parties internally. Andew Linden,
I have sent you an item called "quantum teleporter - SVC-2931" which demonstrates how increadably usefull this function was. Not to mention efficient and sim friendly. I sold a lot of teleporters based on this, as have other people. I dont know anyone who installed an upgrade system into their teleporters (myself included) so there is no way to send out a replacement. In some cases a replacement is not possible if the prim your sitting on is needed to rez particles and other teleporter type effects. @ALL When you go over the 1km range you do get a funny camera effect very similar to the one you get when a normal sit puts your camera at 0,0,0 for a few moments. It goes away after a couple of seconds when you stand up, however I found scripting the camera movment resolved this issue and lets you focus the players camera onto a location where you might be displaying some cool teleport effect. As per my Quantum Teleporter system. Teleporting over a region border appears to work so long as you do not go more than 96m into the next region. If you go more than that your avatar become nonphysical and unable to move until it sits on a prim. I was in the process of making a workaround for this when they busted the link distance so you couldnt go over the borders. I would vote for a 4096x4096x4096 link distance to avoid any strangeness with rotated prims which we saw in a previous fix, and opens the possibility for teleporting into neighbouring regions. I'm sure I can get that to work. I got WarpPos to do it without pausing on the borders by tricking the simulator into updating the avatars location. It's amazing what side effects other unrelated functions can have on helping someone to connect to a region faster Darling Brody I would also vote for a 4096x4096x4096 link distance. This looks VERY useful..
A cubed distance (i.e., 4096x4096x4096) does seem prudent, as it avoids complications with root rotation. Though I personally don't use, and never would use this particular hack for teleports. The oft requested, and FREQUENTLY voted for llTeleportAgent() is far more appropriate. Not to mentioned promised by Linden Lab years ago...
@Darling Why would you not have a basic updater script in your teleporters? All of the units I make and use have automatic updates, making distributions of fixes like this trivial. My teleporters, Thomas Conover's, OS Labs, Aubretec, Omnicron, etc. All have update scripts. Andrew, this is being reported as being "fixed" in the 1.25 change log. Could we get a comment on how it was received internally by the relevant internal parties?
https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Beta_Server/1.25 The only thing I could find, on this issue, in the above reference was
"## Moving a sitting avatar should follow object link rules " Plainly, when an avatar sits, and is thereby linked, it's possible to link up to 300 meters, in each vector, so this test hasn't been met. There seems to be some internal opinion, objecting to the proper upgrade, but this person seems to wish to remain an undocumented feature. We may need some benchmark tests, to determine which relay this person's opinion is undocumented in. llTeleportAgent() is another thing, that should be done, in the near future, and shouldn't be worse than llTeleportAgentHome(), as far as abuse, but llSetLinkPrimitiveParams is really for the local TPHack, but allowing the avatar to choose after sitting, rather than before. llTeleportAgent is for actually teleports, rather than just sit targets. The existing link rules, of 300 meters to each axis, for an avatar, would have been a compromise, but a kilometer would have been much better, for Black Lag City, and four kilometers would be desirable for the newly permitted builds. Arawn, the link rules limit the max link distance to 54m. 54m is the maximum link distance. If you don't believe me, go try and link together two prims at a distance greater than that. When it is stated that the avatar should follow object link rules, this is what they mean.
300m refers to the maximum distance on each axis for llSitTarget(), which is a completely separate function. Now, if you want the link rules to be changed, that would certainly be a viable suggestion, but it is important to note what the link limits currently are, otherwise you are putting the cart before the horse. I'll have to check out
There's a stark failure to communicate, qualifying as Critical to Show stopper, since Andrew made no mention of this, yesterday, and won't disclose which idiot needs to be petitioned to reverse this madness. This is the sort of thing that Office Hours are meant to prevent. Something here is failing a beta test of Transparency. Why wasn't
Testing the script of Madgeek in one server 1.25.0.101089 in the preview grid. Result: Object: You are currently located at <117.61311, 164.58485, 21.34964>. Attempting to move your position up 70.0m, keeping this root object stationary. Arawn, there is no avatar link distance. The 300m you mention refers to llSitTarget() which is a different function. It's not a question of whether it's possible since obviously the bug that allowed unlimited movement with llSetLinkPrimitiveParams() showed that it's possible. The question is what execution of the function works best. Please keep in mind the fact that llSetLinkPrimitiveParams() is a very complex function that deals with a lot more than just avatar movement. The function is designed for changing various parameters of child prims in a linkset, including PRIM_POSITION. As an avatar is treated like a child prim in a linkset, and in fact is given a link number just like any other child prim, this function will allow certain actions, such as changing PRIM_POSITION to work on a seated avatar. Please see my comments re:
I noticed an improvement. Although the maximum distance is 54 meters, now works with objects with more than 1 prim. Server 1.25.5.109327 Changed from the Bug, which broke existing content, to a New Feature, but Critical Status should be retained, as existing content remains broken.
I am pretty sure Andrew Linden considers this issue closed as he did agree to restore the 54m when it was lowered to prim link distance in another JIRA.
However I agree that this function should match the 300m of a sit target, if for no other reason, so a avatar can be placed back on the original sit target after being moved. from a function point of view it would permit teleproters to deliver the avatar anywhere in the region without needing to worry about land permissions as 300 is enough to move horizontally over the surface of the region, while the prim can move up and down to the correct height. Such a feature would let you teleport between parcels even if there is a parcel in the way with ban lines. (note that this function has never let you teleport into the parcel with ban lines, it only let you get to the other side) Darling Brody |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Reopened
Critical
llSetLinkPrimitiveParams content breakage, only moves agents 54 meters now
