Qie Niangao

some of the mods that avaters have need SL water to work. Can you be a bit more specific? There may be some visual effects that depend on Linden water, but there's also some scripted stuff -- notably animations and "swimming" buoyancy imposed by attachments -- that depend on the avatar's height relative to the level of Linden water, i.e., llWater(). Other than scripter laziness, there's generally no reason those can't instead respond to some other height, sometimes set by water prims.

I really wouldn't worry about Javascript at this point. It would be a good enough framework for a virtual world scripting language, as would C#, but all that really matters is what functionality is exposed to the script engine. Second Life imposes severe limits on what scripts can even see, let alone manipulate, but many of those limitations came only with bitter experience. If High Fidelity ever really gets to market, it will need to introduce similar limitations; having Andrew on staff there, they know what happens when script limitations aren't strict enough.

Dora Gustafson wrote: The frame rate all depends on the scene. Yep. With that card, even with those settings, a framerate well over 60 should be standard in skybox conditions. No amount of tweaking is going to give such a high FPS in an avatar-crowded ground-level build full of intricate geometry and heavy textures. That said, I'm curious: Are those settings really what Firestorm thinks correspond to "Ultra" for that card? Because, I mean, there are some extreme numbers there. I'm not sure what impact they'd have on framerate, but they're settings I'd never consider except maybe for photographic effects. (Just for example: 16x anti-aliasing? and yet anisotropic filtering is turned off. Well, at least the distortions won't have jaggies.) Also, as suggested in the other thread, if you're really trying to maximize framerate for a specific hardware rig, you'd really be better off with a different viewer. Right at the moment, you'll probably do best with one of the Linden viewers, but perhaps some TPVs may have picked up the interest-list tweaks now, and not all will have loaded down performance with other features that need finding and turning off.

The Group thing probably would work, but may conflict with other uses of Groups -- notably, land permissions and autoreturn. There may possibly exist rare circumstances in which the location where an object is for sale simply cannot use a scripted vendor -- or any scripts at all -- perhaps due to region settings. If the Group thing were not an option in such a situation, and one were unable or unwilling to scrape transaction history for those sales for which proceeds should be split, there is something off the top of my head that probably would work most of the time: Have a script in the purchased copies of the items that respond to CHANGED_OWNER so that when the purchaser rezzes the item under normal conditions, the script sends a message (probably by email) to a special splitter-script owned by the account that took the full purchase price. Then the message-sending script must delete itself, lest further copies send more messages. The message-sending script better not be copiable by the purchaser, lest one purchase cost the merchant many, many split amounts. And if the buyer happens to rez the purchase on no-script land, CHANGED_OWNER would be missed, no message sent, and no split occur.

Somehow, though, AOs can tell to override the running anim. I think the logic is a bit like this: integer info = llGetAgentInfo(llGetOwner()); if (AGENT_FLYING & info) llOwnerSay("Flying"); if ((AGENT_WALKING & info) && (AGENT_ALWAYS_RUN & info)) llOwnerSay("Running");

