Jump to content

Nickel Briand

Resident
  • Posts

    36
  • Joined

  • Last visited

Posts posted by Nickel Briand

  1. 4 hours ago, Jenna Huntsman said:

    To my knowledge, parcel bans =/= region bans, so it's possible that calling llTeleportAgentHome would not cause them to teleport to the hub, as the region is still up and is accessible to that user, but instead be forced outside of the parcel (sometimes, into a region corner if they cannot access any parcel on the region). I've seen that happen a few times.

    Do you mean if the target has defined  his home in  the same sim but in an another parcel ? I don t think it s the difficulty met by the OP of this thread .

    If so , in this case , it s against the TOS to try to ban him : it s not the land owned by the banner

  2. 46 minutes ago, Porksteeple Knotler said:

    I'm pretty confident it's not concurrency in the script itself, I'm only using llTeleportAgentHome and then llAddToLandBanList, in that order. One would hope that executing in that order would first TP the agent home, then add them to the ban list (which I guess would push them to the edge of the sim and the TP would fail if I did it in the reverse order).

    I don't think it's my management ejecting them manually, either, because the behavior is reproducible even when none of the officers in the community are present.

    It could be wise to trace in your script the size of avatar with llgetagentsize ( to know if his avatar has rezzed  when you do an action ) and the position of the avatar   ( to know if the avatar is higher than 800 meters  when you do an action )

     

    I didn t mean about a manual management when i have talked about administration but the rules applied automatically in the settngs of the sim and in the settings of the land

  3. 17 hours ago, Porksteeple Knotler said:

    I'm helping manage a private island with two sims and we have a user that keeps creating new accounts to evade bans and harass our community.

    I wrote a script that identifies this user's alt accounts when they appear on either sim, sends them home with llTeleportAgentHome and then adds them to the parcel ban list of whichever sim they happened to appear in that day.

    The problem is that llTeleportAgentHome sends the user to some limbo between the two sims instead of removing the user from the estate altogether. They violently bounce up and down ~200m in the space between the two sims.

    The script is deeded correctly and teleports my own test accounts home and off the private estate. I would love to know why this particular user's alts cannot be sent home and instead end up trapped at the border between my two sims.

    Any ideas? Are there other options to remove this user from my sims?

     

    Less relevant notes:
    - offending user has been warned multiple times
    - we report the user every time we see them, but LL has not taken action after months of harassment

    Probably a problem of concurrency  inside your scripts  :

    your target has been previously ejected from the land before the line llTeleportAgentHome  runs  ; so when the line llTeleportAgentHome  runs , the function doesn t find any avatar because he has been already teleported in a neighbour sim ( either by your script ( for instance using both llejectfromland and llteleportagenthome ) , either by the administration  of the sim/parcel ) 

    • Like 1
  4. 4 hours ago, Qie Niangao said:

    Now that you mention it, I'm suddenly wondering if there should be a warning before modifying an original that has links, analogous to the warning before deleting such an original. That's probably more annoying than useful, but I'm not sure.

    There is no warning when you delete an original . 

    1st step ; when you delete the original : the original is in the garbage inside your inventory : the existing links continue to address to the original ( who is inside the garbage )

    2nd step ; when inside the garbage , your purge the original from the garbage ( so there is no way to get it back ) . In this case , all the links towards this original are deleted permanently too

     

      

    5 hours ago, Quistess Alpha said:

    Also, that reminds me of another interesting facet of links. if an object has links to it, you get warned when deleting the thing, so you're less likely to break your outfits by accidentally deleting your meshbody, or something similar.

    As described above , there is no warning specific .  The warning of deleting an object is generic ( deleting an object who has some links , and deleting an object who hasno links have both the same message )

    • Like 1
    • Thanks 1
  5. 4 hours ago, CandyCole said:

    Being able to RENAME items even if they are no modify, or the sort where you can mod but not rename, would be really nice to avoid having numerous folders containing single same-named items. Such is SLife. I recall this subject being raised a few months ago within another topic.

    In addition , the lack of abilities to rename directly objects no-modify is amplified by the uability to rename a link to this object .

    If in a view if intellectuel properties , some people can try to defend the interdiction to rename the object , i can t undesrtand why the feature to rename links is absent in viewers  , although the links have been created by the user and not by the creator

    It could be simpler , for instance  the case of objects with a different "state" . For instance , imagine you have an object with an applier on it . 

    So you have Object1 with applier1

    You make a copy of Object1 . As you can t rename this object . It s named too "Object1" . and you assign it by hud an another applier applier2

    You create one link  to the first instance of Object1 with applier1  and one another link to the second instance of Object1 with applier2

    If the name of links could be renamed , you could have a clearer view of what is used with which state

    I don t see why this feature about links don t exist :  there is no danger against intellectual property rights

     

    In addition europe and asia have several dozens  of language . Imposing them the use of english in their inventory is absurd and even could be seen as a light discrimination . With links where the names could be renamed , the user could watch his/her inventory in his/her native language 

     

    Anyway it show that several features could be developped for links to improve the facilities in second life 

     

     

    • Like 2
  6. 16 hours ago, Qie Niangao said:

    Maintenant que vous demandez, je ne sais pas quand j'utiliserais des liens autres que dans les tenues. Peut-être des dossiers attachés ou détachés en tant qu'unité ?

    J'ai besoin d'une copie lorsque je souhaite modifier une instance distincte de l'élément, distincte de l'original. Cela ne fonctionnera clairement pas avec un lien. Je ne pense pas vraiment que la copie et le lien pourraient être fonctionnellement interchangeables.

    For versioning.

    For example, create a dummy script in your avatar inventory and fill in a few lines.

    Copy-paste as script (optional)

    Make another copy-paste as a link Now edit your first dummy script and fill in the other lines. save it

    Double-click on your copy: you do not have the reported changes

    Double-click on the link: you have the changes reported

    So inside a folder you might have a set of scripts pointing to a production version for example; and work on a new version on other versions of items with the same name (in my case, editing copies of your original script; even if you make a copy of a copy of a copy, you will know what the original stable version is of your script)

     

    Nevertheless , outside outfits , it s limited it s a pity we can t drop some links inside the inventory of an object . Of course not to drop  the links themselves but the objects/notes/scropts.anim/ sounds pointed by these links

    • Like 1
  7. 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 ? 

  8. 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

     

     

     

  9. 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.

     

     

     

     

  10. 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

  11. 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
  12. 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

     

  13. "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 

     

  14. 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

  15. 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

  16. "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 ?

  17. 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

     

×
×
  • Create New...