Haravikk Mistral

Okay so I've briefly dabbled in running bots but I'm not all that familiar with the major bot providers and what their capabilities are. So I'm posting here in the hopes someone more knowledgeable can weigh in. Basically what I'm doing is I'm coding some interactive devices but would like to make sure I can support bots as well as possible; for example, an interactive bar in which an avatar can interact with the bar-tender to mix drinks. However, since it's not easy to guarantee an active avatar is always on the bar I want to be able to allow land-owners to supply bots that can fill in, in this case as the bar-tender in the example. What I need to be able to do however is determine whether an avatar on the device is a bot, so I can provide automatic behaviour as appropriate, rather than waiting for the bot to do something it won't understand! I'm curious what the best way is to detect current legitimate bots, is there a good standard method that they all respond to? Ideally a method that doesn't involve publicly heard chat, for example llRegionSayTo() or a fake dialogue or something. I'm not looking for fool-proof bot detection, just the ability to query possible bots to determine how my object should behave differently toward them. What would be even more ideal is if there is a standard method to call a bot over to the object; so a land-owner could provide a handful of bots who are called over to devices as required, rather than needing bots for everything they have. I've been looking at custom-coding a bot program, but obviously this wouldn't suit most people unless I also provided a bot-service that would keep running all the time, which is a bit overkill for me right now, so I'd like to support current always-on bot services as best as I can.

Basically the only time the base texture repeats should be interfered with is when playing a frame animation with a sizex and/or sizey value greater than 1, in which case the repeats should be treated as <1.0, 1.0>. For all other types of animation the function should be applied onto the texture exactly as it would appear on the prim normally (without animation).

Since the SL viewer only gets more and more demanding to run (with or without newer graphical features), I'm no longer able to run more than one copy of SL locally with any degree of usability, even with one copy hidden (See here). Anyway, I used to sign in with multiple viewers so that I could test anything that supported more than one avatar, so I was thinking I'd try running a simple bot instead, but I have some questions. Firstly, is it okay to just use any account (such as an alt) for simple testing purposes, or does the account need to be registered as a bot regardless? All I really want is to just use my existing alt with one of its available costumes, and have it sit on things, while automatically granting permissions requests (except debit). It wouldn't be for anything more than light, occasional testing so I'm curious if I need to bother registering as a bot account? Secondly, are there any good bot programs that I can run on OS X? I can use virtualisation if I absolutely have to, but obviously I'd rather use something specific, or cross-platform, for example a Java bot, if such a thing exists? Lastly, if there is no simple bot for OS X, is there a good place to start if I were to try and write my own? I used to be a Java developer so with decent documentation I could probably knock together something simple that meets my needs (or possibly other people's as well). Also, if there's a more appropriate forum then please do point me to it! Thanks!

Have you tried using any of the other physics function such as llSetForce, or toggling the physical state of the object with llSetStatus? Not that either of these are really any kind of solution, since the goal is smooth movement between sims. I've posted a JIRA issue for the sake of tracking this problem, but it'll probably be easier to get this issue fixed by attending the right user group meeting to get it some attention.

Lists are always going to be the weak point of llSetLinkPrimitiveParamsFast() as they're pretty unwieldy, even small ones, so you can lose a lot of the benefit of having no delay. For this reason dedicated functions are always better unless they have a strangely long delay built-in. The main advantage of llSetLinkPrimitiveParamsFast() is not in replacing single function calls, but in performing multiple actions at once, or actions that we don't currently have a corresponding llSetLink*() function for. Same advantage really as llSetLinkPrimitiveParams(), except that you don't have to have helper scripts if you need to perform several separate updates within a short space of time.

The function could be useful in something as simple as a greeter ("Welcome sir/madam"), or in any dialogue that is capable of adapting to an avatar's gender rather than simply assuming one or the other. Sure it wouldn't be perfect, but it'd allow the dialogue to be more accurate in most cases for general purpose devices. As I noted though, for adult content it would fall short in a lot of cases; a much more flexible function could handle it better, but it's not something LL would ever likely get behind, so is more suited to an adult HUD where a user can specify what gender they are (or more likely, what parts they happen to possess). But I think that a simple llDetectGender() function still has merit just for giving more option in how a script can address someone.

