Wulfie Reanimator

I agree with @Profaitchikenz Haiku about chat messages being the most basic idea. And based on that concept, if the door script was something like... // door stuff default { state_entry() { // script setup } touch_start(integer total_number) { // code to open door, maybe starts a timer } } You make some changes, like beginning to listen on a secret channel, reacting to messages in the listen event to open the door and only sending a message on touch instead... // door stuff default { state_entry() { // script setup llListen(-777, "", "", ""); } touch_start(integer total_number) { llSay(-777, "ping"); } listen(integer channel, string name, key id, string message) { if(message == "pong") { // code to open door, maybe starts a timer } } } Then your door key, listening on that same secret channel, would send a message when it hears the door asking for a key. default { state_entry() { llListen(-777, "", "", ""); } listen(integer channel, string name, key id, string message) { if(message == "ping") { llSay(-777, "pong"); } } }

The field of Cryptography is pretty big and there's a lot of "basic understanding" you must have before you can read about and understand encryption and what it takes to create your own algorithm, that's why reading stuff about "basic encryption" and "how to make your own" won't teach you a whole lot. What you probably should be looking for are entire courses on the subject that do cover those basics.

Most importantly, jailbreaking voids warranty. I can 100% guarantee LL is not going to make their users do that. Worst-case scenario might be that it'll be a text-only client, but this is all super speculative.

I give up. Even when I put aside all of my frustration and disdain for your stubborn and poisonous attitude to actually help you, you still can't put aside your "I'm right you're wrong" mentality. (This was the main reason why I originally avoided this thread like you noticed.) For the record, I did not read the suggestions given by others, but I'm sure Rolig and Innula were on the right track and probably even had working solutions. The main problem is not the scripts, but Steph's inability and unwillingness to test and show all the code involved because he deems it "unnecessary" while still demanding help or proclaiming that "they couldn't figure it out so there is no solution, it must be LL's fault again." I already called this in the other thread. I don't know why I bother...

The whole script, Steph...

To actually test it... Yes! It seems very likely that the issue is in the script you are passing the information from. Probably because the info is sent in a different format. Will you post the other script here as well?

You will get a "Sim not found." error until you properly give it a sim to send you to. Try saying /-200600 Curious|<128.000, 126.500, 22.848> in local chat near the object.

I did. Send me a teleport in-world and we can try it together.

Either you haven't tried it or you don't know what you're doing. I tested this. I pass it the info, click the object, it asks me for permission, I accept, I get teleported, I come back to click again, I get teleported instantly without being asked for permission.

Well from a person who does not understand the simulator code in the head movement and uses a stick through the mid i frankly do not care what you caim. Also if you are so smart sort out an issue three of us have not been able to solve on the 'owner key' in the LL teleport. Which i noticed you avoided. I've been summoned.. This is all I changed (your code first, then my changes): touch_start( integer total_number ) { agent = llDetectedKey(0); llRequestPermissions( agent, PERMISSION_TELEPORT ); } touch_start( integer total_number) { agent = llDetectedKey(0); // if the agent is the one who has already given teleport permissions to this script, teleport them if(llGetPermissionsKey() == agent && llGetPermissions() & PERMISSION_TELEPORT) { llTeleportAgentGlobalCoords( agent, simGlobalCoords, simLocalCoords, ZERO_VECTOR ); } else // otherwise, request permission { llRequestPermissions( agent, PERMISSION_TELEPORT ); } } Here's the full code: string simName;// = " my sim removed";//this temp to see what is doing what vector simGlobalCoords; vector simLocalCoords;// = <30.0, 90.0, 24.0>;// key agent; key ownerid; default { state_entry() { ownerid = llGetOwner(); llListen(-200600, "", ownerid, ""); } listen(integer channel, string name, key id, string params) { list parameters = llParseString2List(params, ["|"], []); string simName = (string)llList2String(parameters,0); vector simLocalCoords = (vector)llList2String(parameters, 1); //rotation rot = (rotation)llList2String(parameters, 2); llRequestSimulatorData( simName, DATA_SIM_POS ); } touch_start( integer total_number ) { agent = llDetectedKey(0); // if the agent is the one who has already given teleport permission to this script, teleport them if( llGetPermissionsKey() == agent && llGetPermissions() & PERMISSION_TELEPORT ) { llTeleportAgentGlobalCoords( agent, simGlobalCoords, simLocalCoords, ZERO_VECTOR ); } else // otherwise, request permission { llRequestPermissions( agent, PERMISSION_TELEPORT ); } } run_time_permissions( integer perm ) { if ( simGlobalCoords == ZERO_VECTOR ) { llOwnerSay( "Sim not found."); return; } else if ( PERMISSION_TELEPORT & perm ) { llTeleportAgentGlobalCoords( agent, simGlobalCoords, simLocalCoords, ZERO_VECTOR ); } } dataserver(key query_id, string data) { simGlobalCoords = (vector)data; } changed(integer change) { if (change & CHANGED_OWNER) llResetScript(); } }

