[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensim-dev
Subject:    [Opensim-dev] Major issue with core code.
From:       nebadon2025 () gmail ! com (Michael Cerquoni)
Date:       2011-03-27 20:43:15
Message-ID: AANLkTikQMvLp8jd_sqjugDziG9o12L62iS8vdV2276Lm () mail ! gmail ! com
[Download RAW message or body]

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 <nebadon2025 at gmail.com>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 <wade.schuette at gmail.com>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 <marck00 at nexgo.de> 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 <wade.schuette at gmail.com
>>>> <mailto:wade.schuette at gmail.com>> 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
>>>>    <nebadon2025 at gmail.com <mailto:nebadon2025 at gmail.com>> 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
>>>>        <nebadon2025 at gmail.com <mailto:nebadon2025 at gmail.com>> 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
>>> Opensim-dev at lists.berlios.de
>>> 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
>> wade.schuette at gmail.com
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
>
> --
> Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org
>



-- 
Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/opensim-dev/attachments/20110327/edbecee8/attachment.html>

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic