Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006311opensim[REGION] Script Functionspublic2012-09-21 03:422017-11-17 13:23
Reporterwbalazic 
Assigned To 
PriorityhighSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0006311: llGiveInventoryList no longer functions as expected.
DescriptionExpected behavior is for it to create a new folder regardless of if the folder exists or not. In past it would create a subfolder within an existing root folder. EG: #RLV/~gift would create the subfolder "~gift" in the root "#RLV" folder. Present behavior has it making a whole new path from root. The big problem with this any attempt to utilize or reference the given items will fail. Since there are now two #RLV folders, an empty one and one containing the ~gift subfolder, its always going to reference the first one listed (the empty one) and never find the new subfolder.
Steps To ReproduceCreate a script using the following:

(script top)

string foldername="~gift";

(inside script)

llGiveInventoryList(g_LastAvatar,"#RLV/"+foldername, itemlist);

The result "should" be creation of the folder ~gift under the #RLV folder. This functioned in prior releases. Instead it creates a NEW folder called #RLV/~gift in the root folder which is incorrect.


TagsNo tags attached.
Git Revision or version number0.7.4 Opensimulator build from www.opensimulator.org
Run ModeStandalone (1 Region) , Grid (1 Region per Sim)
Physics EngineODE
EnvironmentMono / Linux32, .NET / Windows32, .NET / Windows64
Mono VersionNone
ViewerFirestorm/Imprudence
Attached Filestxt file icon LL-TaskInventoryOffered-and-reply.txt [^] (2,645 bytes) 2012-10-05 18:54 [Show Content]
txt file icon opensim-TaskInventoryOffered-and-reply.txt [^] (2,661 bytes) 2012-10-05 18:54 [Show Content]

- Relationships
related to 0006360closedjustincc llGiveInventoryList causes an exception in the console 

-  Notes
(0022655)
justincc (administrator)
2012-09-21 17:14

According to lslwiki [1], this is the expected behaviour of llGiveInventoryList() - given folders cannot be created within the user's existing folders. Or is this a wrong description of the behaviour of llGiveInventoryList() as implemented on the LL grid?

[1] http://lslwiki.net/lslwiki/wakka.php?wakka=llGiveInventoryList [^]
(0022664)
wbalazic (reporter)
2012-09-21 21:00

Here's info on how it is supposed to behave and how it behaved in the past. Keep in mind this isn't a failure from the viewer side as it fails in Firestorm, Phoenix, Kokua, Imprudence, and Cool Viewer all with RLV protocol enabled.


http://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI [^]

Accept sub-folders given via llGiveInventoryList() into the shared folder :

Starting with RestrainedLove v1.16.2, you may give a list of items to a victim and have them stored as a sub-folder inside the #RLV folder (thus allowing you to @attach the given items later).

Issuing a llGiveInventoryList(victim_id, "#RLV/~subfolder_name", list_of_stuff) command in a script makes a standard Keep/Discard/Mute dialog appear in the viewer of the victim (the avatar which key is victim_id).

Should the victim accept the offer, the list_of_stuff items are put into a new sub-folder of the #RLV folder. The name of this sub-folder is "~subfolder_name" (it is the scripter's responsibility to use unique sub-folder names: if the name is the same as an existing sub-folder, two sub-folders with the same name will appear in the #RLV folder).

Note that the tilde character *must* be used as the first character for the name of the sub-folder (this is so that the victim can easily spot any sub-folder given to them in this way, and so that such sub-folder names appear last in the #RLV folder).

Note also that this feature may be disabled by the user, (by setting the RestrainedLoveForbidGiveToRLV debug setting to TRUE): in this case the given items are put into a folder named "#RLV/~subfolder_name" at the root of the inventory instead of inside the #RLV folder.

Since the user may either refuse the offer or have the feature disabled in their viewer, and since SL may take quite some time to perform the actual transfer of the objects on laggy days, you must check that the given folder is present (with @getinv), before attempting to @attach the given objects.
(0022686)
justincc (administrator)
2012-09-24 17:04

Do you have any idea how the RLV works? Could it be working by changing folders on the viewer-side after it receives an item? In which case the issue may be OpenSimulator side but it might actually be something to do with item/folder movement rather than llGiveInventoryList() itself.

This would mean that normally llGiveInventoryList() would not cause this subfolder behaviour, as stated in [1]

"Note also that this feature may be disabled by the user, (by setting the RestrainedLoveForbidGiveToRLV debug setting to TRUE): in this case the given items are put into a folder named "#RLV/~subfolder_name" at the root of the inventory instead of inside the #RLV folder."

[1] http://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI [^]
(0022687)
stella Luna (reporter)
2012-09-25 07:46

Be careful when working on this. I remember having seen similar issues in SL some time back in the past. I will further investigate in this and report back here later this week.
(0022689)
wbalazic (reporter)
2012-09-25 08:25
edited on: 2012-09-25 08:37

What exactly do you mean by "be careful working on this". It DID work in the last release, and it doesn't now. So there's something that has changed and doesn't function as it does in SL (which I assume is the intent based on the notes above). This isn't new functionality, this functionality has existed for years in RLV with LSL and was functional up until last month. On the 0.7.4 release it discontinued functionality.

(0022690)
melanie (administrator)
2012-09-25 10:21

This pertains to RLV only and is therefore outside the spec for us. RLV is a 3rd party vieer-only addition.
(0022691)
justincc (administrator)
2012-09-25 11:10

If this RLV facility was working in 0.7.3.1 and no longer works in 0.7.4 then that's worthy of investigation. However, from what I've read so far it seems to me that there's no formal support of it by Linden Lab - rather it uses normal inventory operations in some way.
(0022692)
wbalazic (reporter)
2012-09-25 11:28

Yes you are right the RLV protocol has no formal support with LL, but..... since it is based on operational parameters that are in place in the LSL protocol, if it is now failing and wasn't here in Opensimulator, and is not failing in SL/LSL, then something else maybe also be malfunctioning with this command that we aren't aware of because it hasn't been brought to light yet.
(0022693)
melanie (administrator)
2012-09-25 12:15

i don't think that code has been changed in ages. it would be one hell of a wild goose chase unless someone from the viewer side steps up and tells us "you are sending X where you should be sending Y"
(0022694)
wbalazic (reporter)
2012-09-25 12:19

Well, it would be all viewers that use the RLV and/or RLVa protocol. That's why I don't think we are talking about a viewer side issue. If it were, then theoretically Imprudence for example would behave correctly, and Firestorm would not. But Imprudence, Kokua, Firestorm, and Phoenix all behave the same way.
(0022696)
melanie (administrator)
2012-09-25 12:27

Of course. However, we have not changed that code so it's not simply looking at recent changes and reversing them; there were none. The problem lies deeper and I doubt anyone would be interested in fixing it unless the detailed diagnosis is made by someone familiar with viever internals and we are given a "recipe" to fix it. We'd be even happier if such a recipe were expressed in patch form but bare information would also work.
Basically, we need to know what the viewer expects that we are not sending. Then we can go there and fix it. I don't have time to read myself into the viewer source to troubleshoot this, but I'd be happy to do a fix if someone who is familiar with the viewer side tells me what to fix.
(0022697)
wbalazic (reporter)
2012-09-25 13:26

I'll see if I can get someone familiar with the RLVa protocol to give insight on what it's doing. Basically the fault lies in the fact that rather than putting the given directory "under" the #RLV folder as described below:

Issuing a llGiveInventoryList(victim_id, "#RLV/~subfolder_name", list_of_stuff) command in a script makes a standard Keep/Discard/Mute dialog appear in the viewer of the victim (the avatar which key is victim_id).

It instead creates a folder called #RLV/~subfolder name. I believe the RLV protocol adds the functionality of placing given items into the #RLV folder (just a guess here but I'm guessing that #RLV is a coded variable default for the RLV protocol which points to what master/default folder to place RLV given items) rather than in root as the original LSL function does.
(0022702)
stella Luna (reporter)
2012-09-27 02:40

I just tried in SL. I'm sorry to say that it no longer works in SL, too. The example provided by you produces a new separate #rlv folder for any intension to create a sub-folder. THIS WORKED in the past. I tested both, with rlv enabled and without rlv. So far I tested with Phoenix only.

Unfortunately it looks like the appropriate entry in the jira has been removed or made otherwise unavailable to the public. Since I cannot access it anymore I'm not sure it was related to SVC-7748.
(0022703)
wbalazic (reporter)
2012-09-27 03:03

Lovely.. doesn't work there now either. That breaks about 10,000 items... :(
I'll drop Marine an e-mail and see if she's aware of this. I'll also send something to Jessica over at Firestorm/Phoenix and see if they know what has changed...
(0022704)
melanie (administrator)
2012-09-27 03:30

I believe I recall the Received Items folder functionality broke this in SL.
(0022705)
wbalazic (reporter)
2012-09-27 06:17

http://jira.phoenixviewer.com/browse/FIRE-7176 [^]

This is an RLVa Functionality issue.
(0022706)
stella Luna (reporter)
2012-09-27 06:38

Sorry I was wrong. It currently works as expected in SL (Second Life Server 12.09.07.264510).

While testing for OpenSim I obviousely enabled RestrainedLoveForbidGiveToRLV by accident and have forgotten to set it back before I tested in SL.
(0022707)
wbalazic (reporter)
2012-09-27 07:28

That being the case, then the malfunction must lie in the Opensimulator software release and how it relates to RLV. I am going to open a ticket with the RLVa team and see what can be done but if it functions in SL, then we'll have to look at why the same functionality doesn't exist here anymore.
(0022709)
stella Luna (reporter)
2012-09-27 12:14
edited on: 2012-09-27 12:18

I totally agree to this. The Firestorm issue you mentioned (FIRE-7176) has been known for a while and has nothing directly todo with this.

I've setup a simple test environment today with two regions, one running OS 0.7.3 the other one running OS 0.7.4. The tests so far showed me that the problem might be rather complex.

While my first tests succeeded on 0.7.3 but failed on 0.7.4 as expected, it failed on 0.7.3 on a second try too.

I deleted all my test results and relogged without clearing the trash or the cache. After relog the problem still existed and I could see that during the prompt dialog the trash folder has been accessed.

I deleted the results again, cleared the trash and manually created a new #rlv folder that automatically got the usual system folder icon and eithout haveing to relog, it worked again on 0.7.3 but not on 0.7.4.

This just as hint for the developers. Feel free to contact me for testing or more detailed information.

(0022712)
stella Luna (reporter)
2012-09-27 16:05
edited on: 2012-09-27 16:06

Just found another interesting behaviour that might be related. In my tests I used a prim containing the llGiveInventoryList in the Touch event so the iten is given when the user clicks the prim.

Unter this conditions, in Phoenix and Firestorm, after the click in SL a dialog box is displayed without the option for silently accepting the item without sender notification.

In OS 0.7.3 the dialog box displayed contains the option to silently accept the item. In this case, if "(Keep)" is pressed, a new folder outside the #RLV folder is created. In case of using the "Keep" button, the behaviour is as expected and the subfolder is created inside the existing #RLV system folder.

In OS 0.7.4 the dialog box is like in SL and contains NO options to silently Keep, Remove or Mute. But when pressing "Keep" it behaves the same as in OS 0.7.3 when pressing the "(Keep)" button.

Sorry my English. I hope you understand what I describe :)

