Jump to content

Sei Lisa

Resident
  • Posts

    8
  • Joined

  • Last visited

Everything posted by Sei Lisa

  1. Unfortunately, this is not feasible for open-source scripts such as AVsitter, which I maintain. The aim of the check is to prevent abuse of the service by blocking IP addresses that do not belong to Linden Lab. Is there any other approach that could be used for this purpose? What's the difficulty in implementing a reverse DNS that resolves the proxy IPs to an address within lindenlab.com?
  2. I have PHP scripts that look up the host name with gethostbyaddr and verify that they resolve to .(agni|aditi).lindenlab.com; will these keep working?
  3. My preferred method is different to the one explained in the blog post. On state_entry, the rezzee sets up a listen for everything, in a preset channel. The object is taken to inventory with this listener active. The on_rez event does NOT reset the script (or there's no on_rez event whatsoever). In the object_rez event, the rezzer sends the data to the rezzee via the same preset channel that the rezzee is listening on. For security, the rezzee's listen event filters out the messages that don't come from the rezzer, by comparing (string)llGetObjectDetails(llGetKey(), (list)OBJECT_REZZER_KEY) with the id in the listener and returning if they don't match. If no more messages are expected, when the message is successfully received the rezzee can now remove the listener. If more messages are expected, the rezzee can optionally set up a new listen with a filter for the key of the rezzer, and then shut down the old listener. The latter step is unnecessary, though: it would merely prevent script execution for messages that don't come from the rezzer. This method is faster and uses less memory because there is less back-and-forth communication, which is why I prefer it. In particular, it removes the need for a listener in the rezzer in the frequent case of rezzer-to-rezzee communication only. It relies on the fact that the listen queue of the rezzee exists when the rezzer receives the object_rez event, regardless of whether the rezzee has already started executing or not. It works because while the rezzee is waiting for a chance to execute, the communication event is waiting in the queue, so it will eventually be received. Rezzee: integer ListenHandle; default { state_entry() { ListenHandle = llListen(1234, "", "", ""); } listen(integer chan, string name, key id, string msg) { if (id != (string)llGetObjectDetails(llGetKey(), (list)OBJECT_REZZER_KEY)) return; llOwnerSay(msg); // or some other message processing here llListenRemove(ListenHandle); } } Rezzer: default { touch_start(integer n) { llRezAtRoot(llGetInventoryName(INVENTORY_OBJECT, 0), llGetPos()+<0,0,1>, <0,0,0>, <0,0,0,1>, 1); } object_rez(key id) { llRegionSayTo(id, 1234, "message"); } } But given that the official method endorsed by LL is different and more complex, I'd like to know if this simplified method is guaranteed to work in future.
  4. The latest release notes at http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/14#14.04.16.289178 claim to have fixed this issue. Can anyone confirm?
  5. Erik Verity wrote: Made that point here in this thread too, 2 pages back. Right, sorry that I missed it
  6. Someone's made an excellent point here: https://my.secondlife.com/auryn.beorn/posts/520d328ff40e20000200045b Ian Undercroft points to Section 2.2 which states: [...] Additional terms may apply to certain elements of the Service (“Additional Terms”); these terms are available where such separate elements are made available on the Websites. If there is any contradiction between any Additional Terms and these Terms of Service, then the Additional Terms shall take precedence only in relation to that particular element of the Service. For examples of such Additional Terms, please see Section 12 below. It seems quite clear that the Maturity Ratings policy (which is contained in Section 12 and therefore it obviously counts as Additional Terms under Section 2.2) directly contradicts section 6.1(vi) when it says: "Maturity ratings designate the type of content and behavior allowed in a region [...]" Edit: I should not have obviated this: the Maturity Ratings policy also states: "The Adult designation applies to Second Life regions that host, conduct, or display content that is sexually explicit, intensely violent, or depicts illicit drug use." End edit. Therefore, according to Section 2.2, the Maturity Ratings policy overrides Section 6.1(vi) at least for inworld.
  7. Coby Foden wrote: http://lindenlab.com/tos Section 11.4 "You acknowledge that no other written, oral or electronic communications will serve to modify or supplement this Agreement." Yay! Now we can start dropping this to those who have their own TOS 'amendments' in their profiles. :matte-motes-evil: :smileytongue: That's there for a long time. I have a notice in my profile in that regard for a while. (I guess I'll have to change the section numbers though, I think it was 13.4 before)
  8. If you accept the TOS, you have to comply with all clauses of it where applicable (by applicable I mean e.g. that if you don't do machinima, the machinima clauses don't apply to you) in order to abide by it. If some service's TOS say: 1. You can drive on roads. 2. There are roads for you to drive on. 3. You can't drive except using the roads. 4. You can't drive. 5. There are roads explicitly for you to drive on. 6. You can use the roads to drive. 7. Consult the road guide for places you can use to drive. No matter how you look at it, if you drive, even if you only use the specified roads, you're violating clause 4 and therefore not complying with the TOS. No matter the contradiction between 6.1 (vi) and 6.3 (iv), if you conduct sexual activities, post sexual content, post violent content, roleplay with violence, host violent rolaplaying, etc. you're violating clause 6.1 (vi). If they meant it as applying to harassment, the wording doesn't suggest so. One potential solution would be to allow displaying sexual activities in adult-rated places. If you're in an adult sim and feel harassed by someone displaying sexual content, I think you have a problem. Another potential solution would be to specify explicitly that it applies to harassment as written in the 6.1 section introduction. Something like: "You agree that you will not: [...] (vi) Post, display or transmit any Content or conduct or host any activity that is sexually explicit, or intensely violent, in a way that Linden Lab, at its sole discretion, considers illegal, harassing or violating any person's rights." The LL's sole discretion could still be a backdoor, but at least it leaves it crystal clear that the conduct applies to harassment only.
×
×
  • Create New...