Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-28 12:37:43



Reply to topic  [ 30 posts ]  Go to page Previous  1, 2, 3  Next
The @putinv command 
Author Message

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Satomi Ahn wrote:
Are you serious about RLV < 1.13?
Does that make sense trying to be compatible with versions of RLV that do not support @putinv in the first place?

Yes, it makes sense since users might well want to use items given to them by @putinv by a new device together with another, older device not allowing second level sub-folders attachment...

It's one of the gold rules of good programing: when you can maintain upward compatibility, you must maintain it: your users will be thankful for that, believe me.


2009-03-18 17:06:27
Profile WWW

Joined: 2009-03-18 09:41:54
Posts: 23
Reply with quote
Excuse me if I am being insistent, but here you don't really lose compatibility. This only concerns forced put items, items you don't expect to be there, not items you purposedly placed into #RLV which are still where you want them to be. Nothing prevents you afterwards to take the steps for making a forced put item available to old devices.

Other point: if you're trying to keep your inv in a form that will be usable by old devices, you definitely don't want it to be cluttered by a bunch of ~* folders in your shared root! (well, they are at the end of the list at least, so it is not that bad)


2009-03-18 17:20:38
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Satomi Ahn wrote:
I am lost here. Are you saying you want to be compatible with versions of RLV that do not support @putinv in the first place?

I simply say that if you put a new sub-folder in #RLV thanks to @putinv, even "old" RL devices should be able to list that sub-folder in their menu (and consequently also be able to @attach), which is only possible for the first level sub-folders.


2009-03-18 23:08:29
Profile WWW

Joined: 2009-03-18 22:58:33
Posts: 2
Reply with quote
Hi :) My first post hehe. Hope you dont mind me sticking my two cents in. I have been dearly waiting for this command, I have the perfect genie bottle project that will use it.

I would like to second Satomi's idea of placing all the forced folders into one common folder under the RLV main folder. I see many benefits, the first being a great way to disable the putinv function. New users are already confused by RLV, adding in client viewer debug setting can make it plain impossible to help a young AV. I am certainly not looking forward to explaining the debug options. Instead, maybe, if the force folder is there, then force is allowed. If its not there, force is not allowed. Exactly the same way the current RLV folder functions with the RLV inventory commands.

Another advantage, as stated earlier, would be the ease of tracking forced inventory. Easy to identify, easy to delete, easy to filter.

But the advantage that I think will matter most is what happens when a device tries to force a folder that already exists. Currently the command fails, that makes perfect sense. We dont want inventory being deleted from people without their consent. But what happens when you encounter a new version of a device and you already have a folder from the old version? It will fail on the inventory give and then force wear the old folder, which may contain items that are no longer compatible. Using a separate folder for all forced inventory folders will allow devices to overwrite their earlier folders without fear of harming an AVs 'real' inventory.

I am just thinking that for my project, I plan on adding lots of features later to the device that you are forced to wear. I would hate to have to add to the clutter by forcing separate folders, named differently, for each version of the product. That could quickly become insane when thinking about all the devices in SL.

Thanks for reading :)

Kinki


2009-03-18 23:29:22
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Kinki Vacano wrote:
Hi :) My first post hehe. Hope you dont mind me sticking my two cents in. I have been dearly waiting for this command, I have the perfect genie bottle project that will use it.

I would like to second Satomi's idea of placing all the forced folders into one common folder under the RLV main folder. I see many benefits, the first being a great way to disable the putinv function. New users are already confused by RLV, adding in client viewer debug setting can make it plain impossible to help a young AV. I am certainly not looking forward to explaining the debug options.
Instead, maybe, if the force folder is there, then force is allowed. If its not there, force is not allowed. Exactly the same way the current RLV folder functions with the RLV inventory commands.
Please, do not focus on the current debug setting. For now, @putinv has been implemented as a preliminary feature, and, as some concerns have been raised about (theoretical) security issues, I implemented this setting so that @putinv could be disabled (and it is actually disabled by default, but for Boy Lane's Windoze build of the Cool SL Viewer: I can't force her to use unmodified patches, and how much I'd like to spank her for doing such naughty changes without my approval, we don't live close enough to each other for this to happen either... :D ).