(0022713)
melanie (administrator)
2012-09-27 16:11

i'm not aware of a (keep) button so that must be a phoenix addition. We cannot cater to that.
(0022715)
wbalazic (reporter)
2012-09-27 17:39
edited on: 2012-09-27 17:40

I don't think the keep button was the point. I think the point was that there is a different reaction with 0.7.4 as compared to 0.7.3. The keep button is a warning dialog that you are about to be passed an item via script to inventory. There is an option setting in Phoenix and Firestorm that will allow you to prohibit such action, hence the options dialog for silently keep, remove, mute. I believe the point was that the Opensimulator software llGiveInventoryList functionality behaves "differently" in 0.7.4 than it did in prior releases. This was just another example of that. Is it possible to cater to making it function like it did in release 0.7.3 again which was the correct functionality for this?

(0022718)
stella Luna (reporter)
2012-09-28 03:01
edited on: 2012-09-28 03:01

Sure it's not the "Keep" button itself, but this is the closest thing I found that reacts differently under the given conditions and might be an indicator for what happens.

There is one more thing to mention. In SL, at the time the dialog box appears, there is no other visual indication for a change in the Inventory. In OpenSim (both 0.7.3 and 0.7.4) the folder appears at this time already outside the #RLV system folder and is removed (0.7.4) or moved into the #RLV folder (0.7.3) after "Keep" has been clicked.

All I do here is to provide as much information as possible. I made a bunch of tests with Phoenix and Firestorm on SL, OS 0.7.3 and OS 0.7.4 and compared the results in an Excel Sheet. The information I provide here is already reduced to the tests that returned different results under any of the currently six tested configurations, so the developers havent to findout themselves first.

(0022722)
stella Luna (reporter)
2012-09-28 09:11

To me it looks like the logic has been broken in a way the created subfolder is not moved. Here is an example of the steps involved. Look at step 7/8.

There is no difference in steps 1-4 between OS 07-3 and OS 0.7.4
1) RLV is enabled and properly configured in the viewer, a System folder #RLV exists
2) Agent Touched object and in turn triggers Touch event
3) llGiveInventoryList(llDetectedKey(0),"#RLV/~"+"testing",["test object"]) executes
4) A folder #RLV/~testing containing the given items is created at root level in My Inventory

a) OpenSIm 0.7.3 user accepts pressing "Keep" - Result is as expected
5a) The Dialog box "test 1, an object owned by stella Luna, has given you a folder named "#RLV/~testing..." appears. The Dialog contains additional buttons for silent acceptance.
6a) User clicks "Keep"
7a) OS server console displeys 16:54:01 - [AGENT INVENTORY]: folder 7a61d997-7419-4393-ae8e-a32226b7ad18 moved to parent ae3f4dcf-e6cc-7b4a-cde5-f27bb263b556
8a) Subfolder ~testing and its content is moved into the #RLV system folder
9a) Agent gets IM (in chat): [08:15] test 1, an object owned by stella Luna, gave you #RLV/~testing. test 1 is located at TamTam <175.8899, 55.49276, 21.33634>.

b) OpenSIm 0.7.3 user accepts silenty pressing "(Keep)" - Result fails
5b) The Dialog box "test 1, an object owned by stella Luna, has given you a folder named "#RLV/~testing..." appears. The Dialog contains additional buttons for silent acceptance.
6b) User clicks "(Keep)"
7b) No reaction on OS server console
8b) Folder is not moved
9b) Agent gets IM (in chat): [08:19] You silently accept #RLV/~testing
test 1 is located at TamTam <175.8899, 55.49276, 21.33634> from test 1, an object owned by stella Luna,.

c) OpenSIm 0.7.4 user accepts pressing "Keep" - Result fails
5c1) OS server comsole displaye 17:26:20 - [INSTANT MESSAGE]: Delivering IM to root agent stella Luna ab376189-b6b7-419f-b7c3-3cb5a9925119
5c2) The Dialog box "An object names test 1, an object owned by stella Luna, owned by Unknown User has given you a folder named "#RLV/~testing..." with buttons "Keep", "Discard" and "Mute" appears.
6c) User clicks "Keep"
7c) No reaction on OS server console
8c) Folder is not moved
9c) Agent gets IM (in chat): [08:41] test 1, an object owned by stella Luna, owned by Unknown User gave you #RLV/~testing
test 1 is located at Bongo <176.6442, 56.31565, 21.32705>.
(0022723)
wbalazic (reporter)
2012-09-28 10:13

Excellent information!! Thank you Stella! I'm sure this will help the dev's discover the issue/fault and cater to repairing it.
(0022753)
stella Luna (reporter)
2012-09-30 09:12
edited on: 2012-09-30 09:17

Here comes more :-)

