Yingzi Xue

Idea. Anyone that gets banned from a parcel, have their particles get blocked from the parcel as well. This is currently the last hold griefers have on a location, particle spam. As it is now, I have to leave a sign with the parties to block, so particles from objects in neighboring parcels don't affect my patrons.

Griefers rely on lax owners to succeed. It gives their objects time to duplicate and cause havoc. It's a lot of work to sit and watch your land, but that's what has to be done to overcome griefers. When you ban them quickly, they know you're on point and they can't get away with it. Most move on. Those that are persistent are up against a watchful eye and a ban hammer. They can't win.

Syo Emerald wrote: And banning based on identity might only work for those, who have some sort of identification material linked to their account. If you create a new account now, there is little to nothing to truely identify who it is. You're right, you can't ban by identity, but a robust security system and an active owner (or security employee) will stop griefers quickly, no matter how many avatars they create. If you're faster at banning than they are at making new avatars, it quickly becomes counter-producting for them to even try. I speak from years of experience, it does work to be vigilant and arm your land with a good security system. When you crush a griefer's desire to even try, you know you're doing something right.

Griefing has been and always will be around. Even if you make it "illegal" to own, use or create griefer tools, it's still going to exist. It's like trying to stop software piracy, it's not going to happen. It's like trying to plug security holes in software, someone always finds a way. I've dealt with a lot of griefers in the last several years. Here's what I've learned: A vigilant owner will stop griefing in its tracks. A scripted security system will do wonders against griefers. Griefers eventually run out of avatars and move on. Choosing your location wisely is also a factor. Allow me to address each of these in more detail. An owner (or employee) who watches the goings on at their business or locale can usually stop griefers before they do any serious damage. It simply requires watching avatars and reacting quickly. This means you need someone there most hours of the day. I've been using a scripted security system at my locations for years and have successfully fended off griefers. The issue with banning avatars is that you can only ban 100 avatars at a time on the land ban list, so you need a scripted system to work with the land ban list efficiently. This is accomplished via temporary bans and script-controlled ejection. Done correctly, you don't need anything but a database of keys and ban status and a script to do the banning and receive owner commands. I am able to shut down most griefers in seconds. They tend to not bother coming back when the security system is on point. No matter how determined a griefer is, they will eventually run out of avatars and get bored. This is when they move on to an easier target. Many try to return at a later date, but they are no match for a good security system. And no, there isn't anything this robust on the market in SL, I had to write it. Location is key. The biggest advantage a griefer can have, after you've taken care of their objects on your land, is land around you that doesn't auto-return. You still get the particles jumping into your land from all around you. The only way to stop this is to own the region you're on, but if you're on mainland the best thing you can do is purchase land in a mostly abandoned region or at least surround yourself with abandoned land. This eliminates any straggler objects from being an issue. You don't have to wait on neighboring land owners to come online and clean their parcels. It would be nice if LL cared more about griefers, but it's not a lost cause, you can do many things to win the fight. You just have to apply yourself to get the desired result.

The grid can be used for what you need. The grid consists of invisible snapping points, dictacted by the grid unit setting under options window (see options button in your pic). For instance, if you set it for .5, the snapping points will be .5 meters from each other, allowing you to arrange prims using the grid ruler (aka snapping to the grid ruler). You can get desired spacing by using the grid snapping points while moving your prim/object using the axis arrows. If you need help, let me know, I'll be glad to show you.

Second Life isn't GTA V or Just Cause 3. There is no story except the one you create. Second Life is an empty shell, a set of social and creative tools that allow ultimate freedom; a true virtual world made by the users themselves. Thus, it's constantly changing and the content possibilities are literally limitless. You never know what you're going to find around the next corner. Your mistake is thinking of Second Life as a game with a story or some sort of direction. It is not. Second Life is free to experience, without paying. You can't own land, but you can rent it as long as you have the ability to earn in-world money (called Lindens) to pay for it, or have pay info on file to buy virtual currency. In Second Life, you live a virtual life of your choosing. It's that simple. As in real life, nothing is handed to you. This isn't Sims 3, it's a completely emersive virtual world with endless possibilties you create for yourself. Maybe the reason you feel SL sucks so bad and is of poor quality is because you haven't done anything to further your own experience, instead thinking it should be handed to you. Second Life is a virtual world, not a game. Its experiences are dynamic and reflect the population. Today something exists, tomorrow it doesn't. Such is life in Second Life and such is the beauty of a true virtual world. It helps to understand what something is before criticizing it. I suggest starting at Second Life Wiki, which is chock full of specifics.

