Void Singer

Sion Pearl wrote: I have usernames turned off, so I'd see him as Paul. J. Franklin. Even with usernames turned off, you still see the username if you mouseover a resident. I am not sure I understand why usernames are such a big deal. because usernames are constant and unchangeable, whereas display names can be duplicated. for instance, I could set my display name to "Scion Pearl" and pretend to be you.... which might not be a big deal for some people, but it means if you are a content creator I can screw with your customers, and if I'm I'm a griefer, I can get you in trouble for what I did... additionally display names are often used by griefers to make it even harder to report them (for people that can't see their usernames) by using extended unicode characters. as well as to try to get around policies on g rated land or general LL policies (names/groups are not supposed to have foul or abusive language in them)

and now since it looks like you three are done (I hope) here's the same script with optimizations and simplifications, to take it a step or two further in the learning process (if it makes no sense, ask, if it it still makes no sense, that's ok, because it's meant to be a bit more advanced) //-- Void's Edit integer giVisible; //-- default off switchVisible(){ giVisible = !giVisible; integer i = llGetNumberOfPrims(); //-- use a count down loop instead of a 1 to X loop to save a variable do{ //-- PRIM_NAME is ok, but why not PRIM_DESC ? it would let you name the parts AND still glow individual parts //-- (~llSubStringIndex()) same effect as (llSubStringIndex() > -1) //-- (string)llGetLinkPrimitiveParams( i, [PRIM_NAME] ) == llList2String( llGetLinkPrimitiveParams( i, [PRIM_NAME] ), 0 ) //-- testing if the string is anywhere in the text is kinda dangerous, cause it could be... anywhere //-- instead, you might want to test if it starts with the string, or if it's in a certain spot, but I've left it alone here if (~llSubStringIndex( (string)llGetLinkPrimitiveParams( i, [PRIM_NAME] ), "glow" )){ //-- we stuck all the variables in here since the same ones are used every time, and then multiply them by the hide/show value llSetLinkPrimitiveParams( i, [PRIM_GLOW, ALL_SIDES, 0.25 * giVisible, PRIM_COLOR, ALL_SIDES, <1.0, 1.0, 1.0>, 0.4 * giVisible ]); } }while (--i); //-- considered using a list of prim numbers, built in the changed event, but changing the name of a prim does not fire a changed event } default{ state_entry(){ llListen( 9, "", llGetOwner(), "" ); } listen( integer channel, string name, key id, string text ){ //-- reuse channel for a test integer and check to make sure we got a valid command //-- make sure to strip extra spaces and lowercase the text in case the user added a space, or capitalized //-- (~channel) == (channel != -1)... if we get a command that we don't know, it will be -1 //-- other wise we get FALSE/TRUE to test against our current cisibility and only change if it's different if (~channel = llListFindList( ["hide", "show"], [llToLower( llStringTrim( text, STRING_TRIM ) )] )){ if (channel != giVisible){ switchVisible(); } } } touch_end( integer num_detected ) { if (llDetectedKey(0) == llGetOwner()){ //-- this should really have an if that checks the name of the touched part, //-- and if it's a certain part THEN switch visibility. switchVisible(); } } attach( key id ){ //-- this is actually kinda sloppy since it will fire on detach AND attach //-- but it lets it start going invisible before it gets attached, so //-- the speed is a bonus if (giVisible){ switchVisible(); } //-- however, the on_rez event might be a better choice, if you use //-- !!llGetAttached(), so that you can make everything visible if //-- the object is rezzed to the ground (as people often do for editing) } } the idea here isn't to show anyone up (I'm pretty sure everyone helping was keeping things simple), but to demonstrate for the people who are at the simpler level what improvements can or might be made =)

events can be dumped on state change change it you are not careful (all queued events after the event a state change is called from, or any queued during a the state exit event). the workaround is not to use state exit and to call a fast timer and state change from there, but events could still be lost if they queue up after the timer is called but before it is fired. the only other workaround is to never change states or never use events that can fire without you being able to handle them. additionally, some events, if triggered before the previous one of the same type has fired, will be replaced the current one (not true for most events that support "detected" functions, IIRC sensor, does this, "target" events, and run_time permissions) [and/or may be ignored if they try to queue while it's firing (on_rez?, attach?), this part is not thoroughly tested] and of course, if the script is set not running, those events won't be fired, and if it crosses a region boundry or goes back to inventory before being set to running again all queued events will be lost. and IIRC if you are in a no script zone, and have not taken controls, events queued in that zone may be lost on region change. I have never seen an attach event fail to fire outside of those circumstances though.

Perrie Juran wrote: Would it be possible to make a mobius strip in SL? And please, no punning. torus, twist 90/-90, hole size y: 0.05 although if you want interesting, try size <0.01, 1.0, 1.0>, hole size 0.5/0.25 and twist 270/-270 or 360/-360 you can also bend torii into single prim rifle slugs, and single prim mushrooms by twisting them in the same direction and cutting them.

it all depends on where you go, private estates and land owners tend to be pretty quick about dealing with that stuff when they have staff around. me I kinda like griefers, because they always wanna play "my gun is better than your gun" (aka the ruler game ::cough:: ).... and I have a gun that bans them, teleports them home, and ejects them if that fails... not once, but repeatedly, at any altitude for the whole region I manage....

don't suppose that's related the LUF?

:: coughs :: I guess "female" was a bit subtle for a joke... what I meant was "it has no ~balls"

you can thank me for suggesting that nPose get a home on the wiki then, and Innula for maintaining it, and Nandana for asking her to (and writing the original) =)

if it'd been posted 3 days earlier I'd have thought it was a joke...

