Get the Timestamp of the owner changed

[Avalon Criss]

Hi all,

Is it possible get the date timestamp, in order to know when an avatar has become owner of the object?

I think of that because I'm serching a method to deactivate scripts after a period from purchease date, but avoiding need of database service of a third party vendor system.

Have you any suggestion?

 

[Wulfie Reanimator]

the Changed event triggers on CHANGED_OWNER.

[Qie Niangao]

Note that script events won't fire until the object is rezzed which could be arbitrarily long after purchase. That's usually better for such things, but not literally compliant with the stated "purchase date" requirement. Also of course scripts can be reset in Modify objects (regardless of the script itself being no-mod), which could prevent expiration unless special measures are taken in the script.

[Avalon Criss]

Thanks for reply,

it's exactly the problem I face.  The script will fire only when rezzed, so it can print the date of first utilization and store it as protected key (and check its presence  coupled with another preinstalled key I set, to recognize reset or delete attempts and promptly freeze the script). This could be ok for my purpose, but there is a problem if the object have copy perm, as the buyer can always rez a new copy without rez the first delivered copy from his inventory.. and the license will never expire.

The only way to get the timestamp of changed owner is through a vendor system? 

Maybe is there a method to import directly in world (without using an external server as a bridge) the data provided by SL in .csv file history transaction?

Edited February 27, 2023 by Avalon Criss
minor correction

[Quistess Alpha]

Hmm, yes if you wrote a custom vendor, you could llEmail() it (or a permanent prim in a secure location that had been communicated with) if you don't have the timestamp.

I think it ~might be theoretically possible to scrape marketplace (MP) info if the prim can 'log in' as the creator to the MP, but I don't know if LSL is sophisticated enough to make that kind of http transaction.

[Qie Niangao]

If you're already using a commercial vendor system then… well, it would depend on that system and how easy it is to access its API from in-word scripts.

But if you're selling the items with your own "vendor" then sure, you can store the sales in your own vendor (a variety of places to put it, including LinksetData for up to 64K of persistence, or in Experience Key-Value-Pair which gives lots more space, but it needs an Experience, and you'd still want to weigh that capacity with the future market for whatever the products are you're selling.

But then there's the problem of communicating between the product and your sales record. The product will need an immutable address to contact, and that's hard to come by directly.  (An email address lasts only as long as the prim containing the email-reading script stays rezzed; http addresses change with every region restart.) There are various registry services to keep track of new addresses, but there's nothing standard.

(Quistess posted while I was typing, but I don't think there's too much overlap in our responses. I never even thought about Marketplace sales; that's a twist that probably most sellers would really want to support somehow.)

[Quistess Alpha]

Thinking on it a bit more, the easiest 'hack' for the MP would be to set up a no-copy 'voucher' item similar to how some gachas worked: you buy the voucher on the MP, then when you rez (but not attach, the script needs to prevent that) the voucher, it emails the in-world vendor and deletes itself when the vendor responds (preferably via http). The vendor then acts as it would if the voucher's owner had bought the item with L$.

[Avalon Criss]

Nice idea. A post activator that will delete itself could be the easiest solution. Meanwhile the script print the timestamp as protected key in the Linkset Data, to begin the period countdown.

Thanks for your suggestions

[primerib1]

15 hours ago, Quistess Alpha said:

Thinking on it a bit more, the easiest 'hack' for the MP would be to set up a no-copy 'voucher' item similar to how some gachas worked: you buy the voucher on the MP, then when you rez (but not attach, the script needs to prevent that) the voucher, it emails the in-world vendor and deletes itself when the vendor responds (preferably via http). The vendor then acts as it would if the voucher's owner had bought the item with L$.

Why not allow it to attach? on_rez fires on attachment as well?

Unless I'm missing something here...

[Wulfie Reanimator]

5 hours ago, primerib1 said:

Why not allow it to attach? on_rez fires on attachment as well?

Unless I'm missing something here...

I think what she's going for is using llDie in a rezzed object. That would permanently delete the (no-copy) rezzed voucher, but won't do anything in attachments.

[Quistess Alpha]

7 hours ago, primerib1 said:

Why not allow it to attach? on_rez fires on attachment as well?

1 hour ago, Wulfie Reanimator said:

I think what she's going for is using llDie in a rezzed object. That would permanently delete the (no-copy) rezzed voucher, but won't do anything in attachments.

Exactly. There are plenty of ways of handling a "Sorry, I have already been used" state, and I guess with linkset data that's even easier to do "securely", but just being absolutely sure the object is destroyed with llDie seems the least "messy".

[Avalon Criss]

Yes, the object attached will not delete itself after sent activation code, because llDie has no effect if called from attachment.

I solved with

if (llGetAttached() == 0){

as arbitrary check before sending the activation code.

Then it wait response of activation done before llDie.

[Avalon Criss]

On 2/28/2023 at 4:04 PM, Wulfie Reanimator said:

I think what she's going for is using llDie in a rezzed object. That would permanently delete the (no-copy) rezzed voucher, but won't do anything in attachments.

I made some test and I noticed the rezzed activator will send code and receive response both, if the product to activate is rezzed or even if attached as hud