Void Singer

wrong prim counts and "immortal" prims are two separate issues... the first should be limited to magnum regions (most of the linden homes run on this) and the second is sytem wide. there is a fix already being tested for the second problem, and a fix for the first is being actively worked on.

Phil Deakins wrote: Amazing! How come you arranged for "personal information" to be sent to a third party in the first place? [...] that's a completely ridiculous statement, the information was (and must be) collected by the company handling the payments. they literally have to have it to do their job, (just as with paypal)... the only question here is NOT whether they should have had the information (they should), but what they did with it and how they handled it. @Arkady: I don't disagree in the least... non-US residents are stuck in a "damned if you do, damned if you don't" scenario that's rather ugly... I'm glad this was exposed in that companies "fraud prevention" practices, but sorry for the people that got tagged on it. hopefully it means smoother sailing in the future for payments outside the US.

Phoenx help can be found through the phoenix website and inworld phoenix help groups, this really isn't the place to ask about phoenix issues.

... and if not that's perfect bait to get him to post back? =) I will say this... the speed of results is dramatically improved, so kudos for that

there is an improvement noted for derez of scripts, but the last I heard from Kelly was that the bug for MONO derez is still present, but i may have missed an office hour that updated that. I do know that small loads of mono scripts should (and seem to) load equal to LSO, but heavily loaded av's (from a few to several MiB) are still gonna get hit by the lazy transfer delay that's used to prevent region pausing on region entry. dunno how soon that will hit main channel, since magnum is having issues, and leTigre is next up for promotion. mono2performance may go to leTigre

fall through for if is only optimal if multiples are possible, because they run all tests before and after they get less efficient the larger they get. they are whoever the smallest in code size, largest test waste (all options tested) fall through for if/else is only optimal if tests that are more likely to be true are first, because it will run all tests betore the one that is true. they get less efficient the larger they get, middling code size, and test waste (all previous options tested) Binary trees don't begin to really shine until you get over 4 items, at which point they surpass all the others for roughly equal likelihood paths. they get more efficient the larger they get, only adding one test processed for each power of two more options. largest code size, smallest test waste (none).

you can read more about it by looking at FJ lindens posts elsewhere on the forums, which has links to more info.

the first structure is used when multiple condition could be met to be sure and capture them all, the second will only go through to the first matching condition... neither is optimal to the situation, but the if/else version is preferable, since it will skip all tests after the first successful one. it *could* be optimal if the earlier tests are more likely to be true than the later ones. if all options are equally likely, then a binary tree is more optimal, which is a special way of building if/else statements so that all options take the same number of tests to get to, and no tests that are not needed are performed. the easiest way to build binary trees for text options is to index them in a list, and find the index that matches. once you have the index your check the highest possible bit with an if else, then in each of those choices, test the next highest bit, and so on, until you get to the lowest bit which tell you which code to run... below is an example of 4 actions, sorted into a binary tree iteger vIntChoice = llListFindList( ["a", "b", "c", "d"], msg );if (~vIntChoice){ //-- ignore items not found in our list if (0x2 & vIntChoice){ //-- test the second bit if (0x1 & vIntChoice){ //-- test the first bit //-- you chose "d" (0x2 + 0x1 = 3, the fourth index) }else{ //-- you chose "c" (0x2 + 0x0 = 2, the third index) } }else{ if (0x1 & vIntChoice){ //-- you chose "b" (0x0 + 0x1 = 1, the second index) }else{ //-- you chose "a" (0x0 + 0x0 = 0, the first index) } }} and there's the same thing formatted a bit differently for ease of reading the options iteger vIntChoice = llListFindList( ["a", "b", "c", "d"], msg );if (~vIntChoice){ if (2 & vIntChoice){ if (1 & vIntChoice){ //-- you chose "d" (0x2 + 0x1 = 3, the fourth index) }else{ //-- you chose "c" (0x2 + 0x0 = 2, the third index) }}else if (1 & vIntChoice){ //-- you chose "b" (0x0 + 0x1 = 1, the second index) }else{ //-- you chose "a" (0x0 + 0x0 = 0, the first index) }}

the only thing I can suggest at this point is that the firewall may be too restrictive. there may have been a change in the viewer protocols that requires something that is currently being blocked. you may be able to investigate the logs to find out what.

nah, it's fine... I just have to wipe the nose prints off the glass and turn out all the direct lights (damn glare) now that I've increase the font size twice =X I'd size it down to 1024x768, but then nothing fits on my screen anymore.... the perils of getting used to working in a much larger space.

without considering that bug, the answer is "most probably".... it's possible that the same simple short script will actually be larger in MONO than it is in LSO, particulary if it's function/math heavy instead of variable heave (exception, strings), but if it's a script there are likely to be multiples of, it will benefit from bytcode sharing. how that works, is essentially, the MONO engine uses one set of instructions, for all the duplicates scripts, and only has separate spaces for variables and the execution pointer (where each instance is at in the code), which actually saves memory, especially in math and function heavy scripts (not so much in scripts that maintain a lot of variables), plus it runs faster over all. considering the MONO insertion/removal bug (the insertion part of which is supposed to be fixed next roll) I'm still recommending LSO for anything that travels multiple regions, or (de)rezzes often, unless it just can't be made feasibly without MONO. testing on an near empty region with vehicles shows that while behavior is much improved, to the point that a very lightly loaded av is crossing in it there's no perceptible difference, a heavily loaded av still takes a performance hit by comparison... that said, if it's a choice between 3 LSO and 1 MONO script, you might as well go with MONO @Peter: because permissions are communicated through the server to the client and back. I'm not for certain if that ability was intended, or just exposed though... you'd have to ask someone more familiar with viewer coding, 'cause I avoid it like the plague

also try other regions once you manage to get logged into a different region, specifically empty ones, to make sure it's not your home region that's the source of the problem.

the beta was opt-in for a limited number of non-us users in certain areas... noone that wasn't in the beta should be affected, and you'd know if your were in it

Arkady has it... that part is down to computer and vid card specs.... the vid card will control the draw rate, and the memory and processor will determine how well you can multi task (performance wise)... I regular have a half dozen other windows open on my home system while on SL, but I also turn off all those stupid auto start tray programs... I can run a good dozen windows and never notice anything, but my own system specs are beastly... my old computer, I was doing good to run SLand a browser window at the same time. you shouldn't notice a huge difference in behavior, compared to running a single, but there will be a difference, and probably noticeable since your new monitor will be larger (I'm assuming)... which means both an increase to processing of 3d (again assuming the new and big will be home to SL) and a slight increase for application/destop drawing on the smaller. unfortunately there's little you can do to mitigate that, past dropping a few settings on SL funny side note, my own hom monitor just blew up, out of warranty, and I'm using an old 17in CRT for back up... C'est la vie... I'll be buying a new monitor come monday too! lol (Heavens know I've been spoiled, it's so hard to see anything on this thing, dunno how I used to do it)

