Innula Zenovka

Advisor
  • Content count

    9,077
  • Joined

  • Last visited

Community Reputation

2,290 Excellent

1 Follower

About Innula Zenovka

  • Rank
    Advanced Member
  1. Could just be an effect caused by the local lighting. I rezzed a prim, set it to TEXTURE_BLANK, ALL SIDES by script, and then drag copied it. The only difference between the two boxes is that I set the one on the right to Full Bright (i.e. ignore lighting effects) in the editor: Note the difference between the top of the left-hand prim and the other sides -- the top is receiving direct light from the SL sun, and the other sides are in the shade.
  2. Teleporting Without Intervention

    @Turokhan Legion If you don't want to use experience tools, you could give your users something to wear that receives a message from the door telling the objects where to teleport them to. Attached objects, as I recall, are granted PERMISSION_TELEPORT silently when they ask for it.
  3. RLV Attach mesh item from inventory

    If you're using RLV to attach items, forget about llAttachToAvatar. That's for attaching objects that are already rezzed in world. You need to be using RLV's Shared Folders protocol. Basically this means setting up a main folder. #RLV, in your inventory and then setting up various sub-folders inside that to hold particular outfits and parts of outfits. Nalates Urriah has an intro here about how to do it http://blog.nalates.net/2016/06/27/second-life-tutorial-rlv-mesh-and-folders-how-it-works-how-to-use/5/ and Marine Kelley, who makes the RLV viewer, has a lengthy two part tutorial on shared folders here: http://realrestraint.blogspot.com/2008/08/objects-sharing-tutorial.html Once you've read those, and set up your #RLV folder and some subfolders, then you use the various RLV-specific commands to attach and detach the contents of the shared folders, as listed here: http://wiki.secondlife.com/wiki/RestrainedLifeAPI#Clothing_and_Attachments_.28Shared_Folders.29
  4. RLV and restrictions

    Well, the reason typing it in local chat works and having the object say it doesn't is probably that the collar is set to recognise commands from an owner, and to do that it checks the UUID of whoever/whatever is trying to issue the command. Your UUID != the object's UUID.
  5. RLV and restrictions

    I don't quite understand what's going on here. When you say Do you mean that it works when the script is in an object belonging to you, it works, but when you pass the object to your partner, it doesn't work for her? Which one of you uses the prefix "tiff" for collar commands? It could just be that your collar listens to commands starting "tiff" and hers doesn't. Like CoffeeDujour, I'd do the whole thing with RLV. Don't mix it up with collar commands -- that's asking for trouble unless you're sure you understand the collar script.
  6. Prim Auto Align Script wanted.

    @Marlon Wulluf Oh, I see. You simply need to modify the scripts slightly, and to spend a bit more time setting it up, but the principle is exactly the same -- I was trying to demonstrate how to do the calculations, not write the whole script. Anyway, you use the first pair of scripts to record all the offsets and rotations the slave module is to use, depending on which face of the master module is touched. Then store them in a strided list in a modified version of the third script. This example is for a 1 x 1 x 1 cube, so there's a strided list of six different offsets and rotations to take, depending on which face is touched. //PLACE THIS IN THE CHILD OBJECT TO MAKE IT MOVE INTO THE DESIRED POSITION AND ROTATION IN RELATION TO THE MAIN OBJECT integer iChannel = -67341870; integer iIndex; integer iStrideLength = 2; list lOffsetsAndRots =[ //list of possible offsets and rots, depending on which face is touched. <0.0, 0.0, 1.0>,<0.0, -1.0, 0.0, 0.0>, //if face 0 is touched <0.0, -1.0, 0.0>,<0.0, 0.0, -1.0, 0.0>,//if face 1 is touched <1.0, 0.0, 0.0>, <0.0, 0.0, -1.0, 0.0>,//if face 2 is touched <0.0, 1.0, 0.0>,<0.0, 0.0, -1.0, 0.0>,//if face 3 is touched <-1.0, 0.0, 0.0>,<0.0, 0.0, -1.0, 0.0>,//if face 4 is touched <0.0, 0.0, -1.0>,<-1.0, 0.0, -0.0, 0.0>//if face 5 if touched ]; rotation rRot; vector vOffset; integer fncStrideCount(list lstSource, integer intStride) { return llGetListLength(lstSource) / intStride; } list fncGetStride(list lstSource, integer intIndex, integer intStride) { integer intNumStrides = fncStrideCount(lstSource, intStride); if (intNumStrides != 0 && intIndex < intNumStrides) { integer intOffset = intIndex * intStride; return llList2List(lstSource, intOffset, intOffset + (intStride - 1)); } return []; } default { state_entry() { llListen(iChannel, "","",""); } listen(integer channel, string name, key id, string message) { iIndex = (integer)message;//take the index from the face number provided // llOwnerSay("index is "+(string)iIndex); list temp = fncGetStride(lOffsetsAndRots, iIndex, iStrideLength); vOffset = llList2Vector(temp,0); // llOwnerSay("vOffset is "+(string)vOffset); rRot = llList2Rot(temp, 1); // llOwnerSay("rRot is "+(string)rRot); temp = llGetObjectDetails(id,[OBJECT_POS,OBJECT_ROT]); vector vObjectPos = llList2Vector(temp, 0);//read target object's position rotation rObjectRot = llList2Rot(temp,1);//and rotation vector vTargetPos = vObjectPos + vOffset * rObjectRot;//calculate the target position, using the target object's frame of rotational reference, not the region's (i.e. relative to the target object) rotation rTargetRot = rRot * rObjectRot;//calculate the child object's desired rotation, using the target object's frame of rotational reference llSetRegionPos(vTargetPos);//move to the target position llSetRot(rTargetRot);//and rotate to face in appropriate direction } } Then put this in the Master module. As you'll see it's a slightly modified version of the original script. It records the face you touch, lights it up, and then sends the face number to the slave script. The slave then looks up in lOffsetsAndRots the appropriate offset and rotation for the face number it's been sent, reads the position and rotation of the Master object that sent the message, uses those to calculate the region position and rotation it needs, and then moves into place. //PLACE THIS IN THE MAIN OBJECT, SO THE CHILD OBJECT CAN FIND IT integer iChannel = -67341870; integer iTouchedFace; default { state_entry() { llListen(iChannel, "","",""); } touch_start(integer num_detected){ iTouchedFace = llDetectedTouchFace(0); llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_GLOW,iTouchedFace,0.1]); llSetTimerEvent(1.0); } timer(){ llSetTimerEvent(0.0); llRegionSay(iChannel, (string)iTouchedFace); llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_GLOW,iTouchedFace,0.0]); } } See the video here https://www.dropbox.com/s/gdoe82mi53db0u8/20180707_152340.mp4?dl=0
  7. Prim Auto Align Script wanted.

    @Marlon Wulluf I see what's happened. I'm sorry, it's my fault for not explaining more clearly. Sorry. When you read the positions using the first pair of scripts, you have to read them with the two objects positioned as you want to be. That records the desired position and rotation for the child object. Obviously if you record the positions with them placed randomly, it's not going to work. I thought you would realise that from the way I described it, but I should have spelled it out. If you try it again, this time recording the position you actually want the Slave prim to be in relation to the Master, rather than some random position, you should get satisfactory results. ETA: Video of me doing it: https://www.dropbox.com/s/hs1poqthiu1oslr/20180707_052801.mp4?dl=0
  8. Prim Auto Align Script wanted.

    :@Marlon Wulluf Have you tried my scripts? The whole point of the calculations in the very first one, //PLACE IN MAIN OBJECT TO READ CHILD OBJECT'S OFFSET AND ROTATION IN RELATION TO MAIN OBJECT is to calculate what the desired position and rotation are for the slave unit when it's in position, discounting the rotation of the master unit (i.e. its offset and rotation when the master unit is rotated at <0,0.0>. The calculations in the third script, //PLACE THIS IN THE CHILD OBJECT TO MAKE IT MOVE INTO THE DESIRED POSITION AND ROTATION IN RELATION TO THE MAIN OBJECT are to find the position and rotation of the master unit, wherever it happens to be on the region, calculate the offset translated by the master unit's rotation, move there, and then rotate into the desired rotation, again translated by the master unit's rotation. When I tested them before posting this, they appeared to me to be working as intended. If they're not, then please tell me what they're doing wrong. With mine you have to touch the child object to make it ask the master object to announce itself, but that's easy to change if you want to -- I was just trying to explain how to do the necessary calculations. See my animated gifs: https://gyazo.com/5423616c77a75299d446706d557c85b6 https://gyazo.com/488ddb18ada61dae2d2770915430008e
  9. Prim Auto Align Script wanted.

    @Marlon Wulluf I'm sorry for not making myself clearer. All the finished product needs is my final two scripts. The first two are simply there to enable you to calculate rotation rRot and vector vOffset to put in the "slave script". Then all you need in the "master" script is something to make the main unit announce its presence to the slave unit. It doesn't need to send anything to the slave unit -- the slave script reads the master unit's uuid in the listen event, uses that to discover the main unit's position and rotation on the region, and then does the necessary calculations. All the finished product needs are my last two scripts -- throw away the first two once you've used them to calculate the offset and rotation to put in the final slave script.
  10. Rotation in Script Issue When Rotated

    Try setting it to FALSE.
  11. Sailing scripts

    I don't really understand what you're describing. You've got a sail object with two faces. I'm assuming that these are on opposite sides of the mesh, so on the sail's positive and negative x axis (or maybe its y axis). I don't really understand how the two opposite sides of the sail end up "showing a sort of 'X' formation when viewed from directly above" (which I think puts the two faces at 90 degrees to each other, not 180). The script tells the whole sail to rotate -- LSL can't move the two faces of a single object separately -- so I don't see how they can come adrift like that. It's a viewer problem, it seems to me, with your gpu and cpu not drawing the sail as it should be. Maybe a picture of the sail object would help. Or if you want to pass me a copy in world I'll take a look at it, since I suspect I'm not understanding something crucial you're trying to tell me.
  12. Sailing scripts

    The two lines you need to look at are lines 42 initRot=llEuler2Rot(<0,0,PI_BY_TWO>); //INITIAL SAIL ROTATION (ON Z AXIS) DEFINED BY USER and 71 eulerRot=<0,0,num*DEG_TO_RAD>; those both specify the script is to rotate the sail about the sail's own vertical axis, which is, in SL's frame of reference, the positive z axis. If you rez a box on the ground and select it with the edit tools, you'll see it's the vertical blue line running through the box's centre. When people make meshes using Blender or Maya, or whatever, and upload them, however, the axes sometimes get switched round for reasons I don't fully understand, and don't correspond with what SL expects, with the result that when you try to move or rotate the objects by script, they don't end up where you expect them to because the server thinks it's dealing with a conventionally-rotated object rather than one with the axes pointing in the wrong directions (wrong, as far as SL is concerned, anyway). This should be a simple fix (famous last words), at least if the axis about which you want to rotate the sail runs up and down the centre of the object (the main sail in the example boat that comes with the scripts is a path-cut prim, so the prim's centre abuts the mast, on the same principle as a pathcut door. Simply rez your mesh sail, select it with the editor, and choose the LOCAL frame of reference from the drop-own next to "snap" on the top right (at least in the Official Viewer). Observe the colour of the mesh's vertical axis. As far as SL is concerned, the red arrow is the sail's X axis, the green arrow is the sail's Y axis and the blue arrow is the sail's Z axis. If all is as I hope, and the sail has an arrow running up/down along its centre (i.e. the mesh maker has offset the sail's centre if necessary) then you simply need to swap the positions of PI_BY_TWO (line 42) and num*DEG_TO_RAD (line 71) to match the sail's frame of reference. So if the red arrow runs up and down the side of the sail, then you need initRot=llEuler2Rot(<PI_BY_TWO ,0,0>); and eulerRot=<num*DEG_TO_RAD,0,0>; If it's the green arrow, then it's initRot=llEuler2Rot(<0,PI_BY_TWO ,0>); and eulerRot=<0,num*DEG_TO_RAD,0>; If the arrows don't run up and down where you want the sail to pivot, all is not lost, but I'd need to see the sail object before saying any more. And in that case it might be simpler to ask the mesh maker to re-upload the sail (or buy one from someone else who understands axes). But try my suggestion first.
  13. Prim Auto Align Script wanted.

    @Marlon WullufAssuming I was correct, and that you're able to position the objects as you want them, and then store the relevant details by hard-coding them, here's how to do the calculations (no trig involved). I'm going to refer to the main unit, the space station, as the "Main Object" and to the child unit, the module that docks with it, as the "Child Object". This is how faux rezzers work, btw. Obviously the scripts are very different, but the principle and calculations are the same. First, to read the positions, put this script in the Main Object //PLACE IN MAIN OBJECT TO READ CHILD OBJECT'S OFFSET AND ROTATION IN RELATION TO MAIN OBJECT integer iChannel = -67341870; default { state_entry() { llListen(iChannel, "","",""); } listen(integer channel, string name, key id, string message) { list temp = llGetObjectDetails(id, [OBJECT_POS,OBJECT_ROT]);//Read region position and rotation of child object vector vMyPos = llGetPos();//Main object's position rotation rMyRot = llGetRot();//Main object's rotation vector vChildPos = llList2Vector(temp, 0);//Child object's position rotation rChildRot = llList2Rot(temp, 1);//Child object's rotation vector vOffset = (vChildPos - vMyPos)/rMyRot; //calculate how far the child object is from the main object, discounting the main object's rotation //that is, the offset when the main object is rotated at <0.0,0.0,0.0> rChildRot = rChildRot / rMyRot;//calculate the child object's rotation when the main object is rotated at <0.0,0.0,0.0> llOwnerSay("child object's offset is "+(string)vOffset); llOwnerSay("child object's rotation is "+(string)rChildRot); } } then place this script in the child object, and then touch the child object, to make it announce itself to the main object. //PLACE IN CHILD OBJECT TO MAKE IT ANNOUNCE ITSELF TO THE MAIN OBJECT integer iChannel = -67341870; default{ touch_start(integer num_detected) { llRegionSay(iChannel,"boo"); } } Touch the child object, and the main object should chat out the desired offset and rotation. Make a note of these, and remove the scripts from both objects. Then enter the offset and rotation you've just noted into this script, which you should then place in the child object, the module that is to dock with the space station: My example is for two 1 metre cubes, with the faces on their positive X axes (face 2) touching. PLACE THIS IN THE CHILD OBJECT TO MAKE IT MOVE INTO THE DESIRED POSITION AND ROTATION IN RELATION TO THE MAIN OBJECT integer iChannel = -67341870; rotation rRot = <0.0, 0.0, -1.0, 0.0>;//fill in desired rotation here vector vOffset = <1.0,0.0,0.0>;//fill in desired offset here default { state_entry() { llListen(iChannel, "","",""); } touch_start(integer num_detected) { llRegionSay(iChannel,"boo"); } listen(integer channel, string name, key id, string message) { list temp = llGetObjectDetails(id,[OBJECT_POS,OBJECT_ROT]); vector vObjectPos = llList2Vector(temp, 0);//read target object's position rotation rObjectRot = llList2Rot(temp,1);//and rotation vector vTargetPos = vObjectPos + vOffset * rObjectRot;//calculate the target position, using the target object's frame of rotational reference, not the region's (i.e. relative to the target object) rotation rTargetRot = rRot * rObjectRot;//calculate the child object's desired rotation, using the target object's frame of rotational reference llSetRegionPos(vTargetPos);//move to the target position llSetRot(rTargetRot);//and rotate to face in appropriate direction } } and put this in the main object //PLACE THIS IN THE MAIN OBJECT, SO THE CHILD OBJECT CAN FIND IT integer iChannel = -67341870; default { state_entry() { llListen(iChannel, "","",""); } listen(integer channel, string name, key id, string message) { llRegionSayTo(id, channel, "boo"); } } Then, when you've done all that, touch the child object, the module, and it should move into the desired position relative to the main object and rotate itself to the desired rotation.
  14. Prim Auto Align Script wanted.

    Trig isn't my forte either, but fortunately it's not needed. It's too late for me to do anything tonight, but I'll try to find time tomorrow to make a simple example. First, though, please can you confirm that you're in a position -- or would be if you had the tools -- to position the units as you want them to be, and then store the relevant data for future use, when you (or someone else) needs to be able to touch the objects and make them jump into the position and rotation that you've stored?
  15. Prim Auto Align Script wanted.

    If I properly understand what you want to do, you already know the position and rotation, relative to the main unit, you want the module to occupy. That's pretty simple -- just read the position and rotation of the main unit and apply those to the pre-set offset and rotation to calculate the region position and rotation to which the second module needs to move. Or am I missing something?