xigaro

I think data integrity - particularly records of creators and permissions - is one of LL's highest priorities because of the commercial nature of SL. Mistakes happen though and it's in everyone's interest to keep details of the vulnerability private until it's fixed. Where possible any asset transactions which are suspicious or can be traced back to the vulernability would be reversed. Only LL can say if every patched vulnerability is publically reported though. I can't think of a way in script (or otherwise) to cross-reference LL's reported vulnerabilities with the object you're studying. I think llGetObjectDetails() will be 99.999% accurate though The time spent on that last 0.001% may cost you more than you'll save.

On-topic: I wrote a translator HUD a couple of weeks ago but it's not an easy task. For my HUD I decided that the user can decide between channel 0 (so everyone can see their original message in their native language, as well as the translated version - useful in some social circles) or using channel 1 (to hide the original message, but requires /1 prefix). Suzanne is right on the money in my opinion - using RLV to redirect local chat to another channel is the cleanest solution. Once your script has received the chat message it must send an llHTTPRequest() to your web server with the chat message. The server must then translate that, somehow, and return the translated version in the body of the response. Translation is tricky because most online services these days will charge. I struggled to find a free one. Don't fall for Microsoft's "free" translator API because it isn't free and it's a pain in the butt! There may be some software you can install on the server to translate locally but the output won't be as accurate. Off-topic: Sorry this is going way off topic now But I wanted to chip in on the TPV side of things. First of all the majority of TPVs are open source - the code is available for inspection to anyone. It only took me 2-3 hours to understand the login portions of Firestorm. By using Firestorm I am not sharing my password with anyone except LL servers. If you're super paranoid about the published open source code being different from the downloadable compiled .exe then you can compile the viewer yourself from code locally on your PC, or use a checksum to ensure you have downloaded/installed the official version. Granted I will only TPVs which have general community approval - I'm not going to run a TPV given to me by a random stranger. To say that open source software is a "bad idea" because it's "not official" is frustrating to anyone who contributes to open source software and, in my opinion, reverse logic. I can read through my Firestorm viewer code and see what data is sent to whom, but I cannot say the same for the official viewer. This goes for any closed software. That's the first I've heard of Emerald but I don't think it's a big deal. First of all the data wasn't collected by the viewer. The data doesn't contain any sensitive information - no emails, passwords, names, payment information. What was collected ("avatar names, IP addresses, and geo-location information") is information anyone could collect in-world by rezzing an object with a media player anyway. Ultimately the data is useless and not relevant to TPVs. If you think your IP address constitutes sensitive information then use a proxy service or unplug your freakin' PC. </rant> That was way too verbose. Sorry. I feel better though :matte-motes-bashful-cute:

Thanks everyone for your help and suggestions So far we haven't encountered the bug with the hidden hovertext approach. I have taken Rolig's suggestions and wrapped them into a function which seems to work very well for the game- I hope this is of use to you. Simply use this function instead of llSetLinkPrimitiveParamsFast() - hey it's quicker to type too! - and you should be bug free. It checks the list of rules and applies hidden PRIM_TEXT if your rules don't apply PRIM_TEXT already. If anyone can think of a simpler or more efficient approach please reply slppf(integer link, list rules){ /* Attempts to fix viewer texture/color update bug */ // Check to see if hovertext is being used already integer i = 0; integer hovertext = 0; for (;i<llGetListLength(rules);++i) { if (llList2Integer(rules, i) == PRIM_TEXT) { hovertext = 1; } } if (! hovertext) { // Append invisible hovertext as fix rules += [PRIM_TEXT, (string)llFrand(1000), <0,0,0>, 0.0]; } // Apply rules llSetLinkPrimitiveParamsFast(link, rules);}

Oh my, Rolig to the rescue again I've just finished the 17 script version and it feels very sluggish to play. I'm glad there's a better way! No word from my beta testers yet (no news could be good news...) If the invisible hovertext fixes the issue then I'll be sure to use PRIM_TEXT in the function call, thank you

Thanks for your replies Yes four of us encountered the problem all with Firestorm (various versions). I've just tested with the official viewer and have the same problem although it felt less pronounced - delayed rather than not showing at all. Hard to test with such an intermittent bug though! I will try your suggestion of forcing updates with invisible hovertext. It's a shame as I have one script controlling 17 objects, now I will need 17 scripts. I was proud of my efficient scripting But efficiency is useless if the object doesn't work. Will let you know how I get on. If there are more ideas in the meantime please let me know!

TL;DR the viewer is not realising/showing linked prim textures/colors have updated I've written a simple word game with 4x4 tiles for letters as linked prims. I use llSetLinkPrimitiveParamsFast() to set texture offset and/or face color of each tile (the root prim doesn't change color or texture, if relevant). My beta-testing friends live on quite a packed sim and they're running into problems - the viewer doesn't always show the new texture offsets or color changes. Sometimes it is instant, sometimes it takes 3-5 seconds to show, other times it doesn't show at all. The script is definitely setting them fine. If they right-click the object then all the texture offsets and face colors seem to instantly update to their correct versions. We can't recreate the problem on other sims (tried about 6) but I know the troublesome sim has a lot of animated textures, particles, etc going on constantly. We were all testing in Firestorm. My script doesn't hammer changes. It makes 16 texture offset updates and 16 color changes at the start of the game, approx. 120 color updates over 180 seconds, and a final 32 updates at the end of the game. Is this a problem anyone else has come across? I'm stumped for a solution! Thankies

