Qie Niangao

Except that if you're a neighbor, you absolutely want all the prims used up, to keep griefer and random stray prims from accumulating on the parcel. Hence the urgency of landscaping the thing to your heart's content. Actually, it would be good to make sure the prims are all phantom, and any not needed for landscaping be full alpha and preferably rezzed at some improbable altitude so they don't have any viewer lag effect. [EDIT: I agree with sending the owner an IM, but I wouldn't wait around for a reply. In my experience, this only very rarely works (and I've found it especially unlikely to work for owners of land not set to auto-return). It would be interesting to see if it happened to work in this case. We're not allowed to wager on the forums, are we?]

Hmmm. I seem to disagree with most of the other replies here. First of all, it's important to realize that not paying tier is not an effective trigger for the land being abandoned. Sometimes it happens. Sometimes not. It's a classic halting problem to wait for land to go abandoned after an account has stopped paying anything toward it. Thus, it is very, very likely that LL is not collecting any tier nor membership fees on that land. There are huge swaths of Mainland where that's the case. There are also huge swaths of Mainland that are in fact abandoned, but LL has no incentive to be quick about moving land from the first to the second class of land -- especially as long as Tyche is publishing statistics about the percentage of abandoned Mainland, and as long as there's no great demand for freshly abandoned land automatically put on the market. Now, there is a slim possibility that this particular parcel is owned by one of the "founding" accounts (or whatever they were called) that got some amount of land (usually 4096, IIRC) in perpetuity. There's also a slim possibility that the previous owner's credit card or bank account is still paying tier on it, whether they remember it or not. But it doesn't matter: they set up the land without auto-return--effectively establishing a little sandbox. There's no reason to believe that they don't want you to fill it up with your own prims. I'd strongly encourage landscaping the heck out of it, in fact. If the owner didn't want this, they should have set the land permissions differently.

First of all, your listen() handler is using the comparison operator ("==") where you want assignment ("="). So you want: if (message == "1") Birdno = 60; etc. Also, you're starting out in state_entry with a zero-valued Birdno, and using that to clear the timer. That's fine (albeit unnecessary) but as far as I can see, nothing ever sets the timer again. I think you want to do that at the bottom of your listen() handler.

Jaylin Wytchwood wrote: I got something, foe the marketplace guys: TEAPOT. Had to call it Teakettle, cause of the -pot - part. Forced it moderate, jeez, its for tea not drugs. Tea is a drug. "Tea" was an old code word for marijuana (e.g., "Not for all the tea in Mexico"). In a pinch, any self-respecting doper could easily make a bong from a teapot. Trying to list such an obviously subversive item on Marketplace... why, you should be ashamed of yourself! :matte-motes-wink-tongue:

llTextBox to enter the message. Will the recipient sometimes be in a different sim? If so, your options are pretty limited. To send it directly to the recipient (not to a scripted device they have attached or rezzed at their location), I think llInstantMessage() is pretty much the only option. If they can use a script to receive the message, then there are a bunch of object-to-object communication options, all with different complications, the hairiest being addressability of the recipient despite changing object keys, URLs, etc. Anyway, if that's the scenario, you might set up a static, always rezzed "directory" / "forwarding" server and send llEmail through it to the recipient's device, which would have to register with that server every time it changed addresses. It's also fairly common to create external web services to perform that directory /forwarding function, over llHTTPRequests. All-in-world "hybrids" are also common, which use email to propagate the dynamic URLs for HTTP script functions.

