Darkie Minotaur

I'm pretty sure that this is a reply you get from the server you are trying to connect to - so there's not much one could say since you didn't state, which service you are trying to use

Also nochmal zum Zusammenfassen: Wenn es ein script ist, muss es nicht in einem Attachment sein, sondern es kann an jedem beliebigen Ort sein. Ein Script kann dem Objekt in dem es liegt, einen beliebigen Namen geben - das wird oft genutzt IMs von avas und Objecten (d.h. Scripten) lassen sich leicht unterscheiden: erstere oeffnen im Normalfall ein IM Fenster - letztere nicht, denn man kann ihnen keine IM zurueckschicken wenn man auf einen Namen klickt, der vor der IM steht, erhält man bei IMs von Scripten den Ort angezeigt, an dem das Objekt ist, das das Script enthält. Bei avataren bekommt man eine Auswahl von avatar-spezifischen Optionen (z.B. Profil anzeigen) Es lässt sich also leicht festellen, ob ein Script die Quelle ist, oder ob der Ava manipuliert ist. Im Falle des Scripts, ist das ärgerlich, aber weiter nicht schlimm. Im Falle der Manipulation des Avas ist das anders - wenn du sicher bist, dass es kein Script ist, wuerde ich den Account sperren lassen und den Rechner neu installieren. Eine 'Firewall' (dieser Begriff besagt herzlich wenig) hilft nur dann wirklich, wenn man versteht, gegen was genau sie schuetzen soll. Zumal muss die Manipulation nicht auf deinem Rechner passieren - die Wahrscheinlichkeit ist jedoch hoch.

Der Punkt ist: Ein Skript kann nur IMs mit dem Absender des Objekts verschicken, in dem es ist. Auch als Attachment. Natuerlich kann dieses Objekt den Namen des Avas uebernehmen - es ist aber immer das Objekt, das die IM schickt - daher mein Tipp mit dem Klick auf den Namen. Wenn es kein Objekt ist, das die IMs schickt, sondern wirklich dein Ava, dann ist es ein Hack, der nach meinem Wissen nicht per Skript erreichbar ist. Daher auch die Vermutung des Firestorm Supports - RLV ist schließlich eine Modifikation des Viewers, und nicht einfach etwas geskriptetes.

Wenn die IMs von deinem ava kommen, solltest du dich dringend an LL wenden. IMs von deinem ava koennen nicht durch ein ein script verdandt werden. Ein solches IM script klaeme dann immer von diesem Objekt, nicht von dir. In diesem Falle wäre es voellig egal, ob du das Objekt traegst. RLV - das du ja auch schon deaktiviert hast - bietet m.W. nich die Funktionalität, IMs in fremdem Namen zu versenden, sondern (wie der Name sagt) Versand und Empfang einzuschraenken. M.E. bleibt nur, dass sich jemand in irgendeiner Weise in deinen Account eingehackt hat. Also schnellstens an LL wenden - die werden deinen Account erstmal sperren, wuerde ich erwarten.

Also keine Gruppen Nachrichten - in diesm Falle waere das Problem gravierend gewesen. Das Objekt muss nicht eines sein, das du trägst - aber es scheint dir zu gehoeren. Wenn es immer wieder die selben Leute sind, die die Nachrichten erhalten, dann bitte sie, beim nächsten mal den Namen des Objects im Chatfenster anzuklicken - dann wird angezeigt, wo sich das Objekt befindet.

Strictly speaking, this is a Metabolt question, not a scripting question. Metabolt is a viewer - and you have a range of options to control the avatar that you log in with Metabolt. Additionally there are plug-ins for Metabolt to give you more options. Metanomy is such a plug-in for moving the avatar. Read the documentation of both Netabolt and Mtanomy, then log in n avatar and play with it to find out what you can do.

Du meinst, Nachrichten werden per IM geschickt? Oder auf anderem Wege?

I would guess it's one of the following two reasons: your object is called "Object" and Object is on you mute list the script is not set to "running"

