[1 second Orb timing, is it necessary]

was just thinking about which orb maker could lead this effort if was to be done

and I think Them Mole who makes the orb for Bellissaria could take the lead on it. Set a good example for every else who makes orbs

Them Mole what scripts that device who might read this, will probably go nuuuu! we got 1000s of orbs in place already !! You know how much work we would have to do to replace them all !!  And I will say to them, are you Crying Mole or are you Leader Mole. You look like Leader Mole to me, even if the thought of this makes you cry 😸

[1 second Orb timing, is it necessary]

6 minutes ago, Wulfie Reanimator said:

@Mollymews The orb wouldn't need to send any specific info, you can get the position of the orb based on its key (which you have in the listen event). And I'm pretty sure viewers support negative chat messages these days, but I digress.

i never knew that about negative channel chat messages echoing in the viewer text console display. I mostly use the Linden viewer so I dunno much about what TPVs can do. I will have a play with the Linden viewer just to see, even tho am pretty sure that the Linden viewer only echoes console messages received on channel 0

a thing about the orb. It has to send something for the traveler hud to receive a message in its listen event, so I think might as well be the location

[1 second Orb timing, is it necessary]

2 minutes ago, Gabriele Graves said:

Could be done as a gesture with a hot key too and then anyone can use and easily not just the HUD wearers which increases the universality of it.  Though I think I would prefer an llInstantMessage() if I pinged and not use region say back.  It all depends on the rate on pings I suppose.

gesture is a really good suggestion and I think would be quite useful to many travelers who are just moving themselves without a vehicle

like if walking along the road and think to go onto a parcel by the roadside. Play the gesture and we get told in chat or IM if there is an orb on the parcel

so we decided in our design that the ping channel is best to be a positive number

[1 second Orb timing, is it necessary]

1 minute ago, Gabriele Graves said:

Yeah, I was actually thinking of just getting the orb to IM the avatar who pinged with a humanly readable message instead but of course you would have to have a HUD to ping in the first place, so yeah.

we getting into the deep of writing a traveler friendly orb. Which is pretty interesting to me to do

so yes, this could be an option if the publicly known ping channel was a positive number. A person could manually send a ping. Example: /1886 ping

and get a llRegionSayTo response on channel 0: The response being. OrbName: <x,y,z> Name of parcel

