elleevelyn

no I am saying that when you obtain the parcel you pay the 1st month tier in advance by USD money in your account I mean a valid payment method. If you/we don't have this then the parcel can't be obtained. Get message: Insufficient funds/payment method not valid if did go to prepay then isn't necessary to be a Premium member to obtain mainland.

from revenue pov, prepay is better. The provider doesn't have to deal with delinquent accounts. And if have to prepay in USD then is simpler to add the setup fee in USD to the ticket is also easier from the customer pov. Before can obtain the parcel, must have USD in your account. Linden will "sell" the parcel to customer for L$0 if the fee is in L$ for a parcel obtained from Linden thru a ticket, then have to have both USD and L$ in your account. and like a giftcard if don't claim the parcel then don't get your money back - prepay is a use it or lose proposition

yes on the first, and no on the second on the first a new mainland could be - Bring Your Own Home - fixed size parcels of varying sizes say 512, 1024, 2048,4096,8192 & 16384. No subdividiing - prepay tier (+ Linden admin/setup fee) to obtain/buy parcel then must have the 1st month tier in your account Billed monthly in advance thereafter - can have as many parcels as you want - no discount for larger holdings. Price per sqm is the same - parcels can be rented and traded/sold between residents - to obtain parcel direct from Linden file ticket, pay Linden admin/setup fee plus 1st month tier on the second. It may be lucrative should the Damage 2.0 system eventuate then buckshot wielding porch sitters all be marched off to the new Outland continent(s) be quite fun if you a scallywag. doing drivebys of grumpy buckshotters sitting on their porches yelling Get Off My Lawn You Scallywag !! assuming that Linden don't give any Damage 2.0 control to the parcel owner

this was true. Ended up llike a game leaderboard for griefers

comparative frameworks for this kind of app // one state integer active; default { collison_start(...) { if (active) return; ... shrink and hide collision prim ... rez props ... start sensor active = TRUE; } no_sensor() { ... remove sensor ... derez props ... restore collision prim active = FALSE; } } // two states default // state inactive { collision_start(...) { state active; } } state active { state_entry() { ... shrink and hide collision prim ... rez props ... start sensor } no_sensor() { state default; } state_exit() { ... derez props ... restore collision prim ... note: sensor is local to state so is auto-removed when the state exits } } // three states where state default is used to do a onetime setup like read params from notecard, etc default { state_entry() { .. do onetime setup ... state inactive; } } state inactive { ... same as two state above ... } state active { ... same as two state above, with no_sensor state inactive in place of no_sensor state default }

pretty much yes, while there is demand for Belli then Linden will keep printing regions. Is how Linden did the Old Linden Homes continents, and how they did classic mainland the Linden plan, which Patch Linden has alluded too, is to sink the Old Linden Homes continents at same future point, which will necessarily mean force marching the few remaining holdouts to Belli is no reason why Linden wouldn't do the same with classic mainland as it empties out. Start sinking regions into the sea, force marching the holdout residents to the nearest remaining regions. Which may spark a renaissance in classic mainland living, there being fewer on offer than before

a thing is that collision_end event is not always reliable. The server can throttle collisions when it comes under stress, when so collisions events don't always fire a way to mitigate collision throttling is to use collision_start to start the sensor using only the no_sensor event. As the tidyup/derez will be done when no_sensor event fires (no agent is present) then the sensor period can be set to some minutes. 3, 5, 10, etc a way for this kind of script is to use 2 script states: Active, NonActive. Active when avatars present, NonActive when they aren't Active state has a no_sensor event. NonActive state has a collision_start event. The two states have one or other event, they don't have both

the marketplace rules are here: https://marketplace.secondlife.com/listing_guidelines there are a number of Youtube videos showing how to set up a marketplace store. On Youtube use keyword: secondlife marketplace

a issue with this is when a person puts a whole mainland region up for sale they get snapped up pretty quickly no matter where the region is on the rare occasion that a whole mainland region is abandoned (or taken back by Linden thru non-payment of tier) then the region gets snapped up pretty quickly also when it goes to auction. Sure Linden could forgo the auction L$, put the LDPW in to make 8 x 4096 Mainland 2.0 for $US176 month tier. Which is $US10 per month more than the $US166 standard mainland tier. The $120 minus the L$ auction price given the rarity of whole mainland regions being abandoned and the quite low additional return of $10 month (assuming full occupancy at all times) vs LDPW doing nothing, then I can't see it as a ongoing project for Linden to do

