Void Singer

annnnnnnnnnnnnnnd, we haz update v0.5 is live on the wiki (click the picture in the original post) now has support for inline script elements in pages, faster page loads, Title support for external browsers, and a few other goodies

and now we can use llRegionSayTo to negotiate a script pin for loading on the fly...

Innula Zenovka wrote: Void.. does this mean that llRegionSayTo(avatar's uuid,-1812221819, "some message"); is going to be picked up by that avatar's rlv relay without adding to the congestion on the rlv relay channel? that message will hit all attachments on the specified channel, without a peep on the public side... it can't replace the ownersay portion of the RLV protocol, but the stuff that happen off of the PUBLIC and DEBUG channels? you betcha. all with no need to find out the attachments UUID. and the first thing it's needs to be applied to is making update scripts that don't have to rely on e-mail or http... oh frabjuous day !

I get DNS errors from my location as well (Midwest USA) so I queried whois to see what they have.... they show domain stats as ok and list two DNS servers DNS1.RIGRAG.COM and DNS2.RIGRAG.COM, and I get DNS errors for finding both of those as well. it would seem that your DNS servers are either dead, or behind a black hole, either way, it's not getting through so as DNS entries expire, more an more computers will be unable to reach it. whois also lists this info, and it's who I would call to find out why at least 1/4 of the country* can't see either your domain or the domains name servers... Registration Service Provider: Netfirms, Inc., support@netfirms.com +1.4166612100 This company may be contacted for domain login/passwords, DNS/Nameserver changes, and general domain support questions. *Based on the estimate that my connections runs through california, and the SL servers through Arizona and Texas

that'd be good, if they just tweaked the behavior of llPreloadSound, so that it flagged sounds for preloading... then whenever the viewer saw the flag it could start grabbing the labeled sounds.... it'd definitely need to be optional and default off when sound is muted/disabled on the viewer, perhaps with it's own checkbox to enable/disable in case of problems. I don't see loading every sound in every object as being good though, since it could easily be used to spike peoples bandwidth. even with just flagging sounds by preload that might be possible, so some throttles might be necessary. but otherwise I think it'd be a great addition.

add it to your profile as "Member Ranks(up there)".... might be just the thing to get a few dates =D ETA: ::seriously considers changing my Sig to "No Member to Rank".... then wonders if I'd get banned::

looks like it's choking on some cache purges and giving up.... the crash log probably says as much. (note that it's actually handling the crash so if you aren't getting a crash warning on restart you probably have those warnings turned off) I'm assuming you are using sigularity from the folder path, and that you have it specified to use a different cache location than is standard for other viewers (a good thing). so my next suggestion is to navigate to C:\Users\Cyrus\AppData\Local\SingularityViewer\texturecache and delete thecontent of that folder before trying again.... make sure you refresh and that all files and folders under texturecache are gone before you do.

originally I was happy, but not thrilled about this function comming to the grid... the original spec I read was kinda limited.... oh but it looks like somewhere along the line it got a great boost.... now, you can target, not only a single avatar or object, but also when targeting an avatar on a non-zero channel, it targets all the attachments on that av... and the channel is PRIVATE... no more pollution of the region channels... I am seriously loving this function a whole bunch more now. PS just in case you didn't realize, this function is live on the grid as of todays server rollout for the main channel (if it's not already on leTigre or BlueSteel, it should be in 1-2 days time)

unfotunately Rolig has it, and your work around is pretty much the deFacto standard for doing things. there is one additional method that I've used in a few products... and that is to loop the sound at zero volume for a single sound that needs to be preloaded in a hurry as soon as objects come into range. it's only good for a single sound, but I've used it to great effect in weapon sounds (nothing more annoying than being shot 5 times before you hear the bang) ETA: btw, looks good, I like the use of space in it... too many games i SL think flat.

beds aren't the only type of furniture.... just saying

Xcite has been doing a lot of version updates, and generally every time they change a major version they make them incompatible with the older version protocols.... it may just be that the MLP adapter scripts are out of date with the newer protocols I'm not aware of who wrote the xcite adapter scripts (I don't see them on the wiki), or I'd point you towards that person

understood, I can see how that might be a problem, I was more thinking of sub ranks, but it's probably better not to have to send them to support portal if they find they can't post or whatnot to get up to using PM's. ah well, it was a thought, thanks for the speedy notice =)

I thought Lithium let you tie stuff like that to the rank? granted as it stands right now I think you can rank every 2 posts for the basic role, which is probably unworkable, but a slight tweak there would prevent that (or at least give you a heads up that a problem account was on the rise)

the one named "SecondLife.log"

heh actually, I bet if you edit that prim, and removed the cuts, you'd see that missing parts are just more texture that is cut away by the prim parameters... so all you would do is make a triangle inside of your flat texture, and apply it. Optimally, your base corners would be at the bottom and your point at the top center, then change the repeats to 2 and offset to .5 for the height. sub optimally, you could use the center of the image as your top point, and not bother with repeats and offsets, but that means your texture is twice as big as you need it.

to be fair, the physics engine does have some built in throttles, and I would assume they aren't the only ones; so scripts will useually get SOME processing time no matter what. The MONO bug is MOSTLY squashed by threaded rez, but large amounts of scripts in de/rezzing objects at once is still a bit of a problem. there is one other rather obscure an unpublicized bug where certain scripts can eat up more than their share of time, but it's pretty rare, and only has potential to affect region health. in general, the thing that scripts affect most are the avatars they are attached to (low responsiveness at teleports, mono only) and other scripts. the big exception being scripts that affect physics, which obviously have that as an additional load.

POST data should not be URLencoded, only GET data, without knowing at least a smal sample of the get line it's hard to say (need to know which parts you have URLencoded) you can make the script spit out the data that it's going to be sending, as well as any return code/data

