elleevelyn

could be yes. Region servers can be manually restarted when they get stressed. So is no reason the Linden Homes server couldn't be manually reset

there is the list of AllHomes and there is the list of AvailableHomes, not necessarily the same thing as some homes can be broken and marked as NotAvailable, and some whole regions also marked as NotAvailable the likely explanation (from everyone's experience) is that the AvailableHomes list is relatively quite small. Topped up on a needs-must basis with some recently abandoned Homes and some from the not recently abandoned AllHomes list it could be that the re-population is triggered when the claimed level reaches some predetermined point. Same as how caches work say the AvailablelHomes list was 100. And say at 80% claimed then re-populate. with 80 new selections added to the 20 remaining. Problem is that can get stuck on 21. A catatonic state. Everyone playing is abandoning the same 21 Homes over and over. it could be triggered at 60 rather than 80. It could be 50. Dunno. But it can get stuck, go catatonic, when everybody is abandoning within the same period. the abandons already on the Available list staying on the list we could think maybe set the trigger to quite low. Like at 20%. Problem is that if we don't flush the whole cache then we got people playing for the same 80% of undesirables, and when ire-populate, only 20 new additions are added. Can end up with 100% undesirables, which only changes when 21 people give up and keep the undesirable Home they don't want having a short AvailableHomes cache list is not a issue in itself. The issue is how and when iit is re-populated - full fllush on trigger is better than top-up. Still left with how to fill the cache from the AllHomes list excluding the NotAvailables. Most efficient way is feistel network or knuth shuffle if the widest range of cache selection is the goal ps add. I not be surprised at all if it uses a cache. Webservers like caches. From all of the experiences that residents have had, then Somebody Linden coded it up as a top-up cache rather than a full flush cache. Because top-up is typically how caches work. Like our SL viewer cache. when it gets full then remove some from the top to make room for new stuff

try the re-rez as Casidy says as to why this can happen, is typically the script server not always actioning MouseDown. Mouse button has 3 states in LSL: MouseDown = touch_start event. MouseHoldDown = touch event. MouseUp = touch_end event. Some scripters are aware of the issue of MouseDown, so they script using touch_end (Mouse Up) which is more reliable edit add. Is not only the script server. It can happen at times with the viewer generally also. Is noticeable to me that when I am editing outfits the Save Changes button doesn't always work. The screen button widget shows itself being pressed. But the changes are not saved to the outfits server, the screen button reverts to Save Changes and not greyed out like it does when is actual saved. This is an intermittent problem as it doesn't happen all the time. But once it starts then it typically takes a relog to fix

drifting is doable in SL. Is a number of vids on Youtube showing this. Like this one

is as Love says. open_menu is what should be used in touch_start event touch_start(integer start_param) { // restrict touch to owner // when we don't restrict then owner will get the dialog menu // whenever anyone touches if (llDetectedKey(0) == llGetOwner()) { open_menu(llGetOwner(), "Is 2 plus 2?", ["4", "12"]); } } when we want everyone to touch and get the dialog menu then touch_start(integer start_param) { // allow everyone open_menu(llDetectedKey(0), "Is 2 plus 2?", ["4", "12"]); }

sorry, I inferred rapid changes from a projectile reading the arena settings which is not going to be the case in the new world of scriptless projectiles. For sure some projectiles might be scripted: collision effects, tracker bullets. drones on rez, etc a thing about not working as expected/intended. It is not expected that a fluffy popgun can take out a physical tank with one shot. yet it can. That such a tank can also take out the fluffy popgunner in one shot, is neither here nor there really in this context. Same with someone turning up to a snowball fight with a rocket launcher. Will still be up to the arena owner to manage their arena aesthetics to your main point. I do understand your argument. I just point out that if the arena owner has no say in the damage/energy arena settings then is a Linden game system is not unreasonable for an arena owner to set the maximum damage for hits. Like in a tank battle tournament - one hit - 100% damage and you dead. In a social setting 10% damage, takes 10 hits to get dead. The tank on rez, reading the region settings and making this info available to the tank operator leveling this up. Tank vs Bradley. Tank can destroy Bradley with one hit. Bradley can destroy Tank with 10 hits say. Tank uses PROJECTILE_1 = 100%. Bradley uses PROJECTILE_2 = 10%. Nothing prevents either Tank or Bradley from switching between PROJECTILE_ when the weapons maker has scripted it (fluffy popgun) which is where Energy comes in. Suppose Health is 100 and Energy is 105. (Energy is some percentage greater than Health to prevent zero sum situation). To inflict PROJECTILE_1 100 Damage costs 100 Energy. leaves 5 over. PROJECTILE_2 costs 10 Energy,, leaves 95 Energy after the first shot the management of Energy (within the rules of the arena - damage env settings) is then left up to the player as it should be. Not to the arena owner, the weapons maker, or Linden is just a question of how many levels of PROJECTILE there are. Understanding that arena owners may disable some PROJECTILE for example in a snowball fight arena, all PROJECTILE are disabled except for say PROJECTILE_8 which arena owner has set to 5%. Have to hit them 20 times with a snowball before they die. Doesn't matter if turn up to the snowball fight with a tank. Any customer that thinks they can take a tank to a snowball fight (fluffy popgun think) is thinking wrong and if they do then they be shown they are wrong however a tank on a tank battle arena will work as expected edit add. We getting into sophisticated weapons systems now, but a weapon can be scripted to be under full control of the player. Like the weapons HUD reads the arena env settings. These being max. settings, the player via the HUD can reduce the amount of damage and energy expended. Who would do this ? one example: An expert helper player showing their friend how to play. Friend is firing at 10 hits to death. Expert is firing at 20 hits to death. Same weapon delivering at different rates as determined by the player another example: zombie hunting. The beginner friend can single shot a NPC zombie that is scripted to die at 10% damage. The expert friend chooses to double tap the zombies. They race to see who wins the zombie hunt

i agree. Random, meaning uniform distribution, is not fair in some use cases. The allocation of Linden Homes is one of those cases as you say with uniform distribution is possible to always get the same number. When so we can say that this is a catatonic state for the user on the receiving end. Is not enough for the implementer to say: is random so is fair. Is not fair at all for the individual receiving. Linden Homes should not be a roulette game with serial distribution of a set of ordinal numbers [1,2,3,4,5, etc] where the last abandoned home is added to the end of the list then when there are say 100 homes available then at 5 pulls a day will take 20 days for that last home to show up. Which is fine when the home is a undesirable, but not so fine when is a desirable. (Desirable being subjective to the individual) In 1971 Horst Feistel invented a block cipher algorithm (feistel network), which is pretty much used in most encryption methods in some modification or other. The purpose of a block cipher is that the output can be decoded to get back the original value. it follows that when we encode all inputs/values of a set then no two outputs will be the same, and they can be decoded back to the inputs without loss given this then a feistel network can produce a "random" arrangement (permutation) of a set of ordinal numbers. So with [1, 2, 3, 4, 5] there are 120 arrangements: 5 * 4 * 3 * 2 * 1 = 120. Which can all be produced given a "seed' in the range [1 .. 120] taking the cookie idea mentioned earlier then it need only contain the set id (type of home), seed (arrangement id) and the serial index number. Incrementing the index by 1 to produce the next home looks random to the user but it isn't - is deterministically biased compared to uniform distribution. A thing is that many people like bias when it comes to 'random' meaning that they like it when it comes out [3,1,5,4,2] . Much more than they like [1,5,1,3,3] or [2,2,1,1,2]. And when it comes to Linden Homes then many means most if not all people has been about 53 years since Horst Feistel invented this algorithm, so is not like is still waiting to be discovered. When a SL resident can implement a arithmetic feistel network in LSL then this is not something beyond the ability of a Linden professional programmer to do for sure the programmer (more the product manager) has to decide what happens on change Like when the next available home has been taken by another person. The most common method is to increment the index til it matches a available home. Understanding that when the index exceeds the magnitude, the index rolls over to 1 and starts over the other change happens when the seed is changed. Which requires a reset. On reset is when the homes abandoned since last reset can be added to the available list, homes claimed removed. Which gives a new magnitude (number of available homes) ps add. Alternatively to do the same thing then create an index list and do a Knuth shuffle on it (similar to llListRandomize). A feistel network doesn't require a pre-shuffled index list, which is the only difference in effect pps add. For those still reading who maybe into this kind of thing yourNewHome = llFrand(llGetListLength(AvailableHomes)); this is pretty much how it works now. llFrand (equivalent) produces a uniform distribution (like a roulette wheel) if as a Product Manager, my programmer offered this as a solution for my Linden Homes paying customers then I would give them my stoneface and say "Really!" and if they stoneface me back I would say "REALLY!" and not give them any cream cake for afternoon tea. Til they come back from reading up on Knuth, Feistel, Galois, Margolis, et al. and go to me "Oh! yeah" and I will say "Yeah!" and off they will scurry on the promise they will get two cream cakes next afternoon tea. Seeing as how I ate their other cream cake myself due to all the agony I was feeling when I had to say "REALLY!" 😻 annnd if I was the programmer and my product manager said we going with the one liner solution then I put in for a transfer to another team. There are somethings that all the cream cakes in the world can't compensate for

and you're name is bluescutti and you're 13 years old and the game is NES Tetris and why not give it a go and see if can break it bluescutti is official Legend. 34 years people have been trying to break this game by force the registers to rollover, and bluescutti wasted it in 40 minutes https://arstechnica.com/gaming/2024/01/someone-has-finally-beaten-nes-tetris/

correct the code, then post it again - is best that Library subs be complete. And when you do then wrap it in a code block - 7th toolbutton from the left

Flarianna Fluffington Benzo Saccharin Johnen Wicken

only solution is to have your friend give you edit rights on their stuff, assuming that they aren't able to deed the objects to group to move group objects then the object must be deeded to group missed the part about your friend. Sorry for your loss

i don't use Firestorm so I am not sure if it has debug setting: RenderUnloadedAvatar which is in the Linden Viewer 7.1.1 when RenderUnloadedAvatar = False (the Linden Viewer 7.1.1 default) avatars render as a cloud until all their attachments are rendered fully. If they never render fully then they stay a cloud when RenderUnloadedAvatar = True then avatar attachments render immediately - so zombie. And they stay zombie if they never render fully. This used to be the default setting til Linden changed it in 7.1.1

which viewer are you using ?

this is an interesting problem given the issues of collision and collision_end events not firing in all cases. Events throttled which I think has something to do with objects/agents colliding the sim server to pieces a way it could be done is to check for agents in proximity to the link on being triggered by collision_start some p-code // this is p-code // has been written off the top of my head // other than having it compile without error // i have not tested it at all // and is pretty brutal p-code tbf, tho it does show the necessary logic float LINK_RADIUS = 0.5; // link is active when agent has collided with link prim and is still within the link radius float TIMER_PERIOD = 2.0; // period between timer scans // not active active list LINK_COLORS = [<1.0, 1.0, 1.0>, <1.0, 0.0, 0.0>]; list collides; paint() { integer idx = llGetListLength(collides) - 2; while (idx > -1) { integer link = llList2Integer(collides, idx); key agent = llList2Key(collides, idx+1); vector link_pos = llList2Vector(llGetLinkPrimitiveParams(link, [PRIM_POSITION]), 0); vector agent_pos = llList2Vector(llGetObjectDetails(agent, [OBJECT_POS]), 0); integer link_active = (llVecDist(link_pos, agent_pos) <= LINK_RADIUS); // do lookahead to see if more than one avatar on link integer i = idx - 2; integer continue = TRUE; while ((i > -1) & continue) { continue = (llList2Integer(collides, i) == link); if (continue) { agent = llList2Key(collides, i+1); agent_pos = llList2Vector(llGetObjectDetails(agent, [OBJECT_POS]), 0); if (llVecDist(link_pos, agent_pos) <= LINK_RADIUS) link_active = TRUE; idx -= 2; } i -= 2; } // paint link llSetLinkColor(link, llList2Vector(LINK_COLORS, link_active), ALL_SIDES); if (!link_active) collides = llDeleteSubList(collides, idx, idx+1); idx -= 2; } llSetTimerEvent((collides != []) * TIMER_PERIOD); } default { state_entry() { llSetColor(llList2Vector(LINK_COLORS, 0), ALL_SIDES); } collision_start(integer detected) { // add all links and agents to collides list while (~--detected) collides += [llDetectedLinkNumber(detected), llDetectedKey(detected)]; // sort by link numbers for paint collides = llListSort(collides, 2, TRUE); paint(); } timer() { paint(); } }

the main issue is when the Random function has a uniform distribution. meaning any of the available Homes have as much chance of coming up on each roll as any other home. When so then is possible for any kind of Not-The-Same-As-The-Last function to go catatonic. "Catatonic" being a qualitative description for example there are 10 homes available. We have 5 homes (we have seen and abandoned) Homes [1,2,3,4,5] on our Not-The-Same-As-The-Last list. We try for another home next day. The random method selects a home in the range [6..10]. Say is 6. We abandon the No. 6 Home as well. No. 1 home is added back into the available pool. We try again for homes [7,8,9,10,1] and get No. 1 Home again. Our Not-The-Same-As-The-Last list is now [3,4,5,,6,1] and the available homes are [7,8,9,10,2]. And we get No.2 whats the probability that we only get to see one different home each day that we have not already abandoned ? 5/5 * 1/5 * 1/5 * 1/5 * 1/5 = 5/3125 = 0.16% and the probability to see all 5 available homes in 5 rolls, abandoning them all: 5/5 * 4/5 * 3/5 * 2/5 * 1/5 = 120/3125 = 3.84% 96% of the time we will see 2, 3 or 4 homes that we didn't see yesterday we could extend the Not-The-Same-As-The-Last list to more than 5, but at some point we run into sizing issues. Like our Not-The-Same-As-The-Last list could be equal to the size of all available homes minus one this all said. A way to do this is to not use a random uniform distribution function. To use a biased "random" function. And the most biased "random" function is an Arithmetic Feistel Network algorithm which will produce only one instance of each number in the range in some random-looking order. A LSL example of this is here: with this algorithm then we get to see all 5 available homes in 5 rolls in some 'random' order

with Linden viewer 7.1.1 the debug setting is RenderUnloadedAvatar. The default is False when True the viewer does what it used too, attachment bits all over til the avatar resolves, and if it never fully resolves then frankenstein when False the viewer shows avatars as clouds, til they are resolved fully-formed. If they never resolve then they stay a cloud

a way could be to make a whole bunch of template clothing and hair for the body and drop them on the marketplace, full-perms and free. Materials incl. in the template pack and just keep doing it. Every about 3 months, drop another template pack

given that you might want the user to be able to change or reset their nickname at any and all times, then for other things you might want to use more than one listener channel. Like: llListen(12, ... for nickname change llListen(22, ... for other things a script can have up to 65 open listen channels at one time: https://wiki.secondlife.com/wiki/LlListen if you just want to use a single channel 12 then a way is to use a command prefix. For example where "nick" and "other" are commands: /12 nick yourNewNickname /12 nick reset /12 other something /12 other something else parsing the message with for example: string message = " nick yourNewNickName "; // trim any leading or trailing whitespace message = llStringTrim(message, STRING_TRIM); // get index of space separting command from parameter integer space = llSubStringIndex(message, " "); // get the command string command = llToLower(llGetSubString(message, 0, space - 1)); // get the parameter trimming any additional leading whitespace that may be there string parameter = llStringTrim(llGetSubString(message, space + 1, -1), STRING_TRIM_HEAD); if (command == "nick") .. do nick else if (command == "other" ... do other

assuming you own the land in your own name stand on your land. Then (in Linden viewer) menu: World \ About Land \ General \ Abandon Land button before you do this tho, best to take all your stuff back into your Inventory

i been meaning to comment on this, so I do now this method makes decoding a whole lot faster. So when decoding speed is important (and in pretty much every use case it is) then go with this combined method as Tessa suggests

Key2Packed packs a Key into a string of 9 UTF-16 characters - 18 bytes. And because of the encoding method some of the UTF-16 chars will expand when written/converted to UTF-8 LinksetData. the median expansion is to about 23 bytes i will mention that packing already occurs when LSL strings are written to LinksetData, meaning that LSL (UTF-16) two-byte chars < ASCII(128) are automatically converted/written to LinksetData as a UTF-8 single-byte char to compress any string to gain space savings less than UTF-16 <-> UTF-8 conversion. then we need to use a compression algorithm using a model that best fits the data. There are a lot of ways this can be done so ask in Scripting forum, giving an example of the data you do want to compress to LinksetData and go from there

welllll, FPS does mean something. When I have SL open in a window and another app open which I am working in then the SL window out-of-the-box as a background application was set to 20 FPS which is a bit slow as I can see a skipping stutter between animation frames when my avatar is dancing. This is something I do quite often. Turn on the radio stream, put my headphones on and dance my avatar while I am working. And when a song comes on the stream that I really like then I will pause what I am doing and sing and dance along with my avatar in my chair. Music and dance helps break up my work day looking into my NVidia graphics card settings, I saw that I can change up the FPS for background applications: Background Application Max Frame Rate so I changed it up to max. 45 FPS and now my avatar dances a lot smoother when running as a background application. I think the more smooth look comes from the interpolation of 45 FPS being greater than the typical animation frame rate of 30 which most of my dances are set to

this is the most likely explanation I think, probably the only explanation when an orb is not involved

hmm! when we hit a banline on a vehicle then the agent is stopped at the boundary - not over the boundary (the vehicle also being stopped). The agent is not unseated by the act of hitting the banline. The agent and vehicle are stuck in the tape fence, and typically we edit the vehicle and sitting agent off the fence. So something else happened to detach the agent from the vehicle. It could just have been that the system borked in OP instance, or it could be that Linden have changed the behaviour which I am not sure about

i was thinking of another which involved Intellectual Property holders not being paid their share of sales revenue even tho an RL contract/agreement to be paid was in place. The details of the affair are way down in the chat over the street