The following relevant changes have been made in llGiveInventoryList between OS 0.7.3.1 and OS 0.7.4-RC2.

1) The folderID has been removed from the bucket (the last parameter in GridInstantMessage msg (_binaryBucket))

2) The 5th parameter in GridInstantMessage msg (_dialog) has been changed from InstantMessageDialog.InventoryOffered to InstantMessageDialog.TaskInventoryOffered

Using the old code brings back the old behaviour. However, this needs further investigation since the behaviour of OS 0.7.3 is different from the current behaviour in SL. While the folder handling of llGiveInventoryList in OS 0.7.4 is different from the behaviour in SL the dialog box presented in OS 0.7.4 is the one best corresponding to the dialog box presented in SL.

Regarding #RLV it's certainly not intended behaviour to let the user of the constraints to accept the offer silently, leading de-facto to the same issue as reported as an error for OS 0.7.4 in this document.

That said, in my opinion, simply replacing the new code by the old one is only half of solving the problem and NOT a solution.

(0022754)
melanie (administrator)
2012-09-30 09:16

The folder ID sent by the viewer is unreliable for non-RLV viewers, causing many viewers to send received items to trash rather than the proper folder, so I decided to not trust the viewer's desired destination folder.

TaskInventoryOffered is the correct message, that was simply a bug fix. Inventory offered should only be used for avatar to avatar offers.

However, ignoring the viewer's requested destination folder is probably at the root of this and it may need to be determined how to validate this info so we can ignore info from bad viewers.
(0022755)
stella Luna (reporter)
2012-09-30 09:23

@melanie: "Inventory offered should only be used for avatar to avatar offers." There are other use cases as well. Thinking on this as an example is where a display or kind of posestand turns an avatar into a marble statue.
(0022756)
melanie (administrator)
2012-09-30 09:26

InventoryOffered is defined as "one avatar offering inventory to another". The correct message for inventory offers from prims is TaskInventoryOffered. This is not a matter for discussion, as the handling is defined as that and used by SL that way. I will not permit a bug to be put back just to satisfy a viewer mod. In SL, it works with TaskInventoryOffered, so we need to make it work with that as well and not go back to a buggy state.
(0022773)
wbalazic (reporter)
2012-10-02 08:54

Melanie... nobody is asking you to NOT make it work like SL. Make it work like SL... this software does NOT operate identical to SL in this instance. It's not putting a bug BACK. Moreover, earlier in the thread you said you made "no changes" yet now your saying you don't want to put a bug back. Was there a change or wasn't there?
(0022774)
melanie (administrator)
2012-10-02 12:12

The change in question was 9 months to a year ago. This RLV issue is recent.
(0022775)
wbalazic (reporter)
2012-10-02 13:07
edited on: 2012-10-02 13:08

It worked in 0.7.3 in June which is when I last tried it, that wasn't 9 mos ago.

(0022776)
melanie (administrator)
2012-10-02 13:30

DUH. That's precisely what I'm saying - it STILL worked after the change to TaskInventoryOffered.
(0022777)
justincc (administrator)
2012-10-02 13:44

Please keep this discussion civil - being rude will get us nowhere.

As it happens, I suspect that the relevant change may be commit ecb759c1 Tue Jul 17 23:31:38 2012 where I made llGiveInventoryList() use TaskInventoryOffered.

Melanie is right - we can't go back on these kinds of bug fix. I would guess that the viewer actually made an allowance for OpenSimulator using the wrong message. In this case, the viewer would have to look for the right (as used by SL) message instead.
(0022778)
wbalazic (reporter)
2012-10-02 13:54
edited on: 2012-10-02 13:57

I'm not the one being rude Justin, the "professional" developer there above is. I can't imagine why nobody bothers to put a Mantis in. Might be because of remarks from people like Melanie possibly?? If you don't want to help Melanie, just ignore it and let people who are productive like Justin do so then. So far Melanie has decided that because she isn't really interested in it and it has no real benefit for "her" personally, to point her finger at everything BUT looking at the actual issue. Fact is she says she doesn't want to implement "back" a bug, after saying there was no change, when in fact it worked on 0.7.3, and now in 0.7.4 it does not... and... it does NOT work as it does in SL either. It DOES work as expected in SL, just not here. More importantly, I hear time and time and time again "this isn't SL" so why are we insisting it act exactly like SL does anyway? All I'm asking is that it works like it has for the last 2 years.

(0022779)
justincc (administrator)
2012-10-02 13:59

As I said, being rude or trading accusations gets us exactly nowhere. I am interested in getting to the bottom of this issue over time but not if this report is going to go off-topic.
(0022780)
wbalazic (reporter)
2012-10-02 14:01

I agree 100%. Now can I get back to working with the others on correcting the issue? I have been working on getting Kitty involved in this to explain what it is specifically the RLV protocol "was" looking for, and for some reason "is not" now to assist with this. Can we move forward along that path?
(0022782)
melanie (administrator)
2012-10-02 14:06

As far as I am concerned we can go on and fix the bug. Just stop the finger pointing.
(0022792)
justincc (administrator)
2012-10-02 18:32

Please try git master f1886c4. Melanie made a change to honor a destination folder in the TaskInventoryAccepted InstantMessage if one is given.
(0022793)
wbalazic (reporter)
2012-10-02 20:50

Hiro created instance for us. Results are the same, puts a folder called #RLV/~folder in root rather than putting ~folder in the existing #RLV folder.
(0022794)
melanie (administrator)
2012-10-03 05:28