On the page Void linked to, just click on each function for a description. But as a summary: llGetTime() will give you a fairly fine-grained time describing how long your script has been running for, so it will start at 0.0 at the last time your script reset and continue until either the script or region resets again. You can use llResetTime() to reset this whenever you like, or llGetAndResetTime() to fetch the current time and then reset it in one go. You do however need to be careful as a region reset can ruin any timing mechanism based on these, so either plan around it, check for large negative values, or use the changed() event to detect conditions that could throw a spanner in the works. llGetGMTclock() or GetWallclock() will get GMT and PDT time in seconds, bit hard to work with though IMO, but useful enough for scheduling something on a daily basis if you make sure to watch out for the values resetting at midnight in their respective timezones. llGetUnixTime() is probably the most useful as it gives you a standard unix timestamp in seconds from the unix epoch, with this you can easily perform most time-related comparisons. llGetDate() will get a simple date-string, though you'll have to break it apart yourself. llGetTimestamp() is better than llGetDate() as it'll give you the time as well, and goes into microsecond accuracy. However it also returns a string that you'll have to parse, which means that while it is the most accurate timing mechanism we have, by the time you've processed the string into a usable form any advantage in accuracy will have been lost. You can however use llGetTime() to help you correct results, depending on what your exact requirements are. llGetTimeOfDay() will get you the region time (the 4 hour SL day), llGetSunDirection() is similar as it'll tell you where the virtual sun is. These are useful for detecting night in SL regions for automated lights etc. If you require a more precise timing mechanism then you might like to look at JIRA SCR-5 which is a proposal for a timing mechanism with milli/microsecond support, in a hopefully useful format, it's intended to avoid the problems of llGetTimestamp() which is essentially taking an integer value, converting it to a string, and then forcing scripters to convert it back to get any use out of it.

That's not true, I'm sure there are quite a lot of possible uses in adult content given key physical differences that are expected between the two major genders. The inability to represent less common genders is of course an issue, as the standard genders are after all only intended to give you appropriate options when building a standard, non-explicit avatar. I think any niche areas such as adult content are better served by the adoption of a HUD system that users can make use of to enable additional features appropriate to their gender.

Did you view the issue? All I wanted was an answer to the simple question of why an issue that I posted years ago had suddenly been closed. The question here isn't whether the Lindens are within their rights to ban someone from the JIRA, it's whether Oz Linden was right to close an issue without giving adequate information or discussing it when asked, and resorting to banning in place of open discourse, as well as whether he was even right to close the issue at all. His only reason cited has been a decision made in a viewer evolution meeting, however that decision was never to close VWR-7830, but to focus on STORM-313 in the mean time, so where did closing the issue suddenly come from? Why the lack of explanation? Why the lack of any attempt to offer alternative courses of action? I had to come up with the main viable alternative myself which was to separate the issue into the complex case of auto-switching for land entry, and auto-setting group when rezzing objects, using my alt since my main account got banned, and you know what? That got my alt banned too! For doing nothing besides try to extract the simplest part of the issue so it could be reviewed again in its less complex form.

Since when is asking for clarification or the simple courtesy of discussion being a "problem JIRA user"? So now we should all bow to everything a Linden says no matter how misguided or contrary to our interests as residents (you know, the paying customers that allow SL to continue to exist). I, and everyone else for that matter, is wholly justified in persisting in demands for explanation, particularly when they are purposefully ignored. It's not as if I asked much; as the initial reporter of a long-standing JIRA issue it is only common courtesy that I should be informed why my JIRA issue was being closed so I could dispute it if I choose, and discuss alternatives to seeing it done. Instead I'm silenced from the JIRA for wanting some basic human respect on an issue that is as relevant today as it was when the JIRA was first posted, making it completely inappropriate for the issue to be closed. The most telling piece of evidence in this whole debacle is that Oz Linden not once tried to argue with any of the points raised, instead he just resorted to "because I say so" and threatened to ban me. When a Linden starts resorting to threats to get their way instead of discussing the matter, then they are no longer acting in the best interests of anyone but themselves. Was I wrong to persist? I don't think so, as while it's certainly the reason I got muted, failing to do so would go against everything the JIRA and open-development are supposed to be about. Was I wrong to want answers about my issue? Definitely not! If the answer to our questions is being banned then what respect does that show for resident input and community involvement?