Kelli May wrote: I agree. Premium membership effectively gets you to buy L$15600 up front (current stipend, yearly subscription). Like Disney Dollars, they hope you spend them in the park rather than saving them and selling them back. Back when I first took out Premium, the value of the stipend was higher than the annual subscription fee. [Emphasis mine.] That's exactly it, I think. The idea is to create an incentive for SL economic activity: if you have L$s from a stipend, you're very likely to spend those on L$-denominated stuff. That may be (possibly) less important now than it was early-on when there wasn't all that much compellling content to motivate users to buy L$s in order to acquire some bit of that content. In theory, sure, folks could just buy L$s with the cost of Premium membership, but many simply wouldn't do that -- myself included -- so I suspect stipends are still pretty effective at keeping the SL economic engine humming along, but only to the limited degree that stipends are still a significant L$ source in the economy. [ETA: I meant to mention that stipends date back to the age of "Dwell" payments, which distorted the grid economy in favor of places with lots of avatars, hoping to incentivize social interactions. Obviously that got gamed to death. It's just another example of an "economic policy" intended to shape behavior... in SL, as in RL.]

Oh, quite so, and I realize now that I was imprecise to the point of being misleading. I should have said "child avatars" not (RL) "children" ... and if that's what you meant earlier about being in the wrong place, certainly SL isn't appropriate for RL children (and vice versa). The thread's anime subject just seemed more about avatars than about their players.

Noob.

Phil Deakins wrote: The Title you chose for this thread seems to be wrong to me. It's the word 'discrimination' that seems to be wrong. You appear to imagine that your avatar was the subject of discimination because it looked like a child, but I don't know anyone, in any world, who discriminates against children. There are places where children should not be, and so they have to be moved out, but that's not discrimination. It's protecting the child. In different settings those same people would welcome children. It's just not discrimination. Not the sort that has a bad undertone, anyway. [Emphasis mine.] Really? There are some quite well-known (by SL standards) folks who've made it quite clear that they consider all of SL to be a place "where children should not be" which would seem as close to discrimination as makes no difference. On the other hand, the OP's situation may just be the usual overgeneralization and paranoia -- much of which is fully justified by various RL legal witch-hunts conducted for political gain and prime-time ratings more than for any child's welfare. On this subject, I've come to suspect the accuser more than the accused -- not unlike "innocent until proven guilty," that. Not that it matters.

Now that you mention it, basic accounts used to get L$50 each week they logged in. I wonder if those ancient accounts are still grandfathered-in. (I actually have such an account that got L$50/wk at one point, but I let it go briefly Premium and that broke its L$50/wk stipend when I took it back to Basic.)

Right, this takes a bit of practice. Assuming, however, that we're talking about Castle Rock here, I paid a visit, and it would be easy to cut thousands of Land Impact with just a bit of work. There is for example a parking garage with a current LI of 102 but should be 30 or lower using some texturing and modern building techniques including mesh physics but not converting anything from prim to mesh geometry. Also, there are some fairly high-LI trees, by modern standards. It does appear, however, that some first steps have been taken on the sim. A few of the builds do use mesh physics (and not just the purchased ones), so somebody is indeed trying. The other possibility would be to rent a Homestead and migrate part of the current sim's contents onto it. You're really very much better off not increasing LI density on a single sim because you'll start to get complaints about lag. To spread that out over a regular sim and a Homestead would take somebody acquainted with the region's usage, to move just the parts that fit within a Homestead's limits on avatars and LI.

I think you've got your answer already, but I'd sure like to know: Where did you find this skybox rental? I mean, considering how difficult it is for really good landlords to find renters, it would be most informative to learn what enticed you to rent from this guy.

Yeah, I get it that basic sound is working, so alsa and (I suppose) pulseaudio is working correctly when invoked from the viewer. But streams are a very different thing. The audio signal doesn't actually pass through the viewer at all, but rather the viewer tells a separate stream-playing package to connect directly to the source stream, bypassing the viewer. So I was suggesting a test to see if the problem is with connecting to streams (in which case Clementine wouldn't play them either), or with the viewer invoking stream-playing of the parcel URL (suggested if Clementine plays the streams without a problem). I'm sorry I'm not helping that much; it would be better if somebody familiar with the Fedora distro could help instead of me. They'd at least use the correct terms, even if they hadn't encountered the problem themselves.

Okay. Well, I don't use Fedora, so I'm not sure what streaming music program they bundle with that distro, but I'd suggest trying to grab the stream URL that you're trying to play in SL (from About Land / Sound or wherever) and paste it into your music player and see if it works. If you don't have a player, Clementine seems pretty nice for this. Assuming that works, then you have streaming configured well enough that SL parcel audio should work, so then we'd need to figure out what's specially broken about it.

Did you ever have it working on this installation? On Linux, the audio and media streams all go through gstreamer, which is very often either missing of misconfigured. Also, it's a piece of junk, but it's what we're stuck with for streaming stuff on Linux. Anyway, snooping around your gstreamer is more likely to get somewhere than would iptables, I think.

Oh, I just realized one can buy this. Pretty sure I was using a free copy I got somehow, so just now bought it on Marketplace. But if you're building a HUD, you should look at the other stuff in Nexii's Marketplace store, too.