apparently, yes =X

unfortunately, no, unless you can specify the bone lengths... meaning they would have to use a specific shape. this is the exact reason that animations look odd of some av's and fine on others.... fiddling around with the positions for your av you can eventually get near perfect alignment, but it'll only apply to the settings of your particular shape.

you can force it end at a certain physical position, but it'll either jump to that position, or you would have to make the object physical and then try to calculate the position to end at when using target omega.... because there no way to determine the non physical rot on a viewers screen (which starts when they view it, and is determined by their hardware). I don't know if anyone has written such a function for target omega operating physically, though it's definitely possible at that level. alternatively you can use incremental step rot, but it's very slow to be relatively smooth, and there is a viewer threshold for how small those changes can be on a given size object.

::comes along:: oh hai! lol internally the 64k is always "available" but memory is still assigned dynamically in blocks... the ability to specify is just something that will allow cutting out the code that says "hey do we need to check on allocating another block" sooner, which will allow reporting it viewer side as well.... but even then, if we specify 64kb and only ever use 4kb... it'll report 64, and behind the scenes it'll still only use 4, but also continue to check if it needs to add more. this is done for consistency, without which things like script limits and reporting become almost useless, since you can't define what's what anymore or get an accurate read. what we see viewer side is just the reported cap, and not the actual usage (which is what those new profiler commands aim to tell us), internally, it's all dynamically allocated as blocks for MONO... LSO is straight up 16kb block, no variation, no bye sharing. as for permissions, it's possible to revoke just about all of them, and some are auto revoked depending on owner status or how they were obtained... (for instance I believe animate was changed to auto revoke if requested on sit, and then the av gets up, others I'm not sure about)... given the high usage of the one viewer that allows extended permission revocation, it's always safer to check your permissions at least on rez or attach

Torley's Media wrapper works well for shared media, the only caveat is that it's not generally feasible to try and force looping of multiple videos... the reasons being that not everyone's connection streams as fast, so there can be pauses which will extend the play time of the video, or even end users stopping rewinding or fast forwarding it. although you can guesstimate and pad all you want and hope they don't do that. if you are the author of the videos you can make auto redirects at the end which forward to the next video, as about the only option to making it truly feasible.

it was never entirely unexpected, as the whole thing was built to learn what is being spoken vs what the textbooks say, to improve their own translation rate. to that end it was spectacularly successful and if you followed it from the begining you could see how well it improved it's accuracy across the board. but google is a victim of it's own success, and the ease of access despite lower accuracy of the public appliance (which didn't allow alteration) made it hugely popular for real time translation that it wasn't quite ready for...in short they got slammed. Now they're focusing on a better ways to brand and monetize it, again, no surprises there. the website inclusion (which sticks their widget on the webpage, low exposure, high visibility, and tracking) is sticking around because it adds value for them. SL may change to another service, but I predict those services will quickly dry up as well as the mass of current free users on google transition over and are also slammed. eventually it'll only be viable as a paid service or in limited static forms like you see for in page translations. at that point, it'll be pay or do without for live translation.

Great? meh poor pacing, poorer acting (horrible lead), it gets a B from me at best. the series was an improvement for a season or two.

that will require a ticket to fix

did you miss the steps where I said to size it to your max desired dimension? that can be up or down... in the example it was down because an image scanned it of the size mentioned is going to be larger that 1024.

since the all sucked.... none of them... the card game! lol

try turning off voice before teleporting... it looks like it's flooding the connection. second, try logging into a different region (there's a setting to show location on logon screen in prefs, type a different region name into the box that appears before loging in) best of luck