Tommy Rampal

I have a GTX 580 and just manually turn up the graphics. Just because it's not tested, doesn't mean it won't work how you expect it. It's normally so they can set a default on graphic settings.

It sometimes gets sent to your Trash, check there and Restore it. If not contact the merchant and they should normally advise you on what to do next.

Hey guys, Pretty new to sculpts/3D design and using Blender, and I've come across a problem which I'm sure there's an easy way around, I just haven't found it yet. I am using the 'projection' technique, where you reassign the UV map, make the image, set it as a texture then rebake it using the original sculpt UV map, but I am facing an issue... My sculpt is quite rectangular on all sides (it's pretty simple). Sides where I believe (not sure what the technical term is) where the two center points lie come out quite distorted (in a spiked formation going round) when viewing the so-called finished product. What am I doing wrong and how can I get around this? Thanks again all!

Pretty much how I've done it: my game sends a request to make a token that carries the initial command with it, it then repeats that command when the token has been made in the database and follows the communication with that token (using a select query to see if that token exists with the agent who initiated it), upon the final communication it sends a final request to delete that token and the token is also reset within the game.

Mm, I understand. Though wouldn't llTimestamp + (string)llGetOwner be secure enough? A unique date and time, everytime along with the key of the owner to prevent same-time collisions... Or is there a flaw I'm missing?

Trying to think of a random generator for tokens without it being broken easily or clashed with others... On the LSL side, would something like [Object UUID] + [Time] be good?

Thanks for the support guys! So here are some things (web-side) I have done: Moved to mysqli, I never really understood the benefits of using it at first - apart from the syntax is a bit different. I work in object orientated side of things ($mysqli->prepare). As demonstrated above, I use prepared statements - that allows me to use $stmt->bind_param to bind values (set as ? in the query) as string, integer, whatever. So hackers who have field information cannot inject bad data (e.g. 'OR 1').. I don't think? Some things I am not sure of: So the server script sends a HTTP request on rez to a page, this checks if the owner key of that server object (using the headers) is the admin key (which is a set value in the database). If so, the server key is updated with that object key (just in case of an accidental deletion, or a server update). The client/product sends a request to get the server key, and sends a http request. The web code checks if the owner header is registered with the database. So is this bad like Jenni said? If so, what is a better way of going about it following the scenario? In regards of replay data (I presume it's reusing a command over and over)... The client has client side values which it updates from (like game stats), and sends the update via. a command with a passworded base64 encode. I guess that's a big enough form of 'encryption', there's a new password for different type of commands. Would anyone suggest this is not good enough or there is a better alternative out there?

I've just read up on SQL injection aswell. While my SQL queries relate to the headers, what's to stop someone from sending their own HTTP request with malicious headers, such as a SQL injection attack?

Hey all, So pretty much I am developing a stat based game, where levels are sent via. HTTP request to my PHP script, which update the user database occasionally with the latest stats (which are sent via. post data). I'm pretty new to PHP, how the headers work and such. But what lays before me looks pretty clear, that without the correct precaution, some crafty player (unsure why they would go through the efforts, but you never know) could sniff the address/what's being sent, and inject their own data - resulting in cheating when a backup takes place. Could someone make it clear if this is possible for someone to easily manipulate how Secondlife communicates with HTTP/PHP headers, and if so is there a fool-proof way to prevent this? I use Base64 password encoding (as described by the LSL wiki) for the post data. I've been awake +24 hours, sorry if I didn't make much sense -_-. Thanks to those who take the time to help, it's really appreciated!

Server side I was thinking of having two values: one version value for the required update and one version value for the optional update. Depending on the object's own version value, it will display the message accordingly (with the required message overriding the optional message). Client side, a Boolean for optional updates will be set to false once the user has initially seen the update message, but I will have it that an icon represented as a prim appears in the HUD, that once clicked it re-shows this message. That's my take on the optional vs.. required update system. Now my take on the old vs.. new update method (for required updates), is the user has decided to undergo an update, it leaves it in a permanent 'Please update/drop' state. The only way of getting out of this is that the script is reset (back to general use) and the HTTP request fails (in which case it times out and carries on as normal). I will recover the game statistics either: by the transfer from the old to new (sends the statistics as a CSV with the confirmation) or I can do it via. Backup (grabs the stats from my database). What do you think of this concept? This way the user can have many updates from error, but will never work (one will only work) as it will require the old version to activate. Once this has happened, the user can pass on the product through gift or sale, assuming the script isn't somehow reset.

Pretty much, the new version won't function without 'eating up' the old version, so the updated copies will uniquely have an 'update-version' boolean placed in the script, which will be set to false upon the update being successful. Newly purchased products will have this set as false by default. I'm unsure about the optional updates, because sometimes it is nessecary. E.g. Base64 password changes (the form of encryption I'm currently using) to fix some sort of security breach, or communication changes (e.g. change of commands or their structure). Unless I had two update functions, with a 'force-update' toggle in the HTTP side of things: so if it's false, the user has the option to continue. Regarding the failed delivery, it's the same concept of the Secondlife Marketplace - how do they deal with failed deliveries? The finished product will be No-Copy and Transfer. So unwanted copies could mean lost sales!

Hey all, So I am currently working on my product and how it updates when a revised version arrives. My main problem is how to avoid unwanted duplicates through copies (aka. a customer updates one old product many times). The system right now grabs the latest version number via. HTTP request. For the convenience of the customer I want to try and make the updates remote, i.e. the product sends an llEmail to the server (with the server UUID grabbed by the HTTP request) and the server sends the new copy to them. Now here's where the confusion lays, we have one new copy and the old copy. What would be the best method now? I was thinking... upon attaching the new version, it asks the owner to drop the old version to the floor; through this the old version sends a verification and deletes itself using llDie (the product is no copy). Is this a viable method or does anyone have any better ones out there?

Secondlife in itself, no and far from it. But it's content might, for example, I am developing a MMA (mixed martial arts) system that will hope to emulate MMA and the fitness behind it, and the possibilities of extending it to such things like the mobile market, where people can enhance their game statistics and levels from a real life work out using their iPhone.