Qie Niangao

I dunno... the part about getting confused by cuts and slices seems unlikely, unless there was simply a bug. The encroachment detection is supposedly done by Havoc, which doesn't seem to have any problems with cuts and slices when determining collisions. Sculpties, well... the more of the d*mned things returned, the better, IMHO. :matte-motes-evil-invert:

A full Mainland sim costs US$ 195 /mo in tier. A full Estate sim cost US$ 295 /mo in fees. You will pay a hefty up-front purchase price to get a Mainland sim from a private owner (unless one suddenly comes available by auction from LL -- which is very rare). Initial Estate sim setup fees should be lower (although I'm not sure about that any more, given the decline in Mainland prices). If the plan is to let others use parts of the sim for a fee, then Estate sims make that easy by letting you "sell" parcels, granting the "buyer" lots of abilities that can only be approximated by Mainland rentals (using a separate land-owning group for each rental).

Yeah, it's been around since... like, last October, I think. Documented here. Except that I always forget how to invoke it, and have to rediscover it anew each time. (It's "Control-Shift-~" .) The last I heard, Andrew is trying to get the cross-sim encroachment detection working before Mesh deploys to the Main grid. (Not that this is on the critical path, delaying Mesh deployment; there are plenty of other reasons for that, I'm sure, and I don't know that it's even considered a gating feature for Mesh.)

Right. The cud-chewing starts, however, when there's an attempt to apply Freedom of Speech (which has to do solely with limiting how the state can constrain speech) to commercial enterprises, such as Linden Lab. The Lab may well want its customers to have freedom of expression -- perhaps similar to such Freedom of Speech -- but there is no requirement that it do so, any more than a private blogger is required to preserve every hateful comment posted.

The idea of a separate sim just for the stage is in fact very common for mid-size audiences (large enough to matter, but not so large as to need all four sims in a corner). I think the more specific problem, however, is the inherent mistake of trying to accomodate heavily interactive performances (with scripts, avatar physics, wardrobe changes, etc.) from the same stage as trivial impact "performances" such as panel discussions, DJs, etc., where nobody in the audience needs to know or care how lagged the performers may be.

In contrast to Void's comments, I'd assume this is not to be a combat sim, and that there won't be any group of residents role-playing Nazis. Making that work would require a tightly controlled and carefully written script, or very well-instructed actors, or both. It's one thing to have freedom of expression (which, incidentally, has nothing to do with Freedom of Speech as in the US Bill of Rights... but that's an ancient bit of Internet forum cud-chewing). The Lab presumably wants folks to present diverse experiences and to feel free to express themselves. But they also want people to feel comfortable in their surroundings, and this is a topic to which many people are very sensitive. It's not for nothing that WWII books and film scripts are carefully edited. Producers and publishers don't need public outcry and boycotts; neither does Linden Lab. None of this is to say that swastikas, etc., shouldn't exist anywhere in SL. This subject matter, however, has to be handled tastefully, or not at all. Even though the content is user-generated, that's still the business reality for Linden Lab.

For several months, Estates have been able to allow their landowners to return encroaching objects. The thing is, this is most needed on the Mainland, yet it hasn't been enabled. Admittedly, this is a Mainland-only problem, but I'm posting here just in case Estate managers have found any problems that would justify further delay in enabling this across the Mainland. I can see that the pending addition of handling encroachment across sim borders would have more utility on the Mainland than on Estates... but I don't see that as a reason to delay the current functionality. It's puzzling that Support and TTFKAG* haven't been clamoring for this to get turned on. One suspects they get paid by the ticket. ______ *TTFKAG = The Team Formerly Known As Governance. A bit like Morticians / Undertakers / Funeral Directors, this group goes through euphemistic aliases faster than microbes develop resistance to antibodies.

You'll need to be able to script the object that's to be moved by the platform (as well as scripting the platform itself, of course). There are a bunch of ways to make this happen, but the choice of which ones may be acceptable depends on one major consideration: Which part of the motion will be observed, and how should it look? I mean, no matter how you do it, it's more difficult (and laggier) to move an object or objects gradually, so the motion looks natural, than to just poof them from point to point instantaneously.

The effect is disastrous on the Atoll continent, especially near the water line. It's difficult enough to terraform any graceful transition between those manilla-folder-colored scrub and acid-psychadelic coral reef textures, but to have it all scrambled the next day... well, that's why one sees so many of those gawdawful sculpty fake beaches, trying to hide the transition. Although this doesn't rank up there with heavy bugfixing (nor even Estate Windlight settings as exchangeable assets), it should be mind-numbingly simple to implement. It's one bit of information about the sim: randomize or not. If not, the viewer uses some hash on the sim identity (say) as the seed, thus generating the same "random" texture transitions every time for that sim. It's kind of a shame they didn't just bundle in this trivial change with the much more extensive Windlight settings work; they didn't, so it becomes yet another feature requiring changes in both sim and viewer.

Although I personally try to eschew Marketplace purchases altogether, the fact remains that the Lab (foolishly) has been promoting Marketplace commerce over Land-based stores for the past couple of years. It's had a very real effect, with many sellers now hosting only their Magic Boxes in-world -- and for those, direct inventory delivery will cut them free of the grid altogether. There are some things that one would have to be a complete idiot to purchase except after trying or at least seeing them in-world. Some subset of those are best experienced at the seller's location, rather than getting a demo unit poofed in from Marketplace. (Vehicles are an obvious example, although there are vehicle merchants with in-world locations who don't offer demos -- a pretty sure sign that their products are intended for those aforementioned complete idiots.) Seems to me that the best current and future bet for in-world product sales, in light of the Marketplace pressures, is with clusters of theme-related stores gaining from "foot traffic" drawn by sim-hosted experiences (events, etc.). This is basically the RP sim "mall" model, although of course some do better than others at attracting / enforcing theme. If, however, one wants to go the direction that the Lab is pushing with Marketplace, the future of Land is to be overwhelmingly residential, serving only as a place for people to rez their Marketplace purchases. It's all rather depressingly retro, reverting to an era of the Montgomery-Ward catalog and strains of "The Wells Fargo Wagon" from The Music Man.

On the other hand, some of us hate terraforming with great care only to see it look terrible when painted differently the next login. It's especially a problem on Mainland, where one has no control over the textures. There's a jira.

There's really nothing to remove with llSensor. It runs once and that's it. Calling llSensorRemove after llSensorRepeat is the equivalent of stopping a timer in which llSensor is called. (The essential advantage of llSensorRepeat in such an application is that it doesn't tie up the timer() event.)

Pity. "Profile thug" was kind of a turn-on. (Incidentally, this is the first I've ever heard of that other site. You know: the hookup site for the NASCAR set. I'm guessing a gearhead will track down the ex-boyfriend and kill him. Problem solved.)

Next? Ideally, restricting all content uploads to users with a registered and verifiable RL identity (for which PIOF is LL's best current proxy). Actually (as discussed across the street at greater length), some of us would much prefer that uploads not be restricted but that initiating transfers of anything -- even notecards -- be limited to such RL-registered accounts. Probably obviously, transfer restrictions are getting at risks beyond IP infringement, which the upload limitations presumably target exclusively. The reason these came with Mesh, I think, is the widespread expectation that bootlegged models from across the Internet will flood into SL the moment Mesh is available on the Main grid. That expectation isn't unjustified: On the Mesh beta sims, I've seen (way) more ripped models than original work. So, if LL didn't do something to control that, there'd be a much more compelling reason to boycott Mesh products.

Chelsea Malibu wrote: What flabbergast me is that someone would think they could do this unnoticed. Are they trying to take advantage of a situation, are they griefers or are they just plain stupid? On Mainland, I suspect it works more often than not. There's a vast amount of build-enabled Mainland owned by very absent residents. Some of it is generating tier for LL because the owner hasn't pulled the plug yet, and the rest is just stranded in some bookkeeping limbo, not officially abandoned by the owner but generating no tier either. A "squatter" build on any such parcel may be around a long, long time. Because there's just so much of this land on the grid now, it might make sense that there'd be more squatters -- if indeed there are more of them. (I don't know whether there are or not; I'd never try to manage land without auto-return). Incidentally, it's easy for a script to tell if a parcel is set build-enabled, but I think the auto-return interval must be accessed from a viewer (or, equivalently, a bot).

If the attachment emits particles from a child prim, check out this ancient jira as a means of sanity preservation.

As I understand it, it's not really that kind of following. Here's a crude sample of what I think is generally being attempted. Just drop it in a fresh 0.5m cube, be sure you're in default cam mode (press escape a couple times), sit on the box to get the initial cam-in-front-facing-back-at-avatar effect, then touch it to get the cam-in-back-following-the-avatar's-motion effect. default{ state_entry() { llSitTarget(<0.30, 0.0, 0.6>, ZERO_ROTATION); llSetCameraEyeOffset(<3.0, 0.0, 1.0>); llSetCameraAtOffset(<0.0, 0.0, 0.7>); } changed(integer change) { if (CHANGED_LINK & change) { key av = llAvatarOnSitTarget(); if (av) llRequestPermissions(av, PERMISSION_CONTROL_CAMERA); } } touch_end(integer num_detected) { vector myPos = llGetPos(); llSetCameraParams( [ CAMERA_FOCUS, myPos , CAMERA_POSITION, myPos + <-3.0, 0.0, 1.0> , CAMERA_ACTIVE, TRUE ]); llSleep(1.5); integer creeps = 30; while (--creeps) { llSetPos(llGetPos() + <0.5, 0.0, 0.0>); llSleep(0.25); } }} It may be instructive to find out how that differes from what's desired.

... if the camera focus isn't somewhere fixed it works but if it's fixed on something it doesn't (if that makes sense)... It this means what I think it means, and if it's a deal-breaker, then there's no way to do otherwise in a script. Scripts only affect the "default cam" -- what you get when you hit the "escape" key a time or two. Scripts cannot prevent the user from zooming/panning away from that default (as with mouse gestures alt-drag or control-alt-drag), and if the user has already pulled their cam off of default when the script tries to move the cam, nothing will happen until they press the escape key. Now, if that's not the problem and the script is only intended to affect the default cam, then there's probably a way to do what you want. Right now, I'm thinking it would be easiest to do it all with separate calls to llSetCameraParams() but because you're scripting a sat-upon object rather than an attachment -- a crucial difference from the cited thread -- it's possible that the first bit (cam facing the AV) could be done with llSetCameraAt- and -EyeOffset, followed by the llSetCameraParams() for the bit where the cam follows the back of the AV. The cited thread, by the way, hints at another limitation that shouldn't be a problem for you. Smooth following of the avatar to which the scripted cam is attached seems to be impossible except from behind. Luckily, you want that orientation anyway when the AV is moving; even if you didn't, because you have a seated avatar, you could pick backward-facing static eye and focus offsets that would move with the same relative orientation as the object and seated avatar move.

Ironically, looking at that animation UI in this context, I'm much reminded of a cinematic storyboard. (And in the next post, that .bvh listing appears a strong argument that the Animation topic must surely belong in the Scripting forum. :matte-motes-wink-tongue:) One objective way to slice and dice forums would be by statistical cluster analysis of who posts to which threads, then ascribing some plausible name to the resulting thread clusters. Doing that, however, one may well end up with a forum corresponding to "threads eventually closed by moderator" -- hinting which posters may need some re-education (or dosage adjustment).

Let's get real about this. It can't be much of a store, now, can it? It can't change the parcel name/description nor even set it to show in Search. Even in the unlikely event that the parcel is still set for a basic search listing under its previous name and description, accidentally paid for by the previous owner, how likely is that to send searchers to this freebie mall? Much more likely, the store is completely invisible to Search and thus visible only to hapless wanderers, inexplicably drawn to cookie-cutter freebie outlets. It's quite beyond me how this misbegotten endeavor could contribute anything to the SL economy, nor enhance anybody's SL experience -- perhaps least of all the doomed proprietors. So it's not that this "squatter" is competing with any serious business. It's just that the whole thing isn't worth the photons to render it even once. It's just a dopey side-effect of a not-quite-complete abandonment by the previous owner, and anything the neighbors can do to protect their (paying) interests is fair game.

... haven't quite got my head round determining the correct order for separate functions or how to sequence them... Within a state (e.g., default), the sequence of event handlers (such as state_entry(), listen(), timer(), etc.) doesn't matter... just put them in whatever order you think will be easiest to find them when examining the code. You do need to define functions and variables before using them, so you'll generally have a section of global variables, followed by functions, followed by the state(s) and the event handlers they contain. About initialization: Yes, declared variables that aren't explicitly initialized are set to a default value; 0 in the case of an integer, 0.0 for floats, "" for strings, [] for lists, etc. (I think we're not supposed to know whether that default value is set at the time of declaration or when first referenced.) How the on/off toggle should work probably depends on how often people will be adjusting the number of birds from that menu. It may be difficult for some users to find the rezzer once it's been turned invisible, so one might even imagine listening for a chat command on some channel, as do many poseballs (a la "/1show" and "/1hide"). Obviously nicer to avoid those listens, though, if your users won't get lost. Anyway, yeah, it seems fine to have either "hide" or "show" (whichever makes sense at the moment the menu is shown) be one of the menu options. But that's "on/off" only in terms of showing and hiding the rezzer; you may also want 0 to be one of the bird count options, or somehow otherwise let the user turn off the rezzing altogether.

Uh, just to be sure I haven't led you astray here, it's certainly possible for a script to listen to chat and forward it using llInstantMessage() to another avatar. It would simply pass any string it gets in the listen() event into an llInstantMessage() function call. The only reason I mentioned llTextBox() was because folks were worrying about the possible security risk of having the message in chat, regardless of channel. Incidentally, llTextBox() is supported by most viewers now, but there are still some folks on 1.23.5, for whom that function serves only to annoy.

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.