Not well enough as I still have no idea who you're talking about I get the point though! But I've been on the damned JIRA contributing since it was created and reported 274 issues, and yet Oz decides to mute me because I wanted an answer as to why my JIRA was closed, instead of just replying to my queries it's incredibly infuriating. But am I wrong in thinking the issue shouldn't have been closed in the first place? Until group switching stops being an issue for people then solutions should remain in JIRA, even if a Linden doesn't want to work on them right now, but as it is it's still one of the most confusing and frustrating things for users in Second Life, old and new. Of for... I've now apparently been banned completely as I can't even sign-in to the JIRA anymore, is Oz now getting off on being an immature idiot?

What Innula says, but bearing in mind that llInstantMessage() is very slow (roll on llTargetSay()!), however it's by far the least spammy method as it only sends messages to a particular avatar. llOwnerSay() meanwhile has no delay, but only sends messages to the object's owner, but in cases where that's exactly what you want to do then it's a huge improvement.

I'm not sure I follow, you were banned as well? Who by, what for?

While you're right about LL's limited resources being a controlling factor, that isn't a cause for closing an issue as it prevents someone from submitting an open-source patch to it, and prevents users from having their say on its priority or future desirability. Viewer issues are now mostly handled by Snowstorm which is (supposed to be) an open-development group, but open-development can't occur if valid issues are closed as open-source developers should be free to work on and contribute to whatever they want. I can fully understand LL wanting to avoid an issue in the short-term and focus on something else, that's perfectly fine and to be expected, but ditching issues just because they can't be bothered working on it right now isn't a valid reasoning for closing them.

I know, but I wasn't about to be bullied into letting an issue go without a good reason for it being closed; he can't simply be allowed to get rid of an issue when the problem that it relates to continues to exist, that's not how the public JIRA is supposed to operate as it's supposed to be a place for user-input and prioritisation of issues through voting. While users probably won't be able to vote on the issue while it's closed, I'd appreciate comments in support of the issue as he has to see that he's wrong to dismiss the only real solution to in-world group usability issue. Comments and votes on the related JIRA issue VWR-25526 (for the specific case of rezzing objects) should still work: https://jira.secondlife.com/browse/VWR-25526: https://jira.secondlife.com/browse/VWR-25526

After being an active JIRA contributor since it was set-up I've just had my JIRA privileges revoked on my main account for re-opening an issue asking for clarification as to why it was closed. The JIRA issue in question is VWR-7830 Automatically switch active group on group land: https://jira.secondlife.com/browse/VWR-7830 The issue quite reasonably proposes an official implementation of the popular automatic group switching feature found now in many third party viewers, in fact the JIRA issue actually predates the implementation by third party viewers entirely. However it has been closed by Oz Linden, and despite my many reasons why the issue is still more than valid (some admittedly a bit heated given the fact he kept closing it without reason), I've only received two responses that mean anything. The first is that the viewer evolution group decided to focus on the much simpler STORM-313 (improved parcel permissions display), this however isn't a valid reason to close VWR-7830 as it's a complimentary solution at best, rather than an alternative. As all it serves to do is provide more information, most likely overlooked, rather than solving the actual problem. Second reason is that the JIRA is cluttered and needs to be tidied, and this over anything is the most compelling reason I've heard, but there's a reason the JIRA is cluttered, and that's because there are so many outstanding problems that need fixing or improving. All closing issues arbitrarily will do is remove options for actually solving those problems, an issue should only be closed if it is misfiled, or if the problem it related to has been solved, VWR-7830 fits neither of those cases. Aside from all this I've been a resident and JIRA contributor far longer than Oz has even been a Linden, the complete and utter lack of respect for residents who actually know and have to live with the problems they're describing sets a dangerous precedent and wholly at odds with his alleged role as a lead in open-development. I would very much appreciate it if anyone who reads this and sympathises will post on VWR-7830 with your views of the feature, particularly those of you that use it every day in third party viewers. And feel free to make known your opinions on threatening to and then stifling the voice of a JIRA contributor instead of discussing things with them! I even tried to tidy up the issue into smaller pieces, and create a meta-issue to group them all under using my alt, only to have him block that even though that account has done nothing wrong!