some suggestions fill out your inworld profile. A blank profile is not helpful to prospective partners or customers if you have already made products for people inworld then make some for your marketplace store. This way prospective customers can see your work product as inworld objects. And you can make some L$ thru the sale of the products, while also doing custom work and collaborations

i did wonder how Firestorm was going to overcome what you mention here - sending a undeform animation to the server for broadcast to all nearby avatars, after stopping the grief animation so OP, and others affected, still left with this LSL script if they want to stop the grief animation and broadcast the undeform animation, every time the grief animation is detected

Firestorm 6.6.17 (70368) now has a fix for this I think menu: World\Animation Explorer, which now allows the blacklisting of animations started by a script owned by another person to which we previously granted permission. While it doesn't/can't revoke the other script's permissions, it does stop and blacklists the animation itself from playing on us i am not a regular Firestorm user so I haven't tested this extensively like I dunno if the fix only stops the animation playing on our screen or whether it also does an undeform. menu: Avatar\Avatar Health\Undeform Avatar

my assumption is that OP script is applying textures they have provided your assumption is that OP script is applying textures the HUD user has provided if the first assumption is correct then modify perms if the second assumption is correct then both modify and no-modify perms can be involved if I did have a question for OP it would be: Is it that we wanting to prevent the action when the user touches the wrong face for the texture they have chosen to apply ?

this raise the perennial question. When we are providing a asset that is to be applied to change the appearance of an object then why would we provide the asset as no-modify ? as someone who uses other creators's assets when building/modding then I have zero interest in no-modify assets. They go straight to my trashbin. No-transfer sure I can work with that. No-modify am not interested

it can get a bit cumbersome to track changes to linkset faces but is doable https://wiki.secondlife.com/wiki/CHANGED_TEXTURE some p-code showing a way this can be done // p-code // script in the object being changed list textures; list getTextures() { ... get the texture uuid of each link and face llGetLinkPrimitiveParams ... save (link,face,texture) as single csv string item to a list return the list } default { state_entry() { textures = getTextures(); } changed (integer chamge) { if (change & CHANGED_TEXTURE) { list temp = getTextures(); integer stop; integer index = llGetListLength(temp); while (~--index && !stop) { string item_new = llList2String(temp, index); string item_old = llList2String(textures, index); if (item_new) != item_old) { list params_new = llCSV2List(item_new); list params_old = llCSV2List(item_old); ... here we have the link, face, new texture uuid and old texture uuid ... do something with this info include repair if necessary stop = TRUE; } } // textures list becomes temp list for next change event textures = temp; } } }

it can go easier using Replace Inventory Links right click on the old eyes in Inventory - menu item Replace Inventory Links. then drag drop the new eyes onto the dialog New box. Press Start button and voila. All your outfits will have new eyes in place of old

grrr! you right. I toggled it on and was not doing the moire thing. So I relog and is doing it. so bummer

going back a few years to another life, I used to hang out at OIP/HIP area i am standing up by the OIP temple. This week old new person shows up wearing LLQuadDog avatar. So I say Hi! they say hi back and we have a chat. They quite excited telling me all about the adventures and sights they have seen flying round and how much fun and amazing it is all to them over the next week they show up everyday for a little bit chat before fly off for more adventure. New people full of curiousity, Is a joy to be by them one day they stay a bit longer. Then they said: I better go now because is getting dark, and I might not be able to find my spawn place, which some of the people told me is my home . I got lost the other day in the dark and had to logoff over the sea. When I log in the next day I was at my home so I was bit relieved about that so I ask them about their home and they describe totems and fir trees, so I go ah! Waterhead, you have quite a long flight home. And they say: yeah I better go. and in that moment I couldn't bring myself to tell them about World\Sun\Midday because I didn't want to break their immersion. And off they flew anyways few days later they show up again and it starts getting dark. And I say is getting dark you don't want to get lost and drown in the sea again if you can't find your way home. And they laugh and say lol I was looking at the viewer menu options yesterday and I found out that I can stop the sun. Why didn't you tell me that lol I explain that I didn't want to break their new person experience, that we only get to experience this one time. Like childhood, we only get one go at it. And they laugh and say yeah that's true, has been really enjoyable working this game out for myself new people yes so I don't tell them about World Map or Teleport either. And off they flew toward their home place of Waterhead in the midday sun

seems this has been fixed in latest release 7.1.2.72151791427.1.2 so Iam pretty happy now

