Xxaxx Constantine

I know this is an old topic. Just replying here because google ranked this near the top of search results for the error. I had this same problem 2020 with blender 2.82 What worked for me was to join all the objects in my model into a single object. I then joined all the objects in the lod. Having the model and its lod contain just one object each made it work for me.

That explains so much. Thank you all for the input.

I have a script that will cause (at the click of a hud button) various child prims of my target object to rotate. I can make the target prims rotate quite nicely. I'm using llTargetOmega to rotate the prims. THe problem is with stopping it. Nothing I do will return the prim to its default <0.0, 0.0, 0.0> position. I've tried: llSetLocalRot( ZERO_ROTATION ); llSetRot( ZERO_ROTATION ); llSetLocalRot( ZERO_ROTATION / llGetRootRotation() ) Basically throwing snippets at the issue to see if any will bring the prim back to zero rotation. Any clues would be most welcome.

Thanks for the quick reply. I believe I will need to try the pseudo sale idea. Thanks again. Now, I'm off to figure out selling, restricting resell and so many wonderful new things. I hope there isn't any too horrible gotchas lurking in there. I'll start with a small parcel -- in the corner. LoL.

I have a private island that I'm trying to manage. That parts okay. Where the difficulty arrises is in prim managment. I've parceled the land into several areas so that different builders will have different numbers of prims to work with. However, it looks like the prims are being shared among all the parcels. This is undoubtedly because we have not changed owner. Only give build permissions to different groups. Is there a way to limit the prims to the parcel capacity without changing owners? Thanks for any clues.

Thanks for the reply. When I say 180 degrees off, I mean in terms of my understanding of how the parameters work. For all I know I made a number big when it should have been made small. Made the time long when it should have been short. The actual observed problem is the train comes off the rail. I can't keep the loco from climbing over the middle rail. It will bounce up, or climb the rail and then run around the sim off rail. At super low speeds it seems to work okay. But, if the speed is increased at all the train will come off the track. I was hoping to find a way to set the parameters so that the train would have zero bank, and not go up. That's why the attempt to suppress some of the angular motion, etc. But, I'm new to the parameters.

I'm trying to make a train script -- in this case one that is using physics. I'm using the parameters below. Please don't laugh. I've cobbled these together best I could based on the documentations. But, I think I have a few things 180 degrees backwards. The problem I see with the loco is that on curves it will climber over the middle rail. Also in the straights it will some times bounce up like a bucking bronco. Any clue which parameter I've mangled? Or, simpler put, what is the trick to keeping a loco on the track? Thanks for any clues. llSetVehicleVectorParam( VEHICLE_LINEAR_FRICTION_TIMESCALE, <100, 3, .1> ); llSetVehicleVectorParam( VEHICLE_ANGULAR_FRICTION_TIMESCALE, <.1, .1, 3> ); llSetVehicleVectorParam( VEHICLE_LINEAR_MOTOR_DIRECTION, <0, 0, 0> ); llSetVehicleFloatParam( VEHICLE_LINEAR_MOTOR_TIMESCALE, 1 ); llSetVehicleFloatParam( VEHICLE_LINEAR_MOTOR_DECAY_TIMESCALE, 60 ); llSetVehicleVectorParam( VEHICLE_ANGULAR_MOTOR_DIRECTION, <0, 0, 0> ); llSetVehicleFloatParam( VEHICLE_ANGULAR_MOTOR_TIMESCALE, 1 ); llSetVehicleFloatParam( VEHICLE_ANGULAR_MOTOR_DECAY_TIMESCALE, 0.8 ); llSetVehicleFloatParam( VEHICLE_HOVER_HEIGHT, 0 ); llSetVehicleFloatParam( VEHICLE_HOVER_EFFICIENCY, 0 ); llSetVehicleFloatParam( VEHICLE_HOVER_TIMESCALE, 1000 ); llSetVehicleFloatParam( VEHICLE_BUOYANCY, 0 ); llSetVehicleFloatParam( VEHICLE_LINEAR_DEFLECTION_EFFICIENCY, 1 ); llSetVehicleFloatParam( VEHICLE_LINEAR_DEFLECTION_TIMESCALE, 2 ); llSetVehicleFloatParam( VEHICLE_ANGULAR_DEFLECTION_EFFICIENCY, 0 ); llSetVehicleFloatParam( VEHICLE_ANGULAR_DEFLECTION_TIMESCALE, 0.1 ); llSetVehicleFloatParam(VEHICLE_VERTICAL_ATTRACTION_TIMESCALE, 0.5); llSetVehicleFloatParam(VEHICLE_VERTICAL_ATTRACTION_EFFICIENCY, 1); llSetVehicleFloatParam( VEHICLE_BANKING_EFFICIENCY, 0.0 ); llSetVehicleFloatParam( VEHICLE_BANKING_MIX, 1 ); llSetVehicleFloatParam( VEHICLE_BANKING_TIMESCALE, 1 ); llSetVehicleRotationParam( VEHICLE_REFERENCE_FRAME, <0, 0, 0, 1> ); llRemoveVehicleFlags( VEHICLE_FLAG_HOVER_WATER_ONLY | VEHICLE_FLAG_HOVER_TERRAIN_ONLY | VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT); llSetVehicleFlags( VEHICLE_FLAG_NO_DEFLECTION_UP | VEHICLE_FLAG_LIMIT_MOTOR_UP );

Happy to report that after reviewing all the answers and implementing them in my script that everything is working just fine. Thanks again for the help. That multiplication by the local rotation was the bit of magic I needed.