The below is from current Firestorm repo:


    case IOR_ACCEPT:
        // ACCEPT. The math for the dialog works, because the accept
        // for inventory_offered, task_inventory_offer or
        // group_notice_inventory is 1 greater than the offer integer value.

// [RLVa:KB] - Checked: 2010-09-23 (RLVa-1.2.1e) | Modified: RLVa-1.2.1e
        // Only change the inventory offer's destination folder to the shared root if:
        // - the user has enabled the feature
        // - the inventory offer came from a script (and specifies a folder)
        // - the name starts with the prefix - mDesc format: '[OBJECTNAME]' ( http://slurl.com/... [^] )

        ------------------------------------------------------------------
        This block checks that:
            RLVa is turned on
            The message is TASK_INVENTORY_OFFERED
            The item that is given is a folder
            There is a prefix set for putting these subfolders
        ------------------------------------------------------------------

        if ( (rlv_handler_t::isEnabled()) &&
             (IM_TASK_INVENTORY_OFFERED == mIM) && (LLAssetType::AT_CATEGORY == mType) && (mDesc.find(RLV_PUTINV_PREFIX) == 1) )
        {
            fRlvNotifyAccepted = true;
        ------------------------------------------------------------------
        This block checks that the forbid give flag is not set
        ------------------------------------------------------------------
            if (!RlvSettings::getForbidGiveToRLV())
            {
                const LLViewerInventoryCategory* pRlvRoot = RlvInventory::instance().getSharedRoot();
        ------------------------------------------------------------------
        This block checks that the #RLV folder actually exists
        ------------------------------------------------------------------
                if (pRlvRoot)
                {
                    fRlvNotifyAccepted = false; // "accepted_in_rlv" is sent from RlvGiveToRLVTaskOffer *after* we have the folder
        ------------------------------------------------------------------
        Here, mFolderID is set to the RLV folder's ID
        ------------------------------------------------------------------
                    mFolderID = pRlvRoot->getUUID();

                    RlvGiveToRLVTaskOffer* pOfferObserver = new RlvGiveToRLVTaskOffer(mTransactionID);
                    gInventory.addObserver(pOfferObserver);
                }
            }
        }
// [/RLVa:KB]

        ------------------------------------------------------------------
        This evil bit of code depends on the numerical value of the offer
        message and simply adds 1 to get the number of the accept message.
        ------------------------------------------------------------------
        // Generates IM_INVENTORY_ACCEPTED, IM_TASK_INVENTORY_ACCEPTED,
        // or IM_GROUP_NOTICE_INVENTORY_ACCEPTED
        msg->addU8Fast(_PREHASH_Dialog, (U8)(mIM + 1));
        ------------------------------------------------------------------
        This is where the destination folder is packed into the binary
        bucket for the server to move the folder there.
        ------------------------------------------------------------------
        msg->addBinaryDataFast(_PREHASH_BinaryBucket, &(mFolderID.mData),
                     sizeof(mFolderID.mData));
        // send the message
        msg->sendReliable(mHost);

------------------------------------------------------------------------------------

The above shows the things that need to be in place for RLV inventory give to work. Please check all those prerequisites were there. The code I added uses the folder in the binary bucket to move the new folder/new item there. This MAY differ from SL in that SL was changed at some point to use a less safe inventory give system. That is the reason for SL's need to create that offline delivery system.

It used to be that SL would deliver to the target folder (folder for type) and then ask the viewer (as we do now). It would then move the item only if it's rejected. We still have that approach which ensures proper delivery if a user is offline.

SL at some point changed this to create the item only if the item is accepted. This has the side effect of an item never being received if the IM offering it gets lost and also may mean that items refused will not always be in trash, but instead will be actually refused, means, never been accepted anywhere. Overall this is less secure because it relies on offline IM, which, in SL, is capped.

If RLVa relies on this new SL behavior, we will likely not be able to change to accommodate it as our code structure doesn't lend itself to that approach.
(0022803)
justincc (administrator)
2012-10-05 18:49
edited on: 2012-10-05 18:50

Okay, I have also made further changes in git master 16c9c1d, though I do not think that this is a permanent solution.

I can confirm that RLV works with Firestorm 4.2.2.29837 on OpenSimulator 0.7.3-post-fixes but not fully with current git master. When OpenSimulator 0.7.3-pf sends the InventoryOffered message the viewer responds with InventoryAccepted. When master sends TaskInventoryOffered, the viewer responds with TaskInventoryAccepted.

Current LL code also sends a TaskInventoryOffered message, not InventoryOffered.

On 0.7.3-pf, it is the viewer itself which subsequently issues MoveFolder and UpdateFolder (to rename) requests. On current master the viewer does not do this when the folder is accepted.

In git master 16c9c1d I made changes to much better match the data OpenSimulator puts in the TaskInventoryOffered to match that of LL. Please see the packet outputs attached. However, this did not trigger the viewer to make the MoveFolder/UpdateFolder requests itself.

Therefore, I elaborated on git master f1886c4 to send inventory updates to the viewer when the simulator moves the folder in response to TaskInventoryAccepted. Because these were absent, the viewer was not seeing the move until relog.