Yes. If both objects go "offline" at the same time, when one of them returns, it tries to send its new URL to the other object's URL. The other object isn't there to receive it though, and even when the second of the two objects comes back, the stored URL is dead with no object to receive it. When I said "have an experience," I meant "have access to (anyone's) Experience..." Redundancy may be the only realistic way that I can think of, but there's a a kind of critical mass of how many you'd want to use, because if and when the entire network does reach an unrecoverable state, someone must go to every single "node" to link it to some other node. llEmail is almost ideal, because it can send an email directly to an object UUID, but.. The UUID of an in-world object changes every time it is rezzed (e.g. worn) and after sim restarts, so that's the same issue and not any more reliable than sending URLs back and forth. You'd have to send UUIDs back and forth too. There are no other types of cross-region communication in LSL besides Email and HTTP.

ZERO_VECTOR is a perfectly valid argument for any function, just like 0, NULL_KEY, empty string, or an empty list.. as long as you understand what the output is supposed to be. If you are not able to predict when your code produces a <0.0, 0.0, 0.0>, you probably don't understand your code. It is also easy to detect if a user ("customer") gives your script that value.

You've gone off your rocker again, Steph. These are facts and not bugs: "Using all zeroes" does not produce an error message. Converting an integer 0 to float 0.0 does not "confuse the system." It seems to confuse you. ZERO_VECTOR is a constant for <0,0, 0.0, 0.0> <0.0, 0.0, 0.0> is the value of pure black color In a conditional, <0.0, 0.0, 0.0> is intentionally treated as "false." It has nothing to do with color. The color range of your monitor has no effect on what colors can be set in LSL. You're flaunting your lack of understanding of LSL basics again, while stubbornly pretending that it is some bug that LL refuses to fix.

I said "sim" but what I meant was "a piece of land on a sim." Slightly different, but hopefully you get the idea. (Unless the Experience database can be accessed outside of the land where it's enabled?) Experiences are a no-go because there's no guarantee at all that the object(s) will be on (or return to) Experience land. Even if you could guarantee that one of the objects will be on Experience land 100% of the time, it would be useless as the other object would have no Experience access. That, and not everybody has an Experience. I don't want a solution that doesn't work for everybody, as in anybody without an Experience or access to any specific external service.

If it uses any kind of service outside of SL, it's out of scope for this discussion. That's absolutely the way to do it for any kind of real project/product, but the whole point is "what can I do besides that?" I realize that the nature of objects in-world means that there's no absolute way to keep cross-grid communications open, especially if the whole grid goes down, but that's an acceptable reality. I still want to brainstorm ways to maintain -- even if 1-on-1 -- a system like this as reliably as possible, assuming that the whole grid doesn't die. A grid-wide, per-owner Experience or at least limited persistent storage would be the dream that would get me to pay for Premium on its own, but until then... This is an interestingly clever solution even if it's not the solution, by the way.

There are different kinds of lag, and a lot of people don't even know the two main types. Those people who put down the script meters are extremely unlikely to do it just because they're a "control freak," but because they have this vague idea of what lag is and what causes it -- even if it's entirely wrong. The problem is just technical illiteracy, which is very rampant on SL.

This is what is generally called "redundancy." Basically just additional systems that aren't necessary until something breaks. That said, even if you add a third object to work as a "middle man" or the dedicated server, that can go offline as well. Every region on SL restarts at some point, and rolling restarts can take out every sim with a redundant copy of the script, or even the whole grid can go down. Then what? You have to go to every copy and share the new URLs (even if you had a "circular system" where you only need to give one working URL to each object and they'll get every other URL from each other) I count Experiences as external services, mainly because you must have a sim dedicated to it. I might as well host my own simple web-server with nothing but PHP and a text file, but not everybody knows how to set that up, let alone those intimidating server installs. Currently, I've been using and testing this method by having one copy in my parcel and the other "moving around" on the grid.