At least on the SLRR, the situation seems radically different from what it was when this thread started (which, incidentally, was already radically different from when I first noticed these vehicles around my parcels). My maps display every vehicle on every branch of the SLRR (currently excepting the Bay City spur). The number of these particular vehicles on the SLRR has reduced dramatically in recent weeks. I can't find any of them still asking for tips. I haven't seen any of them on the SLRR that don't have a kind of rail car undercarriage (that's very recent). I have no current evidence than any of them are not now phantom. It may be that I've just been lucky in my recent encounters, which admittedly have been mostly limited to the SLRR, but the changes I've seen are dramatic enough that I think those still complaining about these things really should make very sure they still have a valid reason to complain. That's not to say there aren't further improvements that would be welcome. I'd (really) like to see the number of scripts reduced, for example. And of course there is and will always be room for improving aesthetics. (Speaking for myself, however, it's growing difficult to get motivated to work on any non-Mesh builds these days, so it seems only reasonable if this creator has chosen to postpone such surface improvements -- especially to prim-constrained physical vehicles -- until Mesh is in wide use.) One complaint that I think is quite unjustified is that these vehicles are somehow sidestepping the autoreturn settings on Linden public land in some special way. They're simply crossing parcel boundaries before the time limit expires -- and they're not doing that artificially, but as a side-effect of traversing the right-of-way. There's no exploit, magic, nor special treatment involved. Also, there are many ways in which innocent intent can lead to resource conflicts. One SLRR-related case is the increased use of "follower" assemblies to add cars behind the (usually non-physical) ridden vehicle. That adds realism, and it's not done with evil intent or anything, but in fact it has quite worse consequences on many parts of the SLRR than do the low-prim physical automated vehicles discussed in this thread. That's because those unridden "followers" count directly against the parcel prim limits, so they can easily exhaust all available prims in some sims with shorter rights-of-way (and hence, fewer prims), making it impossible for another train with any follower assembly to enter that sim. I'm not suggesting that something needs to be done about this -- LL already has a lot of prims available in most sims, and there's no urgent need to restrict the use of such assemblies. I only mention it as another case of one user's creations potentially interfering with others' use of a shared resource. Finally, there is one very easy thing that I really would like LL to do that would somewhat reduce problems caused by these and other vehicles that get stranded, caught on a no-auto-return parcel but encroaching on another (often no-object-entry) parcel: Enable the manual return of encroaching objects on the Mainland. This feature has been in the sims for a while now, and Estate owners can enable it on their sims, but it remains turned off for the Mainland. As far as I can tell from listening to developers, the problem is that there's simply no Linden in a position to decide such things anymore, or at least none willing to make themselves known by actually doing anything about it. That's a pretty sorry state of affairs. I'd dearly love to be proven wrong. (hint hint goad goad)

Besides teleporting, one could cheat using an attached physical booster script. Unless you're preventing participants from wearing any scripts, it may be safer to go with position-tracking rather than rely on parcel teleport routing (although that may be a fine thing to do for other reasons anyway). Just a guess, but my hunch is that you'd get less lag from repeated llGetObjectDetails() over a roster of "enrolled" participants than you'd get from a sensor, and that calculating speed from distance over time would be more reliable than using instantaneous OBJECT_VELOCITY.