However, this does not rename the folder from, for example #RLV/~good to good. Renaming the folder simulator side is not a good solution since it starts to introduce RLV logic on the simulator which should not be necessary. What we really need now is for someone familiar with RLV (perhaps Kitty?) to take a look and tell us why the viewer isn't doing this move and rename as it does when connected to the LL grid. I suspect it might be something to do with OpenSimulator handling inventory updates differently but to make quick progress we really need someone familiar with the viewer-side.

(0022996)
wbalazic (reporter)
2012-11-02 12:01
edited on: 2012-11-02 23:17

Ok, due to some testing with a few HG patches that Hiro asked for regarding Diva's code, we are running 0.7.5 HEAD. The functionality still remains incorrect.

(0022997)
wbalazic (reporter)
2012-11-02 13:48

Here's the git for that build btw:

7412795a0bedae060e9f2bce2fa12e0497916f6e
(0023028)
justincc (administrator)
2012-11-06 16:29

Yeah, it's not quite correct. And to be honest, I don't think this is the right path to go down since to make it absolutely correct would require some pretty specific coding.

Really, we need to find out why the viewer is not performing these operations itself, as it is for the LL grid (which provides no specific support for RLV afaik). I actually looked through the RLV viewer code in Firestorm 4.2.2.29837 but could not see why this was happening. Hence, input from a viewer dev would be really helpful.

One possibility is that the update has not been occuring because of issues server-side with updating folder version numbers, which I believe the viewer uses for caching purposes. You might want to try git master bf46981 connected with this. However, if it suddenly starts working then you either might not see it, or some other issue may arise due to the actions OpenSimulator is now performing. This is another reason why this needs to be resolved so that the viewer performs the required actions and not the simulator.
(0023029)
melanie (administrator)
2012-11-06 16:54

OpenSim should not have _direct_ support for this. Period. OpenSim should strive to be compatible with SL to the point where the viewer performs these actions like it does in SL. I'm strongly -1 on putting RLVa logic into OpenSim core.

Reasons:
- Future changes could make the viewer side work again. Viewer and simulator could be at odds, causing havoc up to and including complete item loss and/or inventory damage.
- The RLVa spec could be updated, extended or changed in the future. This would necessitate core to monitor the spec for changes and continue to duplicate and maintain this functionality. This task is out of scope for core.
- Where should the line be drawn as to what special case software should be shoehorned into core? Accepting one while refusing all others is not fair and accepting all is not feasible. The only viable option is to refuse all.

The functionality in the viewer should be triggered by OpenSim in the same way SL triggers it, therefore preserving compatibility and future expansion options on the part of the RLVa devs.
(0023030)
wbalazic (reporter)
2012-11-07 01:29

I agree, so make it function like SL. It does "not" right now.
(0023064)
dirk mathers (reporter)
2012-11-10 00:38

As of OSgrid 0.7.5 (Dev) 4f98259: 2012-11-10, llGiveInventoryList drops to "#RLV/~gift" are placed in "#RLV/#RLV/~gift". However, even without the proper renaming of the folder, RLVa command "@attach:" is able to find the "~gift" folder, the items within, and function normally. Further, by adding a second check for the additional "#RLV" folder level, "@getinv:=" is also able to function normally. At this time it appears that with some scripting workarounds it should be possible to restore most if not all RLVa functionality. Proper renaming of the folder would be best, but the present situation is not impossible to work with.

Sincere thanks to all involved in resolving this issue.
(0023110)
justincc (administrator)
2012-11-12 20:23

As the viewer is now doing this, I have disabled the OpenSimulator side-code in git master f605a62 which was causing the #RLV folder duplication, as per my comment above. Hopefully, this will fix folder creation so that we get #RLV/~gift rather than #RLV/#RLV/~gift and no workarounds will be necessary.
(0023111)
melanie (administrator)
2012-11-13 00:32

Sounds like a winner.
(0023198)
dirk mathers (reporter)
2012-12-05 14:15

As of OpenSim 0.7.5 Dev OSgrid 0.7.5 (Dev) 583e441: 2012-12-04 (Win/.NET), this is once again placing the folder in root.

At least when it was doing an extra folder level I could work around. None of the RLVa commands can find the inventory drops unless they go into the existing #RLV folder.

In other words, its broken AGAIN.
(0023199)
wbalazic (reporter)
2012-12-05 14:18
edited on: 2012-12-05 14:19

Functionality was corrected in 0.7.5 (Dev) 4f98259 but is back to broken in 0.7.5 (Dev) 583e441. Although the 4f98259 release wasn't operating entirely as it had in the past, it was at least giving the inventory to the correct location. It is now back to dropping it in the root inventory again.

(0023200)
dirk mathers (reporter)
2012-12-05 14:28

I know nothing about the code, but it seems to me that when the user accepts the inventory the viewer must be issuing some command to move the inventory from root to the #RLV folder and the command isn't being honored server side.

"The folder ID sent by the viewer is unreliable for non-RLV viewers, causing many viewers to send received items to trash rather than the proper folder, so I decided to not trust the viewer's desired destination folder.

TaskInventoryOffered is the correct message, that was simply a bug fix. Inventory offered should only be used for avatar to avatar offers.

However, ignoring the viewer's requested destination folder is probably at the root of this and it may need to be determined how to validate this info so we can ignore info from bad viewers."

From this I infer that the viewer is TRYING to provide the necessary folder information and its being discarded.
(0023212)
justincc (administrator)
2012-12-07 18:14
edited on: 2012-12-07 18:14

It seems I misunderstood you earlier, Dirk - for some reason I thought the information you gave showed that the inventory version fixes had resolved this when I see this is not actually the case.