1999? I think I spent most of that year playing Quake 3 at LAN parties or online... and hanging out on IRC. I'm surprised it took several pages before someone actually came out and said it--Second Life isn't a game. That should've been the first response. Second Life isn't sold in stores, it's not sold on Steam, it's not sold on Origin or any other gaming service. You can't play it on your PS4. You can't play it on XBox (without jumping through some serious hoops). Second Life is a virtual world with limitless possiblities. Content is created by the users themselves. It is a constantly changing world containing real people living virtual lives. It's meant to be experienced, not played. Creativity, exploration, leisure, socializing... these are some of the things that you should be enjoying in real time instead of trying to stream your uber "gaming experience" in SL on social media sites. lol The fact that Twitch TV has banned SL is a good thing; SL has no place on Twitch TV. Maybe the reason they banned it is because they, unlike you, understand what Second Life is and why it shouldn't be streamed. My guess is it has something to do with privacy concerns vs virtual worlds... and the fact that (again) IT'S NOT A GAME.

As Rolig said, always adjust your camera so it's perpendicular to the direction you want to move. In other words, a 45 to 90 degree angle from the direction you want to move. If your camera is facing the same direction as the axis you're moving the object in, it can have a tendency to jump on you, which is why you lose objects. Camera angle is very important. If you find it tedious to use the camera control, try learning the shortcuts instead. ALT-LEFT CLICK - Refocus camera where you clicked. MOUSE WHEEL to zoom in/out. ALT-LEFT CLICK HOLD - Move mouse left and right to rotate around focal point, push and pull to zoom in/out CTRL-ALT-LEFT CLICK HOLD - Same as above, but instead of zoom on push and pull it rotates up/down. CTRL-SHIFT-ALT-LEFT CLICK HOLD - Pan up/down/left/right. These make moving the camera around much easier, because you can do them on the fly. Mastering the camera control shortcuts is key to building quickly and getting that perpendicular angle so your objects don't jump on you.

Another reason the drag copy works the way it does... Since the original is the one that moves when you drag copy, its history stays intact (recent positions, scales and rotations) and can be cycled through via CTRL-Z (undo) and CTRL-Y (redo). This comes in handy, for instance, when you need to move the prim/object back to its previous position after making a drag copy. Each prim/object keeps track of its own history, which can be scrolled through using undo and redo keyboard shortcuts.

Second Life has always had flaws. I don't look at mesh as one of them. I remember a time when male avatars all looked alike (before mesh) because there were limited options for skins, shapes and clothing. Options for female avatars far exceeded that of males, because skirts (for instance) were easily made. Male clothing was at a standstill for a lot of years, until sculpties and mesh came along and opened up a new world of possiblities. I've seen a lot come and go in my almost 9 years of being in Second Life. One thing remains the same. Second Life allows you to be as creative as you want to be, but you have to put the work into it to get the reward. Building, scripting, graphic design, mesh, running businesses---all of it requires hard work and doesn't come easy. I started from scratch in late 2007. I learned to do everything I needed to create my products. Some of it came easy, some of it not so easy, but I stuck with it. Either you want to be creative or you don't. Either you step up to the challenge and conquer it or you don't. I would love to paint in real life, but I don't want to deal with the mess of it all. Instead, I create in Second Life. In other words, this platform, this medium, it's not for everyone. Someone else may prefer to paint in real life. The addition of mesh extended the life of Second Life by several years, something just adding more shapes couldn't have done. It made SL viable again, before it was deemed obsolete. Complaining about mesh and performance issues is valid, but it's like megaprims before it and scripting---people need to be educated in the proper way of doing things. LOD, script efficiency, viewer settings (somehow overlooked), etc. In other words, it takes responsible people to make Second Life a success. Responsible creators, responsible consumers. Education is key. Second Life has always been flawed in one way or another. None of its flaws have ever been a deal breaker for me. Some of them I find endearing. Its limitations make it that much more enjoyable to work with creatively, because you must find new ways of doing things. It forces you to think within set boundaries and come up with something you never thought of before. Second Life is near the end of its life. Something better will come along. Something that allows the level of creativity. When another platform emerges that combines scripting/programming with ultimate creative freedom, Second Life will fall by the wayside. People will move on. It's inevitable. I remember a time, before the internet, when ANSI art and BBS's were a creative outlet. Then the internet and the web came along and made BBS's obsolete. Many held on for several years, but now you can't find but a handful of BBS's still running and even those are empty. Second Life will live on for many of us; people like me who still find creative things to do in Second Life on a daily basis, whether it be writing a script, making a mesh chair or designing a new logo for a business venture. Second Life is second to none in ultimate creative outlet. The amount of abandoned land is evidence of decline, but I blame the marketplace for a fair chunk of it. No longer do merchants need to have an in-world store. It's so much simpler to open a marketplace store and save money, not having to build a store and pay tier or rent land. LL shot themselves in the foot when they bought the marketplace and turned it into what it is. You have to keep in mind, Second Life is based on an aged platform. The fact that we've come this far is a miracle in my opinion, given the limitations that bind; Second Life would have to be completely rewritten from scratch to bring it up to snuff and fix some of the glaring issues. Even then, it would never be the Second Life we know and love. There were times when I used to be cynical about the future of Second Life. Nowadays, I spend my time enjoying what I love about it, because I know its days are numbered. I'll probably be one of the last to leave, if at all, and even then I'll move on to another grid (or run my own).

