Kwakkelde Kwak

Knutz Scorpio wrote: I think others can see that texture while you are logged in but I'm not 100% sure about that one. I'm pretty sure others can't see your temporary textures (or sculpt maps). As far as I know it's loaded to your local cache so your viewer can find it. It never reaches a Linden server.

That really depends on which Linden is at the scene I think. Maybe it's new policy not to return anything over the parcel boundary, but I think it's a personal choice. I've had trees returned in the past, maybe a couple of inches over the property line. Then again that indeed WAS in 2007 or 08. Anyway, if you're sure you're not bothering anyone, I don't see a reason not to do it. Rules are here to help, not to restrict.

You could also write a simple script, just load 8 pictures with a big "0", "1", "2","3" etc... then asign those to the corresponding faces.

Ah the ++ ...I'm not that experienced with scripting

Patrick Playfair wrote: { llSetTexture("textures",current_index); if(++current_index >= textures_number) current_index = 0; } I'm not sure, but "textures" isn't specified from what I can see and current_index never changes....

Don't change to integers or whatever..just use a mono script All it takes is a click.

No idea if the solution is this simple, but it could be: I always have to click the browse button twice for some reason, but it always works.

Shift...hmm shift..oh there it is, on the keyboard, next to the "z" To copy an object you select the object you want to copy, hold shift on the keyboard and pull one of the arrows. You do need to have copy permissions (not copyrights) on the object. Also you need to unlink the wall first, or you will either copy the entire house or copy nothing at all but instead move the prim (this is when you have "edit linked" checked in the edit menu).

If one of your LOD models isn't the right scale, there's a couple of things that could be wrong. Two I can think of from the top of my head are: - If the model is too big, maybe you have some geometry attached to that LOD that shouldn't be there. - If the model is too small, you possibly have geometry on the edges deleted compared to the other LODs. Both are because the uploader takes the size of the bounding box in the highest LOD and applies it to all others, same for the physics. EDIT Oh I see someone already posted this...duh.. anyway, this might be what is happening. Also if you never see LOD 4, I wouldn't generate it, but set it to its bare minimum in the uploader and save on display cost/prim cost. For the materials, if you have the same material set to all LODs and they show correctly before exporting, the order should be fine. Maybe you are missing one of the submaterials in one or more of the LODs.

Now that you found the log file, could you post what it says when the error occurs?

Yes so the rotation i suggested doesn't work aswell What would work is an attached car that replaces the one on the actual wheel (using alpha or something to hide that one) ... then put the spin in the animation. It would work...but there has to be a better and easier way I guess.

As far as I know you can't put a targetomega in a child prim if you want it to spin an avatar, I think the opposite of what you wrote will work though, targetomega in the main prim and rotation in the children.

Yes maybe that's because I was on agni ...like I said a 500 error, as far as I can find, is indeed a server error so it's probably on LL's end. So someone pulled a wire from an aditi server.... I bet they will stick it back in on monday.

If you use one 512x512 for all surfaces you will only have to load it once. Whether that's better than a number of smaller textures ofcourse depends on their number and size. if you use less than 16 128x128 textures that will be easier to load, or less than 4 256x256 ones. The only small problem you might encounter with several smaller textures is the fact they all need to load and they likely won't do that all at the exact same time, so on rezz some textures will stay grey a little longer than others. With small textures and used on parts always shown that won't be a very big issue though.

Well that doesn't help much no...looks like a server error, but erm, that's what you already knew. The messages don't say anything about corrupt data or any problems with the mesh itself, so I wouldn't suspect the files. The viewer should be fine aswell. I have no issues and you have issues on all your machines. It's a long shot, but maybe resetting your modem helps. EDIT From what I read a 500 error is not anything that can be fixed from your side. Let's hope it's temporary, (if not, file a JIRA or use the support channel). SL servers are always a bit unstable in the weekends in my experience.....

There was an earlier post, same as yours: http://community.secondlife.com/t5/Mesh/Errors-and-crashes-with-the-mesh-client/td-p/947649 It wasn't answered... so it's no real help... What does your logfile say? Maybe that will give us some information....

I think a nice stack of single lines as I posted is at least 10 times more readable than two screens of white lines and brackets, this is all very personal ofcourse. I always put a bracket on a new line, both opening and closing ones. But when an "if" or an "else" only points to one command I am not going to fill a script with brackets and air for no reason

It really depends.... if the model is not superdetailed you can get away with a couple of prims I bet. On top of that you don't need to duplicate the entire model for the different frames, you can keep a base in one material and have seven frames of animation by moving arms and legs. I think seven frames would make quite a nice frog jump, ofcourse not as nice as a fully animated rigged frog:).

No you will need to move the lower arm itself, rigging unworn parts is not supported (yet).

If you do it with seperate meshes, you have the same issue, since you can't switch mesh like you can switch sculpt. Unless you mean seperate meshes for every small frogpart. That would destroy smoothness between those parts. It really depends on the object and its detail what is the better solution. I haven't played with the prim animating scripts for a long time, but my experience was very jerky as soon as there was a small amount of lag. Until unworn rigged meshes are supported, there is no good solution as far as I know, but several that will work quite well. Trial and error I think to come up with something satisfying....

Maybe i am cursing in the church of script here, but if a 16k lsl scripts memory is all used, I normally just switch it to mono.... And fully packed prims do have problems loading everyting in time in my experience yes...but that's just my experience, i have nothing but that to back this up:)

Latin squares don't need a lot of thinking:) .... Latin square generator and yw ofcourse, great OP...

SUDOKU! Now all we need is a plugin script for all 3D applications so we don't have to move around the squares by hand:) You don't really need the latin square ofcourse since with 8 different SL faces you can almost fill Meaves entire 13x13 (169) grid with unique squares (128). I think that will give a more randomized look than 13 tiles spread randomly. But all ways lead to Rome (No pun intended..well maybe) On the other hand with the latin square setup you only need two SL faces and don't even use all their rotations and mirrors.

Very true, in cases like the script by Rolig two posts up, where next to the text you set the colour, you really need the brackets. For single commands I prefer the one without brackets, since it's nicer to read for a human being. This is especially the case if you want several voice commands all with a single action. Example: if (message=="open") llSay(0,"The eye opens."); else if (message=="green") llSetColor(<0.0,1.0,0.0>); else if (message=="red") llSetColor(<1.0,0.0,0.0>);

I've seen this suggestion on the forums before.... you can have 8 different materials, so why not make one mesh with all the frames in it? all frames can have the same texture on a seperate material ID (SL face) , all you have to control by script is the alpha, unless you want superrealistic shadows and occlusion... That way there will be no high texture load. Only thing is you are limited to 8 frames ofcourse.