From further analysis of the Firestorm viewer code by grepping RLV_PUTINV_PREFIX (which is "#RLV/~"), it seems to me that the viewer is expecting the server to perform the move on TaskInventoryAccepted (in this case to the nominated #RLV folder) but it then expects itself to rename #RLV/~gift to gift once it receives a certain notification about this folder.

Currently, the viewer is not doing the rename. I strongly suspect the problem is OpenSimulator-side, either because we're not sending BulkInventoryUpdate (rather we're sending InventoryDescendentsPacket) or because we're not using transaction IDs properly. I suspect the second reason though it could be a combination.

Therefore, in commit 63cff49 I have restored the server folder move, since it looks like we should be doing this anyway. However, I have run out of time to address the notification issue so it may take a while. However, please be aware that this WILL be fixed, so please DO NOT rely on folders to continue to be 'wrongly' named.

(0023224)
dirk mathers (reporter)
2012-12-11 21:04

Thanks again for addressing this. I'll continue to check both "#RLV/" and "#RLV/#RLV/" until I hear anything further.
(0026994)
jdedourek (reporter)
2014-11-07 18:23

I am trying to work out a set of test scripts for locating regressions in opensim by using git bisections. This seemed like a reasonable but to work on because it is marked "major", is repeatable, and no one seemed to be working on it. The bisection procedure identified commit

ecb759c Fix regression where llGiveInventory() had stopped asking non-owner receivers to accept/decline.
(0026999)
jdedourek (reporter)
2014-11-13 16:52

A new, very interesting data point:

According to the discussion above, inventory folders given by a scripted object to an avatar are handled by a taskinventoryoffered/taskinventoryaccepted/taskinventorydeclined sequence. Whereas, inventory folders given by an avatar to an avatar are handled by a inventoryoffered/inventoryaccepted/inventorydeclined sequence.

Using the latest master (r/25443) I found the following:

If a scripted object offers a folder named #RLV/~test01 to an avatar, the server moves the folder to the #RLV folder but the client does NOT subsequently rename the folder from #RLV/~test01 to ~test01. This is not the desired behaviour.

If an avatar offers a folder named #RLV/~test01 to an another avatar, the server moves the folder to the #RLV folder and the client subsequently DOES
rename the folder from #RLV/~test01 to ~test01. This IS the desired behaviour!!!!!

Conclusion: there is a subtle difference in the code handling taskinventoryoffered and inventoryoffered EITHER in the client (firestorm) or the server (opensim).

I do not intend to delve into the client code (at least for the present). Therefore my next step is to carefully examine the code handling taskinventoryoffered and inventoryoffered in opensim to try to identify a difference.

Any tips or pointers will be appreciated.
(0027000)
wbalazic (reporter)
2014-11-13 18:49

It actually performs the same in Firestorm or Singularity, so we suspect that it's not a client side issue with RLVa. This "did" work properly prior to 0.7.4 release from the Opensimulator.org website distribution. Something changed at that release that broke this functionality.
(0032450)
Lotek (reporter)
2017-11-16 19:41
edited on: 2017-11-16 20:46

Bumping as this is still broken in all RLVa viewers, most notably Firestorm and Singularity. Bug does not happen with 'vanilla' RLV viewers such as Kokua uses.

llGiveInventoryList(kAvi, "#RLV/~myfolder", ["item1", "item2"]);

RLVa results (incorrect):
#RLV
   #RLV/~myfolder
      item1
      item2

RLV results (correct):
#RLV
   ~myfolder
      item1
      item2

RLV folder creation notes:
http://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI#Shared_Folders [^] (scroll to "Accept sub-folders given via llGiveInventoryList() into the shared folder :")

RLVa folder creation notes:
http://catznip.com/index.php/RLVa_/_RLV_Differences#Give_to_.23RLV_Folder_Depth_.26_.23RLV_Folder_Creation [^]

(0032451)
UbitUmarov (administrator)
2017-11-17 12:45

scary issue history...
this seems a problem easier to debug from viewer side, Actually RLV dev side.
like already said, would be nice rlva telling us " you are doing this, and we need you to do that, and that will not impact rest of operations"

Contrary to original goals, exact clone of LL services is no longer our goal.
In many cases because we just can't.
(0032452)
UbitUmarov (administrator)
2017-11-17 12:56

What I said does not mean we will not go on fixing main features we should had working years ago...
Just now we do consider limits on that.
(0032453)
melanie (administrator)
2017-11-17 13:23

If this isn't a necrobump, what is? ;)