SOLVED - She wiped her system and the problem disappeared. She also found she had a bunch of malware on her computer. Stuff with names like "HackTools, patcher,keygen,wpakill and gendows". Not sure which is malware and which isn't.

I don't check ownership. If you own the HUD then you're a legit owner. I can give the HUD to any of my alts and it works as expected, but I'm using the same computer/same viewer. I'm going to try using it on a different PC, see if a default install might have something set my viewer doesn't. EDIT: Just installed Firestorm 32-bit on my Asus tablet with Windows 8.1, brand new never before installed on the system. It works as expected, which only deepens the mystery... what in the heck is going on with this person's viewer(s)? Or is it something else?

I've created a HUD for limited custom camera functionality. When I use the HUD, my camera functions as expected and does not revert when I move. I gave an early working version to a friend who informed me that her camera reverts to the default rear view when she moves. We checked the suspect debug settings, the suspect preferences settings, but we can't find a setting that stops this behavior. We did uncheck the "Reset camera position on avatar movement." but it did not stop the revert. I had her change to a default avatar, which removed all attachments. She is using Firestorm, but we also tried the SL viewer. I am at a loss. Does anyone have any ideas what would be causing this?

While the College of Scripting is great for starters and the wiki (User-defined functions) goes into a little more detail, neither explain it very clearly. Functions can accept data passed into them and return data out of them, depending on how they're declared in the script. Example 1 Do something. No data passed in or out. Note that global variables can still be changed and local variables can be used. Called from anywhere in your script using do_something(); Even though no data is passed into the function, the parentheses still have to be there. do_something(){ // Do stuff} Example 2 Pass data into a function for use. Variables can be any data type and names of your choosing. In this example we pass text into a variable named 'text', which we then use in the function to place the data where we want it. Example: say_something("The menu has expired."); say_something(string text) { llSay(PUBLIC_CHANNEL,text); } We can have more than one variable passed to our function. Example: say_turns_left(llKey2Name(current_player_key),turns); Sample output: "Yingzi Xue has 5 turns left." say_turns_left(string name, integer number){ llSay(PUBLIC_CHANNEL,name+" has "+(string)number+" turns left.");} Example 3 We can also return values back from the function using 'return' followed by a data type that matches our declared data type before the function name. So... in our script: calculate_word_score("delicious",100,50); would return an integer of 950. We could calculate our word score and store it in our current_score all in one statement: current_score += calculate_word_score(submitted_word,current_score_modifier,current_bonus); integer calculate_word_score(string word, integer modifier, integer bonus){ return (llStringLength(word)*modifier)+bonus;} The format is as follows: return_data_type function_name(passed_data_type variable_name, passed_data_type variable_name...){} As shown in the first example above (do_something), you don't have to set a return data type if you're not returning data. You don't have to pass data into the function. What your function does is directly dependent on how you declare it.