I actually worked on methods to make this work once (and the reverse, mario world style gravity around a small spherical surface)... it can be done, but it's really choppy, and requires more than a little prep. it cannot be done natively at this time, nor is it an expected ability in the near future. as noted above i can be faked for some scenarios.

psst Pete, nPose is a female sit/pose system... (it's vanilla too... no props)

:: reads post :: :: reads Signature :: :: blinks :: :: shakes head profusely to clear it :: anyways.... child avatars involved in sexual activities are not only prohibited by the Terms of Service, they are in fact Illegal in most jurisdictions throughout the world (though ages and depictable actions may vary by location). as suggested, you should file an abuse report (help menu --> report abuse), in the category of "age play" with a screen shot and the exact time and location of the offense.

well no, but if they don't act on it, then what good does it do them, and what threat is it? for instance, to us?

Phoebe Avro wrote: LL need a 'Panic Button' of some sort just so residents can inform them when they have a grid wide problem to not have such a mechanism is foolish at best that's not the same thing in my minds as a ticket, but it IS a fantastic idea..... a simple "trouble report" ability, region outages, service failures, what have you.... with a little warning that it is not for problems affecting individual accounts.... that way if inventory or L$ or teleports are failing badly, people can easily report it it, and those reports can build up, and if they hit a threshold, some staff person has to check on it.... ya know, I'm going to see if I can't figure out who to pitch that idea to

Cerise wrote: In a less direct way, the company has better information about whose word spreads fastest, and hence what needs to be countered or supported first. I'll concede that knowledge base participation can be filtered like that, but that last line there that I quoted... think about it... to counter or support what being said by the voices that are driving opinion in the community, they have to actually DO something about it. If they attempt to bury it or gloss over it they're subject to backlash from those people, and things like Streisand Effect. sociologically, the change in behavior is to the advantage of the people doing the helping and driving opinion, because that's what LL has to respond too the quickest..... this works to improve LL's image, by responding to the major community trends that cause dissent, satisfying the greatest number of people. rather than think of it as manipulation (everything is to some degree, and this goes both ways) it's much more productive IMO to treat it as mutually beneficial... for everyone... occasional users get to draw on community experience, the most prolific contributors who see a larger piece of the picture from the trenches point the way to what needs the most attention right now, and LL responds to their direction, and gets a filter for what the major issues are, no guessing required as in the past., making them more responsive (not just in theory but practice) and a large network of people who are passionate about the product and want others to enjoy it as well. ok, so that's not how it's sold to the suits in marketing that want control and ROI, and you and I both know that... but we both also know you can't build a feedback driven system that only works to one positions advantage when there's a choice by either party

::resists temptation::

oh, I think I'll be subversive... you should definitely post in Customer / Technical Support for Basic Members - A New Idea

Dora Gustafson wrote: @Void: yes ban lines are yellow now. You just revealed you are not using Viewer 2 heck I would have thought that was common knowledge (heavens know I loathe it many different levels for breaking things that worked fine before)... to be fair I don't use it much, because of several key bugs and issues, but I also don't tend to go many places where I'd be seeing ban lines either... I also prefer many of the extended toolsets that TPV's offer. and actually, I think I have seen them now that I think about it, and wrote them off as someone using a megaprim wall to do their own version of ban lines... and the increased solidity does improve the look.

I don't remember them telling us why, but a guess would be reconsolidation as a US based company was part of it...

there's a small problem with that theory Cerise.... just because a person is helpful, does not make them supportive of the main cause, and associating their efforts also exemplifies them, giving them a larger voice within the community which can lead to more weight being given to those peoples negative perceptions.... for instance, most of the top three tiers of ranks, while being very helpful to others, are also very critical of a broad range of LL policies and technologies (or lack thereof), and there is a very strong feeling of dissent with LL that flavors their contributions. surely THAT is not the association they are hoping to make? granted it tends to filter in well founded and thought out criticism and discount poorly crafted ones, and it doesn't actually remove it. You can see and feel the almost palpable air of discontent among those ranks, that also have facts and experience to back up their points of bitterness. ETA: @Pep: time for me to do a little experimenting...

is that supposed to make them less ugly? ah well... it's still true that it's likely to be a configuration mishap, but i guess we can add, making sure the land is not set to only allow group members or people with land passes.

Sigmund Leominster wrote: [...] If only we could help [...] you could try not giving it the attention he so obviously craves? or barring that, suggest he take up photography using historical methods and hope he leaves cyanide on utensils he eats with or has an unfortunate accident making flash powder....

Yellow?!? normal ban lines are RED.... so if they're seeing yellow... make sure they don't have "view parcel borders" turned on (the only yellow lines I know of), and on an outside chance, have them make sure that their maturity level matches the parcels, and that they pass any of the optional restrictions you have turned on (restrict parcel to Payment Info On File, and restrict parcel to Age Verified). your security orb shouldn't have anything to do with seeing and sort of ban lines unless it actually bans someone, so this is likely to be a configuration issue (could be on your end, could be theirs, or a combination of both)

Darrius Gothly wrote: I think you might want to check with Void though .. just to make sure she's not getting your missing text and quotes. *GRIN* nope, nothing here....

Darrius Gothly wrote: [...] Receiving Kudos advances someone's Rank. [...] I know a few people have said this... but I haven't witnessed it... I know I reached Advisor before kudos had been enabled, and before the backtrack to add kudos for old posts occurred. so did several others, who could all be witnessed putting out a lot of answers in the forum of the same name. I do know that (accepted) "Solutions" raise it, although perhaps only in some forums but not others, and I don't think there was much back tracking if any on those, because I know my count would be higher on my user page if they were.