this could be an extension that an orb maker could provide.  In the orb listen event then we can determine the type of sender (key id).  If ping sender is agent respond RegionSayTo on channel 0 (show in sender's chat window). If is an object respond on channel -1887

example is to use llGetDisplayName(id) as a filter in the listen event.  If the function returns empty string then sender key id is an object, else is an agent

 

[1 second Orb timing, is it necessary]

9 minutes ago, Gabriele Graves said:

Could maybe put the parcel name in the response message in that case.

is enough I think for the orb maker to just send the location. The parcel owner (by virtue of the orb maker) is providing the traveler with the most important piece of information

when our orb gives its region location, then the traveler hud can get all of the parcel's details for the location when this is of interest to the traveler. https://wiki.secondlife.com/wiki/LlGetParcelDetails

the onus should I think, be on the traveler (hud script) to fetch the more detailed information if this is what they want. And shouldn't be an expectation on the parcel owner/orb maker to try to decide what the traveler does or doesn't want to know

 

[1 second Orb timing, is it necessary]

1 hour ago, Gabriele Graves said:

The only problem I can foresee with this is that we cannot know the orb's area of influence and so it limits it's usefulness especially as often orbs can be anywhere on the parcel and so knowing it's location may not be that useful.

as a traveler it would always be best to work on the assumption that an orb operates on the whole parcel all the way up

when we start getting into an orb's range (area of influence) then we shouldn't rely on the orb's response always being correct. The only thing we can be sure of is that we received a location for the ping. Which we can interpret as an advice to give the location a wide berth on the X and Y (go around the parcel)

is possible too that when we ping, there isn't an actual eject method in place - is just a signal/sign saying please stay off my lawn.

the idea is to give travelers a way to get a forewarning, on which they can act beforehand

[Can I temporily stop "derender" in a region.]

12 hours ago, BookishMelinoe said:

I've noticed a few stores lately have hunt objects that name themselves randomly after other items in the area

another one for hunt providers, is to change the positions of the hunt items on some random cycle

[Getting premium without a credit card?]

best to talk with Paypal Support about this.  They will guide you thru what is required from you to enable your Paypal account to function as you want

[1 second Orb timing, is it necessary]

in a previous conversation on here, we talked about orbs that could announce their position when pinged. I just repeat the conversation topic  here for those who make orbs as something to consider

the orb and traveler scripts could communicate on a pair of publicly known channels. First channel to ping, second channel for response

-1886 is the publicly known ping channel. -1887 is the publicly known response channel

example code

// orb

llListen(-1886, "", NULL_KEY, "ping"); // listen only for "ping"
 
listen(integer channel, string name, key id, string message)
{
   if (channel == -1886)
   {
      // we have a "ping" from key id, so respond to the requestor with our location
      llRegionSayTo(id, -1887, (string)llGetPos());
      return;
   }

   ... do other orb listen stuff here ...
}

// traveler HUD, automated ping on region change

llListen(-1887, "", NULL_KEY, "")

changed (integer change)
{
   if (change & CHANGED_REGION)
   {
      llRegionSay(-1886, "ping");
   }
}

listen(integer channel, string name, key id, string message)
{
   if (channel == -1887)
   {
      llOwnerSay("Orb at: " + message);
      return;
   }

   .. do other hud listen stuff here ...
}

all it takes to get this kind of thing started is for a commercial orb maker to start doing it, and to say what the channels are. Other people will follow along and start using the same channels also

ps. As a traveler we don't need the response to be overly informative. We just need to know the position of the orb on the region. We can ourselves work out from this, which region parcels/areas to stay away from

 

[1 second Orb timing, is it necessary]

if I use a LM to go some place and turns out to be old and I get kicked out by a orb because new owner, then I don't mind

sometimes I find that this can be better than me wasting my time, wandering round thinking is the old place with a new rebuild, trying to find the vendor which isn't there anymore

 

 

[1 second Orb timing, is it necessary]

3 hours ago, Rowan Amore said:

I've seen several parcels.for sale in the Land section.  Water parcels with NO actual land.  And people wonder why when sailing along what you think is OPEN water, you run into ban lines or orbs.  NOT a resident issue but bad marketing practice by LL.

i think most sailors, like travelers generally, know to use maps and charts when travelling

i think Linden could help resolve this issue by asking Catznip to make a code submission for their minimap to go in the Linden viewer

[1 second Orb timing, is it necessary]

13 hours ago, Love Zhaoying said:

Hmm..since parcels are never round, wouldn't it make sense for certain llFunction() calls, and thereby "orbs", to only work within the actual boundary given by the (shape of the) parcels?

some of the extended orb systems allow the user to set up multiple exclusion zones. Like separate rooms in a building for example

 

for the curious, the basic function for knowing when a point is inside a rectangular box goes something like

integer IsInBox(vector pos, vector bpos, vector bsize)
{  // return TRUE when pos is in box. Box at position: bpos, and box is of size: bsize
   bsize *= 0.5; // half the size dimensions for the calculation
   return
     (pos.x >= (bpos.x - bsize.x)) &
     (pos.x <= (bpos.x + bsize.x)) &
     (pos.y >= (bpos.y - bsize.y)) &
     (pos.y <= (bpos.y + bsize.y)) &
     (pos.z >= (bpos.z - bsize.z)) &
     (pos.z <= (bpos.z + bsize.z));
}

 

edit add. What Phil said

[1 second Orb timing, is it necessary]

9 hours ago, Codex Alpha said:

Not one solid argument has been made as to why 15 seconds or more is not enough to attain their privacy or to secure their belongings, or stop someone sitting on their sofa.

the arguments have been made and they are solid

argument 1).  I am on my pose stand in my changing room in my home trying on skins, bodies and adult parts.  Some rando comes in. I have 3 choices. 1) Don't care and do nothing. 2) Do kinda care and kick them out in 15 seconds. 3) Do care and kick them out immediately. Many people go with option 3) Do care

