Jump to content

Has anyone made a better version of random portal script?


Prokofy Neva
 Share

You are about to reply to a thread that has been inactive for 3186 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

// Creator: Yumi Marikami
// More awkward than it needs to be because of LL's instance that the mapdest call must be // directly in touchstart integer destok = FALSE; vector dest; key last_ds_req; readyDest() { destok = FALSE; integer count = llGetInventoryNumber(INVENTORY_LANDMARK); if (count == 0) return; integer which = (integer)llFrand(count); llSay(0,"Which is " + (string)which); last_ds_req = llRequestInventoryData(llGetInventoryName(INVENTORY_LANDMARK,which)); } default { state_entry() { llAllowInventoryDrop(TRUE); readyDest(); } on_rez(integer junk) { llResetScript(); } dataserver(key id, string data) { if (id == last_ds_req) { dest = (vector)data; destok = TRUE; } } changed(integer a) { if(a & (CHANGED_INVENTORY | CHANGED_ALLOWED_DROP)) { integer count = llGetInventoryNumber(INVENTORY_ALL); integer t; for (t=0; t<count; t++) { string itemname = llGetInventoryName(INVENTORY_ALL,t); integer itemtype = llGetInventoryType(itemname); if (itemtype != INVENTORY_LANDMARK) { if (itemtype != INVENTORY_SCRIPT) { llRemoveInventory(itemname); llSay(0,"Invalid item '" + itemname + "' removed."); } } } readyDest(); } } touch_start(integer junk) { if (!destok) return; llMapDestination(llGetRegionName(),dest,dest); readyDest(); } }
Link to comment
Share on other sites

This originally worked fine on one click.

You load a prim with landmarks and it selects them at random and when you click, you are teleported to that location.

Then it stopped working and needed double clicks.

Then it only worked if you took it into inventory and put it out again.

Now it rarely works at all. Maybe it's buffering. But I don't get the issue.

I know there was something precious the old Lindens had about the map and this author indicates that in the "more awkward than it needs to be."

Perhaps there has been progress.

Link to comment
Share on other sites

It looks like it ought to work just fine, although you shouldn't normally need the changed event unless you expect other people to be dropping things into the device.  All you really need are the touch_start event, the dataserver event, and that user-defined function.  The limitation that the original scripter was referring to is a limitation of llMapDestination.  That means you automatically have to make two clicks to TP -- one to activate llMapDestination and one to teleport from the open map view.

There is a much better way to do things, using llTeleportAgent, but that's only practical if you are either using it to teleport only the object's owner or if you are using it within an experience.

Link to comment
Share on other sites

Trying to come up with a way for it to fail on some touches, I wonder if maybe there's no dataserver event triggered when llRequestInventoryData() is called on a defunct landmark. That would leave destok FALSE so it wouldn't do anything when touched until the random selection turned up a valid landmark.

I agree that an Experience would be a good one-click solution here, although two clicks may be good in this case: seeing the random destination on a map before choosing to go ahead with the teleport seems preferable, especially because llAllowInventoryDrop lets anybody add their landmarks -- which is unusual.

Link to comment
Share on other sites

That's a really good possibility, Qie.  As far as I know, there's no way to intercept a message that the teleport desitnation no longer exists, so that would almost certainly make the script fail.

I can't imagine why anyone would design a system like this that allows people to drop random LMs into it, unless they were confident that only a small cadre of authorized people were going to do it.  If that were the case, though, they wouldn't need CHANGED_INVENTORY_DROP if they simply set the object to share with a group.

Link to comment
Share on other sites

Hi, I should have explained that in fact I *do* need other avatars to drag their landmarks into it.

That's the whole point of this object -- you get a community of people sharing different "finds" or just the general public dropping in things they find of value. You can cull it out occasionally when it fills up with spam but generally it works, people tend not to spam it but to put in sites they find valuable.

Yes, I understand the "two clicks" -- one to activate map and one to teleport. I don't know why that "has to be" if now there are one-click teleporters within sims, instead of the old way of right-click/teleport in two steps but I guess the hiearchy of the world map versus the local location is a factor.

In any event, when I said before it "worked with one click" I'm saying it worked with one click *to bring up the map*. After that, there was a second click to teleport. That gave the user a chance to visually see if he was going to land in the water or something.

But now it doesn't even get  you to the map in two clicks. Maybe this is lag on the sim or buffering but all in all it just works worse than it did.

