Page 12 of 13

Re: We've updated Kitely to OpenSim 0.9.1.1

Posted: Thu Mar 26, 2020 3:20 pm
by Oren Hurvitz
Christine Nyn wrote:
Wed Mar 25, 2020 5:36 pm
Following the update to improve the linking/unlinking response times we are seeing a new problem.
...
What is happening is this: the normal way of creating such a build is to put it together and then to ensure that the various parts are correctly named and have the correct descriptions, and this stage is done while the build is fully linked. When we do this the editor shows the changes made exactly as you would expect, but a script interrogating the build does not see the changes in the child prim details and persists in reporting whatever was there originally.
I created a script to test this, but it worked fine:
Link explorer.zip
(729 Bytes) Downloaded 19 times

I tested as follows:
1. I created several boxes
2. Linked the boxes
3. Put the attached script in one of the boxes
4. Clicked the box with the script. It showed the current names and descriptions of all the boxes in the linkset.
5. Using "Edit linked", I changed the name and/or description of some of the boxes
6. Clicked on the main box again. It showed the updated names and descriptions.

So I can't reproduce the problem. Can you share the script that you are using? Please send it to our email address contact@kitely.com.

Re: We've updated Kitely to OpenSim 0.9.1.1

Posted: Thu Mar 26, 2020 3:43 pm
by Sara Nyn
Oren Hurvitz wrote:
Wed Mar 25, 2020 8:04 pm
Hi Christine,

To help fix this problem, please send us an example of one of these scripts.
So when one of the better script authors in *all* of Opensim reports in great detail an issue your first response seems to be questioning the scripts...............

Re: We've updated Kitely to OpenSim 0.9.1.1

Posted: Thu Mar 26, 2020 4:26 pm
by Oren Hurvitz
Sara Nyn wrote:
Thu Mar 26, 2020 3:43 pm
Oren Hurvitz wrote:
Wed Mar 25, 2020 8:04 pm
Hi Christine,

To help fix this problem, please send us an example of one of these scripts.
So when one of the better script authors in *all* of Opensim reports in great detail an issue your first response seems to be questioning the scripts...............
I want to use the script to fix OpenSim. I was unable to reproduce this problem myself (see the comment above), which is why I need the script Christine used to try to reproduce the problem.

Re: We've updated Kitely to OpenSim 0.9.1.1

Posted: Thu Mar 26, 2020 6:36 pm
by Christine Nyn
Thank you for looking at this Oren.
If you can't reproduce the effect perhaps the world where the script was running might yield some data you could use. Black Sails.

The script itself is what you might call a bread-and-butter script that scripters everywhere will have examples of. For what it is worth I'll include it here but I really don't think the script itself will be of much help.

Code: Select all

// example script for Oren
// Christine Nyn, 26-March-2020

/*
	The point here is not how the script operates. It is that a change made
	to the object description of a linked prim in the editor can not be
	picked up by the script. The editor sees the change and is consistent
	in that selecting another object entirely and then returning to the
	edited prim will still show the change. 
	
	The only way to get the script to see the change is to unlink the prim,
	make the change, and then relink.
	
	Not relevant in this particular script, but it is also the case that a
	change to the name of a linked prim suffers in exactly the same way.
*/

list guns;

gun_links()
{
    guns = [];
    integer p = llGetNumberOfPrims();
    string desc;
    while(p)
    {
        desc = llStringTrim(llList2String(llGetLinkPrimitiveParams(p, [PRIM_DESC]), 0), STRING_TRIM);
        if(llGetSubString(desc, 0, 2) == "gun")
        {
        	// if "gun" is found the script then looks for P1, P2, P3 etc which would
        	// identify the port side guns. Similarly for bow, starboard etc.
            list temp = llParseString2List(desc, [" "], []);
            guns += [llList2String(temp, 1), p, 0, 0];
            // [location, link number, init to zero, init to zero]
        }
        p-- ;
    }
    guns = llListSort(guns, 4, TRUE);
}

default
{
    state_entry()
    {
        gun_links();
    }
    
    on_rez(integer foo)
    {
        llResetScript();
    }
}

~ Christine ~

Re: We've updated Kitely to OpenSim 0.9.1.1

Posted: Fri Mar 27, 2020 9:38 am
by Oren Hurvitz
Christine,

I tried to reproduce the problem using a script based on what you posted above, but I still couldn't get the bug to happen. In order to allow for checking the linkset repeatedly, I made the script check the linkset on a timer (shown below).

One possibility is that the bug is dependent on how exactly the prims are linked and modified. What is the exact sequence of events you're using? Here's what I'm doing:
1. I created a box and put the attached script inside it.
2. I clicked on the box to start the timer.
3. I created another box and linked it. Currently its description is empty.
4. I started the edit panel; checked "Edit linked"; clicked on the new box; and changed its description to "gun p1". Then I pressed Tab, in order to save the change.
5. The next time the script listed the guns, it displayed this prim.