argument 2). I am with my partner and we are having a snuggle in our bed in our bedroom in our home.  Some rando comes in. We have 3 choices. 1) Don't care and do nothing. 2) Do kinda care and kick them out in 15 seconds. 3) Do care and kick them out immediately. Many people go with option 3) Do care

to say that there is not a solid argument for option 3) suggests that we don't care that the home owner does cares about their privacy in their own home. And that their caring about themselves in their own homes, should be overridden by the system to better serve the interests of the rando

[1 second Orb timing, is it necessary]

5 minutes ago, Ardy Lay said:

The first "security orb" was a scripted device that used physics to "orbit" an avatar.  Residents didn't have any control over land at the time.  The device wasn't named "orb" for being a sphere.

then Luc Aubret invented the blitzer and the world was never the same again

[1 second Orb timing, is it necessary]

1 minute ago, Phil Deakins said:

I don't think there is a suitable alternative method of doing that.

yes is the most suitable way to be sure that we are within our boundary

a less suitable way which can be done when we understand where our parcel boundaries are and our parcel is a regular shape, is that we know where our parcel center point is. So we can rez a prim in the sky, set its XY to the centerpoint then set the size. But yes we do have to know what the center point is to do this and is best done when we know exactly what that is

[1 second Orb timing, is it necessary]

17 minutes ago, Love Zhaoying said:

Always seemed to be a humorous way of doing things! (Sit on the thing, and change its height.)

 

i still do this today when i want to go way up and I haven't got any LM.  Still do as well when putting up a sky platform. Rez the prim(s) on the ground, fit to the parcel boundary. Sit and change the Z. woosh!

[1 second Orb timing, is it necessary]

9 minutes ago, Love Zhaoying said:

Nope, it just allowed you to fly above the "maximum" height, and also to fly faster than normal.

i can't remember now exactly but am pretty sure Flight Feather and the other flight assists got invented because we could only fly ourselves up to 256.  To go higher without a flight assist we had to use a warp teleporter, or sit a box and set Z to 256 or more. Once we got up there, we could set a LM tho and be able to teleport to there using the LM

[1 second Orb timing, is it necessary]

2 minutes ago, Love Zhaoying said:

I remember you could only fly above a certain height with a "flight feather" or similar gadget (flight assist) - is that still true now?

not now. we can fly up without any assist since about 2012

[1 second Orb timing, is it necessary]

12 minutes ago, Phil Deakins said:

Correction: in those days the sky ceiling was 768m

 

yes you are right. I got it mixed up with the clouds that were at about 256, but then I could be misremembering that height as well

[llGiveInventory() Reliability]

39 minutes ago, agentronin said:

Should the JIRA include source code for the script I am using to do the sends?

yes.  Is always best to be able to JIRA a way to reproduce the problem

[1 second Orb timing, is it necessary]

3 minutes ago, Coffee Pancake said:

I remember the problem and at the time .. the Linden solution was passable.

What we need now is the region to send a complete list of all the parcels on a region (and neighboring regions) that informs the viewer about where the user can access and where they can't. Even just a raw matrix made from 4m squares that the region updates as and when parcels are redefined changed would be awesome.

I would also like to see parcel access controls improved to allow better access and avatar visibility much like we have for EEP now with multiple height based zones.

The cherry on top would be prohibiting sub letting of mainland.

definitely I agree this would be the best way to go when I am the traveler

i just wonder if Linden mightn't rule it out because of the time needed to search every parcel banlist for an avatar when it arrives on a region

with view distance then it might lessen the load on the region(s) server overall. Dunno tho exactly as only Linden would be able to assess the difference between the two. And if there was a measurable delay then a person with a long view distance could be considered to be lagging themselves if the difference was significant

[1 second Orb timing, is it necessary]

21 minutes ago, Gabriele Graves said:

