Jump to content

Kaluura Boa

Resident
  • Posts

    179
  • Joined

  • Last visited

Everything posted by Kaluura Boa

  1. Your prayer was heard. llGetParcelMusicURL() is available on servers LeTigre 11.12.02.246118. It should become available gridwide in a few weeks. (Look at the very bottom of the Release Notes.)
  2. Hmmm... cd ~/.secondlife/cache ;rm -R ./* WARNING: These 2 lines are a loaded gun pointing at your foot. When you launch a terminal, it always opens in your $HOME. So, if the first line to go to the cache directory does not work as expected, the second line will just wipe clean your $HOME... and you will really really regret it. Instead of shooting your 10 toes one by one and adding a bullet in each ankle, I strongly suggest to go to Preferences >> Network in your client. The cache directory is shown on this tab. Point your file browser to this directory and then you can delete everything by hand. (Don't worry, your client wll recreate all the folder it needs on next start.)
  3. It is not pretty and there is more that you care to know but you can point your browser at secondlife.com/httprequest/homepage.php At the end of the line, you can see "inworld" and the number of avatars currently logged in.
  4. Sorry, but there is no such setting in any client nor TPV. I have an AZERTY keyboard too and WASD is totally useless --if I ever wanted to use it. I just use the arrow keys. That is what I have used instinctively the very first time I logged in and what I use since. Tough luck for you if you have a crippled laptop with a bad arrows layout... Eventually, you may try to switch the client to French if you speak it. I do but I have never bothered to even test. The size of the space dedicated to French in the "Second Universe" clearly indicates that English is a more viable solution.
  5. Fixed... Grumble, grumble and grumble... :matte-motes-wink:
  6. UPDATE: The more I work with physics cost, the more I learn... UPDATE 2: Of course, you must read "32 PE", not 64. The title says it all. Here is the script: default { on_rez(integer param) { llResetScript(); } state_entry() { llSetLinkPrimitiveParamsFast(LINK_ALL_CHILDREN, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_NONE, PRIM_LINK_TARGET, LINK_THIS, PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]); llSleep(0.5); float prc = llList2Float(llGetObjectDetails(llGetKey(), [OBJECT_PHYSICS_COST]), 0); string text = "/me -- Physics cost: " + (string)prc + " PE"; if (prc > 32.0) { text += " -- Cannot enable physics."; } llOwnerSay(text); // // Auto-clean. llSleep(1.0); llRemoveInventory(llGetScriptName()); } } After that, you can enable/disable physics simply through the Tools floater in any viewer --even if not mesh-aware, or with a regular vehicle script.(Use llSetStatus() which seems more reliable than PRIM_PHYSICS.) But, more importantly, you may want to add regular prims so that you object does not lean, take a tumble or sink in the ground while it is trying stand on its root prim only with all its child prims phantom but not weightless... <grin> Beware! Unlinking let the prims revert to regular prims. The physics shape type is not saved as permanent prim property. Either you link the prims that must keep your vehicle over the ground after using my script, or else you use it on the whole vehicle and reset the wheels/land gear/legs/what-not prims one by one with the following (auto-clean) script: default { on_rez(integer param) { llResetScript(); } state_entry() { llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_PRIM]); llSleep(1.0); llRemoveInventory(llGetScriptName()); } }To check the physics cost of your vehicle: default { on_rez(integer param) { llResetScript(); } state_entry() { list tempo = llGetObjectDetails(llGetKey(), [OBJECT_PRIM_EQUIVALENCE, OBJECT_PHYSICS_COST]); llOwnerSay(llList2String(tempo, 0) + " PE"); llOwnerSay("Physics Cost: " + llList2String(tempo, 1) + " PE"); llSleep(1.0); llRemoveInventory(llGetScriptName()); } }That should be all... until I learn something new. :matte-motes-wink:
  7. Here is something that works... default{ state_entry() { vector top = <0.0, 0.0, 2.0>; // Top of pyramid (Can be anywhere around the root prim...) vector size = llGetScale() / 2.0; list corner = [<-size.x, -size.y, 0.0>, <size.x, -size.y, 0.0>, <-size.x, size.y, 0.0>, <size.x, size.y, 0.0>]; // The 4 corners of the base list params; integer i = 0; for (; i < 4; ++i) { if (i) { params += [PRIM_LINK_TARGET, i + 2]; } // We use child prims 2 to 5 // vector offset = top - llList2Vector(corner, i); rotation rot = llEuler2Rot(<0.0, 0.0, llAtan2(offset.y, offset.x)>); // yaw... offset /= rot; rot = llEuler2Rot(<0.0, llAtan2(-offset.z, offset.x) + PI_BY_TWO, 0.0>) * rot; // ...and pitch + 90°... // ...to point Z-axis of cylinder edges towards top of pyramid offset = llList2Vector(corner, i); size = <0.05, 0.05, llVecDist(offset, top)>; // Size of edges offset = (offset + top) / 2.0; // Pos of edges, in the middle in between corner and top params += [PRIM_POS_LOCAL, offset, PRIM_ROT_LOCAL, rot, PRIM_SIZE, size]; } llSetLinkPrimitiveParamsFast(2, params); // Everything at once! }} Just do not ask why it works. I have been working on a personal version of llLookAt() and this is the very last version of my formula which I am using, somewhat hidden in this script. In simple words, I set each edge child prim in between a corner and the top and I let it look at this top... without forgetting to stretch the prim to connect the corner with the top. As simple as that! Since the script reads the size of the base of the pyramid, it will adapt whether the base is square or rectangular... or even to any number of corners --with some modifications. The top of the pyramid can really be anywhere but the script assumes that the base lies on the X/Y plane. EDIT: I wanted to send you a pyramid but it seems SL cannot find you. Just IM me, I shall send ASAP.
  8. EDIT: Script updated since I discovered that PRIM_PHYSICS may not be so reliable, that SL need a pause after the change of physics shape and that reading OBJECT_PRIM_EQUIVALENCE is not very useful. A change happened... Sort of. Meshes happened. And with them came the (convoluted) Prim Equivalence system in which physics is allowed for objects up to 64 PE (NOT prims). However, you do not need meshes nor any special viewer for this. The PE system is enabled as soon as your object has a physics shape other than "prim"... and you can change that with a script using llSetPrimitiveParams() and the rule PRIM_PHYSICS_SHAPE_TYPE. For example: llSetLinkPrimitiveParamsFast(LINK_ALL_CHILDREN, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_NONE, PRIM_LINK_TARGET, LINK_THIS, PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]);// This (loooooong) line removes all the child prims from the equation// and changes the physics shape of the root prim to use PEllSleep(0.5); To give time for SL to realize something changed. llSetStatus(STATUS_PHYSICS, TRUE); You can check the physics cost of your vehicle with llGetObjectDetails() and the flag OBJECT_PHYSICS_COST. It must not exceed 64 PE to be allowed to enable physics. Any way... Just simple as that! No meshes, no V3...
  9. I tried with fixed times of 10/45, 22/45, 45/45... The drift is greatly reduced. With a time of 10/45: [08:43] llSKfM: pos=<200.00000, 94.00000, 92.00000> rot=<0.00000, 0.00000, 0.00000>[08:43] llSKfM: pos=<209.99920, 103.99940, 92.00000> rot=<0.00000, 0.00000, 89.99792>[08:43] llSKfM: pos=<200.00020, 113.99890, 92.00000> rot=<0.00000, 0.00000, 179.99610>[08:44] llSKfM: pos=<189.99970, 104.00050, 92.00000> rot=<0.00000, 0.00000, -90.00515> Final position: [08:44] Kaluura: <199.998169, 94.000458, 92.> <0., 0., 0.> The drift stays below 0.01 for both the position and the rotation. Interesting information to write on the wiki page...
  10. I felt slightly insulted by this "and compute badly"... My calculations are accurate! I replaced llSetKeyframedMotion() with something more direct in the uuMakeCurve() function: llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_POSITION, llGetPos() + move, PRIM_ROTATION, rot * llGetRot()]);llSleep(time); And I also made the object say its position when you click it. Here are the results of 2 full circles on llSLPPF: [02:24] llSLPPF: pos=<200.00000, 94.00000, 92.00000> rot=<0.00000, 0.00000, 0.00000>[02:24] llSLPPF: pos=<210.00000, 104.00000, 92.00000> rot=<0.00000, 0.00000, 90.00011>[02:24] llSLPPF: pos=<200.00000, 114.00000, 92.00000> rot=<0.00000, 0.00000, -180.00000>[02:24] llSLPPF: pos=<190.00000, 104.00000, 92.00000> rot=<0.00000, 0.00000, -90.00008>[02:25] llSLPPF: pos=<200.00000, 93.99999, 92.00000> rot=<0.00000, 0.00000, -0.00001>[02:25] llSLPPF: pos=<210.00000, 104.00000, 92.00000> rot=<0.00000, 0.00000, 90.00005>[02:25] llSLPPF: pos=<200.00000, 114.00000, 92.00000> rot=<0.00000, 0.00000, 180.00000>[02:25] llSLPPF: pos=<190.00000, 104.00000, 92.00000> rot=<0.00000, 0.00000, -90.00003> Final postion: [02:26] Kaluura: <200., 93.999992, 92.> <0., 0., 0.> Almost perfect! I made only 1 turn with llSKfM: [02:35] llSKfM: pos=<200.00000, 94.00000, 92.00000> rot=<0.00000, 0.00000, 0.00000>[02:35] llSKfM: pos=<209.77640, 103.77720, 92.00000> rot=<0.00000, 0.00000, 87.99987>[02:35] llSKfM: pos=<200.34710, 113.88950, 92.00000> rot=<0.00000, 0.00000, 175.99560>[02:35] llSKfM: pos=<189.91070, 104.81920, 92.00000> rot=<0.00000, 0.00000, -96.00464> Final position: [02:36] Kaluura: <198.611908, 94.073349, 92.> <0., 0., 352.> I think I'll keep on using the old lag-inducing methods until further notice. I can do much better than Havok... by hand!
  11. First, no, you do not need a mesh-aware viewer to script llSetKeyframedMotion(). Just insert the following line in the state_entry(): llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]); Any way...Despite the late hour, I managed to scribble something that works... list FrameList;uuMakeCurve(rotation rot, integer dir, float angle, float radius, float steps, float time){ // dir: 1 = left, -1 = right // angle: in degrees // time = total time // vector offset = <-radius, 0.0, 0.0> * (llEuler2Rot(<0.0, 0.0, dir * PI_BY_TWO>) * rot); // Offset from relative center of the arc of circle time /= steps; // Time for each step angle = (angle * DEG_TO_RAD * dir) / steps; // Arc of circle for each step rot = llEuler2Rot(<0.0, 0.0, angle>); // Relative rotation for each step FrameList = []; integer i = 1; // Don't re-do step 0! for (; i <= (integer)steps; ++i) { vector move = (offset * llEuler2Rot(<0.0, 0.0, angle * (float)i>)) - (offset * llEuler2Rot(<0.0, 0.0, angle * (float)(i - 1)>)); // Relative movement from previous pos to current one. FrameList += [move, rot, time]; }}default{ state_entry() { llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]); } touch_end(integer num) { uuMakeCurve(llGetRot(), 1, 90.0, 10.0, 24.0, 12.0); llSetKeyframedMotion(FrameList, [KFM_MODE, KFM_FORWARD]); }} BEWARE! My left is 1 and my right is -1. And I realized that the function does not need the pos. Everything is relative in llSetKeyframedMotion()... including the rotation. It works, I said, but the drift is awful. Doing 4 quarters of circles does not bring you back to your starting position. I will see if cosinuses and sinuses are more precise than vectors * rotations... tomorrow... Later this morning already! btw, did anybody notice that all these relative positions and rotations are driving you insane? :matte-motes-confused: I want absolute positions!
  12. I do not know if it is officially supported or else if LL will eventually pull the plug of the feature but you can display any texture of which you know the UUID on a web page by using the following URL: texture-service.agni.lindenlab.com/<INSERT-UUID-HERE>/0x0// No "raw URL" allowed in the posts, please add the "http" header The final "0x0" is the size. It means "original size" but it can be anything larger or smaller, square or rectangular. This is also the name of the picture in case you would try to save it. For example: texture-service.agni.lindenlab.com/398acae7-eb03-04b6-0a9f-0f65480bc9a1/0x0 We should soon see if LL notice the big hole at the bottom of their server... :matte-motes-big-grin-wink:
  13. Nope, llTeleportAgent() does nothing, not even on an LR region, not on touch, not on collision... Nothing. I'm really disappointed... I checked the owner of the portal in Nysray and, no, the object does not need to be deeded to land group. A piece of the puzzle is missing. A new permission? A new event? Any way, I wonder why such a useless function compiles gridwide for both Mono and LSO while it is not even supposed to be available at all.
  14. For those who missed the news: SL Game Regions If you have a Premium account and a mesh-aware client at your disposal, here is a TP link to Nysray. In short, we will soon get a lot of new functions to create in-world games where avatars turn into game characters. Amongst the obvious new functions, there should be (something close to) llTeleportAgent() and llForceAttach(). (For the rest, I did not see anything that could not be done with already existing functions... but I am not in the secret of the grid gods, so...) The Stargate people will be happy because that is what stands in Nysray: You cross the threshold of a portal and you are teleported into a game region. No dialog, no map, no nothing! From my chat history: [2011/11/04 15:08] Second Life: You have been teleported by the object 'Shimmering Rift' on the parcel 'Premium Zone'. [2011/11/04 15:08] Second Life: Teleport completed from http://maps.secondlife.com/secondlife/Nysray/12/7/56 [2011/11/04 15:08] Welcome to LR!: Welcome to LR! Please wait while we load your game interface [2011/11/04 15:08] Second Life: You have been teleported by the object 'Welcome to LR!' on the parcel 'Summoning Circle'. [2011/11/04 15:08] <>: <> LR 8, not on a mainland continent. Grid: (1142, 1208) (The last line is from my gadget which tells me where I land.) You can already see that you get a full message "Teleport completed" when you are TP'd from region to region but not within the same region. And the "game interface" is a HUD which jumps on your screen... also no dialog, no permission, just silence! A glitch happened and the HUD that is supposed to disappear when you TP away stayed on screen. I detached it manually after arriving at home and... [2011/11/04 18:52] <>: <> Dunnideer on Sansara continent. Grid: (1031, 992) [2011/11/04 18:53] Second Life: You have been teleported by the object 'LR HUD 5.17' on the parcel '(redacted)'. Meaning: This llTeleportAgent() function is already gridwide. :matte-motes-evil-invert: I think I am going to have some fun (and frustration) trying to find the syntax...
  15. Alas... Triple alas... What you and all scripters miss is llGetInventoryDesc()/llSetInventoryDesc() and llSetInventoryName()... In other words, there is no way to access the description of an item in inventory and changing their name by script is not an option either. There certainly must be more than one Jira about inventory description but I did not even bother searching. These Jira are on the shelf next to the as much desirable functions to write notecards. :matte-motes-frown:
  16. "In all cases, reading a new notecard line or block of text should be initiated as the very last action in the current event so that the script makes its stuff when it should just go idle otherwise." I re-read what I wrote and I agree with myself. :matte-motes-wink-tongue: If you read the next notecard line right after having checked that you did not reach EOF, it means that the delay stops your script before to process the current notecard line. In other words, the delay hits you with its full strength. On the other hand, in theory, if reading the next notecard line is the very last instruction to execute for the current event, the delay should be lost because the Virtual Machine jumps to other scripts and when it comes back to your script, it is more than likely that the delay has expired. This is of course only a theory since I am no expert in SL's VM but a sound one... until some expert comes and tells me that LSL's VM was written by a psycho-rigid developper :matte-motes-big-grin-wink: who enforced delays in a way which invalidates my theory. Whichever is true, I will keep on writing my scripts with the assumption hope that delays can get lost in the void in between the scripts. Besides, I dislike the idea of inserting a delay in the middle of an event when I can put it at the end where delay will anyway happens because the VM has to do its end-of-event stuff, to jump to another script and what-not. In the worst case of the psycho-rigid developper, it just lengthens a bit an unavoidable delay.
  17. You did not say if you need to access the multiple notecards the one after the other or all concurrently, or else if you may need to read several lines of one notecard at once. If you never need more than one line at once, I would read and store the first line of the notecard(s) on rez --long before it is needed any way-- and then read a new line from the corresponding notecard just after the display. The delay will go unnoticed while the user is busy reading. If you may need several lines at once from time to time, depending on the contents of the notecard(s), a sub-script might be more appropriate. It will read a block of text from the notecard(s) and then read a new one from the same notecard after having received the link message to provide a block of text in order to always have something to provide on request. The sub-script can also take care of the display if that is all which is needed to be done with the notecard contents. If some process is required, I would look which way is the most efficient, i.e. which way needs the shortest link message: To transmit data from the main script to the sub-script to process and display or --the other way around-- to transmit the block of text from the sub to the main script. The second solution is the best if the main script needs some of its own data to process the block of text and some new data result from these calculations... or else the flow of the main script may become a real labyrinth. In all cases, reading a new notecard line or block of text should be initiated as the very last action in the current event so that the script makes its stuff when it should just go idle otherwise. I hope what I said is helpful. You did not say much about your script so I could not be more precise.
  18. You said yourself that you calculate an integer from the value of llDetectedTouchST()... Why do you convert it into a string? If you transmit an integer to your function TouchMeLongTime(), things are much easier. TouchMeLongTime(integer k){ if ((k >= 1) && (k <= 8)) { Menu("MAIN"); } // else...} I would also point out that it is sub-optimal to use a static string as parameter of a function, especially when all you do is to test this string against other strings, as I guess you do. As a rule, I always try to avoid working with --from worst to best-- lists, strings, rotations, vectors, floats to work only with integers as much as possible. In this case of a menu, I would just define some (pseudo) constants at the beginning of the script and forget about their real values. For example: // Values are irrelevant, they must just be unique.integer MAIN = 1;integer OPTIONS = 2;integer THIS = 3;integer THAT = 4;// etc, etc So you can re-write your Menu() function to use integers. Menu(integer type){ if (type == MAIN) { // Main menu } else if (type == OPTIONS) { // Option menu } // etc, etc} Much faster --to type too--, less memory hungry... And with integers, or numeric values in general, it is easy to check if a value is within a range, like for example: if ((type != MAIN) && (type < THAT)){ // Special case} Just think of strings as a plague and avoid them! ;-)
  19. I encountered the same problem last week: llSetKeyframedMotion() would not compile on the 2 sandbox regions mentioned by Andrew. But now, I just came back from Bispinor and it works. As for finding the 2 regions, just make a search on "sandbox" in the map. Aditi is not that large...
  20. EDIT: Void beat me while I was doing my tests in-world. Nevermind... It's almost the same thing but in a function. I retrieved this old thing in my inventory: integer uuRot2Face(rotation rot){ vector vee = llRot2Up(rot); integer k = llRound(vee.z); if (k == 1){ return 0; } else if (k == -1){ return 5; } vee = llRot2Fwd(rot); k = llRound(vee.z); if (k == 1){ return 3; } else if (k == -1){ return 2; } vee = llRot2Left(rot); k = llRound(vee.z); if (k == 1){ return 1; } else if (k == -1){ return 4; } return -1; // So that the compiler doesn't complain.} It works quite well even if the dice isn't exactly straight.
  21. I am no expert in the SL cache system but I know for sure that cached files use the in-world UUID as name... So, in theory, the answer is no, no and no. Once the first preload has started, the UUID is used so the client will not start another download for the same UUID. This prevents concurrent downloads for the same asset. Next, whether the asset is fully downloaded or not, it will be considered as cached. So, if the cache is not too buggy, no new download will occur until the asset is flushed because the cache needs to make room to stay below the configured limit. However, I think that using llPreloadSound() in a timer will force the clients in range to check their cache repeatedly and some people might consider this idea negatively... especially if they never come close enough to actually hear the sound. Think also of your neighbors and the client-side lag it can induce.
  22. Yes and no... No: Scripts cannot attach anything from your inventory to your avatar. Yes: A script can however attach the object in which it resides, if it is rezzed in-world and if you give the permission. (Blue dialog totally unavoidable.) Another yes: Most TPVs provide the RLV features set which allows you to attach/detach or wear/unwear anything. (No dialog, AFAIK.) Chose the answer you prefer...
  23. You must never trust the permissions shown in your inventory. They are a mix of the perms of the object and of its contents and since your inventory shows only the perms you do not have, the objects usually appear with less perms than what they actually have. In other words: Check the contents of your knives (scripts? textures?). Their missing perms is what your inventory and the one of your buyers will show, plus the missing perms of the object itself. You need to learn the paranoid perms rituals of the veteran content makers: Set, check. Re-rez, double-check. Transfer (to your most trusted alt), triple-check.
  24. Your sensor event is totally wrong. You just need an empty one because you are only interested in the no_sensor() event... and there is that bug which prevents no_sensor() from firing if there is not at least an empty sensor() event. Any way, that is not the problem. The problem is that you write the script directly in the object and, in that case, on_rez() does not fire until re-rezzed. So, no sensor at all. Which is a good thing... Instead of a sensor, I would rather use llGetObjectDetails() to check the position of the rezzed item. key ItemKey;default{ on_rez(integer param) { llResetScript(); } state_entry() { llSetTimerEvent(0.0); // Not needed until we have an item to watch } touch_end(integer num) { if (llDetectedKey(0) == llGetOwner()) // Owner touch to rez the first one { llRezObject(llGetInventoryName(INVENTORY_OBJECT, 0), llGetPos() + <0.0, 0.0, 0.5>, ZERO_VECTOR, ZERO_ROTATION, 42); // Never ask why 42. } } object_rez(key id) { ItemKey = id; // We just rezzed something... llSetTimerEvent(5.0); // Start watching. } timer() { if (llList2Vector(llGetObjectDetails(ItemKey, [OBJECT_POS]), 0) == ZERO_VECTOR) { // Gone? Rez a new one! llRezObject(llGetInventoryName(INVENTORY_OBJECT, 0), llGetPos() + <0.0, 0.0, 0.5>, ZERO_VECTOR, ZERO_ROTATION, 42); // Never ask why 42. } }} Attention: In all cases, take the rezzer in inventory first or reset the script before to delete/take the item. There is no way to differentiate in between a sold item and a deleted/taken item.
  25. Hmmm... I wasn't very clear in my post. You need to use a TPV only once to import *one* multi-face sculptie. After that, you can re-use the imported object as many times as desired... as long as you do not modify its prim type. On the other hand, all viewers can see the multi-face sculpties. Since there is pretty much only one useful multi-face sculptie, if your religious beliefs do not forbid you from using a TPV, anybody can import their own and live happy together... until "real" meshes take over.
×
×
  • Create New...