Once the code for @putinv will have matured enough and once Marine will have adopted it in her own patch, then the debug setting shall go away and @putinv shall be a permanent feature. And even should it be decided that it should still be possible for the users to disable @putinv, I'd simply add a new check box to the "Cool features" tab, under the Restrained Life one...

Quote:
Another advantage, as stated earlier, would be the ease of tracking forced inventory. Easy to identify, easy to delete, easy to filter.

I tend to differ strongly with this view... Please see my earlier posts in this thread...

Quote:
But the advantage that I think will matter most is what happens when a device tries to force a folder that already exists. Currently the command fails, that makes perfect sense.
No, it does not... You can give as many folders as you wish with the same name.

Quote:
We dont want inventory being deleted from people without their consent. But what happens when you encounter a new version of a device and you already have a folder from the old version?

Good question, and I will have to test this.. But if you give first "~genie_bottle/genie hat v1.00" and later "~genie_bottle/genie hat v2.00", I think you should be able to attach "~genie_bottle/genie hat v2.00", even with v1.00 still there in another "~genie_bottle" folder... I'll test it... tomorrow. Bedtime now for me !

Anyway, putting the two folders inside another sub-folder like suggested by Satomi would not change a thing...

Quote:
It will fail on the inventory give and then force wear the old folder, which may contain items that are no longer compatible. Using a separate folder for all forced inventory folders will allow devices to overwrite their earlier folders without fear of harming an AVs 'real' inventory.

NEVER !... This has been made VERY clear by Marine in her license.

Citation:
Quote:
- Not include code that would mess with the money, password, assets or personal data of the user. This means the RLV does not and will never send your IMs to whatever third-party object or server, log your password, force you to send money to something or someone, or delete your inventory items.


Kinki Vacano wrote:
I am just thinking that for my project, I plan on adding lots of features later to the device that you are forced to wear. I would hate to have to add to the clutter by forcing separate folders, named differently, for each version of the product. That could quickly become insane when thinking about all the devices in SL.

What I think is "insane" is to give away different versions of a product and not name them differently... How do you want users to know which is the good version (and BTW, sometimes the good version is not the latest, because of a new bug in the latter).

Also, with the method you suggested (overwriting folders), what if a user interacts with two different versions of the same device and they overwrite each other's folder ?... If the user uses the older version last, they end up with old deprecated stuff that overwrites the latest version... No good.


2009-03-19 00:24:40
Profile WWW

Joined: 2009-03-18 22:58:33
Posts: 2
Reply with quote
Henri Beauchamp wrote:
Please, do not focus on the current debug setting.

But having a way to disable that feature makes perfect sense and should be included, for exactly the same reason I can still use RLV and not have an RLV folder.

Quote:
Quote:
Another advantage, as stated earlier, would be the ease of tracking forced inventory. Easy to identify, easy to delete, easy to filter.

I tend to differ strongly with this view... Please see my earlier posts in this thread...

I know :P But, me, as a user, not technically inclined in programming, the folder makes sense. If the folder is there, then all the stuff goes in it. If it not there, then I dont receive folders of items.

Quote:
Quote:
But the advantage that I think will matter most is what happens when a device tries to force a folder that already exists. Currently the command fails, that makes perfect sense.
No, it does not... You can give as many folders as you wish with the same name.

Ok, I asked Boy last night, she said it failed.

Quote:
Quote:
It will fail on the inventory give and then force wear the old folder, which may contain items that are no longer compatible. Using a separate folder for all forced inventory folders will allow devices to overwrite their earlier folders without fear of harming an AVs 'real' inventory.

NEVER !... This has been made VERY clear by Marine in her license.

Citation:
Quote:
- Not include code that would mess with the money, password, assets or personal data of the user. This means the RLV does not and will never send your IMs to whatever third-party object or server, log your password, force you to send money to something or someone, or delete your inventory items.


But the @putinv command violates that license as it stands now...

'- Not include code that would mess with the money, password, assets or personal data of the user.'

