GAH, scratch that last email, it works, i had a space at the end of the prim name ie: "minutehand " GRRR...
On Sun, Mar 27, 2011 at 1:28 PM, Michael Cerquoni <[email protected]>wrote: > Well I took your suggestion and added in the scanning loop, and its still > not working correctly, its reporting the wrong prim # atleast compared to > what the viewer is seeing. here is a screenshot > > http://www.onikenkon.com/screenshots/link_order_issue_03.png > > So it seems that this method will also not work.. > > > On Sun, Mar 27, 2011 at 8:02 AM, Wade Schuette <[email protected]>wrote: > >> Here's an easy to understand snippet of code that does the job, regardless >> how inelegant. >> ==== >> >> // The function is to find out what prim numbers correspond to those names >> right now (in case it has changed). >> // Author : Wade Schuette; Date: March 27, 2011; >> // Anyone is free to copy modify transer or whatever this code (just take >> off my name if you do!) >> >> // Note: I'm sure there are vastly more elegant ways to keep all the >> specific names out of the routines, >> // and put them into lists at the start, but my goal was just to >> illustrate a very simple way that works >> // and can be read by a new scripter. >> >> // global variables set as a side-effect of the getPrimNums() call; >> // My example linked set is a body with various parts. This code is run >> from the root; >> >> integer heart; >> integer liver; >> integer stomach; >> >> // subroutine to find which prim corresponds to known names, by brute >> force exhaustive search. >> getPrimNums() >> { >> integer i; >> integer numPrims = llGetNumberOfPrims(); >> llSay(0, "This link set has " + (string) numPrims + " prims."); >> for (i=1; i <= numPrims; i++) >> { >> llSay(0, "Prim " + (string) i + " is " + llGetLinkName(i) ); >> >> if (llGetLinkName(i) == "heart") { heart = i;} >> else if (llGetLinkName(i) == "liver") { liver = i;} >> else if (llGetLinkName(i) == "stomach") { stomach = i;} >> } >> } >> >> >> default >> { >> state_entry() >> { >> >> getPrimNums(); >> >> // OK, those are assigned and the integers can be used in your >> code. >> llSay(0, "Please confirm from the list above..."); >> llSay(0, "Heart is prim number " + (string) heart); >> llSay(0, "Stomach is prim number " + (string) stomach); >> llSay(0, "Liver is prim number " + (string) liver); >> >> } >> } >> >> ==== >> >> >> On Sun, Mar 27, 2011 at 9:16 AM, Marck <[email protected]> wrote: >> >>> The prim numbering used to change even when an object crossed a region >>> border. This was fixed some time ago. >>> >>> For an example how to circumvent this issue in a script, see >>> http://forums.osgrid.org/viewtopic.php?p=10732#p10732. A more >>> generalized solution of this can be found in thread "Single Script >>> Color/Linkset Changer"; in both cases, the relevant function is named >>> "getLinkNums". The basic idea is to put a label either in the linked prim's >>> name or description field and then retrieve the proper prim number by >>> searching for the label(s). >>> >>> Michael Cerquoni wrote: >>> >>>> Any chance you have an example of how you do this that you can share? I >>>> would like to see how your doing this. >>>> >>>> On Sun, Mar 27, 2011 at 1:41 AM, Wade Schuette <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Just a note - While I agree entirely that the prim order should stay >>>> constant for an object the user hasn't changed, as an application >>>> developer I always start by polling all linked prims to determine >>>> which one is which number (today), and then work off that list. >>>> Otherwise, adding a single new prim to the object, or unlinking it >>>> in order to resize or retexture a prim that refuses to change when >>>> linked, will totally break the user script, and is maddening. >>>> With polling, I can unlink or relink or add pieces whenever I feel >>>> like it and the code doesn't break. The one extra step only has to >>>> be written and debugged once and used as a utility subroutine after >>>> that. What WOULD kill it is if the root prim changed, of course. >>>> >>>> And, I developed that habit in Second Life, although it's totally >>>> crucial in OpenSim since we have to keep unlinking complex objects >>>> in order to change a stubborn linked prim that refuses to change >>>> while it is linked. Why is THAT, by the way? Can THAT be fixed? >>>> >>>> Wade >>>> >>>> >>>> >>>> On Sun, Mar 27, 2011 at 4:01 AM, Michael Cerquoni >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> I spoke to Melanie, she says she has a fix for this! apparently >>>> this has been an issue for a while, I had no idea, thanks >>>> Melanie :D >>>> >>>> On Sat, Mar 26, 2011 at 11:44 PM, Michael Cerquoni >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> I have just stumbled across a major problem with the core >>>> code, it seems that every time we rez an object its linkset >>>> prim order is changing. This makes it impossible to script >>>> things that call upon a certain # in the link-set. I have >>>> filed a mantis: >>>> >>>> http://opensimulator.org/mantis/view.php?id=5421 >>>> >>>> see screenshots of issue here: >>>> >>>> http://www.onikenkon.com/screenshots/link_order_issue_01.png >>>> http://www.onikenkon.com/screenshots/link_order_issue_01.png >>>> >>>> This is a major issue that should be resolved before 0.7.1 >>>> is tagged i believe. >>>> >>>> -- >>>> Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> >> >> >> -- >> R. Wade Schuette, CDP, MBA, MPH >> 6751 Scio Church Rd. >> Ann Arbor, MI 48103-9270 >> cell: 1 (734) 635-0508 >> fax: 1 (734) 864-0318 >> [email protected] >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > > > -- > Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org > -- Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