Thank you so much for the replies, I will study these to not only get one that works, but also see if I can understand how. This rotation stuff is probably the biggest challenge I have met in LSL so far.

I have a sliding door that works just fine -- until the root prim is changed. Basically I would like to slide the door along its local X axis independent of which prim is root. I've tried a few wild guesses with converting back and forth to different coordinate systems. So far isn't working. I'm wondering if there is a direction someone can point me in. Thanks,

Very helpful information. Much appreciated.

Thank you both for the answers. Follow up question though. I am wondering based on your answers if there are special considerations when using sound from a hud.

Can someone please give me a clue on when one should use llPlaySound versus llTriggerSound? I suppose the issue comes down to not really understanding the difference between an attached sound and unattached sound. Would this mean the sound follows the object -- if the object is moving. But will that matter if the object doesn't move?

I suppose for flying around in world and chatting with friends this might not be too too much of a hindrance. But, for anyone editing scripts this can be a major pain. Just seems callous to force this into the populace. Well, at least it is not being tauted as a feature

Sorry, I should have been much more specific. Second Life 3.6.2 (279321) Jul 31 2013 01:07:29 (Second Life Release) This is the latest upgrade. For me at least. My viewer was working fine yesterday too.

This bug (I hope to heck you don't call this a feature) is very reproducible. Highlight text in a script, or in the slurl box. Click the mouse anywhere in that same script or box. Highlighted text is gone, cleared, deleted, removed. This is very dangerous behavior for any of us folks that use copy and paste. I hope this is on the fast track to being fixed. Or, if this is a feature, please tell me where in the preferences I can opt in for the non-delete highlighted text when I click with the mouse option.

Thanks for the reply. Much appreciated.

I would like to make a small sandbox on my region. I have found instructions for making the parcel -- seems clear enough. But, I want to double-check a couple of issues. First, my understanding is that since I own both parcels and since the parcels are in the same region I do not have to worry about changes in prim limits. Meaning I can build anywhere on the region without worrying about whether the prims are in the small parcel or the larger area. Second, what about avatar access. Do I have to carve up the avatar limit between the two parcels. Meaning do I need to designate that X number of AVs can be in the sandbox -- and thus lower the number of avatars that can be in the rest of the region. Or, can I just let the total number of avatar roam anywhere within the region without setting limits on which parcel they are in. Thanks for helping a noob out.

Two very excellent responses. I appreciate the fast and able advice. Based on reading some of the posts in the forum when using chat between scripts I use llRegionSayTo if I know the UUID, otherwise I fall back on llRegionSay. Seems to me that llWhisper requires the server to dynamically assemble a list of "nearby" objects whereas the llRegionSayTo and llRegionSay both use previously assembled lists created by the llListen. Course, this all is predicated on the fact that I have never had call to listen on the PUBLIC_CHANNEL. Anyway, thanks again for the heads up about attached and helpful reminder about the SayTo.

I am trying to use llMessageLinked with LINK_SET to send a message to a script contained in a prim being worn by the sitting avatar. Is this possible? I know the avatar is "linked". But is this a special kind of linking? I haven't been able to make it work as yet, and I can't tell if this is do to errors in the script, or perhaps because it's not even possible. Just trying to make a hat color changer that you sit on to activate menu with color options. Thanks for any clues.

I made a kind of xylophone. 8 bells that can be touched by anyone nearby. This works great in a quiet area. However, if I try to use the xylophone in an area rich with birds, babbling brooks, and other scripted sounds, then the notes are intermittent and often don't play at all. I am assuming this is a result of a limit on the number of simulataneous sounds that can play at any given time. If this is the case, is there any way I can use script to detect this issue so that the script can tell the xylophone owner why their instrument is suddenly not working? I think a clear error/warning message is better than the instrument suddenly becoming flakey. Or, am I totally misled and the instrument should be working just fine no matter how audio saturated the area is. In which, case I will need to look for a different kind of bug. Thanks for any clues.

Our region is not super busy, and it is not totally quite. Running the tester I get about the same results. llRegionSay: 57.099980 llWhisper: 88.222660 llRegionSayTo: 96.620320 I was thinking about this. The relative difference between llWhisper and llRegionSay makes llRegionSay look great whenever one is using a channel for communication. Obviously llWhisper makes sense when speaking on public channel to nearby AVs. So in my mind, the use of llWhisper is off the table. When choosing between llRegionSay and llRegionSayTo, I guess it would depend on whether or not the channel was unique. Seems that if the channel was unique and only one script was "listening" in. Then llRegionSay might be the way to go. But, if I had 100 grape plants and one basket listening to the same channel. If a grape plant script wanted to send a message to the basket script llRegionSayTo might be best. That way I don't have 99 fellow grape plants being activated as a result of the message. Of course there is (at least) one other consideration... script self-documentation. If one uses llRegionSayTo in a script it is clear to any reader (even yourself after brain freeze) that the message is intended for a single target script.

Thanks so much for the heads up on all attachments getting the message. That will be so much easier than setting up special channels etc. Much appreciated.

Yes, I have a hud that I want to use for selecting options on an attached object. The hud and attached object are on the same Avatar. Thanks

Hello, I'm looking for the most efficient way for a hud menu to message a script contained in an object that being worn by the Avatar. At first I was hopeful that since the hud object is attached to the AV and the worn object is attached to the AV that somehow I could use a linked message system. That has failed so far. Is llRegionSay the proper (i.e. most efficent, least laggy) way to go? Or, is there another way to get these two objects on the same AV to receive message from each other? Thanks