Lucia Nightfire

Maybe soon we'll get access to an unchangeable prim parameter that would be unique enough to reference instead with link,name,desc,settext changes in mod objects, heh.

Maybe soon we'll get access to an unchangeable prim parameter that would be unique enough to reference instead with link,name,desc,settext changes in mod objects, heh.

Forgot to mention if you have Advanced Lighting Model enabled alpha masked prims won't show the red highlight.

A lot of "offsim" island and wave objects use invisible root prims too. Also, Ctrl Alt T won't show red highlights for objects using alpha masking. The object would have to be a source of physics, scripts, sounds, particles or media that would show a red highlight using beacon highlights.

I've filed requests for land owner features that would deter resource abuse in the past. Here are a few examples: https://jira.secondlife.com/browse/BUG-3854 (Needs updating to add/remove paramters) https://jira.secondlife.com/browse/BUG-4153 https://jira.secondlife.com/browse/BUG-11653 LL developers have publicly stated their fears of adding additional options to the About Land floater citing fears of overwhelming users or bloating the menu. This is simply and unjust & undeserved stigma considering the success of Firestorm which has 3x as many options as LL's viewer and is used by a majority of Secondlife users. Land resource controls would deter much of the common resource based grief vectors used today and would spare guests from unwanted experiences and spare Governance receiving multiple reports for the same events.

You can also compare list hashes and replace the list if the hashes don't match. Saves you from having to loop through the list checking for agents that left the parcel every timer event. list AGENTS; string md5; default { state_entry() { llSetTimerEvent(2.0); } on_rez(integer i) { llResetScript(); } timer() { list GAL; if ((md5 = llMD5String(llDumpList2String(GAL = llGetAgentList(AGENT_LIST_PARCEL,[])," "),111)) != md5) { key k = NULL_KEY; integer i = -llGetListLength(GAL); for (; i < 0; i++) { //ghost detection: certain ghosts are seen by llGetAgentList(), one returns NULL_KEY, others a correct agent key, but none are seen by llGetAgentSize() if ((llGetAgentSize(k) != ZERO_VECTOR) && (llListFindList(AGENTS,[k = llList2Key(GAL,i)]) == -1)) { llOwnerSay(llKey2Name(k) + " has just arrived on the parcel."); } } AGENTS = GAL; } } }

And don't forget when LL releases Animesh you can fill your club with animated and interactive barkeeps, bouncers, dancers, strippers and drunks. They will look just like bots but instead of agents they will be objects. The primary resource you'll have to be concerned with is land impact consumption.

The capture height limit is 400m.

As long as the worn crasher is legacy based(prims or sculpts) and not mesh, setting a realistic max complexity will defend against it. The viewer doesn't report numbers over 2,147,483,647 or singed 32 bit value but will still defend correctly if it is exceeded as shown in https://jira.secondlife.com/browse/BUG-41034 If the laggers are mesh, the size of your render memory mainly factors if you crash or not. There was a limited available(3 days) project viewer codenamed "Love Me Render" that was supposed to address the latter by dropping LoD's of attachments that exceeded your max complexity setting as requested in https://jira.secondlife.com/browse/BUG-37668, but it had many bugs as hasn't been worked on in months.

If https://jira.secondlife.com/browse/BUG-5671 was implemented land owners and their guests wouldn't have to see their neighbor's ugly prims.

Never hurts to also evaluate for valid key with something like: if ((key)message) or even string trim of spaces and/or substring 36 digits: key k = llGetSubString(llStringTrim(message,STRING_TRIM),0,35); if (k) I do this mainly with textbox entry as I've accidentally clicked enter after adding the key creating a newline or was copying the key from chat or a spreadsheet and included unwanted spaces.

Throwaway accounts do this exclusively with 0 return time land abroad to restock their alts when their last account gets banned. Governance will not remove the ban boxes no matter how many times you AR them either.

I'm sure Cake will be a different version that these so does that make it a Straight Flush? heh

http://wiki.secondlife.com/wiki/LlSitOnLink sadly won't work from an HUD as the function is host centric. You will have to execute it from the rezzed object you want targets to be forced sat upon. I lobbied to get it to allow remote sitting on anything the target owns, but it was denied. It seemed the author wanted the feature to be as simple as possible which is a shame.

I've heard certain dens of sin like visitors who are young, dumb and full of.....fun.

Updated? There was nothing special before and nothing special now.

LL is currently working on animated mesh. This will revitalize the pet/breedable market as alpha cycling and puppeteering means will no longer be necessary since an actual avatar skeleton and animations can be applied instead. Now if only LL would just make an effort into combatting no-copy object duplication...

I'm curious if the driver for this feature and animated mesh was more to help reduce lag and scene render memory than it was with the actual demand from users and creators, heh.

Main Channel went to 17.05.05.326149 Magnum & Cake went to 17.05.23.326524 LeTigre & BlueSteel went to 17.05.22.326523 That'll be $27.50

It just doesn't sound intuitive or user friendly to have to turn on edit links and scale the root prim just so the rest of the link scales up or down by script. If they have can already scale the root by hand, wouldn't they just be able to scale the whole thing by hand? Am I missing something?

These functions also make scaling simpler than looping through all links changing sizes, local positions and rotations. http://wiki.secondlife.com/wiki/LlScaleByFactor http://wiki.secondlife.com/wiki/LlGetMinScaleFactor http://wiki.secondlife.com/wiki/LlGetMaxScaleFactor

https://jira.secondlife.com/browse/SVC-2622 may be of interest.

Afaik, supplemental animations are only going to be used with new animation override functions. You might want to confirm that at the next Content Creation meeting.

Animated mesh is still an object linkset that has a root link and will allow linking and delinking. Legacy prims will perform just as they do with any linkset. They just won't be apart of any animations since those are only rendered with mesh links that have rigging data. This will allow ease of building scenes, settings, buildings, furniture, vehicles, etc. and combining them with animated mesh, especially with existing content. It will allow packaging them for rezzers as well. Animated mesh is not an only-rigged-links exclusive. As far as land impact based on bones actually being used, wouldn't the animation itself dictate what bones are "dead" or "freewheeling" and not the skeleton. As far as we know there will be no skeleton customization offered.

Personally I don't think land impact should need anything special other than a minimum value, sort of how pathfinding characters are done, but with legacy prim land impact being honored instead. With pathfinding chars, legacy land impact is not honored, meaning, a 255 link linkset or 25000 land impact, tortured materials legacy prim will become a 15 land impact character with llCreateCharacter(). Mesh land impact is honored, so a 900 land impact mesh pf char will still be 900 land impact with llCreateCharacter(). So with max([32 or 64,actual land impact]) that only increases with prim torture, material changes or size changes like any normal linkset, I don't see anything else special is needed. A minimum is the only thing needed to curve abuse as far as rezzed animated mesh is concerned. That is to prevent rezzing thousands of 1 land impact meshes for tiny critters like bugs or flowers, etc. With attached animated mesh, there will have to be something else done, whether it be a hard limit on # of attached animated mesh allowed or a # of slots consumed by a single animated mesh.