You are altering a persons assets by forcing them to receive assets. The exact same is true for the @autoaccept command that is currently in RLV. I guess the rule is a bit more hazy then the license states.

But segmenting the asset alterations, and any alteration is completely against the license as you indicated, then at least you should limit it to one very specific predictable folder.

Quote:
Kinki Vacano wrote:
I am just thinking that for my project, I plan on adding lots of features later to the device that you are forced to wear. I would hate to have to add to the clutter by forcing separate folders, named differently, for each version of the product. That could quickly become insane when thinking about all the devices in SL.

What I think is "insane" is to give away different versions of a product and not name them differently... How do you want users to know which is the good version (and BTW, sometimes the good version is not the latest, because of a new bug in the latter).

But that is exactly the point, the user should not have to know the latest version, or have to suffer from have tons of copies of items build up in inventory. It should just work for them. And this might be more about compatibility between objects then it is about the actual 'good' version hehe.

Quote:
Also, with the method you suggested (overwriting folders), what if a user interacts with two different versions of the same device and they overwrite each other's folder ?... If the user uses the older version last, they end up with old deprecated stuff that overwrites the latest version... No good.

Well, that is the same problem regardless, even with different devices that wish to attach objects on the same attach point. In these cases, the onus falls on the device makers to negotiate that.

Thanks so much for the reply Henri. I just want to add that I love discussing RLV :) and I am not fighting you or pushing you, just debating about a feature that I would love to see. And to be honest I dont much care about the overwriting really because there are many ways around it and it was based on the premise that a second folder would fail (which you say is not correct). But the work arounds can clutter inventory, so that needs to be weighed in as well.

Kinki


2009-03-19 01:12:20
Profile

Joined: 2009-03-25 20:55:42
Posts: 4
Reply with quote
Quote:
I know :P But, me, as a user, not technically inclined in programming, the folder makes sense. If the folder is there, then all the stuff goes in it. If it not there, then I dont receive folders of items.


This I can understand, and it makes sense to a degree - but it does require new users to explicitly setup that folder - and the ones that just don't get it are rather large. RLV, even just installing the viewer, is already challenging enough for users. The benefits of a putinv in my opinion far outweigh the potential disadvantages. If a special folder is used, it should be created on demand as needed (along with the parent #RLV folder.) I strongly believe such limits should be in the relay implementation and not in the viewer. If you don't like certain behavior, use a relay that filters that behavior.

Quote:
Quote:
Quote:
But the advantage that I think will matter most is what happens when a device tries to force a folder that already exists. Currently the command fails, that makes perfect sense.
No, it does not... You can give as many folders as you wish with the same name.

Ok, I asked Boy last night, she said it failed.

Multiple folders with the same name are allowed in inventory, so this is an issue with implementation. That said, behavior in that case would be unpredictable. Any device that does a Put should check to see if that folder already exists before sending another copy. Version numbers are the right answer too to ensure the proper version is in inventory. Don't forget that folder name collision between different scriptor's items is a very real and likely scenario (see below.)
Quote:
Citation:
Quote:
- Not include code that would mess with the money, password, assets or personal data of the user. This means the RLV does not and will never send your IMs to whatever third-party object or server, log your password, force you to send money to something or someone, or delete your inventory items.

But the @putinv command violates that license as it stands now...

'- Not include code that would mess with the money, password, assets or personal data of the user.'

You are altering a persons assets by forcing them to receive assets. The exact same is true for the @autoaccept command that is currently in RLV. I guess the rule is a bit more hazy then the license states.

But segmenting the asset alterations, and any alteration is completely against the license as you indicated, then at least you should limit it to one very specific predictable folder.


Technically you are correct, BUT, it's pretty clear that the intent is about LOSS of assets - deleting, transferring away, etc. (and that intent is listed in your citation specifically.) After all, the EXISTING code makes changes to assets by renaming them if permissions allow, adding attachment point info. Perhaps Marine would be willing to clarify that intent here or in the license?

Quote:
But that is exactly the point, the user should not have to know the latest version, or have to suffer from have tons of copies of items build up in inventory. It should just work for them. And this might be more about compatibility between objects then it is about the actual 'good' version hehe.