- Issue History
Date Modified Username Field Change
2012-09-21 03:42 wbalazic New Issue
2012-09-21 17:14 justincc Note Added: 0022655
2012-09-21 17:14 justincc Assigned To => justincc
2012-09-21 17:14 justincc Status new => feedback
2012-09-21 17:19 justincc Assigned To justincc =>
2012-09-21 21:00 wbalazic Note Added: 0022664
2012-09-21 21:00 wbalazic Status feedback => new
2012-09-24 17:04 justincc Note Added: 0022686
2012-09-25 07:46 stella Luna Note Added: 0022687
2012-09-25 08:25 wbalazic Note Added: 0022689
2012-09-25 08:37 wbalazic Note Edited: 0022689 View Revisions
2012-09-25 10:21 melanie Note Added: 0022690
2012-09-25 11:10 justincc Note Added: 0022691
2012-09-25 11:28 wbalazic Note Added: 0022692
2012-09-25 12:15 melanie Note Added: 0022693
2012-09-25 12:19 wbalazic Note Added: 0022694
2012-09-25 12:27 melanie Note Added: 0022696
2012-09-25 13:26 wbalazic Note Added: 0022697
2012-09-27 02:40 stella Luna Note Added: 0022702
2012-09-27 03:03 wbalazic Note Added: 0022703
2012-09-27 03:30 melanie Note Added: 0022704
2012-09-27 06:17 wbalazic Note Added: 0022705
2012-09-27 06:38 stella Luna Note Added: 0022706
2012-09-27 07:28 wbalazic Note Added: 0022707
2012-09-27 12:14 stella Luna Note Added: 0022709
2012-09-27 12:15 stella Luna Note Edited: 0022709 View Revisions
2012-09-27 12:17 stella Luna Note Edited: 0022709 View Revisions
2012-09-27 12:18 stella Luna Note Edited: 0022709 View Revisions
2012-09-27 16:05 stella Luna Note Added: 0022712
2012-09-27 16:06 stella Luna Note Edited: 0022712 View Revisions
2012-09-27 16:11 melanie Note Added: 0022713
2012-09-27 17:39 wbalazic Note Added: 0022715
2012-09-27 17:40 wbalazic Note Edited: 0022715 View Revisions
2012-09-28 03:01 stella Luna Note Added: 0022718
2012-09-28 03:01 stella Luna Note Edited: 0022718 View Revisions
2012-09-28 09:11 stella Luna Note Added: 0022722
2012-09-28 09:13 stella Luna Run Mode Grid (1 Region per Sim) => Standalone (1 Region) , Grid (1 Region per Sim)
2012-09-28 09:13 stella Luna Environment .NET / Windows64 => Mono / Linux32, .NET / Windows32, .NET / Windows64
2012-09-28 10:13 wbalazic Note Added: 0022723
2012-09-30 09:12 stella Luna Note Added: 0022753
2012-09-30 09:14 stella Luna Note Edited: 0022753 View Revisions
2012-09-30 09:16 melanie Note Added: 0022754
2012-09-30 09:17 stella Luna Note Edited: 0022753 View Revisions
2012-09-30 09:23 stella Luna Note Added: 0022755
2012-09-30 09:26 melanie Note Added: 0022756
2012-10-02 08:54 wbalazic Note Added: 0022773
2012-10-02 12:12 melanie Note Added: 0022774
2012-10-02 13:07 wbalazic Note Added: 0022775
2012-10-02 13:08 wbalazic Note Edited: 0022775 View Revisions
2012-10-02 13:30 melanie Note Added: 0022776
2012-10-02 13:44 justincc Note Added: 0022777
2012-10-02 13:54 wbalazic Note Added: 0022778
2012-10-02 13:57 wbalazic Note Edited: 0022778 View Revisions
2012-10-02 13:59 justincc Note Added: 0022779
2012-10-02 14:01 wbalazic Note Added: 0022780
2012-10-02 14:06 melanie Note Added: 0022782
2012-10-02 18:32 justincc Note Added: 0022792
2012-10-02 20:50 wbalazic Note Added: 0022793
2012-10-03 05:28 melanie Note Added: 0022794
2012-10-05 18:49 justincc Note Added: 0022803
2012-10-05 18:50 justincc Note Edited: 0022803 View Revisions
2012-10-05 18:54 justincc File Added: LL-TaskInventoryOffered-and-reply.txt
2012-10-05 18:54 justincc File Added: opensim-TaskInventoryOffered-and-reply.txt
2012-10-09 17:28 justincc Status new => feedback
2012-10-15 12:33 danbanner Relationship added related to 0006360
2012-11-02 12:01 wbalazic Note Added: 0022996
2012-11-02 12:01 wbalazic Status feedback => new
2012-11-02 13:48 wbalazic Note Added: 0022997
2012-11-02 23:17 wbalazic Note Edited: 0022996 View Revisions
2012-11-06 16:29 justincc Note Added: 0023028
2012-11-06 16:54 melanie Note Added: 0023029
2012-11-07 01:29 wbalazic Note Added: 0023030
2012-11-10 00:38 dirk mathers Note Added: 0023064
2012-11-12 20:23 justincc Note Added: 0023110
2012-11-13 00:32 melanie Note Added: 0023111
2012-12-05 14:15 dirk mathers Note Added: 0023198
2012-12-05 14:18 wbalazic Note Added: 0023199
2012-12-05 14:19 wbalazic Note Edited: 0023199 View Revisions
2012-12-05 14:28 dirk mathers Note Added: 0023200
2012-12-07 18:14 justincc Note Added: 0023212
2012-12-07 18:14 justincc Note Edited: 0023212 View Revisions
2012-12-11 21:04 dirk mathers Note Added: 0023224
2014-11-07 18:23 jdedourek Note Added: 0026994
2014-11-13 16:52 jdedourek Note Added: 0026999
2014-11-13 18:49 wbalazic Note Added: 0027000
2017-11-16 19:41 Lotek Note Added: 0032450
2017-11-16 20:46 Lotek Note Edited: 0032450 View Revisions
2017-11-17 12:45 UbitUmarov Note Added: 0032451
2017-11-17 12:56 UbitUmarov Note Added: 0032452
2017-11-17 13:23 melanie Note Added: 0032453


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker