Tommy Rampal

I am not so familiar with HTTPS, how to set it up and how to make use of it within PHP (I have been making use of my University studies, and security hasn't been a hot topic as of yet (early years)).. And checking that the request came from Secondlife servers is what I want. I intend to store a log of all HTTP communications from my PHP scripts, so any malicious communication sent can be manually checked and the owner key can be blacklisted from all further communications. HTTP_responses are just confirmations and return data (e.g. the script sends a special command to request it, and generates that command within the singular script), and to get that confirmation, the token needs to be checked (the token gets created and destroyed on the fly in a handshake, every time the script requests something).

So pretty much, my scripts communicate with my PHP files via. llHTTPRequest; depending on the POST data, it does a query and returns the results in an echo. It works fine and I am currently working on a token based system to ensure no spoof requests can be made; I am a bit clueless however when it comes to checking that the HTTP request has been sent from Secondlife servers. Has anyone got some advice and/or sample code to check this? Also, additional advice to keeping my PHP-LSL communications secure/spoofless would be greatly appreciated.

Depending on what you wanted to do with the screenshots, you can always work with the open source viewer and make some sort of macro? Or just a macro in general?

I also noticed the bug is inconsistent, it flashes 1x1 when the texture animation is initialised - but not everytime. This provides an awful effect for scenarios such as it being used in HUDs.

Thanks for all your help all, much appreciated!

Rolig, am I correct to assume that it's wrong to use touch_start when calling states because not only will it trigger the state change, it will also trigger touch_end (if used) in the new state? Also, I am also skeptical on memory and performance; would having a slave state to substitute a recursive state drink memory and response times? How is that compared to having an init function? Forgive me I haven't really studied the memory side of LSL.

To my understanding and experience, calling a state within the same state does not call state_entry; I've tried using jumps and targets but they seem to cannot break the event barrier; and finally I cannot reset the scripts, as I lose precious memory saved in global variables. What other (practical/optimal) alternatives can I take to get the result I want without adding unnecessary lines of code? E.G. default { state_entry() { //CODE GOES HERE } touch_start(integer num) { state default; // To save future errors and unnecessary code } }

Hi Cerise, this was turned off.

I'm on the beta viewer 2.7.5, and for some reason working with llSetTextureAnim doesn't work properly or not at all. When a texture is animating it goes buggy (as in, jittering from a working animation to the entire non-scaled version of the texture constantly) when changing the view (zooming, orbiting) etc. I changed viewers (back to 2.7.2) and it started to work fine again... Anyone else having these problems. My script calls this line on certain llMessageLinked: llSetTextureAnim(ANIM_ON | LOOP, 1, 4, 4, 0, 16, 8 );

There's phones out now with 1GB of RAM (Take the HTC Evo 3D). And for graphics processors... Take the Tegra 3 showcase Aeon provided.

I also like to run my viewer at full resolution 2560 x 1440. This works fine with Lighting and Shadows turned off (I get around 100-200FPS in a skybox on average), and it doesn't seem to make any difference when I resize the viewer... But it's not the case with Lighting and Shadows, it really has trouble keeping a usable frame rate when at optimal resolution (around 8FPS). I have to resize to around half, which gets me around 20-30FPS with everything set to the max. I just really hope LL optimises the lighting and shadows engine to support large resolutions (which it was good at until now...) on high spec machines without getting choppy, the same goes with Kirsten's Viewer. True SLI support would really help this problem.

From a business perspective the ideal rating would be General. As that reaches the entire spectre of the Secondlife grid and maximises all potential interest. So say the worst case scenario being I pick General, and Secondlife decides it's not. Do they just go ahead and change it? Or do I have to restart the region, etc. Not to mention the sudden loss of support to customers who can only reach General regions.

No elements of death or blood (really), about as much violence as you'd see on a wrestling programme (WWE) or UFC - and that's catered to young audiences.

So obviously it's clear to us (well I hope) what makes something Adult rated in Secondlife. But what about General and Moderate? Is there any documentation on this, aside the obvious (casual nudity, gore, etc). I say this because I am developing a combat system (based off martial arts/MMA/boxing/etc) along with a sim enviroment for it, and I'm trying to analyse what age market I should/can make it available to.

So Secondlife is releasing graphics intensive features, depth of field and shadows, but has not been optimised to take advantage of high-end/today's hardware? I've been playing around with Nvidia settings to try and make use of my SLI (2 x GTX 580) for Secondlife, but haven't really had any improvements on performance. Does Secondlife take advantage of GPUs and SLI as it truely should?

10 years time? Do you realise how close phones these days are nearing the Secondlife minimum requirements (though outdated)? Check out the HTC Sensation, HTC Evo, etc; they're not far off. There's no reason why a watered down java based viwer (a port of the beta web client perhaps) can be optimised now, ready for when such a capable phone is released.

It's funny that in just about 2 months, compared to the 'puny overpriced' phones, there are already devices out that run at dual-core (Android). For Linden Labs and Secondlife to ensure it's ongoing success, the time to go mobile is drawing very near. If they're not already developing it, they really should get started. There's no reason why they can't develop and test it on an API/dev kit, tweeking and putting it into place, ready for when a capable device comes out. Android would be ideal, so many devices get released so many times, and it runs on Java (same as the beta web client)... So porting shouldn't be difficult.

I was stating 'near crippling' as a comparison towards the huge performance spike that those who do not have higher tier hardware would notice more, and for the price I paid on hardware I am in no case happy with a 22 frame rate; It is noticeably more choppy for me as I am normally used to above peak. Think of it as going back to a 56kbps connection after all those years, you lived with it back then and it still (over time) fulfills its use - but now you just won't acept it. I wouldn't think running SLI would barely touch on SL, but I haven't noticed many changes when installing the second GPU.. Though I just installed it, set 'SLI' in the Nvidia control panel, and, well, that's it. I will see if there are driver updates when I get back home. But its bizarre that one of you have an earlier release model to mine (GTX 560 vs. 580), and I can't touch AA with the Lighting and Shadow settings enabled. Bare in mind I run SL at 2560x1440 resolution. It'd be great if LL really worked on optimizing everything to work best on the minimal of hardware, like a game developer optimizes a game to work best on a game console. That way they could work faster to bring a (watered down) version to tablets.

Do you crash everytime you turn Lighting and Shadow on? I do, only when Anti Aliasing is enabled at any rate - click 'Hardware' and see if it's enabled.

Hey all, So playing around with lighting and shadows; depth of field doesn't want to work for some reason... But does anyone get a near crippling frame rate, even on a high-end machine? I have 2 GTX 580s in SLI, 16gb of RAM and a Sandy Bridge i7 processor; and get no better than 22FPS on average (while I am in a skybox with a simple house), compared to 170fps. I also crash without fail when trying to set Lighting and Shadows with AA... "you can turn anti-aliasing on with lighting and shadows, but your mileage may vary as far as its efficacy and performance impact. " http://wiki.secondlife.com/wiki/Antialiasing Is there something I'm doing wrong? How is it for everyone else?

So it actively adds and removes prims to the HUD containing scripts? Is that possible when attached? I've probably misread something vital here.. The page where the sliders are used need to be reused on command.

I have an advanced GUI 'page' which consists of multiple sliders (a settings page), which really can't be placed into one texture . But wow on your test, how did you carry out this test may I ask?

So to my understanding (I don't keep up to date with LSL changes as I should), this is to replace the scripting practices of those who put singular link_message scripts in child prims to save up on sim resources. My case is a little different, I use this method to work with quite an advanced prim based GUI (around 38 prims) where it sends out unique commands to child prims depending on which prim was touched; each prim reacting/changing differently to each command (e.g. a prim turns into a button, then into text, or hides if it is not needed). Now I was thinking, I could just recursively use LlSetLinkPrimitiveParamsFast's for each prim - but not only would that make the GUI change in a very transitioned manner, like you'd see a flood of chat text (compared to all changing at the same time); it would also drain the main script memory, which could be used for other things. Has anyone got any ideas of how I can work around this? Or should I not worry and carry on as usual?

Hey guys, For those estate/sim owners out there: I was wondering if it was possible to easily change e.g. from homestead to full or vice versa to fit better purposes or monetary situations? Thanks!

I was working from a block, and made the main face (which I want everyone to see) the one with seam/pole. It was a simple sculpt, so I can rebuild again putting the seam somewhere else/insignificant. It's a shame there's not a workaround (assuming there isn't), more of a reason to look forward to mesh I suppose.