BTW, I also checked the logs in the world "Black Sails", but it didn't show any errors.

Can you, using this script, cause the problem to reproduce? If not then could you email me your actual script? Perhaps I will be able to use it to figure out what's wrong. Thanks!

Code: Select all

list guns;
integer timerEnabled = 0;

gun_links()
{
    guns = [];
    integer p = llGetNumberOfPrims();
    string desc;
    while(p)
    {
        desc = llStringTrim(llList2String(llGetLinkPrimitiveParams(p, [PRIM_DESC]), 0), STRING_TRIM);
        if(llGetSubString(desc, 0, 2) == "gun")
        {
            // if "gun" is found the script then looks for P1, P2, P3 etc which would
            // identify the port side guns. Similarly for bow, starboard etc.
            list temp = llParseString2List(desc, [" "], []);
            guns += [llList2String(temp, 1), p, 0, 0];
            // [location, link number, init to zero, init to zero]
        }
        p-- ;
    }
    guns = llListSort(guns, 4, TRUE);
    
    llSay(0, "Guns found:");
    integer index;
    for (index = 0; index < llGetListLength(guns); index += 4)
    {
        llSay(0, "   link=" +  llList2String(guns, index+1) + ", desc=" + llList2String(guns, index));
    }
}

default
{
    state_entry()
    {
        gun_links();
    }
    
    on_rez(integer foo)
    {
        llResetScript();
    }

    touch_start(integer num)
    {
        if (timerEnabled) {
            llSetTimerEvent(0);
            llSay(0, "Stopped timer");
        }
        else {
            llSetTimerEvent(5);
            llSay(0, "Started timer");
        }
        
        timerEnabled = 1-timerEnabled;
    }
    
    timer()
    {
        gun_links();
    }
}

Re: We've updated Kitely to OpenSim 0.9.1.1

Posted: Fri Mar 27, 2020 5:10 pm
by Christine Nyn
Oren Hurvitz wrote:
Fri Mar 27, 2020 9:38 am
Can you, using this script, cause the problem to reproduce? If not then could you email me your actual script? Perhaps I will be able to use it to figure out what's wrong. Thanks!
I'll see how closely I can reproduce the steps that were taken before a script was introduced to the build and see what happens. It's looking like this might be better moved out of the general forum though so what email would you prefer me to use?

Re: We've updated Kitely to OpenSim 0.9.1.1

Posted: Fri Mar 27, 2020 7:03 pm
by Oren Hurvitz
Christine Nyn wrote:
Fri Mar 27, 2020 5:10 pm
I'll see how closely I can reproduce the steps that were taken before a script was introduced to the build and see what happens. It's looking like this might be better moved out of the general forum though so what email would you prefer me to use?
Please send to contact@kitely.com.

Re: We've updated Kitely to OpenSim 0.9.1.1

Posted: Mon Mar 30, 2020 12:43 pm
by Ilan Tochner
We rolled out a live system update (one that doesn't require taking down the entire system) that fixes the following issues:

1) Some object properties were automatically reverted to their previous state within minutes of being changed.

2) Some objects that were deleted inworld became "phantom objects" that could be seen by the viewer but couldn't be selected or deleted (and would only disappear once the viewer was restarted).

We've already fixed a few more issues that will be included in the next full system update (an update that will require taking down the entire system). We expect this next update to be ready for deployment later this week (see the original post in this thread for details).

Re: We've updated Kitely to OpenSim 0.9.1.1

Posted: Mon Mar 30, 2020 8:17 pm
by Chris Namaste
:)
(copy of the errors im experiencing of previous post-bc it keeps existing & getting worse) just fyi, i donno if this was on agenda-fixing items or not :)
to be safe,i send it again,just for info, thankyou's!!!

thx ilan,again,for following all steps via the web,so you could see what happened - its now worse, i copy (for exemple the top to another folder - another color, to make a new color with same top, what i always do, and it jumps back to the previous folder several times) fyi

previous text in this topic :
'the texture upload 'weird error' keeps existing :'(
today,i logged in welcome center, the jeans i made yesterd was 'white' like 'new pants white'
i changed the jeans in welcome with my texture (again)

imagine customer buys & gets a white jeans (or same situation with my skin a few days ago)?
i really never seen this before, in no world & worry :'(
icant show or give more info,hope this helps?
thanks for reading
chris'

Re: We've updated Kitely to OpenSim 0.9.1.1

Posted: Mon Mar 30, 2020 8:49 pm
by Ilan Tochner
Hi Chris,

Please see the first post in this thread. We fixed the issue you reported (it's a result of the "not enough permissions on asset(s)" problem) but we haven't rolled out that fix yet because doing so requires a full system update and that requires taking down the system.

As stated in my previous post, we hope to complete the other tasks that we're currently working on (that also require a full system update) later this week. Once those tasks are completed, we'll put a notice on our website notifying you when we'll take the system down for maintenance so that we can roll out all the fixes that require a full system update.