Jump to content

Nickel Briand

Resident
  • Posts

    29
  • Joined

  • Last visited

Everything posted by Nickel Briand

  1. It looks there is a nuance between the information shown on the viewer and the information shown on the account page . Actually , my account page tells "payment info on file" http://snag.gy/OkZoV.jpg But if i look the viewer , it tells "no payment info". http://snag.gy/6NxWu.jpg If i do a script , it tells neither "payment info on file" , neither "payment info used" http://snag.gy/TYkvO.jpg I know i have done several manipulations on my account in the past : i ve added billing information while a moment , cahnged it , remove it , added again etc ... etc .. May someone explain to me the nuance and what are the exact definitions between the three comportments ?
  2. You should give up this script and use the event transaction_result : http://wiki.secondlife.com/wiki/Transaction_result and the function llTransferLindenDollars http://wiki.secondlife.com/wiki/LlTransferLindenDollars
  3. Bad instance . Firstly , in your instance , the seller knows who is the buyer and who would be the receiver . If the object is copy/mod/no transfert , he can easily and without risk resend his item if it fails . Indeed , what is the difference between the case where the receiver receives the gift and does a copy , and between where the receiver receives the gift twice ? None . The selloe has necessary some logs about the transaction and about the name of the avatar who must receives the gift . Do the seller can verify if there is complain , that someone doesn t try to earn a gift without have paid it. The problem is only for no copy / no transfert iterms . These items are less frequent because they interest less the users Secondly, your instance is unrreal . Never someone will spend money to make a gift to someone when the other is offline . Why ? Because the receiver , when he will log in , and if his hims are not capped , will receive the object without message certificating that this object is sure . The message is "nameof object wants to give you nameoftheobjectgifted". The name of the sender object may be easily modified by a giefer to tell "the super hipy shop wants to give you the super object 10000l$ worth value" And this risk that the reciever will refuse your item , is higher and more frequent that to have his ims capped And, because the receiver can t trust to accept items from people he doesn t know , he will refuse . So the buyer won t take the risk to give a gift when the other is offline . By my experience , i have never seen around me someone giving a gift when the other is offline ( except noobs ) Always the gifts were online
  4. I am trying to upload a mesh with 2730 faces , 3759 vertexes. at high details I know in some other models , it has worked . But with this one , i have this curious message "The model exceeds 4000 instances." after calculating weights What does it mean ? What i need to change exactly to be able to uload it ?
  5. I know this , but you read the half of words "If destination is an avatar that refuses to accept it (by manual decline or muting), is in busy mode, or is offline with instant messages capped, it is not returned to the prim's inventory; it is deleted." So your method to give inventory in checking if they are online by llrequestagentdata is wrong . Because people can be busy and it will fail Because the refresh of the status online has not been done , and it will fail And if you want to ckeck the busy status , the script needs to be in the same prim that the avatar A better and sure method is that user requests explicitelly ( by script , hud, attachemen,manually or else ) he wants the new item , so you don t need llrequestagendata.
  6. Innula Zenovka has wroten "However, that is not a great deal of help if you are trying to deliver objects in SL, where the problem most certainly exists." But the cap is on the function llgiveinventory . There is no link with llrequestagentdata . To check if this someone is online by llrequestagentdata is wrong. Because if you log off in an another sim , you will be online for the other sims while 10 minutes . So you can loose inventory too. Zanara Zenovka has wroten "Maybe try some item deliveries in SL using various methods and get back to us." But there are some existing . For instance , a client-server method where the client contacts by http the server , and gives the uuid of the avatar . The server answers and gives the inventory
  7. Look this answer of melani in openimulator http://opensimulator.org/mantis/view.php?id=4528 " The recipient doesn't receive a message, but does indeed receive the item. In that way, it's consistent with SL when IMs are capped, because capping can also cause the dialogs to be lost in SL, but delivery as such still works. " So your problem doen t exist because of the online indicator Anyway , this method with status online doesn t work , because for the dataservives , the users can be online , but in reality they are offline . And the delay is generally of several minutes . Put an offline detection who records the hour of logoff in a first sim ; put the same scipt in an aonther sim ; log off from here ; log in ; displays the records ; the records will be different Even in the best comportment , the sim caches 60 seconds the status ( by configuration of the sim , cf Maestro ) So , your method fails anyway
  8. Bad scriptings is to abuse some ressources who are limited as the dataservices when you can replace them with other solutions as http . Http is scalable , llrequestagentdata is not You forget too that llrequestagentdata has met some issues when the online indicator could be refreshed only after 10 minutes !!!! ( check the wiki or https://jira.secondlife.com/browse/SVC-6831? ) And you are daring to joke about http failures ??? Even in the best cases , the online status is not refreshed from the sim to the dataservices immediately ; what your scripts do when the dataservices tell that the user is online , but the sim tell he is offline ? It s a lot of bugs . Http doesn t need this refreshing , so they work hugely better For your instance of volunnter , you check if the voulunters are online , but your forget to check if they are available , if they have free time to spend for help . Normally , it s up to the volunteers to give an information to your device "yes, now , i can help" . Not in the other way . That s why Http will owns always llrequestagentdata
  9. "However it's going to break a lot of systems and make your SecondLife potentially unpleasant. Delivery systems rely on this information to know if it's safe to send items to you. Game systems use it to check if you potentially left the game. As LL implement those new game related features i could see a lot more systems doing online checks." It w wrong ; firstly because it can be easily replaced by other ways more secure . Secondly because if these scripts use llrequestagentdata, then they are badly coded. A delivery system works even when the user is offline ; basic instance : default{ state_entry() { llSetTimerEvent(10.0); } timer() { llRequestAgentData(llGetOwner(), DATA_ONLINE); } dataserver(key queryid, string data) { // gives the script only when the owner is offline if (data == "0") { llGiveInventory(llGetOwner(), llGetScriptName()); llSetTimerEvent(0.0); } } } ( tested in http://maps.secondlife.com/secondlife/Magnum%20Sandbox%203/29/126/34 ) So the object arrives to the user ( after he has rezzed of course ) Even if we are guessing they need it , merchants don t need to be able to give inventory to 30 000 000 accounts because their group is maybe 10 000 or 20 000 members . A status online limited to one group is more than enough A game to know if the player has left, shouldn t check llrequestagentdata, but should check llGetAgentSize or llGetObjetDetails on the avatar to know it . Because these last functions return a value when the player is online AND is in the same sim of the game . And a bug majoriy of games can t work when the player is outside the sim http://wiki.secondlife.com/wiki/LlGetAgentSize They are very few use cases who are grid wide . And even for use cases who are grid wide , you shouldn t use llrequestagentdata but you should check some http/urls of prims ( for instance huds , or bdsm collars ) And even the bords with online status don t need to be able to check 30 000 000 users but only the owner Never i have used llRequestAgenData(data_online) in my scripts except to check the status of the owner only . Scripters who do it are bad scripters To add , llrequestagentdata(online) is laggy for the whole grid , because the dataservices are centralized ; to find some alternatives solutions at the level of the sim is maybe laggy for the sim but doesn t impact the other sims
  10. Weird message . What is your browser ? Personnaly i go to this page http://secondlife.com/support/downloads/ whith my broser ( internet explorer or chrome ) and it works fine
  11. "To be fair, those tags weren't terribly reliable anyway; seems the vanity colors also screwed with the ability to correctly detect viewers. V2 was never detectable as such." You right ! For instance on opensim , with one last version updated of TPV , only 2/14 viewers are correctly named ... so less than 15%
  12. Relogging in switching the viewers may cause you more various issues . Textures , Inventory , and objects caches don t work in the same way in v1 and v2 . But for the initial problems you had , i guess you have some network issues . Are you in Wi-Fi ? Have you ckecked your packet loss in the summary at the bottom of your logfile ? ( or at the bottom of your hep/about menu) For the head sizes , it s weird . Except something who would has changed your installtion directory ( as the files avatar*llm ) i have no other idea
  13. You may easily with this : - to know my hours of work - to know when i am in holiday It s already too much specifically if you are a detective agency , or if you are in my real network , but not in my second life network . But of course , specialist spiers will use other informations about the user and will do more crosschecks. Justice have given some proves and verdicts that to try to know the hours of connection by wifi on internet was strongly illegal . I don t see why it should be different To know when i log in and when i log off is not your business . It s the same thing with several softwares . You don t need to know when i turn on my computer when i turn it off . You don t need to know which viewer i use or which software is installed in my computer .t s not your business And several softwares have respected this choice ; skype respect this choice , msn respect this choice , ICQ respect this choice , IMVU respect this choice , Blue mars respects this choice and the list is long . Even this checkboxes in teh preferences of the viewer or in the web profiles should demontrate you that this was not a "paranoid" idea . If it was , why these options have been designed ? And the viewer ( any viewer ) are pushing to the confusion . A noob when he comes to second life sees some tabs about privacy , checks or unchecks them and he realizes later it s useless . It s a fault to let scripts work and give more power then the viewers . You have lied to him I have not agressed you , but you agress me in guessing my paranoia ? But should it mean than the whole internet users are paranoid , because users of other softwares have defended their privacy ? Are you sure that what you are thinking is not a thought of paranoia ? Don t worry about the X . I know where it is and i will use it certainly if and when i find it necessary . Sorry if you couldn t have my money and you will stay alone in your sim because you don t listen the other users After several posts , you have always refused to explain why you would need about my infos without my consent
  14. "It most certainly is my business if I bump into.....as I have done a number of times......a 'friend' who is showing as offline. And nobody can answer the one simple question.....why would anyone who isn't on friends list and who has never heard of you.... want to know if you are online anyway ??" It s because you refuse to read and to listen . You react emotionnaly , i don t know why One day , somebody has asked me my credit card number . Sincerly and honnestly i don t know why he was expecting with it . Maybe he had some excellent reasons . Maybe it was for an humanist and philantropic reason . But i have refused to given it . And it s my right, it s my freedom. Are you against the freedom ? If you are persuaded "there are no reasons that someone who isn't on friends list and who has never heard of you want to know if you are online anyway", so you admit we can delete this functionnality because it s useless, and because this delete has no consequences When there is an hole of security or a lack of privacy who exists , it s rationnal to prevent it . There is no need to read the thoughts of others , to investigate longly . But these others ( those who want to keep this function ) don t want to tell neither their reasons although they are more able than us to tell it And the only fact that people who are against the delete, or the restriction of this function , are not able too to answer to your question , are not able to justify their real need, make them suspicious about their activities And again .. Why emerald has stored the links between avatars and IPs of some people they have never heard of them ? Or why developerrs of Redzone has stored some passwords of users they have never heard of them ? Do you refuse the lessons of the past ?
  15. "You've lost me. Why would anyone who has never heard of you even want to know you are online ?" Good question .. why emerald has stored the links between avatars and IPs of some people they have never heard of them ? Or why developerrs of Redzone has stored some passwords of users they have never met ?
  16. Even if hadn t given my RL identity , i have created a social network around my avatar . Scripts don t belong to my social network . llRequestAgenData(uuid,DATA_ONLINE can threat it You complain i live as turtle , but it s exactly what you do , and better than me : you tell it s safer to not divulge your RL identity. You prefer to live in second life with only anonymous identities If you are trying to justify llRequestAgenData(uuid,DATA_ONLINE) only with the main idea "we are inside a social network , don t live hiden" , so you should , to keep logic , delete the IMS and oblige people to talk only in local chat . You should too delete all the options to mask some informations in the profile , because you want to oblige people to Ipublish informations even to everyone . And why to keep friendlists too ? it s useless if you obey to this idea "we are inside a social network , don t live hiden" And why to have groups , too , if we follow your idea ? I am sure it s not your goal . But it proves the weakness of your argue
  17. Social environnemnt mean to meet some people . But 99 % of the users who can scan me if i am online are neither friends , neither contacts , neither old contacts , neither some people who are in common groups , neither some people who i have met one day . So it s normal to forbid them to know it. Why they should ?
  18. If you were friend , you could add in your contact list . Even if you didn t add him , you could exchange your calling cards It was not the only way . You have told sooner you could check the online status with groups . And now you you tell that llRequestAgenData(uuid,DATA_ONLINE) was the only way So , ever you are a liar , ever you are an hypocrit
  19. 1) To mute don t protect. 2) Busy mode don t protect 3) Online in groups are protected by teh combination of 3 ways : - the user may hide his groups . - the groups may hide their users - the groups may be in closed subscription So the user user has the choice to publish or not publis his privacy in his groups . He has not this choice against llRequestAgenData(uuid,DATA_ONLINE) And nobody is obliged to use groups 4) To add: llRequestAgenData(uuid,DATA_ONLINE) is avaailable on teh whole user database of linden so 20 000 000 accounts . Generally the most active and largest groups have at the most 50 000 accounts . It s very limited compared to the 20 000 000 5 )To scan someone in a large group , takes several minutes , because there are no warranty it will scan the targetted peope at the first llRequestAgenData(uuid,DATA_ONLINE) takes 0.1 seconds , so it s easily repeatable and automating 6) You can t export without developping in C++ the viewer the results of your group scan . You may export easily by script the results of your scan , publish it in secoond life , and publish it too in the whole internet. ( any script may be a server web http accessed outside sl ) 7) you need to be online to use groups . You don t need to be online with llRequestAgenData(uuid,DATA_ONLINE) . Just a prim dropped in a sim is enough So llRequestAgenData(uuid,DATA_ONLINE) gives extremely more power than groups Delete this function
  20. Guys .... give up with your notebooks ; they can t handle SL . They never been able , so i don t see why they suddenly could . If you want to run at low graphics or to run under 15 FPS it s ok , but you will suffer big pains . And with sims with crowd , your computer will be often frozen And a GT220 can t handle high graphics , even on a desktop . They will run maybe 10 FPS at this mode Trust me , i have run SL on a notebook in the past
  21. Yahoo is unable to track someone online , and to know your connections hours to SL in a forced way even if you publish your web profile in the web. And the IP is not tracked on media on prims if you use only in-world URLS and don t use external URLS. Even if the IP is tracked by an external server , the external server can t know which avatar has called the page . Let s guess a griefer who puts a media on prim ; there are 30 people in the sim . After a moment he can see a call to his web server . He can know the IP published . But he doesn t know who between the 30 people has this IP To add , if the griefer wants to grief someone specifically , he must wait that his target will turn his media .. He will wait a long time . Maybe some hours , maybe some days , maybe never . And think too that for many people the IP adress is dynamic not static . Think too that some people can protect themselves by proxies too . With llRequestAgenData(uuid,DATA_ONLINE) , the griefer/spyer doesn t need to wait , and it a forced comportment . And there are no existing protection So your two points are not so critics , the user can decide himself to activate or descativate these features to increase his privacy . He has the freedom of the choice . It s not the case with lRequestAgenData(uuid,DATA_ONLINE) As it s scriptable , not only a griefer can know the hours of connection of someone else , but he can build a whole database. I don t know if someone has tried it , but it s technically possible . It s not an innocent affair .
  22. You may delete the timer in this case and remove inventory directly inside the on_rez event ( and maybe too in the attach event ) Indeed , the object of the OP is an attachment or can be useful only when it s attached . Of course , after the 30 days , the user could use always his object until the next rez . ( so , in practice , 30 days and some hours ) But the on_rez event is fired at the login if it s a an attachment . And he couldn t stay logged eternally
  23. llRequestAgenData(uuid,DATA_ONLINE) helps better the griefers than yourself . Indeed , a griefer can easily use an alt and you couldn t detect him because you don t know his new name or key . Yourself , because of your activities change less often alts .So you can be tracked easier by the griefers
  24. When you pay 300 euros , you don t pay for furnitures , but you pay to have a land . Contact your scripters and sellers who have sold you their stuff ( scripts and scripted objects ) It s up to them to find a solution and to fix your items
×
×
  • Create New...