There are many ways to waste script memory and many ways to save script memory. It all comes down to good programming habits. Without seeing the script code you're talking about, I can't give you tips specific to your script. Good habits come with time, experience and knowledge about the language you're working with. There are important factors involved which vary from script to script, so it's difficult to narrow down where your problem areas are. Some general tips: Use local variables when possible, keeping globals to a minimum. Only create functions when they're absolutely necessary (repeating code, for instance). Even though llGetFreeMemory results can vary, it's still useful to approximate memory usage and test different ways of doing the same thing to maximize memory in your scripts. When using lists, storing variables like keys, vectors, integers and floats as their actual data type (and not string) tends to save on script memory. Further reducing some data types (keys, for instance) to smaller values can also save on script memory. Always think efficiency first. Take a minimalist approach in your scripts. Strive to have your scripts idle, waiting for events. Remove unnecessary listens. Stop unnecessary timers. Keep text usage (chat message text, for instance) to a minimum. Text is one of the biggest script memory hogs. Only split scripts into multiples when absolutely necessary. Once you've written a script, place it in inventory, then use that script to load your objects with so that you're taking advantage of bytecode sharing and use less memory. Use "Link" functions (llSetLinkPrimitiveParams, for instance) in place of using more than one script in your object's prims. Consider how your scripts (and products) will impact others and plan accordingly. If your script becomes bloated and you know it (typically, you do), try to reconceptualize your script design and come up with a simpler way to do something. It might mean eliminating some features in your script, but may give a huge savings. Choosing a lesser method of user input, for instance, can save on the code needed to do the job, thus saving on script memory. HUD's are great for offloading input from script code to meaningful buttons, simplifying the script. When it's not necessary to use text, use values to represent settings instead. Learn how to use bitwise integers for script functionality. Those are just a few.

Invader Dench wrote: This is the most stupidest thing I have ever seen any online game do, and I been around for awhile. MMO's and other things, you basically are now going to cut off alot of those people who are your economy. Hey I live in one of those states, I work my butt off, if I wanna goto a Skill Gaming sim and spend some lindens that I bought with my hard earned money, THAT SHOULD BE MY GOD GIVEN RIGHT! You are doing this while hey look Prostitution and escort services are around, but no lets not target them. Lets target the people who work their butts off to the bone who goto these sims to relax, to spend some of their real life cash into lindens. What burns me up the most about all of this...Arkansas has a lottery that is gambling so either you guys up there didn't do all of your homework, or something else. Heck I can go 15 miles away to West Silaom Springs, Arkansas to a casino. I applore you do a age limit, don't punish those users in those listed states in this. Everyone of those listed states has a lottery, which goes under skilled gaming, so why punish them? I for one play the Arkansas one quite a bit, Please reconcider this, I don't want to lose the ability to goto these sims cause someone up in LL decided to target these states and punish the users in those states from it. Go with a 21 year old Age limit and keep it at that. These sims are a large part of your economy please look at it that way, I goto Ocean view games alot, and I tell you I have NEVER had issues there. The people are friendly. I think you'll find it unlikely that LL would put themselves in harm's way vs Arkansas law. Age restrictions wouldn't do anything to reduce LL's liability vs state laws.

As Phil has laid out clearly in his last two posts, LL has been crystal clear with their responses. In the case of a game having a configurable option for switching between pay-to-play or free-to-play, it was clear in LL's response that it would fall under the skill gaming policy if a game gave the option for both. I myself asked LL early in the thread about specific game concepts and they responded with the same language found in the wiki; in other words, an assertion of the language. They didn't have to come out and tell me, reasserting the language made it clear. That's called affirmation, directly from LL. Anything else you read into it is just that, you reading more into it than you should. Sorina, I respect the fact that you've been into games since 2004 and heavily since 2007. I am sure you know SL games quite well, having used them for so long. I think we can all acknowledge that and move forward from it. It doesn't apply to interpretation of skill gaming policy, which takes basic reasoning skills and common sense, not experience with games.

A number of games and operators were approved yesterday. Check it out.