It's that complicated problem again. Objects in SL can request to have an URL assigned to them for HTTP communication. Objects can also send HTTP messages. This makes it possible for objects to talk to each other using HTTP, grid-wide, bypassing region restrictions. But there's a problem. Almost any interruption to the script's existence causes the requested URL to die. Script reset, rezzing, region change, and region restart will all cause all URLs for the object to be released. One solution to this is to use an external service, which is definitely the most reliable way but not the only one. What about solutions that are completely in-world and LSL-based? I've deliberately gone out of my way to not read up on it before trying to come up (and creating) my own solution. Now that I've done that, I'd like to ask for feedback and suggestions on it. Some "plain English" first though: This is for two objects maintaining a bridge between each other, not a multi-object network. Both objects use identical scripts, so there is no dedicated "server" or "receiver." Though, since this script only has the bridging code, it can very easily be changed into something more asymmetrical. (Like sending commands from A to B, but B will only act on commands and not send them.) How it works: On state_entry, on_rez, and changed, the object requests for a new URL. If the URL is given, it is saved into memory. (Because you cannot recall it otherwise.) The object will then check if it has a stored URL for the other object. If it doesn't (usually the first time the script runs), it will only send its URL to an avatar to handle the linking by hand. This is done by going to the other object and saying the link on a chat channel. If it does, it will send its own URL to the stored URL (other object) before also sending the URL to an avatar. (The latter is currently just a safety-measure.) From the other object's perspective now, when it receives a HTTP message with an object URL, it will store that URL as an invisible hovertext. This is done for relatively safe persistence in case the object is reset (go back to 1). This works and the objects will be able to update each other with new URLs when one of them has to get a new URL for any reason. You can test this by placing the script into an object on the ground, copying its URL from chat, placing another copy of the script in an attachment while in another region, and giving it the first object's URL. Teleporting between sims will show new URLs being requested for your attachment and sent to the first object, which sends you a message (via llInstantMessage) confirming that it has stored it. One problem that puzzles me though is.. if there's any way at all for the objects to create a bridge by themselves if they have both gained a new URL and failed to communicate it to the other object. One case where this happens is when both regions are down at the same time, or if both objects are worn as attachments and the avatar(s) log off. One solution I'm thinking about adding is a confirmation that the URL was actually received, similar to TCP packets. This way, if the URL wasn't received because the other object was offline, it can be sent again after some time. But there is no way to test if the other object's URL has changed, meaning that it can never receive the new URL. For the sake of a catch-all test-case, let's say that these objects will never be on the same region at the same time and are guaranteed to break their bridge regularly because both objects will go "offline" simultaneously for some indeterminate period of time. key avatar = "please-use-your-own-uuid"; integer chatChannel = 445; key urlRequest; list urlParams = [HTTP_METHOD, "POST"]; string urlPrefix = "http://sim"; string thisObjectUrl; GetNewUrl() { llOwnerSay("requesting new url"); if(llGetFreeURLs()) urlRequest = llRequestURL(); else llOwnerSay("no free urls"); // todo: retry later } LinkWithExternalUrl() { llOwnerSay("checking for stored url"); string url = llList2String(llGetPrimitiveParams([PRIM_TEXT]), 0); if(llGetSubString(url, 0, 9) == urlPrefix) llHTTPRequest(url, urlParams, thisObjectUrl); } default { state_entry() { GetNewUrl(); // manual external url override llListen(chatChannel, "", "", ""); } changed(integer change) { if(change & CHANGED_REGION || change & CHANGED_REGION_START) { GetNewUrl(); } } on_rez(integer param) { GetNewUrl(); } http_request(key id, string method, string body) { if(method == URL_REQUEST_GRANTED) { thisObjectUrl = body; // check for stored url, send if possible LinkWithExternalUrl(); // send own url to avatar llInstantMessage(avatar, "new url: " + thisObjectUrl); } else if(llGetSubString(body, 0, 9) == urlPrefix) { // store remote url llSetPrimitiveParams([PRIM_TEXT, body, ZERO_VECTOR, 0]); llInstantMessage(avatar, "new url stored"); } else if(method == URL_REQUEST_DENIED) { llOwnerSay("URL_REQUEST_DENIED"); // todo: retry later } else { // undefined llOwnerSay(llList2CSV([ "id", id, "method", method, "body", body]) ); } } listen(integer c, string n, key id, string m) { if(llGetOwnerKey(id) != avatar) return; if(llGetSubString(m, 0, 9) == urlPrefix) { llSetPrimitiveParams([PRIM_TEXT, m, ZERO_VECTOR, 0]); LinkWithExternalUrl(); } } } It should be apparent that this script is still a kind of proof-of-concept and in-progress. It does not handle denied URL requests or retry anything, for example.

@Prokofy Neva I believe the main point was "there's no other option on the page, only Facebook." Telling them to make Twitter account doesn't help either, because they want to use their SL account.

Generally, especially with AVsitter, you can pretty much unlink everything from the root, and link anything else to that root (with all the scripts and animations) while keeping it totally functional. AVsitter doesn't really depend on anything but having as many prims in the linkset as there are sitters. How those linked things look is totally superficial. You'll also need to readjust the animations if the new object is a totally different shape.

I think the realistic way to actually do this would be to create your own web-based content service (similar to Youtube, Vimeo, etc) and have it communicate with scripts from SL. So, when a user pays an object (like the booth), the script in that booth sends a message to your web server, the web server authenticates it someway (you might want it to be somewhat secure so people can't just go to the URL on their browser for free) and then gives a response to the booth script so it can then request the actual video for viewing (after which the web server doesn't give another OK until another authenticated payment). I don't know if anyone's already done this, but my uneducated guess would be no, because I think the majority of the work is on the web server rather than SL scripts.

Well, what's the news?

Almost everything about this thread (how the title and body is phrased, the second post from OP) hints towards trying to get kneejerk reactions from people and create a cesspool. bringing up the "is it a game or not" debate graphics are bad why not "just upgrade" them more people would play saying "humans" instead of people was this a bad question ive spent money why should i spend more making the "game or not" comparison a second time ignoring the fact that SL is almost 100% user-generated content The unfortunate thing about this kind of subtle phrasing is that you can always say "but I'm being serious" to get people to bite despite others calling it early, and there's no real way to tell if they actually are or not. Fact is, everything I listed there is something that could be considered both inflammatory and genuine, and we'll probably end up with a 200+ replied thread where people have started arguing with each other because of someone's genuine attempt at trying to answer the OP's questions at face value. Hence my "guaranteed replies" bait meme. There's just so many easy topics to jump on, it's too perfectly crafted from a 1-day old account called "Quantum Incitement" as their first post on the forum. All that said, I'm gonna unfollow and probably not post in here again, here's hoping I'm wrong!

What I meant by orbiting is something that is done by scripted objects. If pushing is enabled, the object will just apply force to your avatar to throw it straight up, constantly. Optionally, even if pushing is disabled, an even more common thing to do is cage the target avatar into an object and make the object push itself up instead, since that can always be done.