Qwalyphi Korpov

Emma SecretSpy wrote: Hello all, I'm trying to use this example script from the Wiki, with llOverMyLand. // This script will email you a daily count of new visitors and repeat visitors.// Visitors are counted once per email update cycle. // -----------------------------------// Configuration: customize this script here.// Change this to your email address.string MyEmail = "you@example.com";// This is a number 0 to 96 meters, anything farther away than that will not be noticed. float SensorRange = 96.0;// How often to send email updates.integer UpdateFrequency = 86400; // Number of seconds in 1 day.// ----------------------------------- // Internal Variables -- Do not change.list todayVisitors = [];list allVisitors = [];list repeatVisitors = [];list firstTimers = [];integer newVisitors = 0;integer returnVisitors = 0;string ParcelName; default{ state_entry() { list parcelDetails = llGetParcelDetails(llGetPos(), [PARCEL_DETAILS_NAME]); ParcelName = llList2String(parcelDetails, 0); llSensorRepeat( "", "", AGENT, SensorRange, PI, 20); llSetTimerEvent(UpdateFrequency); // Email me a regular report. llOwnerSay("Visitor Log Started."); } sensor(integer avsFound) { key avKey; integer avNum; for(avNum=0; avNum<avsFound; avNum++) { avKey = llDetectedKey(avNum); if (llOverMyLand(avKey)) { string whom = llDetectedName(avNum); if (!~llListFindList(todayVisitors, [whom])) { // This person hasn't been seen yet today. todayVisitors += [whom]; if (~llListFindList(allVisitors, [whom])) { // This is a returning visitor. returnVisitors++; repeatVisitors += [whom]; } else { // This is a first-time visitor. newVisitors++; allVisitors = [whom] + allVisitors; firstTimers += [whom]; } } } } } timer() { list parcelDetails = llGetParcelDetails(llGetPos(), [PARCEL_DETAILS_NAME]); ParcelName = llList2String(parcelDetails, 0); string subj = "Visitor Log for " + ParcelName; string body = "Number of Visitors Total: " + (string)(newVisitors + returnVisitors) + "\nReturning Visitors: " + (string)returnVisitors + "\nNew Visitors: " + (string)newVisitors + "\n\nList of New Visitors:\n\t" + llDumpList2String(firstTimers, "\n\t") + "\n\nList of Returning Visitors:\n\t" + llDumpList2String(repeatVisitors, "\n\t"); newVisitors = 0; returnVisitors = 0; todayVisitors = []; repeatVisitors = []; firstTimers = []; if (llGetListLength(allVisitors)>500) { allVisitors = llList2List(allVisitors, 0, 499); } llEmail(MyEmail, subj, body); }} It works well when the parcel belongs to an avatar but when it is deeded to a group, i reveive an almost empty message: Object-Name: Object Region: xxxxx Local-Position: (182, 43, 32) Number of visitors total: 0 Returning visitors: 0 New visitors: 0 List of new visitors: List of returning visitors: In the wiki notice, it is said: "On group deeded land the object containing the script must be deeded to the same group. (It is not enough to set the script to the group.)". But I shared my object with the group (= the land's group). Did I miss something (i can't find where I can "set the script to the group" as the wiki says) or is there a bug? Thank you for your answers. It's not entirely clear but it sounds like you have not deeded the object to the land group After an object is deeded to a group it will show the group as the owner. Shared with group must be done befored deeding. Set object group to the land owner group Check the SHARE box Click Deed button Confirm that your really want to deed the object After step 4 the object will show the group as owner.

It's likely that the script really is referring to the group tag the object is "wearing." A script working like the one I tested with by Fred Gandt does that. Possibly you could do this: Create you inviter object Set the group of the object to the group you want to invite to Add the inviter script & run to setup for the group Change the group of the object to the land group if needed. Step 2 may be difficult if the land is set for immediate auto return. But it's your land so you can adjust that. With Fred Gandt's script resetting or rezzing after changing the object group tag will cause it to invite to the current group. This type of group inviter doesn't really invite to a group. It gives a link to the group information. Which won't allow joining for group that aren't open enrollment. Further information here: http://wiki.secondlife.com/wiki/Group_Inviter

Nova Convair wrote: - Clicking on the media face of the prim will NOT trigger a touch event - You can not read what url the viewer is on. you can only readout the url for the media face but that's the one you have set yourself - so that does not give you any new info. - The visible contents of the media prim face is NOT on the prim face. The built in browser loaded the contents directly from the web site. SL, the sim, the prim are not involved and have no knowledge what the user sees. - Even if you change the url for the media prim and force an update - that will only work if the user has automatic showing of prim media activated in the viewer. Many - if not most - will have that "feature" switched off. Well... I'm certain there's much I don't know of about media prims. An example is your point about not being able to touch a media face and have the touch detected. Not knowing that - yesterday I modified my media prim to llOwnerSay the current media URL when I touched it. Worked fine for me. Of course the trick is to right click the media face and then select 'touch' Left clicking the media face is ignored. Nothing is simple. Now to your second point. My media prim script uses the llGetLInkMedia function to obtain the current media URL. To test your theory I had my ALT change the URL (so I didn't know what it was.) Then I touched the prim and my script told me the current URL that my ALT had set. I admit I had a clue because we were both seeing the YouTube video page he had switched to. Regarding your third point - it's true that if people often have media settings that make it difficult to serve them changed content. For those set up to see it there are tools that work. Of course there are many ways to tell a script to check the current media URL and revise it if it's not in the preferred watch_popup format. Those who can't touch a media face can, for example, touch another face.

L33TCrew wrote: Hi i want to create a script that automatic replace the url on my media prim when i click on a youtube video. the default url looks like this "http://www.youtube.com/watch?v=Ow1h0V40LD8" and it is to be changed by script automatically on "http://www.youtube.com/watch_popup?v=Ow1h0V40LD8". is there anyone who can help me with this? Sorry for my Bad English^^ A script can obtain a media prim's current media URL using either llGetLInkMedia or llGetPrimMediaParams. A new current media URL can be set using either llSetLinkMedia or llSetPrimMediaParams.

Arwen Serpente wrote: My comment was referring to objects in inventory with mixed creators, sorry that I wasn't clear when I posted it. I attempt a tiny clarification. The OP appears to be asking about items in inventory (right click object, select profile...) So I would think your answer was excellent. The creator of an object is sometimes shown through this inventory process - without rezziing the object in world. However, if it's not (for the reasons you provided) then rezzing it in world allows access to more details.

Innula Zenovka wrote: I think the problem is that safe_posJump is using llSetLinkPrimitiveParamsFast, which doesn't work move physics-enabled objects. For these purposes, avatars (and anything attached to them) are physics-enabled. It would work if you were sitting on the object, but not if you're wearing it. BTW, safe_posJump is now broken under certain circumstances anyway, and you should use llSetRegionPos instead. It still wouldn't work in this application, though. Instead of using safe_posJump or llSetRegionPos, you'll need to use something that calls llMoveToTarget repeatedly. Ezian Ecksol's CamJumper script in the wiki shows one way of doing that. ETA This isn't an ideal method of moving about, though. In particular, you risk getting stopped by buildings or mountains if you're not moving fast enough. You might consider using llTeleportAgent instead (that would work in an attachment), though I think it may still be affected by BUG-4062 llTeleportAgent() and llTeleportAgentGlobalCoords() can break any script in any attached object that contains a changed event.. That's in a part of the jira now inaccessable to ordinary accounts, though, so I don't know if it's been fixed or not. As I recall, it only triggered under certain, somewhat unusual, circumstances (it's never affect me, though I did stop using llTeleportAgent when possible after I read about it). The only other solution I can think of would be RLV's forced teleport option, but that depends on your users having RLV-capable viewers and turning on RLV, which not everyone is prepared to. I can't say I understand the convoluted process now used to obscure JIRA status. I did find a mention of BUG-5533 in the RC Magnum release note of 4.11 and 4.16 It's all very confusing because BUG-5533 is "Closed" with a resolution of "Duplicate" Why list a duplicate JIRA in the release notes? I don't even try to guess. In any case - it looks like a maybe a fix for the issue is deployed on the Magnum RC. Fix for "llTeleportAgent() and llTeleportAgentGlobalCoords() can break any script in any attached object that contains a change event." http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_Magnum/14#14.04.16.289178

Wow - I feel better now seeing that the script you posted filtered for the toucher's key in the llListen. I understand it's far more complicated that way. It just feels better to me.

Dora Gustafson wrote: When all instances listen on the same channel (dlgChannel) they will all act on what you choose in one dialog I don't think you are having dialog boxes from all of them :smileysurprised::smileyvery-happy: I'm not certain but perhaps dialog boxes do come from all of them eventually. One of the reactions to a dialog response is to issue another dialog. Which might be avoided by moving the llListen from state_entry to the touch event where it can be limited to the detected key.

Innula Zenovka wrote: I can't say I often (ever?) use llPassTouches, but am I correct in thinking that I would consider using it only if I've got scripts in both the root and a child prim, both scripts contain touch events, and I don't want the touch event in the root to fire if someone touches the child prim? It's an old function, and, to my mind, it's now pretty much obsolete since there's very circumstances in which I would need a separate script, let alone one containing a touch event, in a child prim. I think when I first came across llPassTouches I wanted to ignore all child touches in the root prim script. However it didn't do anything in Root. So I never found a use for it. It's only needed if both root and child have touch events and you sometimes or always want Root to detect the child touches. Default behaviour is the same as llPassTouches(FALSE) when there is a touch event in the child prim. It's confusing because it does nothing if not in a child prim script containing a touch event.

Charlotte Holmeforth wrote: You may find this function of use http://wiki.secondlife.com/wiki/LlPassTouches . It can prevent touches on a child prim being passed to a script in the root prim. A tiny clarification: It turns out that the default behavior is for touches not to be passed to the root prim if the child prim has a script containing a touch event. llPassTouches (per the WIKI caveats) has no effect if there is no touch event in the child. It's unneeded if you don't want the touches passed & have a child touch event. It does nothing if used and the child has no touch event. It does nothing in a root prim script.

Nova Convair wrote: This is never TRUE if(k != HTTPRequest) You have only one request, so why would "k" ever be not "HTTPrequest" I have this late arriving tiny bit of clarification: The http_response event should check that it is dealing with it's own requested response. Per the WIKI "This events will be triggered in every script in the prim, not just in the requesting script." In a single script situation it's not "needed" but having it there avoids problems down the line. For example - later adding a profile photo script to the prim that shows the stream status.

LepreKhaun wrote: I've edited the wiki entry to better reflect what to expect. Thank you for bringing this to our attention. Thanks for adjusting that. I think I've finally grasped what I need to do to stream some text using multi-row textures. Identical bookends,

LepreKhaun wrote: SMOOTH|LOOP slides along the horizontal U-axis (in the X direction), instead of playing separate frames. You're trying to do both with the 1x8. What's happening is your viewer pulls a frame through, then scrolls down to the next and pulls it through etc. It works correctly with the 8x1 because you're "pulling the ribbon" from one end to the other. Hmmmm.... well it obviously doesn't do what I expected. The WIKI says "If SMOOTH is set, the frames slide smoothly from one to the next, if off, each frame is displayed in turn centered on the face." So I'm feeling misled. There probably could be some rewording about 'frames slide smoothly within an X row however dropping down a row gives you a less smooth transition"... aw, I'm getting sea sick here with waves of flippin' frames filling my head. Still there are puzzles beyond the one by - I must go down to the sea again. The ribbon thing.. I like that.

I thinking llSetTextureAnim(ANIM_ON | LOOP | SMOOTH ... would be useful for some scrolling text signs. It looked simple. I'd used the un-smooth variation to do some little animations. So.. just divide up a texture into frames and have them follow each other smoothly across the face of a prim. I make a 1x8 stack of texture and try it .. omg.. this is not what I expected.. One frame begins to follow the preceding across the face but ... then is suddenly is following itself instead. Then I make a 8x1 texture and it gives me what I wanted. But a function that only works as described when it's nx1? Am I missing something that makes this function behave? I include a photo below. Top prim is using the 1x8 texture. It shows frame 7 following itself. Bottom prim shows frame 7 following the tail of frame 6. The significant lines from the two approaches are: llSetTextureAnim(ANIM_ON | LOOP | SMOOTH , ALL_SIDES,1,8,0.0, 8.0,0.36); llSetTextureAnim(ANIM_ON | LOOP | SMOOTH , ALL_SIDES,8,1,0.0, 8.0,0.36);

Hello Peoples. I was sleep at HyberNation when I have a dream. I dream that Local Payments Beta notice is still pinned to top of forum after two years. Okay is not two years but still I think dream will come true. So I offer this and go back sleeps: You're not involved, we don't forget it Perhaps it's a silly phase you're going through And just because people still post Don't get us wrong, don't think we think you're listening You're not involved, no-no We come and see you, but then again That doesn't mean we think you're listening So if we post, don't make a fuss Don't tell the world about the two of us You're not involved, no-no You keep a posting pinned by the top It's like a nasty stain you're showing us. And when we ask you to take it back You don't to show us we don't meam that much to you You're not involved, no-no Ooh, we wait a long time for you Ooh, we wait a long time You're not involved, we don't forget it Perhaps it's a silly phase you're going through And just because people still post Don't get us wrong, don't think we think you're listening You're not involved You're not involved

As I began planning for winter projects I came across a blog that goes into some detail about the SLCC and it's demise. http://www.fleeptuque.com/blog/2012/07/personal-perspective-the-end-of-the-second-life-community-convention/

Here's a link to a thread from 2012: http://community.secondlife.com/t5/General-Discussion-Forum/No-Second-Life-Community-Convention-2012-this-year/td-p/1540467/highlight/true/page/2 I think it's all part of an effort to pursue a path where the LL does less and less. Like setting up forums so the residents could provide the customer support. It just required a little coordination and support to keep it going. And now look... it keeps going with less coordination and less support.

I have this tiny clarrification to add: There are 33 'Community Managers.' Most of them are specific Lindens. However some are generic Lindens and some aren't Lindens at all. Although the non Lindens are probably really Lindens - if you know what I mean.

walterwhiteSr wrote: The other day, I was in a public sandbox, trying on stuff. A girl comes in, and she has music going, as I get closer to her the music gets louder, move away lower sound. I tried to Chat with her but she didn't speak english, and then left. I have seen re.act radio, but can't find out any details That sounds like media on a prim (MOAP). A MOAP object attached to a nearby resident (not as a HUD) can heard even if not seen. For example the prim could be hidden, transparent or too small to be seen. There is an option in some viewers to allow 'Play media attached to other avatars.' If you turn that off then you won't be bothered by attached media.

Rolig Loon wrote: Just out of curiosity, has anyone else had trouble getting the list of prim owners on a parcel to update properly? Recently, if I look at About Land >>> Objects to see who has prims on my parcel, or if I use llGetParcel PrimOwners to do the same thing, I find that the list doesn't update. I can add a pile of prims, or have an alt rez stuff, but the list stays the same. I've tried toggling the Refresh button, teleporting out and back in, relogging, waiting 24 hours ..... and the list is the same as it was last weekend. Same avs, same prims per av. Very odd. I did notice that last night. Only four owners listed although there were lots of items owned by others.

Storm Clarence wrote: I gotta admit, Qwal, it's tough being a tiny these days. With everything going on--from alpha layers to zits on child avatars--and a tiny can't even find a decent pair of pants on marketplace. What gives, LL? Well... as a tiny I have tiny expectations. Of course I also have my tiny problems. So when I see there is a Tiny Community... I should expect very little. So - my bad for thinking it was something nice.

Pie Serendipity wrote: I had a look at the Tiny Marketplace . . . . . . but there was too much small print for me. I see you made a tiny joke there. But I did warn you.

Madelaine McMasters wrote: Oooh, I went to check out this Tiny marketplace community and the first two advertisements were for a certain popular male attachment. I guess size does matter! Exactly. Dat's not the tiny community I'm interested in.

Hellos people of Second Life, I almost never shop the marketplace. I almost never complain. I am not about drama. Here's the thing: Today I try the market place and something amazing is there. They have a place to click for your own special community. First one listed is Tiny (naturally.) I AM Tiny. This is so wonderful. Now I can shop for my tiny specific items instead of weeding through all the big stuff. But NO!!!!!!!!!!!!! The TINY Community is just a search for the keyword "tiny." It's clothes for little girls and like that. On the first page there is even this item: BIGAVS MESH MACRO KIT. It's a damn kit for making giant AVs. So I call it the Tiny Community Beta Program because it's not ready for prime time. My conclusion is it's crap. I provide the warning above as a public service.

Hellos people of Second Life, I almost never shop the marketplace. I almost never complain. I am not about drama. Here's the thing: Today I try the market place and something amazing is there. They have a place to click for your own special community. First one listed is Tiny (naturally.) I AM Tiny. This is so wonderful. Now I can shop for my tiny specific items instead of weeding through all the big stuff. But NO!!!!!!!!!!!!! The TINY Community is just a search for the keyword "tiny." It's clothes for little girls and like that. On the first page there is even this item: BIGAVS MESH MACRO KIT. It's a damn kit for making giant AVs. So I call it the Tiny Community Beta Program because it's not ready for prime time. My conclusion is it's crap. I provide the warning above as a public service.