https://wiki.secondlife.com/wiki/LlGetObjectDetails begin with OBJECT_RENDER_WEIGHT

display boards like this are done with https://wiki.secondlife.com/wiki/LlRequestAgentData DATA_BORN is the rez day

is pretty simple from a coding pov to do yes. As simple as: list homes = llListSort(homes. 1, TRUE); list homes = llListRandomize(homes, 1); product manager goes thru the impacts these two methods will have on the customer base and picks one

gaming a pseudorandom system is about identifying the source (seed) of the pseudorandom number generator, the method use to obtain the seed, and the method used to generate the outputs. There is no other identifying/discovery method that can gain us information to better predict the next number. Is why people give up on doing this with a sorted list then we can gain information independently of the system, that will indicate to us at what time a home we are interested in is most likely to appear. How we gain the information I am not going say in any detail, but is pretty trivial to do, and when people do work it out then they are going to do it. A lot more people than previously who tried to game a pseudorandom number generator edit: for completeness with a shuffle list we can't predict the order of the homes remaining on the list, unlike the sorted list where we know the list is ordered by abandon date

is true about the natural occurrence of variation due to house retention lengths (rate of play) a issue with the sort by abandon date method is that it can be gamed, resulting in people not into gaming wondering why somebody else seems to get nice homes at a frequency rate greater than theirs. Which creates a perception problem among the customer base about fairness i am not going to get into how this can be gamed. Just say that some people will do it. from a implementation pov, knuth shuffle is O(n) . quicksort is O(n logn). Is a bit quicker overall to do a shuffle. And given that shuffle or sort is going to happen one tiime, when the list is flushed, then I would go with a shuffle to avoid the gaming issue, moreso than it being a little bit quicker

addressing your point when the AvailableHomes list/cache is a subset of AllAvailableHomes then a serial index can make sense and be the most efficient how might this be done ? 1st pull (any person) gets 1 2nd pull (any person) gets 2 3rd pull (any person) gets 3 and so on til the serial index reaches Magnitude/listlength. On which: Claimed Homes removed from the list/cache. Abandoned Homes on the list not removed. New Magnitude. Serial index reset to 1. And start over in this case, from the users pov, serial index increment is better than random() as it means they will get different Homes in each of their upto 5 daily pulls - assuming the list has 5 or more Homes on it at some point Magnitude lowers to some level, on which the AvailableHomes list is re-populated on re-populate, shuffle the list (feistel or knuth). or more correctly shuffle the list index. The serial index pointing to the list index which points to the Home entry in the list. We have shifted the shuffle from the serial index to the list index why shuffle ? 2 homes from Region A. 3 homes from Region B. 1 home from Region C, etc. We don't want to present these homes in block order. Caveat: In either case (block order or shuffle order) is still possible for a person to get homes on the same region in their 5 pulls. Depends on how many people are playing at the same time and their combined RateOfPlay pattern. Altho when fewer people are playing at the same time then shuffle order is better for these fewer players. The fewest being 1 player remaining questions are: 1) when the AvailableHomes list is re-populated should all remaining entries be flushed, the list filled with a new set from the AllAvailableHomes list ? In my view the answer is yes 2) when should the re-population occur ? In my view the answer is when the list lowers to some level, and every X hours regardless of level. Every 24 hours, 48, whichever picking which homes on which regions to populate the list with is another exercise. The algorithm to do this is a feistel network if we want to cycle AllAvailableHomes thru the AvailablebHomes list with the widest distribution i not get to deep into how this algorithm works in this case. So I try keep it brief example: 4 regions with 4 homes on each. 4 blocks of 4 homes. Total 16 homes. The goal (widest distribution) is to place 1 home from each block into a set of 4. 4 sets with a home from each region. Present each set in order feistel network does this as is fundamentally a block cipher. Arithmetic feistel network deployed when the number of homes on each region and/or the number of regions is not in the binary sequence note that the distribution goal can be lower. Like 2 homes from any region and 1 home from any of the other 3 regions. The algorithm when coded as a generator stops sooner will Linden do any of this ? Maybe, maybe not, dunno my main point in all of my posts on this topic is that "random-looking" is better than "random" from the Linden Home owners pov. Random-looking is the outcome of a serial process applied to an arrangement. [1,2,3,4,... etc] is an arrangement as humans we may not see [1,2,3,4, ..10] in the same way that we see [6,3,2,5, ..., 8] as this latter "looks random". Algorithmically tho is no difference