Ahh - but how do you know if a folder in the PUT folder is one from YOUR project, or someone elses? I could definitely see cases where there is more than one folder named "Latex Doll". Perhaps the user ALREADY had a newer version of the items, but YOUR copy of the device was older and is handing out OLD items?

No, sorry, something given via @putinv should never ever EVER cause asset to be deleted. Users just have to clean their inventory manually like they already do with notecards, pictures, landmarks, etc. The potential of losing a valuable item is just too great.

A user would never have to worry about versions. If the version number is in the folder name, the device would attach the correct version. With version numbers increasing, it would be obvious to the user which ones could be deleted. Deleting any asset should be the sole domain of the user and never an automatic thing via RLV code.

A prefix registry for folder names (on a wiki somewhere) would help mitigate folder name collision (I would prefix all my stuff via SC_ for example,) but you can't count on people to follow it. Unique Content creator prefixes along with version numbers solves all these issues. In fact, if the existing implementation is maintained (where it just refuses to overwrite an existing folder) that solves a number of issues and makes the device code easier (it doesn't have to check for existing folders of the same name.) It also prevents a build up of TONS of items since the exact same item would not be duplicated (think of all the copies of the RR HUD for example...)

In defense of the special put folder idea, the chances that a user will ALSO want to use those items with older scripts that are not subfolder-aware are rather slim. In those cases, moving them to the parent #RLV folder manually is an easy enough thing to do. It also reduces further the potential name collision with existing items.


2009-03-26 15:28:48
Profile

Joined: 2009-03-18 09:41:54
Posts: 23
Reply with quote
Some wild (maybe good or bad :p) ideas:
- writing the UUID of the object in the folder name
- (auto)deleting the folder on @clear (could be disable-able if you want to keep the folder for future utilization)
- instead of deleting: moving into another subfolder ".old". If you want to use the folder again, just move it back to where you want.

Writing the UUID would allow to safely (re)move folders.
But that wouldn't work for versioning, as the new version of the object will likely be a new object (different UUID).


2009-03-26 17:22:14
Profile

Joined: 2009-03-25 20:55:42
Posts: 4
Reply with quote
Satomi Ahn wrote:
Some wild (maybe good or bad :p) ideas:
- writing the UUID of the object in the folder name
- (auto)deleting the folder on @clear (could be disable-able if you want to keep the folder for future utilization)
- instead of deleting: moving into another subfolder ".old". If you want to use the folder again, just move it back to where you want.

Writing the UUID would allow to safely (re)move folders.
But that wouldn't work for versioning, as the new version of the object will likely be a new object (different UUID).


Interesting idea, but It would be preferable to use the uuid of the creator (not owner though) as a suffix to the foldername: myjunk-v42-[insanly long uuid]. Then, at least, if you are a frequent user of object X (Jackie's teddy handing out leashers) you don't end up with 9134554 copies of the same object. That said, I don't think the creator info is exposed to the viewer during an asset transfer, which kills my alternative *pouts*. You would have to do it by convention in the scripts using it (yucky.)

Furthermore, a single object could, based on what it detects about the victim, send DIFFERENT inventory (avatar height, capability, etc.) or different items based on device operator choices (black latex doll, pink, etc.) A device may also send several folders at different points in time as part of a larger experience (jackie's teddy give a prison uniform at one stage, a gag at another...)

Again, not a fan of deleting inventory, even if you (your object) was the one that gave the items. I just don't see a need. It also senselessly recreates items in your inventory that you already have - over and over if you re-use the device, and adds load to the already-overloaded asset servers. It really would be "best practices" to see of the item already exists in the user's inventory before sending it again (@findfolder?)

Renaming has issues. If they sit on an object the second time and get the same stuff again, do you have .old.old? Eventually ending up with .old.old.old.old.old....??


2009-03-26 20:04:55
Profile

Joined: 2009-03-18 09:41:54
Posts: 23
Reply with quote
Sorry, I wasn't clear.
It is not renaming, I suggested, but really moving. ("Latex Doll"->".old/Latex Doll")


2009-03-26 22:36:08
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 30 posts ]  Go to page Previous  1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.