It's a grand pain in the butt, especially before one knows it happens. Even then, it's a pain, although in the cosmic scope of all the things that are a pain about scripting, it's one of those happy cases where it's possible to work around it, however annoying that workaround is. (Someday I'll post the whole story of failing to work around an insanely obscure bug in Linden plants, of all things. But not just now, because I'm busy failing to install Windows 8.1 because computers are the devil's devices.)

Wandering Soulstar wrote: Qie, I did not think that a script set to not running was using available script memory ... does though make some sense if the state of the script when it was stopped is maintained. How though is that different from an object (prim) containing the scripts that is inside another object? As to the buffer issue .. I know, am wondering about that myself, and until I get the HUD past initial coding and can do a stress test on it (my next building project) I will not know. Difference is that the scripts inside an object's inventory have no state; they'll start from default state_entry if rezzed somewhere they can run, and until then they're just compiled code stored in a central server's database. (I can't think of any theoretical reason that sim-resident not-running scripts complete with state couldn't be shunted off to the same database instead of residing in sim memory, but they aren't. On the plus side, having them all in sim memory makes them quick and cheap to turn on and off.) I wanted to raise the event buffer issue in case somebody had a suggestion. Off the top of my head, I'd just delay the responses for random amounts of time and hope for the best, but there may be some standard practice that's sure to always work for any number of responses.

Wandering Soulstar wrote: Just thinking of the multiple deliverers ... I could have them loaded into the HUD, but not running and only start them as needed to deliver and then shut them down afterwards .. at least would keep general memory from being over burdened It may be a good thing to do, but it doesn't affect memory use. Every script in the contents of an object rezzed on the sim must be resident in that sim's script engine, whether it's set running or not. That's because there's simply nowhere else for the script's state to exist. So here's another option: Instead of pushing the updated script directly from the HUD, have the HUD rez a "script update relay" object that it will use to pass on the scripts to the intended target prims. The only advantage of this is that the relay object can have oodles of scripts inside to simultaneously llRemoteLoadScriptPin out to the targets, but the relay object doesn't have to be rezzed on the sim except on those rare occasions when there's an update to distribute. I should caution, however, that I'm unsure of the system design, now that it's been explained. I'm particularly concerned about the HUD listening to hundreds of target prims that will all respond to the HUD's call: I'm thinking all those simultaneous responses will overrun the HUD script's event buffer.

Just thinking out loud here, but: could use llRemoteLoadScriptPin to deliver both the intended payload script and a script that further distributes that payload to another target. Should be possible from within one target to figure out which would be the next target -- either in a flat sequence or a tree of self-spreading scripts. I think a single script could spread itself this way, using a start parameter to avoid doing it when merely reset. (Otherwise, a flat sequence would be just as slow as doing it from a central prim; slightly slower, in fact.)

Apparently not. I tested this because I could imagine a mechanism that would make this happen, but the event didn't fire.

irihapeti wrote: if have a good gfx card then max draw distance for static/still views renders faster after all resources have been downloaded and when cache is not full it renders faster bc it culls less. It culls less bc: is this previous known resource within the draw distance? If the answer is yes to everything then it dont need to cull the scene [...] Hmmm. Even in this static case, this would imply that it's cheaper to draw than to cull, which may be true but it's not intuitive to me. In fact, for modern Linden viewers (not sure if Firestorm has yet caught up with this part of the Interest List changes), there shouldn't be much to cull with the shorter draw distance unless the viewer previously had a longer draw distance for the same scene, or somehow otherwise contaminated its object data with lots of objects outside the current shorter draw distance. Unless I'm missing something.

Actually, I was a little surprised myself. I'd known somehow that the next step was 1/2 sim, but I thought it would add the same cost as the first 1/2 sim ($125/mo), so it comes as a happy surprise that the next step is at the same rate as the full-sim. (Admittedly not quite enough of a "happy surprise" to get me to tier-up to it right away, but a boy can dream.)

This is silly. Yeah, it's technically against the ToS to share IMs in-world or on other Linden properties such as these forums, but that's an obvious leaky bucket. Suppose you were IM'd something that needed the landowner's attention -- I dunno, infanticide or something. You gonna man-up and break the ToS and let the landowner know? Or just sit on your hands because: ToS, let the babies die? Or superficially sidestep the ToS and send the IM log in email or text message? (And if you would send the information by another medium, just what does that mean about the real value of that clause in the ToS?) Incidentally, the whole incident seems much ado about nothing. Getting bumped in an arrival area happens all the time. The only reason to make anything of such an event is to stir up drama. I don't want one penny of my tier money going to pay Lindens to adjudicate such nonsense.

You know, I now have no idea what that checkbox is for. It's documented in viewer help on the wiki, but it really doesn't make any sense to me. Before, I thought it only controlled whether the parcel is shown in Search results for users with specific maturity content settings. For example, I thought, a parcel on a Moderate region could still be listed for a General-only Search as long as "Moderate Content" was not specified in this checkbox for the parcel. But now I doubt that's correct: with a General-only search, I don't think I'm seeing any results from Moderate-rated regions, regardless of how this checkbox is set. (Maybe I'm overlooking them, or doing it wrong?) I'm quite sure it does not affect preferred maturity ratings and parcel access, which is controlled by the region's maturity rating, not the parcel's.