If you take the dialog example, you just find out which button has been pressed using llListFindList which will return the index at which the button that has been pressed in the list of buttons - e.g.: list glButtons = ["Ham", "Eggs]; You culd then keep a 2nd list of counters that starts: list glCounters = [0,0]; In the listener, you sumply increase the index at the same position as the button that has been pressed and increse the conters at this position by 1 and replace the old value by the new one: integer index = llListFindList(glButtons, [message]);if (index != -1) { glCounters = llReplaceList(glCounters, llList2Integer(glCounters, index) + 1, index, index);} I hpe this points you in the right direction

I use lslforge since it best suites my most important requirements (or Eclipse does): Possibility to integrate SVN Support for different languages - especially PHP multi plattform (I work on Mac OS as well as on Win) As far as LSL is concerned, it suppoert syntax highlighting, sysntax copletion and even off line debugging (which I've hardly used, though)

It's a bit difficult to help you without any hint as to what goes wrong - and what should happen.

Depending on what you're doing with the group membership, you could set up your own group system using an external database.

You can't record sounds within the scope of LSL. Depending on what you actually want, something might be possible outside SL.

Thanks for the example. This situation would indeed be a case where you need alt detection. Alt detection can - as far as I see - technically omly be approached by detecting if two avas are on the same machine (physically or virtually). The IP address is one important indicator for that - though not the only one. The IP address alone is, however, not a death proof instrument. To prevent confusuion: I'm talking about the client IP address - not the sim IP address that you get by looking at the HTTP headers sent by LSL HTTP communication. The client IP address is the IP address of the client the user is using. There is no way to detect the client IP address from inside SL. There are ways of trying to get these IP adresses by using IP connections that come from the client machine directly - usually using prim or parcel media or parcel music. I guess that's similar to what you had in mind when you where talking about using a website to give out a token. But this would also rule out persons that are located behind the same IAD (at least in most cases), since all of the clients run e.g. behind the same router have the same public IP address. You would have to use other mechanisms - there are some out there - that collects and evaluates further infoirmation about the client. Depending on what exactly you plan to do, there may be other glitches as well.

Maybe I'm just a little slow - but how would a player actually cheat using an alt?

It seems you've missed the upheaval RedZone and other tools like it have caused - you're on thin ice here (search the archive ans you'll know what I mean). Freya has alredy summed up the chances of detecting alts reliably based on IP addresses - although I don't think that someone has ever seriously tried that - it requires a lot more than just IP addresses, and then it would still be no proof of alts.

As far as I know, this is an issue with llSetLinkTexture, llSetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast which the scripts in question may use. llSetTexture does not have these perm restrictions. If you have a link set you want to change the textures for, that means, each linked prim will nedd a script that changes it's textures. ETA: The restriction should only hold for copy perms. This of course means: If you don't have copy permissions, you can't apply the texture to more tha one prim's faces - and you couldn't copy it to the inventory of several prims in a link set.

check the first line of your updated version

In fact, you posted faulty code - check next time before you jump to hasty comclusions. apart from that, it would be nice to have a result that tells you what exactly went wrong.

The simplest way is to use one of those song recognition tools. If you have access to a smart phone, there are toos like Shazam or SoundHound - and I'm sure, there are some for the PC or Mac, too. Just as Google or Bing ot AskJeeves ...

What kind of rotation are we talking about?

A while ago (like 2 years), I did a similar test that proved the theory about the throttle. Fortunately, I still have the scripts. My approach was slightly different in that I tried to get to a real burst as possible - so I deviced a master script tht triggers slave scripts to fire requests. Running this setup again ow I found, that LL obviously has changed the throttle. From the tests, the limit of 25 still seems to work quire reliably. The 26th got throttled without fail in may tests as well. As for the time it takes the system to 'recover', it seems that 40 secs is the best approximation I could get - again, pretty reliably. (Tested with 10 bursts). Finally I tested with one request per second - which ran smoothly. Actually, I let the script rest for 0.9 seconds to take into account the other computing steps take - taking the time with llGetTime(), I easyly sent out 180 requests in about 175 seconds (the timestamps in the database that got created on each request confirm that). To wrap it up: Either there is an nwanted bug, or a undocumented change - I can confirm that the 25 requests in 20 seconds no longer works - the best rartio you get, if you send out 1 request per second. P.S.: I have to crrect my statement in so far that the Wki contains two links to discussions. Kelly Linden stated in the second one: "UPDATE: The basic mechanics have not changed but the actual rates changed since this was posted. The new rates are 25 requests per 20 seconds and are per object, not per owner per region. If the object making the requests hits the limit then stopping for 40 seconds will clear the throttle."

I don't really think that yout post is a reply to the post - but still interesting. As far as PDO vs. MySQLi is concerned, I stick with the authot of the page you quoted. He wraps up: " In my opinion, the features and flexibility of PDO far outweigh the very slight performance hit." And I absolutly agree that there are a range of factors, that influence how you should/could design your application. As far as OOP is concerned, I agree, too. But that hasn't even been mentioned here.

Das ist die Avination Währung

Well, there's a (good) reason for it - and over all LL are pretty tight aboot letting scripts generate assets (and we know what a feeble creature the asset server is). There are many ways to store data - why don't you just use an outworld database?