Innula Zenovka wrote: I'm a bit surprised by this explanation. Sure, if I wanted to make a game that was configurable to be either pay to play or free to play, then I can see that charging and immediately refunding the L$1 would make sense. However, if I were writing a free to play game, or even converting a game to be strictly free-to-play, I really wouldn't want completely unnecessary run time permissions or money events cluttering the script up. Not when the alternative is to do everything in a touch event. More likely, to my mind, is that if you've made a pay to play game and want to make a free-to-play alternative, the easiest (though certainly not the most efficient) way to convert it is to re-write part of the money event, even though that means leaving a lot of stuff in that's not really needed. Exactly. I agree with everything you said. Speaking to all here: If you're writing an all-in-one solution (free-to-play and pay-to-play), the tendency would be to just make it configurable with both options, but the efficiency-minded creator would probably make two versions, ripping the "dead" code out of the free-to-play version to save on script memory. I remember at one time there was talk of LL rationing out script memory (EDIT: Per discussions in 2009 and a 2010 LL blog post that has since been deleted; see more here). If you look at Script Info under About Land, General tab, some (if not all) of the code seems to be in place to limit script memory on a per parcel basis. Even though it may never be implemented, it makes sense to be as efficient as possible (my main point from the last several posts). I made that commitment a long time ago.

Sorina Garrigus wrote: It is possible obviously and some do but on freeplay games with pay and win options built in it extra scripting. And the impact on the sim can easily be multiplied by a couple hundred in even a moderately sized game room or arcade. Some games would require menus but most wouldn't. I have one called Galaxy War which is one of my favorites to play that has multiple config options. Players set if its co-op, or competitive, or how many computer opponents there are, the AI difficulty level etc. There are just way too many game mechanics and various other options to say menus are not required at all. Menus aren't required at all if you use notecard configuration or external configuration. There are ways to get around menus and save on memory. I have a product that uses menus, texture cycling and timers. Hundreds rezzed in the same region and still good performance. It's all in the design. Many factors cause lag.

It's possible to create a session system without menus by keeping track of the player key and the status of the game. I just wrote an example script which uses around 575 bytes of 16k script memory. At the very minimum, if designed properly, session code is small taters. You could add a timer to expire a session if the player leaves mid-game, which is a few extra lines of code. A timer would be minimal impact, being set for something like 5 minutes. Approximately 685 bytes used. That's with all the code necessary to maintain a session, compiled in LSL2, not MONO. Yes, the code needed for menus can memory intensive, but menus are not required at all.

Back in 2008, I wanted to store sales data for my stores, so I created a simple in-world server object. I would periodically move the data off to a spreadsheet on my PC with copy/paste. I did that for years with great success, even though the storage space was quite small (16k). In the event memory got low, I would drop old data. I used email and chat history as a backup, so I had two redundancies. Nowadays I use HTTP and an external server. How the pay-in-instant-refund idea got traction with game creators is a mystery, but even in a pre-MONO and HTTP world, there were more robust options. If it were me, I would've complained to the creator for clogging my transaction history with pay spam until they removed it or made it optional. I'm sure free-to-play games still exist, somewhere in obscure corners of the grid, where people still cling to ideas like community and having fun. Actually, KR Engineering games now fit the bill since they don't accept pay in anymore.

Phil Deakins wrote: I thought you meant my script, since you included my name. I thought you'd misunderstood something, as Innula did. No, I was just mentioning you since the conversation started with your post, was being inclusive.

Phil Deakins wrote: Yingzi Xue wrote: Also, keep in mind (Phil) that your script is only going to pay out when it's designed to do so, which means if your script is set for split profits, for instance, the script most likely won't be exploited as they're paying in more than they're getting back. My script is going to do not such thing. As I said earlier, I don't remember ever writing any scripts that deal in money I merely wondered if a script that gets the owner's permission to take money from his/her account expects a user to pay in. The answer was posted and it was no, so I really don't know why all the discussion about debit permissions has continued. Phil, the "your" was hypothetical, I wasn't referring to an actual script that exists. Innula and I were writing responses at the same time (the script posts), hers just posted a few minutes before mine because I'm an edit freak. Then a conversation ensued.

Innula Zenovka wrote: Yingzi Xue wrote: It would be interesting to know what allowed them to pay a wrong amount. If you can't keep fraudulent payments from happening, at least you can prevent a person's account from being drained with debit permission by not allowing it at all. I'm told it's easy enough to circumvent the options in the pay window simply by using a slightly modified viewer. The other thing people have to remember -- obviously you know this, but some readers may not -- is always to check if (payment == payPrice) before giving out the goods! Most definitely. I always check for price vs paid amount. One can almost obsess about safeguards for scripts. I know I do. Most times I go overboard, but a few extra bytes are worth the peace of mind.