And no, the point of this object isn't just to teleport the owner, but the public at large, anyone who clicks on it

Link to comment
Share on other sites

Yeesh, are you guys now referring to any old thing in SL as an Experience and not just this new super-thingie called Experience? Lord save us.

I wonder if the issue is indeed the defunct landmarks. This is a chronic problem of course because sites constantly go out of date, sometimes within months. And maybe if the objects just stores up too many of those it repeatedly fails.

So the one object I use it in is called International Bazaar where I stuff it with all the landmarks of RL country or language sims. So I guess because a lot of those have fallen out, that explains the failure.

Also I have to say, before what it did with that occurrence is that it just stalled at the map level. Now it won't even take you to the map level.

Allow inventory drop is precisely the way this was made. That was how I requested that it be made by this scripter in fact. I wanted the ability of people in the public land preserve to share landmarks and explore, or in various other settings or groups, say, stores with sales or whatever.

Like most things that people fear on the Mainland and in open groups, it really isn't the havoc imaged. Over the years I've only found a few people trying to spam it with sales or griefer sandboxes.

Finally, I don't mind if it has two clicks on general, i.e. one to pull up the map, then a pause to see where it is going, i.e. so you don't land in a hostile area. But two clicks to get to the map or two clicks and fail, that's the issue right now.

Link to comment
Share on other sites

Do you know how many landmarks are already inside it? I am wondering if it is churning away processing a mass of items each time a changed event occurs.

 

To save you having to laboriously count them all, you could add a line to the readyDest() function to set the prim's hovertext to do it for you;

 

