Jump to content

Helium Loon

  • Posts

  • Joined

  • Last visited

Everything posted by Helium Loon

  1. Japanese kanji were imported from china during the Heian period (IIRC). So yes, they look virtually identical. That kanji is 夢, which can be pronounced as either "mu" (む) or as "yume" (ゆめ, pronounced "yuu-meh") in japanese. It means "a dream, a vision, or an illusion."
  2. @Void: Absolutely correct. Time is the zeroth dimension; Any object needing to exist in one or more dimensions must have time to exist in. I'm so happy a few others have figured this out too.... :matte-motes-sunglasses-1: ...though I'd argue the unidirectional requirement for time. Personally I describe time as separate, but not quite so limited, as a 'dimension'. Time is actually an n-dimensional volume where discrete potential outcomes split from each previous result. Hence, all possible eventualities do exist, simultaneously. Time paradox is eliminated, and the only question then becomes how does one travel ACROSS time, as well as up/down it....... @OP: We actually have quite a few dimensions we are building in in SL.....a 'dimension' is simply an independant quantifiable quality an object can possess. Height, width, depth....but also color, glow, twist, cut, and more are also dimensions within the qualities that define a 'prim'.
  3. If you have a close approximation to the total sound length of the elements, llSetSoundQueueing() may be the simplest way to get it to work, like you said. Although it only allows two sounds queued currently (there is a JIRA in place to increase the queue depth), if one does like this (this assumes the sounds are at least several seconds long each....) llPreloadSound("Sound1"); llPreloadSound("Sound2"); llSetSoundQueueing(TRUE); llPlaySound("Sound1",1.0); llPlaySound("Sound2",1.0); llSetTimerEvent(sound1duration+sound2duration-0.5); Then in the timer() event, have it play the next sound in sequence and set the timer to the next duration. That way, the queue should always have room for the next sound, and each should start immediately after the prior one. If this is what you are already doing, and you are still getting issues, you'll probably just have to use your own sounds that you create to specific durations you know precisely. And you may still get issues as timers are affected by sim time dilation.....
  4. Nope, no additional rotations. However, I had forgotten about being able to restrict the rotations....that may be an interim fix, though I'd still like to find an answer to WHY it is happening.....
  5. I tried unlinking all the prims (only 6), and everything is set to the default (ZERO_ROTATION). There aren't any rotations set beyond the ZERO_ROTATION that is passed in during the llRezObject(). After the physics/buoyancy are set, it rotates OFF from zero. I can't find any explanations. All the prims (including the root prim) in the linkset are all set to zero rotation. I don't think the sit target is affecting it. I've tried modifying the sit target location, and it doesn't seem to have any effect on the rotation it ends up at.
  6. I've run into a problem, and it's only half-scripting related..... I've got a multi-prim object that is being rezzed by another. After it is rezzed, I set it physical, and set buoyancy up. Everything works fine....except it rotates to an odd angle. I've tried everything to get it to rotate to a normal angle, but it seems determined to go to that angle as it's 'default' rotation.....and I've tried adjusting it from a manual rez and putting a new copy into the rezzing object, but no go. Any ideas on what could be causing it, or how to fix it?
  7. PeterCanessa Oh wrote: Not so Helium. All child prims in a link-set have the same, root, parent. You cannot have a 'heirarchy of prims' - just root and children. As Winter said, if you want to move/change only 'some' child prims you have to address them individually. It may be possible to do that quickly enough using llSetLinkPrimitiveParamsFast() but for any realistic number of child prims there will be a visible delay between the first and last moving. If there are fewer prims in the 'base' than the 'wheel' it may be more effective to move the whole thing and then move each base-prim back to their original position, rather than moving each wheel-prim. The same visual delay is likely though, unfortunately. You are absolutely right, Peter. I stand corrected.....and somewhat dismayed. That's a shortcut in the rendering/building pipeline that shouldn't have been taken, IMO. Virtually all rendering engines support heirarchical linking for animation purposes......why would LL have deliberately taken a shortcut there? The storage cost per prim? That doesn't hold up, since link numbers (due to limits) for children don't add up to that many bytes. Seems strange to me. The computations for rotations? That doesn't really hold up either, since those matrix ops have been highly optimized over the years.....I really do wonder why they did that. The only reason I could possibly fathom was the database retrieval and parsing of objects would be simplified by having a single root with all other prims being children of that root. Oh well.....means a few designs I have in my head simply won't work now. I'll have to figure out some workarounds.....or wait for mesh to go live.
  8. However, rotating the 'wheel' of the build is possible. The base could be a heirarchy of prims, with an 'axle' as the single prim that links between it and the 'wheel' prims (which would allow it to form a heirarchical chain of prims, maintaining the single-parent-to-any-number-of-children rule. The script can then rotate THAT prim (requires some additional math work, since you have to calculate the rotations about the child, not the root) and the prims that are children of it will move with it as desired.
  9. Sorry, but as far as I know, any single prim can have only one prim as a parent. Even if you were to link a bunch together as a single object, it still has a root. If you select that object, then another prim, and link them, the root prim of the multi-prim object is the 'prim' selected in that object....and is what the other gets linked to. Linking is a parent-child relationship between two prims. Each prim can have one parent, but can have many child prims. This allows heirarchies to be built....but one child prim cannot have two parent prims.
  10. I use something similar to the 'getLinkNum' function.....along with a couple of variations (that use llGetSubString) to match based on the prim name starting with or ending with a certain string, and returning a list of all matching prim numbers. list GetLinkNumsByStart(string s){ integer i; list t = []; for(i=0; i < llGetNumberOfPrims(); ++i) if(llGetSubString(llGetLinkName(i),0,llStringLength(s)-1) == s) t+=[i]; return t;} The GetLinkNumsByEnd(string s) function is the same, only it uses indexes on the llGetSubString() from -(llStringLength(s)) to -1. With careful naming of prims, you can easily control whole sets pretty easily. And you only have to run the functions once (unless you are linking/unlinking prims in script too....) after rez to fill in the lists. It works for full names too, but you have to pull out the single list element (an extra step, if you don't need the list capability.)
  11. Unfortunately, LSL isn't a full programming language......it's simply a scripting language, and it's functionality is limited to what LL decides to expose, as well as the event-driven nature of the design. #include would be nice, however it has its own problems....LSL isn't an optimizing compiler....so any functions you '#include'd would always appear in the resulting compiled code, even if they were never called in the script. So a large library would typically eat up memory while only providing a very few functions that get used. I try to keep a 'library' file of useful routines on my personal box, and when I need one of those functions in a script, I C&P it into it. Keeps things from getting bloated. I also occasionally go through those functions to try to optimize them as much as possible (both from memory usage and speed). There are considerably more pressing issues concerning LSL, even in my mind......I'd still like to see a 'llDialogOrdinal() ' function that returns the INDEX of the button pressed, and not its text. Numeric comparisons are a LOT more efficient than string comparisons unless you carefully choose your strings (which isn't always an option.) It is possible to put together a 'library' script with useful functions that can be called via chats or link messages with a well-defined API so that you could just drop that script into the object, and write your other code to send and receive the data for the functions......but it wouldn't be synchronous, as others have mentioned.
  12. Sorry about those errors.....I was posting from work, several interruptions, and no chance to proof it. Glad you got it working though. And as many others have already noted, FOR() loops may be marginally slower, but in a simple loop like this, the savings of going with a WHILE() isn't really worth the potential issues with different list lengths.
  13. Stacy Aquila wrote: --------------------------------------------------------------------------------------------------------------------------------- list PussyPrims;list PrimList;key Owner;list DildoPrims;list AssPrims;init() { integer link; for (link = llGetNumberOfPrims(); link >= 1; --link) { if (llSubStringIndex(llGetLinkName(link), "D1") != -1) { DildoPrims += (list)link; } else if (llSubStringIndex(llGetLinkName(link), "D2") != -1) { PussyPrims += (list)link; } else if (llSubStringIndex(llGetLinkName(link), "D3") != -1) { AssPrims += (list)link; } else if (llSubStringIndex(llGetLinkName(link), "") != -1) { PrimList += (list)link; } }} default{ state_entry() { init(); Owner = llGetOwner(); integer NumLink = llGetNumberOfPrims(); llListen(97, "", NULL_KEY, ""); integer i = 0; do { llOwnerSay("Dildo=" + (string)llList2Integer(DildoPrims,i)); llOwnerSay("**bleep**=" + (string)llList2Integer(PussyPrims,i)); llOwnerSay("Ass=" + (string)llList2Integer(AssPrims,i)); llOwnerSay("PrimList=" + (string)llList2Integer(PrimList,i) ); } while ((++i)<NumLink); } listen(integer channel, string name, key id, string msg) { integer a = 0; integer b = 5; string MSG = llToUpper(msg); while(a++ < b); // PROBLEM HERE <<<<<<<<< { if (MSG == "SHOWD1") { llSetLinkAlpha(llList2Integer(DildoPrims,a),1.0, ALL_SIDES); return; } else if (MSG == "HIDED1") { llSetLinkAlpha(llList2Integer(DildoPrims,a),0.0, ALL_SIDES); return; } else if (MSG == "SHOWD2") { llSetLinkAlpha(llList2Integer(PussyPrims,a),1.0, ALL_SIDES); return; } else if (MSG == "HIDED2") { llSetLinkAlpha(llList2Integer(PussyPrims,a),0.0, ALL_SIDES); return; } else if (MSG == "SHOWD3") { llSetLinkAlpha(llList2Integer(AssPrims,a),1.0, ALL_SIDES); return; } else if (MSG == "HIDED3") { llSetLinkAlpha(llList2Integer(AssPrims,a),0.0, ALL_SIDES); return; } } while ((++a)<b); } } I've pointed out the main problem..... Your first loop is a null loop. The ';' at the end. And you've got a second loop marker at the end. So your code is only executing once, not multiple times. Perhaps something like this: listen(integer channel, string name, key id, string msg) { integer a = 0; integer b = 5; string MSG = llToUpper(msg); string test = llGetSubString(MSG,0,0); string test2 = llGetSubString(MSG,-1,-1); list templist; float h; if(test == "S") h = 1.0; else h = 0.0; if(test2 == "1") templist = DildoPrims; else if(test2 == "2") templist = PussyPrims; else if(test3 == "3") templist = AssPrims; else return; for(i=0; i<llGetListLength(templist); ++i) llSetLinkAlpha(llList2Integer(templist,a),h,ALL_SIDES); }
  14. Probably ought to post it in the main scripting forum as a sticky so others can find it more easily: Archived Scripting Forum
  15. I see lots of people arguing that there needs to be mesh editing tools IN the viewer, and many arguing that it would be too complex. Actually, very simple editing tools for meshes could be integrated into the existing editing tools VERY simply. In the Editing Floater, up at the top where you select the radio/check boxes that allow you to select what you are editing (i.e., Position, Rotation, Strech, Select Texture, etc.) we could add a "Select Vertex" and "Select Poly" options as well. At this point, Editing an existing mesh in world, while tedious, would be doable. Adding a "Mesh" tab to join the "Texture", "Object", "General", etc.......would also provide specific specialized parameter changing (Perhaps Tesselation of selected face(s)) to allow a simple basic sphere mesh that could be rezzed internally, thus allowing one to add detail and more then move the new faces/vertexes as needed. Such an interface would be very primitive, and only provide the most basic functionality.....but it would permit an in-client interface for mesh development/editing. Should be doable without extensive work. Slow, tedious, but it WOULD be relatively easy to do (client side). Server side this might be a bit more complicated, but it still should be doable.
  • Create New...