Hi everyone! I'd love to help out other people with their SL scripting projects but I'm not sure of the "going rate", if there is such a thing. What do people normally charge for writing scripts? Is it per hour? Thanks in advance :matte-motes-big-grin: Xig

Ela's idea of a giant prim to change the centre of mass seems to have done the trick. Spot the hack on the right The other plywood prim inside the bus is the root prim. So it looks like the centre of mass is indeed the pivot point. It now turns on its rear wheels almost as a bus would. It's not ideal though. There doesn't seem to be much documentation online about how the centre of mass is calculated or how I can alter it. If anyone has a better suggestion pleaaase let me know! In the meantime I'll keep working with the hunchback bus Thanks everyone for your suggestions so far.

Thanks everyone for your ideas. Yes to clarify the effect I'm after is pivoting the vehicle at the rear wheels. With a big bus it looks awkward when the rear wheels slide around. I've made a (terrible) animated GIF to show the effect I'm after. Actually my animation is a bit wrong and Kwakkelde's link to this image is exactly what I'm after. I have tried setting the root prim to a cube above the rear axle and put all scripts in that prim, but alas that didn't seem to work either. Any other recommendations I can try? I've run out of ideas! Off topic: rear-wheel steering vehicles do exist. Some big lorries in Europe have rear-wheel steering as well as front-wheel steering. Fork lift trucks on building sites steer entirely from the rear (it makes my head hurt watching them).

Try connecting to another region on the SL grid. It might be a poor connection to one simulator but you may have better luck with another. You can set a custom landing point on the login page, or visit SLRUL and try teleporting to a random point on the map. Once you're online try teleporting back to the original region. If you still can't connect, or can't connect to the original region, you'll need to open a support ticket to inform LL of connection problems. Explain all the steps you've already taken. Include your IP address (www.whatismyip.com) and the name(s) of the regions you're trying to connect to. They may ask you to go through additional diagnostic steps. There's not much we can do on the answers board. Sorry D:

I've built a big vehicle which is a hollow oblong with a few extra prims. Basically a bus. I have a vehicle script which works well but it steers from the centre of the vehicle instead of the rear axle. I've read that this is because of the object's centre of mass. I can't find a way to change the centre of mass though. Changing density of linked prims doesn't seem to work. Putting the script in a child prim at the rear of the vehicle didn't work either. Nor did setting VEHICLE_LINEAR_MOTOR_OFFSET (because it's angular, I suppose). So - is there a way I can change the centre of mass and/or the pivot from where the vehicle steers? Thanks for your help in advance!

I'm not sure that's a good idea. An 8 hour work (office) day should include a balanced variety of activities to keep the brain engaged - various computer tasks, answering phones, running errands, meetings, recreation, etc. Most importantly regular breaks from the computer.