If everything else reported in this thread is true, it doesn't actually add much (any?) information to know that your machines are clean of known threats that scanning software would be able to find. [EDIT: Not quite true; see below.] If it were anything like that, there'd be a lot more people complaining about it by now, especially because the OS in this case is Windows. As far as I can see, the only plausible spyware hypothesis would be that of a threat not yet identified in public. In contrast to thousands of folks getting big red flags from anti-spyware tools were it a known threat, I don't know how many people would be aware of the spam itself. I certainly would never know: gmail is far too good at screening spam, and I almost never check on what is drifting through that folder any more. The point is that lots of folks may be getting the spam without knowing and reporting it, and that means we can't really tell if it's only Windows users (which would indicate some new threat resident on those users' machines) or Mac and Linux users too (which would pretty conclusively demonstrate a breach at Dragonfish). [EDIT: I guess, had we not known the negative scan results, it would have been possible (if extremely unlikely) that there were stock keyloggers on both the OP's machines and that of the other person who used a friend's credit card. So, yeah, there's some information gained by those scans.]

Although those who don't care might do well to STFU, I'll not follow that advice, and herewith have it be known that I don't care. Honestly, as far as I'm concerned, there could just be the one General Discussions forum for everything. If somebody started a discussion about scripting, say, or some other topic that strikes my fancy, I might see it and add something. Or not. Well, okay. I guess I'm glad there's an Answers section because it seems to screen out the most tedious and repetitious of easy questions. And it's good there are Commerce and International sections because both are full of people speaking in strange tongues.

Yeah, I sorta don't see the point of making anything explicitly "inspired by" anything else already in world, unless you know you can make it dramatically better in some way. Otherwise there are such limitless possibilities that it's awfully lame to be unable to come up with something unique. Even so, that unique creation will be influenced by everything else you've seen, no matter how hard you try to be original. Those unintentional influences seem plenty enough "inspiration" to me.

For real? Yep. (Not in SL... I hope I didn't mistakenly give that impression.)

Right, and there's a recent case of a Minnesota man who made a hobby of successfully coaxing people online to commit suicide. The thing is, as Venus rightly points out, the criteria for RL "harassment" is quite a bit different from SL, where "harassment" is just over the edge from "poor sportsmanship in gameplay." I don't think we know the OP's story in anywhere near enough detail to guess whether there's RL harassment involved. Unless there's been plausible threat of grievous bodily harm or actual property loss, seems to me (IANAL), a court would have little interest in the matter. It also seemed that the complaint wasn't so much about RL harrassment as about violating research ethics. In my experience, there are nearly as many make-believe "researchers" in-world as there are on forums, and the threat of losing an imaginary grant may not be all that compelling.

I was all set to agree with the OP, and was typing a response about the improbability of the spyware explanation, and then I got to thinking about it, specifically about the probabilities around this: Nicolette Lefevre wrote in part: 1) I received these spam-emails to 3 addresses used for SL. 2 of these are ONLY used for SL. And NONE of my other email-addresses received these spam-emails and I have dozens of addresses. One for each account on some website or other. As I said NONE of these other email-addresses received the spam. It is highly unlikely (though admittedly not impossible) for a spyware to randomly get just 3 addresses that are known to SL and none of the others. If my math is correct then the statistical probability for this is about 0.3%. (8 out of my total of 50-60 email-addresses are known to SL) It doesn't have to be random. The spyware may only be collecting information from Dragonfish/888.com-related sessions and nothing else -- especially if the whole purpose is to pump online casino ads to recipients who might likely be interested in online gambling. The problem with this explanation is that it still requires that the computers that supplied the compromised information were in fact infected with some pretty elaborate spyware. Seems to me that it would have to be either a keylogger or something running internal to the browser, to see the pre-SSL-encrypted data. Either that, or the breach is, as the OP suggests, at the other end of that SSL pipe, inside Dragonfish. Whether the leak is from Dragonfish or from spyware that targets 888.com-related properties, one would expect other businesses who use Dragonfish to have gotten complaints from their customers. Exploring that possibility might be worth some CFO-to-CFO backchannel phone calls.

blaze Sion wrote in part: i have never heard of anything like that in all my years i have played this game and i can not believe you would even suggest that kind of service. Then you've not been paying close enough attention. The time to fuss about that policy was about three years ago, when it changed. If anything, they've been answering a somewhat broader set of support questions for Basic accounts than they did back when they first instituted the change. To your specific avatar-rezzing problem: you're not the only one to experience this, specific to one account. One person I know not only has Concierge-level support but has been trying to work directly with senior Linden developers for over six months on just such a problem, without success. By not getting a support response, then, you may not be missing much. On the other hand, maybe you could trick them into committing to solve the problem if you pay them the US$10. If they fell for it, however, I think they'd be very eager to refund the $10 at the end of the month.

Yeah, a snapshot and chat log of any harassment, repeated for each offender and each incident. One thing to be aware of is the difference between "whitelist" and "blacklist" access restrictions, especially as it determines the height over which a ban is effective. If you were to set your land to allow access by group only, that's a "whitelist" ban, and only works to 50m above ground level. If you ban specific individuals, those are blacklist bans, and extend to 768m above ground level. Of course, if you have a skybox above that height that you want to keep private, that's a job for a script (e.g., a "security orb", or the like).

If they're really bypassing the banlines through some exploit then yes, that's a serious ToS violation and yes, they can all get banned from Second Life. Only if you AR them, though, with enough evidence and details about what's actually happening.

wisearyan wrote: Yes, it seems like its a user specific issue. I checked my line speed at dslreports.com & the results are the same as they used to be. There is no decrease in line speed. DNS resolution is working good too. Do you think its a possibility that some people didn’t like my SL behavior pattern & have deliberately done this so that I get fed up & leave the game ? Or do you think that not possible? I think too much troubleshooting is making me crazy...lol :matte-motes-big-grin: It would be theoretically possible, if you were wearing an attachment they gave you or if you were only visiting sims they could contaminate with "wisearyan-griefing devices" but you've tried removing all attachments and logging into different sims, so that's kind of ruled-out. I suppose to be hyper-paranoid, it might be hypothetically possible for somebody to manage to transfer an inventory item to you that somehow tripped-up teleporting, or otherwise cast some evil spell on your account through super-leet griefer skillz, but for that the only countermeasure is voodoo.:smileytongue: Also, I wouldn't expect there to be an overall bandwidth problem with your network connection; the network concern would be specific to the route to Linden's datacenters -- and very possibly specific to the kind of traffic that occurs when teleporting, on the specific connection used. (In case you were thinking it, yeah, possibly traffic-shaping by the ISP, but more likely a glitch either in the ISP or somewhere on the LAN or firewall. Just to give you an idea: In the distant past, there were routers with funky firmware that had to be upgraded to maintain Second Life connections, and a software firewall that got an SL-incompatible update. It's amazing the Internet works at all.) It was a good idea to test DNS; in my experience, however, DNS problems usually affect initial login rather than teleporting, but that may be just luck of the draw. If you haven't already tried a fresh alternate account, that would be the next step I'd recommend, because I can certainly appreciate the difficulty of trying the current account through a different ISP.

Well, FWIW, it's very unlikely to be a server-side issue (although not quite impossible: see below). Everybody else is merrily teleporting around the grid, so unless the servers have it in for you, it's something to do with your connection or installation, and I think we've ruled out an installation problem. (Incidentally, I read in your first post that you'd cleared cache, but I was suggesting manual deletion of the cache and settings directory, as opposed to the simple cache clearing in Preferences... but TBH, you've already tried different viewers, and anyway you may have tried the manual route already, so never mind all that.) One way it could be server side is if there's a corrupted asset unique to your avatar or some other account-specific glitch. This is exceedingly rare, but easy enough to test: create a completely vanilla, fresh-off-the island alt and see if s/he has the same problem with teleporting. If so, the problem is external to LL. If, on the other hand, the alt can get around just fine, then it's time for a support ticket: something in the original, troubled avatar's inventory or accouint is broken, somehow triggering disconnection upon teleporting. I wouldn't know how to debug that problem much further without Linden help. Well. I suppose it would be worth trying the Test Male or Text Female avatar with absolutely no attachments or clothing, on the premise that there's a bad asset associated with the current avatar's appearance. Thing is, you've already tried with no attachments, and presumably your avatar textures are baking successfully sometimes, so that all seems unlikely.

No, don't permaban them. Why lose the tier? Instead just manually set their result ranking to the bottom of the pack, with no explanation. Then when they come here to b*tch about how Search is broken, we'll all know (but shhh! don't spoil the joke!). If only it were possible, it would be even better to keep their search listing ranked at the very top but only when queried by them, their alts, and everyone in their landowning group, while burying it for every other searcher.

I wonder if you're always seeing the "Boom, error in audio file transfer" error in the console before the crash. Usually this is just a long-standing problem with sound, but I'm just thinking about that Ogg Vorbis exploit and wondering just what the Lab did with those crasher assets to protect users of older viewers. Of course, for that to be the cause, there'd have to be some reason you'd keep getting exposed to that sound asset. Had you not already tried with them all removed, it could be an attachment (not necessarily scripted, theoretically, although it would need to trigger on teleport, so...), and not so easily something in the environment (because you've experienced the problem on multiple sims). This is probably a dead end. Other than manually removing all the cache and settings directories (if you haven't done that already), I'd circle back to a network cause. If you can somehow try the account on a different network connection, preferably with a different ISP, that could help narrow things down. Of course, if any network-related software has updated (e.g., a software firewall, device firmware, etc.), that could do it.

Have you tried rebooting all the devices on your network, especially including the ISP's router (or cable modem, or whatever) ?

Gee, I don't think it's that complicated, if the object is always supposed to push upwards with the same result regardless of where on the surface the collision is made. The only thing is that the force falls off as a function of the distance cubed, so... something like this, maybe: default{ collision(integer total_number) { key av = llDetectedKey(0); vector AvPos = llDetectedPos(0); vector myPos = llGetPos(); vector up = <0.0, 0.0, 1.0>; float distance = llVecMag(AvPos - myPos); llPushObject(av, up*30.0*llPow(distance, 3.0), ZERO_VECTOR, TRUE); }} I think you may also want some kind of initial de-bouncing because I think you're likely to get two collision events right at the beginning. (Or maybe I'm not understanding the project.)

Medhue Simoni wrote: There does not need to be a bias for larger parcels. The problem is how the search ranks things. It does not make any sense that a merchant with a small parcel can out rank a merchant who owns a large parcel and sells hundreds of what the person is searching for. Parcels size does not even need to be relevant if the search worked correctly. I have no idea how this ranking is being done, but as a search user, I'd much prefer a result that had only a few matches with what I sought and nothing else, to a parcel with scores of matches with it and hundreds of other things. (To re-emphasize: I have no idea how this is actually being done. For all I know, Pam may have those 40+ dining sets and nothing else set to show in search.)

I've been playing with it some more and this really is a major improvement. To reiterate, however, we need a way to get from a search result to the corresponding world.secondlife.com page for the parcel. If it's just not within the design of the new Search window (which is a major improvement over the earlier V2 search window), then worst case it can open in another window or even an external browser. But those "Go" buttons are extremely valuable, along with the ability to do text search within that result, and otherwise see details of everything on the parcel set to show in search. Don't hide all that value! And whatever else is done, please, please do not remove those world.. pages ! I hope those are still what the new search engine crawls. (If it's using something else, I trust it still has all the show-in-search articles on the parcel. Right?)

I'm very glad to see that, indeed, "Search Results are Saved" across teleports, without that dopey "Go to last query" thing. That's a big deal to me. On the downside, it's very significantly slower to load than the previous V2 search (initially, or if one presses "Search Home" to back out of a result set). I suspect it's preloading a bunch of those scrolling classifieds, or maybe all the apparatus to make the scroll. Anyway, something is sure taking a long time. And I'm very disappointed that the full search page for the parcel isn't shown anywhere, with the "Go" buttons one gets for individual item destinations, as with search.secondlife.com. That was a big improvement when "web search" (GSA) came into Viewer 1, and a big disappointment to see it missing from Viewer 2. Is there any way we can get that back, or at a minimum, an "open in your browser" to see the actual result item somewhere, instead of the abbreviated version that shows currently? As best I can tell, the problem of "for sale to individuals" Mainland parcels being included in the results is fixed. The "Type" terminology is very odd, though: "Mainland - Full Region" and "Mainland - Auctions"... unless this means that the plan is to migrate most private sales to some auction process (or... something). Still need to play a lot more with it. It's frustrating because the bugs introduced with the Mesh merge, having nothing to do with Search, are making it really crashy and hard to use for very long.