readyDest() {    destok = FALSE;     integer count = llGetInventoryNumber(INVENTORY_LANDMARK);// suggest adding the following line for monitoring content level    llSetText("Containing " + (string) count + " landmarks", <1.0, 1.0, 1.0>, 1.0);    if (count == 0) return;    integer which = (integer)llFrand(count);    llSay(0,"Which is " + (string)which);        last_ds_req = llRequestInventoryData(llGetInventoryName(INVENTORY_LANDMARK,which));}

 

I suspect Qie is right and that it is getting thrown by non-existent LMs. Since there is already a diagnostic line in there chatting the random number out on channel 0, it might be worth adding some lines inside the dataserver event to see what happens each time it gets triggered.

 

I have noticed in the cinema slideshows I created that when there are several dozen textures inside a prim the contents take a long time to show in the build floater, and likewise editing the scripts in them can sometimes take a long time to get the text up. In some extreme cases I wasn't able to actually edit the script until I had right-clicked the content line for it and set it non-running.

Link to comment
Share on other sites


Prokofy Neva wrote:

Yeesh, are you guys now referring to any old thing in SL as an Experience and not just this new super-thingie called Experience? Lord save us.
[ .... ]


No, an Experience is an Experience. That's what we both meant.  It has a very specific meaning these days.

I'm skeptical about the number of LMs in your device being the problem. Each time you call a dataserver event with llRequestInventoryData, there's an automatic delay of 1.0 seconds (see http://wiki.secondlife.com/wiki/LlRequestInventoryData), but this script is only calling the event once each time you click it.  The rest of the script is doing things that should be done in an imperceptably short time.  I think it's more likely that Qie is right.  All it would take is one bad LM to stall the whole thing and force you to reset it.

Link to comment
Share on other sites


Prokofy Neva wrote:

Yeesh, are you guys now referring to any old thing in SL as an Experience and not just this new super-thingie called Experience? Lord save us.

It's rather that the Experience tools are a non-obvious collection of features, and each piece is useful -- but requires that a corresponding Experience be enabled on the parcel where the script will run.

In the above discussion, the functionality is full-fledged llTeleportAgent(), which could port an Experience-participating avatar to the destination with a single touch (or even without a touch; my telepad domes, for example, teleport depending on which direction you walk off the pad).

Another Experience function, the persistent store of Key-Value Pairs, is useful without any scary-looking permissions. The associated Experience must nonetheless be enabled for the KVP-using script to work on a parcel, so scripters are apt to continue saying "Experience" when talking about such scripts, even though the end-user has no idea there's any Experience stuff involved.

Link to comment
Share on other sites

I know y'all want to chew the fat about experience, but....

I had a think about the OP's script issues and read up a bit, and have found a couple of things.

First, regarding the llMapDestination call, a wiki caveat is

  • if called from touch, it may only work for the first or last touch in the event queue (example: num_touched > 1)

 

In the script, it is being called inside a touch_start event where the number of touches (junk) is being ignored. This suggests it should instead be called from within a touch_end event, and the test should be made for the number of touches being either 1, or if greater, only the last toucher should be processed.

Further to this, and again, coming back to the timings, I see two more potential problems,

llMapDestination causes the script to sleep for 1 second.

Before the touch_end event has completed, readyDest will be called, which will raise a dataserver event, and  ( from the wiki) However, be aware that further dataserver events cannot be received until the event that sent the request has been completed.

So, if a second touch is made before the dataserver call resulting from the first touch has been completed, the second touch might not trigger a dataserver event because the first touch event won't complete until the dataserver event completes.

With the inherent 1-second delay I see a prime case for repeated clicks being lost, and hence the perception that the OP has to double-click to get the thing to work. It looks to me as if this is a sim-loading issue catching out a script that would previously run happily when things weren't quite so busy.

 

So my suggestion is, switch to using touch_end, use the event variable recording how many touches there were and only process the first or last, set a 1.2 second timer before calling the llMapFunction, and move the call to ReadtDest to get the next random landmark into the timer event. As a safgeguard, instead of the return statemnent at the top of the touch event, I think I would have a global set to false if a previous touch event is still being processed which the dataserve event then clears, and if this variable is false when touched, whisper to the user that a request is still in progress, please try again later.

 ETA

The dataserver event never even returns a key for a non-existent LM, it just hung there, so I moved the call to readyDest back, and set the timer going just before calling requestInventorydata. Testing shoswed that even after 30 seconds there was no key issued, if an LM doesn't exist you might as well give up after 0.5 seconds and try for another one. I could find no documentation backing up the original script claim that the call had to be in a touch_start, it worked fine inside a touch_end.

 

I've sent a notecard with my script revisions to the OP for them to trial it.

 

 

 

Link to comment
Share on other sites

Hi,

As I mentioned to you in-world, it works great, thanks so much!

It works on the keg filled with numerous "dead" landmarks -- it just says "invalid" when the map is pulled up and moves on without fussing and stalling.

To be sure, it keeps chattering for awhile with messages but that doesn't matter.

The point is you can click, re-click, click again past the duds to the live ones and get on your way to a good destination.

It also works great with a brand-clean keg of new workable landmarks. And works to have any member of the public add their landmark to the list, I've tested with alts including those not in the group. This is "as intended" and not the zoo you might think. Yes, it piles up and some of them get dead or you get a spam  or two but it's manageable.

If anyone wants one of these, IM me inworld. It is for sale on the Marketplace (the current version will be replaced) and inworld for $20 or $25 depending on location, with the proceeds going to cover the tier of the SL Public Land Preserve. Originally the script and the object were commissioned projects but that was years ago. The script is on all perms so it's been made public.

Please let me know how you would like to be credited on the script and how to do that.

Link to comment
Share on other sites

Re: It's rather that the Experience tools are a non-obvious collection of features, and each piece is useful -- but requires that a corresponding Experience be enabled on the parcel where the script will run.

 

But are you saying that the "non-obvious collection of features" now captured for "The Experience" are just "the way Second Life used to work and do things?" That does sound like the script is being rewritten, figuratively if not literally.

Teleport agent is essentially a sit hack, no? Didn't it start out as only a hack of sit? Which is why you could only get very old scripts to go 300 meters. Nowadays they have them to 4,000 so it has advanced I guess.

Even so, cross-sim teleporters can't be one-touch, correct? Due to the intervening map? Or? Maybe they exist, haven't bought them.

And the other advance is that before, you used to have to right click on the object, look for the word TELEPORT on the object's menu, then click again.

There was no one-click teleport until in recent years which I still find disconcerting as an oldbie. I do think a pause before a teleportation is a good psychological factor. When the map is involved ,it's very important so that you don't see you are being  unwittingly taken into a combat zone or a griefer sandbox or just the open sea. The map should mean something.

Of course none of this will exist or matter in the new dispensation where there will be no geographical contiguity and -- wait for it -- no map, either. How can you have a map when there are holes everywhere from the "not always on demand" sims? Even if people "link up" on the user end like Caledon and Winterfell, if X sims within those systems are not runinng "hot" -- no sense to have a map, right? What service will want to render you a map full of holes or things that might be there? That is permanently in the state of a rolling update?

Instead, there will be lists with pictures, as there has been in Kitely, or in the old project by Raph Koster which actually was a great little virtual world because it was a farming game but with interactivity and user content. But no contiguity or map.

I really do think that as much as some geeks are happy to overthrow thousands of years of real-life human experience making maps and navigating, this won't go over so well and user behavior -- emergent behavior, if you will -- will override this.

Of course in the new world, you need one-touch teleportation because *there is no map*. You just want to go through the Croquet rabbit hole or worm hole.

Yes, I realize the key value pairs can be used for vendors or whatever and this is Experience even though not "a thing" to see.

Link to comment
Share on other sites

With experience tools, when you join the experience, you give permission to all scripts set to that experience to do various things to you -- animate your avatar, teleport you, attach objects to you and so on -- without their having to ask further permissions.

So certainly people should ask themselves if they trust the owner of any particular experience.   I'd think you'd be at an advantage here, Prok, because you're well-known and, while people may disagree with your views at times, I don't think anyone's going to be worried that you'll be trying to grief them with your experience.

This, I assume, one reason why LL are allowing only people with premium accounts to own experiences.

Anyway, once they've given granted overall permission to the experience to which the portal gates are set, any set of gates will be able to teleport people to any accessible location on the grid that the gate has stored.   You simply walk into the gate and, with no further ado, your screen goes black and whoosh, you're teleported, just as if you'd teleported using a landmark or accepted a tp invitation from a friend or been God-teleported by a Linden.

I've made a teleporter system that uses this for the Freedom Continent estate, if you want to take a look.   If you to the main Adult Hub region and go downstairs from the main arrivals point, you find yourself in a big room with lots of doors.   These teleport you to various locations on the 20~something regions that comprise the estate.

Link to comment
Share on other sites


Prokofy Neva wrote:

Teleport agent is essentially a sit hack, no? Didn't it start out as only a hack of sit? Which is why you could only get very old scripts to go 300 meters. Nowadays they have them to 4,000 so it has advanced I guess.

That is correct. Those in-sim "teleporters" don't use any teleporter functions at all. You sit on it, it jumps to the destination, throws you off (err... I mean unsits you) then it hurries back home pretending it never moved at all. That's the basic principle anyway. Some use a poseball that vanishes into thin air after moving you, some short range ones simply use an extremely offset sit position and I think some old ones actually pushed you off to your destination (give or take a few meters).


Prokofy Neva wrote:

But are you saying that the "non-obvious collection of features" now captured for "The Experience" are just "the way Second Life used to work and do things?" That does sound like the script is being rewritten, figuratively if not literally.

A digression perhaps but the earliest version of what we call an "Experience Key" today was introduced more than five years ago with the Pyri Peaks Fun Fair where it's disguised as a ticket to the Tunnel of Love. In 2011 they had developed a more advanced version and launched the Linden Realms to beta test it. It was also used in the Magellan hunt and probably was an integrated part of the walk-through-to-tp portals at the newcomer areas. So it's hardly a new invention in itself, it's just that they didn't make it publicly available until recently.

Link to comment
Share on other sites


Prokofy Neva wrote:

Teleport agent is essentially a sit hack, no? Didn't it start out as only a hack of sit? Which is why you could only get very old scripts to go 300 meters. Nowadays they have them to 4,000 so it has advanced I guess.

Even so, cross-sim teleporters can't be one-touch, correct? Due to the intervening map? Or? Maybe they exist, haven't bought them.

There are several ways to move avatars in "teleport" style, but in recent years a specific function, llTeleportAgent, has started working, first only for the owner of the scripted object, and now also for Experience permission-granting participants. The script can just do this whenever it wants, zero clicks required, but practically it's done in response to some indication (such as a touch) that a teleport is requested.

So that's one way to effect cross-sim teleports with one (or fewer) touches, and no intervening maps. But for the Experience-based version, it's not enough to simply buy them: one must also enable an associated Experience on any land where they are to be used (the origins of the teleports).

I haven't been paying attention to the market for Experience stuff. I don't know if anybody is selling scripted objects with the scripter's own Experience compiled-in. That seems risky, because if anybody figures out a way to use the product for griefing, the Experience can be disabled, bricking all instances of the product. Instead, I guess, the code that uses Experience functions would be compiled by the buyer into an Experience for which they have responsibility.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3186 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...