However if it is designed as a way to allow enforce the "explorers" option then it will not be appreciated regardless for the reasons I've gone over a few times lol
If it were to be created then I would imagine that current zero-second orbs users who use skyboxes would love it but still want to keep their orbs to stop others traversing their space.

I can imagine the can of worms it opens though perhaps that is why it hasn't gone anywhere.
 

yes I tend to agree with this assessment. Trying to retrofit new things into a pre-existing social order is quite fraught

maybe Linden could think about it, when they start designing the Premium Plus parcel/region offerings. Which I am pretty sure will be on their own estate when they come

[1 second Orb timing, is it necessary]

1 minute ago, Coffee Pancake said:

Banline visibility was broken in 2007

Rather than add viewer side controls to allow users to show or hide banlines as needed for whatever they were doing at the time, LL did the cheapest simplest option and fudged when regions informed the viewer of the nearest (and only the nearest) neighboring parcel with an access restrictions

 

to be fair to Jack Linden, he asked a question as the then Boss of Mainland on the forums.  The question: If there was one thing we (Linden) could do right now fro mainlanders which won't cost us (Linden) a lot money then what would it be

and the forum mainlanders said: A way in the viewer to turn off the neighbours red tape.   SO thats what Linden did

in those days there were heaps and heaps of people with 512m parcels, including me. When stood in the middle of our parcel, the red tape was visible on all sides (including the long ends - 16 meters away). Linden, in addition to putting in the visibility switch, changed the tape color to yellow and reduced the distance to about 10 meters.  And I am pretty sure they (Linden) only reduced the distance. I don't remember exactly what the distance was, but I think it was tied to camera View Distance.  Any banline info within View Distance used to be sent to the viewer

so agree, in this sense Linden broke Banline visibility. And maybe thats all Linden have to do, to fix it for travelers in a simple way.  Restore banline distance visibility to View Distance.  The greater our view distance the sooner we can see banlines when Banline Visibility is on

[1 second Orb timing, is it necessary]

7 minutes ago, HeathcliffMontague said:

I've experienced, pretty sure it was on Route 4, banlines actually stretching out into the road once

this is true on some of the pre-LDPW built roads.  Some of the early-days Linden road builders never used boundary markers on the angles and bends. So some road builds encroach on the neighbouring parcels. One day some day maybe when they get time, LPDW will straighten them out

[1 second Orb timing, is it necessary]

18 hours ago, Gabriele Graves said:

I think though the proposal still operates under a couple of misconceptions.

1. That is it the build they want to hide rather than their own presence.

I would be willing to bet that most people who use zero-second orbs don't care that others can cam around their build, they don't actually want to hide it that much.  They would more want to hide their own presence completely while they are on their land which means no mini-map dot, not radar ability, etc.  This is not even being explored in this discussion but is a very important aspect of privacy.

2. That they would be happy with others being on/passing through through their space if everything was hidden from others.
 

this idea goes all the way back to 2007 about, when Parcel Banline visibility was raised. In those days Banlines were red tape and we couldn't hide them in the viewer

Jack Linden decided that they would go with Banline visibilty as a place to start

at that time tho, people like Argent Stonecutter and Ciaran Laval raised the idea that a closed layer could be done at the top of the sky divided by parcel (a true skybox). In those days the sky ceiling was 256m and would work just as well if not better with 4096m sky ceiling

the idea was as described here.  Nothing inside the parcel skybox is visible from outside, nothing outside the skybox is visible from inside. Nothing includes everything. Avatars, objects, green dots, camera, and script functions return NULL object/agent not found. Same with scripts inside the box.  Try to scan the neighbourhood with a script while inside the skybox then NULL. Cam beyond the parcel skybox boundary then see nothing, not even anything below the skybox on the parcel. Nothing outside the skybox is sent to the viewer

is still a good idea I think. For those who want a total private space, but can't afford to have a whole region

i can't remember now what year it was but Penny Patton raised this idea again, and I can't remember either which Linden it was, but they did report that they did run some quick tests doing this. It never came to anything then, but is still hope that it might happen one day