At the moment I'm working away on building the new range of Z&A RLV cells while retiring the old ones. Given that they all contain the same script engine there's not a lot of scripting to be doing with that. Sure, there's the odd cell-specific plugin to write here and there but generally nothing I'd call "fun". The bulk of the work is prim-flinging and meshing, something I really enjoy, but it's not scripting, which I really enjoy.
A few days back, when I suddenly couldn't fling prims around so well, I did what I often do in that situation: I rezzed out a cube, got cosy with it and started scripting. This time the idea was to finally do a complete re-write of another early Z&A product to make it better and different. One of the RLV API features it makes use of is the @sit command. While working on that bit of code I decided to have a play and see just how far away (on a region) an object can be before the force sit fails.
[Caution, vague non-technical terms follow]
Keep in mind, at this point, that objects exist in two places in SL. They exist on the server and so exist as things that can be seen by scripts (because scripts live and run server-side). They also exist client-side in the sense that there's a list of "stuff" your viewer knows exists at any given time. Hence the reason why it's always suggested that people have sensible draw distances otherwise you end up potentially wasting a lot of memory and bandwidth loading up lots of objects and textures and the like that you can't really "see".
In the script I was toying with I check that any given object that is a potential sit target actually exists. Of course, the object my script is in and the object I'm verifying might be a few thousand meters apart but the script can still get information about it. RLV, on the other hand, being a body of code that exists only in the viewer, can presumably only ever deal with objects known to the viewer at any given time. Given these facts I sort of assumed that @sit might fail for objects not in draw distance.
Turns out it's a little more complex than that.
Having satisfied my curiosity that things near (the avatar/camera) can be @sit targets and things a long way away can't be (in my case a handful of things in the workshop, where I was stood, vs a chair in Mistress' house, which is about 2km away from the workshop) I got on with writing the code.
Yesterday, while doing some testing, I noticed a very curious thing. One of the target objects, which was near me (and well within my draw distance, about 33m away from where I'd have been stood when the @sit request was sent), just wasn't working. Or, more to the point, the @sit request was coming back as "ok" from my relay but I wasn't being sat.
After double-checking the code I then turned on RLVa debug messages in Firestorm and saw messages like this:
Antony's Collar: failed: @sit:{uuid}=force (invalid option)(where {uuid} was the UUID of the object, of course). Now, the object in question wasn't in my direct line of sight; it was obscured by a floor and a wall. But, like I say, it was just 33m away from me. Unsure what was going on I cammed out to it, grabbed the UUID of it again and double-checked and, sure enough, it was the right UUID. I tested again and it worked without me having changed anything in the code!
This is the point at which I started to suspect that it might be related to Project Interesting. I won't claim to know anything about how PI works other than what has been mentioned at a high level, but one thing I seem to recall reading is that it tries to do a good job of only loading/holding details of objects you can actually see. So an unobscured object in a scene, that's on the very edge of your draw distance, will be known to the viewer. On the other hand an object close by but obscured by other things won't be.
I guess you can see where my thinking was going at this point: like I said, the problem object, although only 33m away, was obscured by a floor and a wall from my location.
So, to test this idea (that it was about things being obscured, not that it's PI directly to blame), I made a little test rig on the platform outside the workshop. First I made a 3-prim object like this:
The blue bar is the root and is called "Force Sit". The two arrows are named with the UUID of two objects 23m either side of the object. Inside the root is the following code:
The idea is simple: stand at the arrows and click an arrow to be force sat on the object that's in that direction. The difference between the two objects is that one of them is in the clear while the other is obscured:
by two hollowed out cubes, one inside the other:
Initial testing never had a failure. But, I'm guessing, my viewer would "know" about the target object even when obscured and wouldn't bother dumping the data when it was fairly close by. Even heading down to the ground, walking about, and coming back up didn't make a difference. It all still just worked.
So I decided to leave it alone, all sat outside the workshop, and test it again the next time I logged in. Which I did this morning.
I got into the workshop, walked out onto the platform, detached my camera from my avatar using flycam so that my camera would stay about 38m from the arrows and about 45m from each of the target objects, and did the test.
First I touched the green arrow, which would attempt to force sit me on the object that I could see. That worked just fine.
Next I touched the red arrow, which would attempt to force sit me on the object that I couldn't see as it was inside the boxes. Nothing. I didn't move. One again I turned on RLVa debug messages and, sure enough...
Antony's Collar: failed: @sit:{uuid}=force (invalid option)I then raised my camera and tilted it down a little until I could almost, but not quite, see the target object:
It still failed. I then raised and tilted a little more until just one corner of the object was visible:
...and this time the test worked. I was force sat on the object inside the box.
That seemed to pretty clearly demonstrate it: object distance from your avatar, or your camera position, isn't the only thing that will affect how a @sit works -- it's also about if the object in question is obscured.
Keep in mind too, as mentioned above, that a relay will still reply that the operation worked "ok", but the avatar won't be sat and internally the sit will be seen as a failure (something that can of course be overcome by use of @getsitid).
The point of all of this? Well, like I said at the start, there's no actual conclusion to this; I just felt the need to document a curious problem that I'd run into and how I looked into it and what I found. It feels like it's something related to what Project Interesting has done although, of course, I'm not sure. I've also not tested this (so far) with any viewer other than Firestorm 4.6.9.
What I do know is that, if and when this code becomes a released product, this effect is something I might need to note in the documentation. People might see the product work fine on some victims but not on others and there'll be no obvious reason why this is the case.
No comments:
Post a Comment