SL won't utilize the extra graphics memory, but other open applications may benefit from the excess and run more smoothly sidenote: WTF were they thinking with that processor name? Sandy Bridges get washed away by excessive surf lol

oh good you got my note that 2.6.2 fixed the stuttering issue... I haven't noticed any problems with AA or anistropy, other than they don't work with FBO/shadows enabled (and never did), but that's easily fixed by turning them off in SL and overriding them in the vid card control panel. The crash on logout is new to me... have you (or someone) filed a jira and included the logs for it? easier to fix things when they are known =) I'm not saying v2 doesn't have a host of other problems, or that "basic" mode isn't a mind numbing disaster (and I've looked at what it does, there's no reason the viewer shouldn't be able to hot swap those settings, instead of requiring a close)... but the problems you mentioned either are fixed (stuttering) have workarounds (AA anistopy) or are new to me (crash on close) Perhaps a laundry list of problems you are facing would be more useful than spamming your hatred of v2 to EVERY post about a v2 issue someone is having (we get it, I despise v2 on multiple levels too, so I'm right there with you)... perhaps then people could point you to fixes for specific issues at least. yeah it's a PITA to have to troubleshoot problems, and ideally we wouldn't have to... but I think you'd prefer solutions to it just being broken, yes? PS if/when you decide to make that post, you might want to make your own thread for it, so it can get full attention, rather than being tacked onto another thread that probably won't have the same visibility.

Opensource Obscure wrote: [...]Using outdated viewers which don't and won't support new features is not a good way to support the development and advancement of the Second Life platform and its ecosystem. neither is using broken dev branches that obviously need to go back to QA.... not that any of that is an average users concern.... just saying

Jenova Spires wrote: Really? I thought I read somewhere that LL was simply experimenting with XMPP as a POSSIBLE solution, but later abandoned it. I wish I could remember where I saw that. Wait, wait, were you being sarcastic? Ugh, my sarcasm detector seems to have caught the bug from group chat. LOL unfortunately, yes. XMPP turned out to be great for large multiple chats, but not for large single chats. no one had tested it for the latter, and it turns out it can't handle it any better than what we've already got. I remember a time when lagging group chats also lagged the client and region the client was on if left open.... you had to make sure to close all large group chats or you'd slow to a crawl and eventually get disconnected. improvements are slow, but they are happening. even the lindens hate this problem as it's resisted every thing they've thrown at it to make it behave.

that's what's know as "Crash To Desktop" you say that you "did a full and complete format of my computer and deleted every old file", and I'm hoping that means you formatted the hard drive and REINSTALLED windows (otherwise you could have some conflicting files in the OS portion, or might have removed some needed ones)... if that's not the case, my suggestion at this point be to do that and update all your drivers, as it'll save you a million headaches later when you discover something else borked. Next I notice that you have dual monitors.... which SL doe not generally play nice with, so make sure SL is limited to a single main monitor for best compatibility. and finally, if you copy the log from C:\Users\<cumputer-username>\AppData\Roaming\SecondLife\logs\SecondLife.log (default location for win7) the end of that may give a clue as to what the viewer is choking on.

my philosophy? if you can't tear it apart cobble it together or see how it works, you'll never be able to fix it, and new things will never be created. Yes that means you have to put up with a lot of horribly scripted stuff, and the way we combat the worst of that is by making the really common stuff Open Source and Free. a little story to expand on Innula's example of the Timeless Door Script. When I first starting fooling around with LSL I too came across it.... and in theory and creativity, it's great, has all these options and does all this stuff.... that most people didn't care about or use... they just wanted a door. It also had problems because the original coder either didn't quite get rotations, or didn't want to give away the "big secret". now me, I was never good at quaternion rotations either, so I applied myself to figuring out how to use them correctly (and looked like an idiot a few times along the way), or at least the formulas for how (I still don't fully understand them), because I knew there was a simpler way.... and discovered that for a little extra effort when making the door, all the problems were solved (and the script only needed one line of actual code, 3 if you wanted to make it easy to set up). but what to do? sit on what I knew and sell it as the super efficient door that never forgets and always works? or show everyone else how simple it could be, and hopefully get people making better versions of what was freely available and bloated overused? I went with the latter. People started using it, and even hacking it up to add features... net result; things in SL got a little better over time (although I still come across the Timeless Door from time to time and cringe) BUT, if that inefficient code hadn't been out there to see, I never would have known, and may have used something like it myself. And if the ideas that were part of that script weren't out there, I might never incorporated them myself.... others have added features or requested them that I might never have considered myself. at least one person took the same simple code I put out, and built a door server, a single script that controls ALL the doors in a house; something I hadn't thought to do (but should have) the moral of the story being that, as a community we need the inefficient to generate more and new ideas, and we need the people that see the popular and commonly used items to make them efficient and freely/cheaply available, so that the inefficient designs aren't clogging the tubes and we also need the people willing to demonstrate and help along in showing the more efficient ways of doing things. with those three things all of SL improves, and has been for some time ADDENDUM: I saw the first uncredited rip of my Zen Resizer the other day and it made me sad (literally all they did was take my name out of the help file... didn't even bother to rename it). seriously don't be that person who doesn't do the the simple act of giving credit for something you got for free when asked.... it's one of the smallest prices you'll ever pay for anything. in fact, try to give it for any whole script, unless it says public domain.it's just a courtesy, but it's one that keeps the free stuff flowing.

yay, turning off show logins DOES work

sure, add an attach event like in rolig's example, but instead of a reset, check if gBooMoved is true and if it is call the same move code... at that point you might want to shift the move code to it's own function that you can call it works because the prim no longer cares where it's at in the moment, it just moves up or down from where it's located at the moment.