Chaser Zaks

  • Content count

  • Joined

  • Last visited

Community Reputation

223 Excellent

About Chaser Zaks

  • Rank
    Advanced Member

Recent Profile Visitors

361 profile views
  1. Enabling IM to email = Sigh

    Create a email filter either on the server or email client to automatically move emails from * (I think that's the address?) to a subfolder, that's what I did. My email is structured like so: Inbox Second Life Important / Security Invoices Instant Messages Jira News Objects
  2. Sending an object to a blocked person.

    When you send a object to a blocked person, the object is automatically declined without notification that a item was sent or that the item was declined. As the blocking system uses the internal decline function, it the object is still technically received, it is just put into their trash folder. It will still require manual purging.
  3. GDPR and off-world databases

    I live in the US. The EU can cry at me as much as they want, but GDPR can't touch me.
  4. Show me your funny Second Life pictures. this thing, it is my favourite bug and I hope it never gets fixed.
  5. This used to be a thing back in 2007. Since they brought back community gateways it would be nice if they added that(especially since I would like to get into Orientation Island one day so I can investigate bugs and find all the holes that need to be patched up so new residents don't accidentally go outside the tutorial area).
  6. SL a California based virtual world

    Despite Linden Lab being a California based business, LL seems to be on very neutral on grounds when it comes to politics. Personally I find it good business practice. You don't make your customers angry at political based decisions if you don't do political based decision, all sides win and LL keeps customers. Granted there are some things that can be argued are political based decisions but really though they are more of common sense rules, rather political decisions.
  7. object return to owner

    It may be possible to use integer canReturn; default{ state_entry(){ llRequestPermissions(llGetOwner(), PERMISSION_RETURN_OBJECTS); } run_time_permissions(integer p){ canReturn = TRUE; } touch_start(integer dt){ if(canReturn) llReturnObjectsByID(llGetKey()); else llRequestPermissions(llGetOwner(), PERMISSION_RETURN_OBJECTS); } } However, I am unsure if llReturnObjectsByKey has an exception to allow residents to return only their own objects over land they do not own.
  8. GDPR is coming, and it affects you

    The EU is overstepping their boudaries if you ask me. I run a company(both in SL and out) based and hosted in the US. People from the EU can access it because I don't block access based off country(except China and Russia, which get requests blocked based off an AI's suspicion level. I don't mind good users from China or Russia, it's the script kiddies probing my servers I don't want) because im lazy I'm not going to put code that I don't want into my software. If someone access my site or services, they do so under the US state of Kentucky law. If the EU gets angry at me for doing stuff according to my law, then they can try sue me. I'd like to see them try and get past my freedom eagles.
  9. What happens at Documentation Island?

    Documentation island is used by Linden Lab to make knowledge base articles. Lots of the screenshots you see on the KB have been taken there. I believe back when Torley Linden did video tutorials, he used documentation island sometimes. Basically it is just a noise free area for LL to make helpful articles and videos.
  10. Most discriminated against group of avatars

    No particular order, but if I had to make a top 10, this would be it: Furries Child avatars New residents Vampires / Bloodlines users(generally they seem to be bunched together) Sculpt based avatars More than sculpt based, prim based avatars I think the kemono avatar has worked it's way up in this list due to how it looks(apparently flat chested = child now? Idk) Avatars using realistic sizing / not having the height slider all the way to the max Avatars that have a bunch of idling scripts(compared to those who have a few but constantly running scripts) Resident last named residents. Script based discrimination would be(in order): New residents by a long shot, which saddens me. It makes new people feel not welcome and potentially damages the community. Script count and script memory usage. Granted a lot of memory can lag a sim when entering/exiting, but not when it isn't doing anything. People need to learn script time is the real main culprit. Avatars not using max height. I've been ejected from places for not being a giant several times. Specific fandom/group I can't really order. Furries, child avatars, and vampires seem to be all hated equally when added up. I could understand the hate for child avatars a bit(eg: going to adult areas like zindra causing worry for other residents, baby talk when not in a RP area), but it's just a few child avatars that do this. I have met some really cool people who use child avatars before. Can't really speak for furries since I am one, but even some furries make me dislike furries sometimes.
  11. When I say authenticate in this, I mean to take some information to confirm that A equals B(EG: Is Chaser.Zaks equal to Chaser.Zaks). It is important to note that this isn't fully finalized and Linden Lab may change specific stuff, this is written based off what I know. This isn't a Linden Lab notice, it is a resident to resident notice. Some things MAY BE INCORRECT. This is intended for primarily scripters to raise awareness they need to update their scripts to properly authenticate people via UUID. Please do not spread F.U.D.(Fear, Uncertaincy, Doubt) by skimming through this and spreading incorrect/inaccurate words in group chats. If you already authenticate users by the UUID, then you don't have anything to worry about. The change: If you haven't seen it already, take a quick skim through During a User Group meeting, it has been slightly confirmed(As in, it is the current plan, this may not be 100% the choice yet) to allow users to change their last name, and even first name. For scripters(Both LSL and external), this is a very big and concerning change. We can normally authenticate residents by their username(EG: Chaser.Zaks, Saltyalt.Resident, Ebbe.Linden, etc), but because of this change, this is no longer a viable solution. I have always been authenticating residents via their UUID. The UUID will never change. It is important to authenticate residents using their UUID. What this means for existing content: If you are a scripter, if you haven't already been doing so, authenticate users by their UUID. If you are not a scripter, check that you can authenticate residents via their UUID. If you cannot do this, you will need to contact the creator. If you are a web developer, APIs are planned to allow us web developers to authenticate and update information as needed. Why this change is may be of impact: If you authorize people to be in your parcel by their username, and they change their name, they may no longer be authorized to enter your parcel and get ejected. Why this isn't a security risk / Why you shouldn't worry someone will take over your sim: Once a username has been used(EG: Chaser.Zaks), it can no longer be used again, for example: Say I have a security system which lets me use stuff like /1 eject <name>, or /1 ban <name>, and said security system only checks to see if the user who used it has the name "Chaser.Zaks" I change my name from Chaser.Zaks to Chaser.Soupcanister Someone sees this and thinks "I can use this to my advantage", So they try to change their name to "Chaser.Zaks" They are told they cannot use this name as it has been previously used. Estimated time frame of this change: Not any time soon, but within this year likely. Think somewhere like October or December 2018. This is a big change and a lot of stuff needs to be changed internally to make sure it doesn't break stuff. I assume some things internally may be using name based identification. Updating scripts: Sometimes people may use llDetectedName or the Name parameter from listen. You should instead use llDetectedKey or the UUID parameters when possible. You do not need to change this for stuff that just says "Hello, <insert name here>". For reference, this: string thePowerUser = "Chaser Zaks"; default{ state_entry(){ llListen(1, "", "", ""); } listen(integer channel, string name, key uuid, string message){ if(name == thePowerUser){ /*Do important things here*/ } } touch_start(integer detected){ if(llDetectedName(0) == thePowerUser){ /*Do important things here*/ } } } Should become: key thePowerUser = "796b1537-70d8-497d-934e-0abcc2a60050"; default{ state_entry(){ llListen(1, "", "", ""); } listen(integer channel, string name, key uuid, string message){ if(uuid == thePowerUser){ /*Do important things here*/ } } touch_start(integer detected){ if(llDetectedKey(0) == thePowerUser){ /*Do important things here*/ } } } If you need assistance with this: Please send me a message In-world with the affected script/object with full permissions. I will upgrade the script for you free of charge. I am unable to fix products that are no modify. Please do not kill the messenger.
  12. Abusing Abuse reports

    E.I.G.H.T., or Governance8 Linden is indeed a Linden Lab employee account. If I recall correctly, it is one of a few Governance accounts Linden Lab uses to do things in world(It is shared by multiple people, they just use which ever is available at the moment). However, something seems off about the story. Linden Lab NEVER will tell someone they are being investigated unless they suspended a user's account first, or are investigating something on behalf of the user(EG: Suspicious logins). In fact, you usually will not even see them because God Tools permit them not to be even seen by people if they so desire. Telling people they are being investigated is going to make someone change their ways and skew the investigation. Make sure that the message you are getting is actually Linden Lab. People can use LSL to spoof being someone, so even though it says it is Governance8 Linden, it might just be a object. Are you seeing Governance8 Linden's avatar in-world? If not, this may be a tell tale sign that it is indeed a object pretending to do so. If can conclude that it is a object, please report this object. Linden Lab will find out who owns it and warn or suspend this account. Impersonating a Linden is a big no-no.
  13. Why crowded venues suck

    Oh, yes. That is correct. I typed that when I was half awake. I was mixing up avatar appearance xml exporter with the appearance data files. I had forgot about project shining, so yes the bot thing is incorrect and I have updated my post to reflect so. Thank you for pointing this out!
  14. To answer the op's original question, the portals work off the destination guide with a bit of Linden magic to generate landmarks(if it gave you a landmark). I do think it should be revised to only pull destinations from the new resident friendly category though. Being offered a location only to be kicked out of said location isn't the welcoming message we want to send to new resident whom may potentially stay and become part of our community.
  15. Why crowded venues suck

    It is a partial myth. It isn't possible to do this with LSL alone. There is no method to detect appearance data with LSL. The truth in this however, is a bot can download the appearance data and check for the appropriate layers in the appearance XML. (Because I know someone will bring it up, This is not in violation of the TOS, it is also how the viewer works) This was incorrect, as pointed out by Qie Niangao, I had forgot completely about Project Shining which bakes these layers. Bots are unable to see this except for the bake layers which do not include any of this. However the next part is correct. It is also possible to use LSL to get a list of worn attachments and go through each one and check for the word "body". However this is both horribly flawed as not every mesh body has the word body in it, and is also easily defeated by wearing a cube named body.