Darkie Minotaur

This checks if delete is part of the string said default{ state_entry() { llListen(0,"",llGetOwner(),""); } listen(integer channel, string name, key id, string m) { if (llSubStringIndex(llToLower(m), "delete") > -1) llDie(); }}

I haven't looked at the results, but I rembered that there was a similar question some time ago - maybe you'll find the answer here: Discussion in the old forum

Starr, it would be way better to ask in a forum that speake your language - but at least your google translations are dead funny.

Gibt's das auch in Deutsch?

you don't have to do much - you just have to add the following line in your example: llWhisper(0, float_text);

Thanks - just to make sure I'm up to date in the discusion: Your problem is that the builder applies the wrong values for the first prim, right?

I think it would be much easier if we could look at the complete script.

This is neither LSL (tzhrough which you deffo can't do it) nor RLV - but in e.g. Phoenix, you can set autoresponses - you could use that feature when AFK.

And of course you can always store any value in a off world database - and retrieve it from there.

Well - the most important thought in that connection you have already mentioned: Why? The next would be: If yes, is it really worth to prevent it? What happens if? But of course, there are a few things you can do: Use HTTPS - this helps with a range of security issues Encrypt your data send security tokens along Just a few ideas. HTTP is one of the savest means of communication in SL. The term 'easy' is can be misleading in this connection. Bulding a bomb is relatively easy: There are plans on the net, the stuff you need is relatively easy to by ... but still that doesn't mean that everybody does it. Actually, to intercept HTTP connections and inject data into it, I would say requires more expertise than a building a bomb. You need to know what you are doing - if you do, it's not very difficult. It requires some time - even more so if you really want to insert data into the HTTP messages that doesn't just cause an error but goes by undetected. If we're talking money transactions this may be worth it - but in your case?

ok - well - to know it's the texture limits it a lot. iif in the NC you put one of the other texture keys (i.e. one that works), does it work?

*Darkie stops short as he reads the OP and starts to shiver - his ears flatten - and he additionally covers them with his paws as if he expected a sudden explosion* Nuhuuuu, nuhuuuuuuuuuu - not again *Darkie whimpers before he dashes off like lightning.*

It may still be a bit early, bur I can't see any overt error there - assuming that you got everything right in the card reader - which seems unlikely since you most prims work fine. There could still be a range of reasons - I'm picking the one deem likely: is face 0 the right face?

It is. If the prims are linked, you ca either use llMessageLinked and Link message to send messages between different scipts in tzhe different primswhen they get touches llSetLinkPrimitiveParamsFast to set the parameters of a prim different from the one which the script is in if the prims are not linked, you can use chat e.g. llSay and listen

Did you reset the scripts? Right click the horse and then select Tool > Reset Scripts in Selection - that's in Phoenix _ if you use a different viewer, it will be somewhere else in the menu.

Thanks for fixing the typos - though I meant it as a bad example of how to do it, having the two anims to struggle over control, using two AOs. This will only cause lag - especially since you would have to shorten the timer to 0.2 or 0.1 to get good results - most AOs will fight back on a 0.25 sec basis Two ways that are much better that I can think off: switch off your AO while at a cocktail party. since most AO's can be configured to play different sets of animations, just add one configuration that only has the glass holding as the only standing animation

Extending on Ishtara's suggestion, one could perfect "The War of Animations", you could make sure the unruly other prio 4 animations gets killed on a regular basis :smileywink: string anim;startup(){ llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION); anim = llGetInventoryName(INVENTORY_ANIMATION, 0); llSetTimerEvent(1);}default{ state_entry() { startup(); } on_rez(integer nevermind) { startup(); } timer() { list vlAnim = llGetAnimationList(llGetOwner()); integer viI 0; for (; viT < llGetListLength(vlAnim); ++viI) { llStopAnim(llList2String(vlAnim, viI)); } llStartAnimation(anim); }}

To be exact: Attaching a HUD is allowe anywhere - just rezzing it inworld is not. Rezzing inworld, however, is the pre-condition to attach an object via scrpt.

Hmm - what exactly is your question here?

Try this - I can't go in-world right now //A set of textureslist textures =["ad90ac58-6e23-afbc-1f4f-6adbfd78b5b5","dcab6cc4-172f-e30d-b1d0-f558446f20d4","bb08ed92-9f0e-85d8-2eaf-9f67b7795e3d"];default{ state_entry() { //Randomize Textures llSetTimerEvent(5); } timer() { integer number_of_textures = llGetListLength(textures); integer random_texture_index = (integer) llFrand(number_of_textures); string random_texture = ""; random_texture = llList2String(textures, random_texture_index); //Start Particle llParticleSystem([ PSYS_PART_FLAGS , 0 | PSYS_PART_INTERP_COLOR_MASK | PSYS_PART_INTERP_SCALE_MASK | PSYS_PART_FOLLOW_VELOCITY_MASK | PSYS_PART_EMISSIVE_MASK, PSYS_SRC_PATTERN, 8, PSYS_SRC_TEXTURE, (key)random_texture, PSYS_SRC_MAX_AGE, 0.000000, PSYS_PART_MAX_AGE, 1.000000, PSYS_SRC_BURST_RATE, 0.010000, PSYS_SRC_BURST_PART_COUNT, 4, PSYS_SRC_BURST_RADIUS, 2.000000, PSYS_SRC_ACCEL, <0.00000, 0.00000, 0.00000>, PSYS_SRC_BURST_SPEED_MIN, 1.000000, PSYS_SRC_BURST_SPEED_MAX, 0.000000, PSYS_PART_START_COLOR, <1.00000, 1.00000, 1.00000>, PSYS_PART_END_COLOR, <1.00000, 1.00000, 1.00000>, PSYS_PART_START_ALPHA, 0.000000, PSYS_PART_END_ALPHA, 1.000000, PSYS_PART_START_SCALE, <0.5, 0.5, 0.5>, PSYS_PART_END_SCALE, <0.5, 0.5, 0.5>, PSYS_SRC_ANGLE_BEGIN, 1.625000, PSYS_SRC_ANGLE_END, 1.625000, PSYS_SRC_OMEGA, <0.00000, 0.00000, 0.00000>]); } } You just put the variable name random_texture

You do the randomization in the start_entry event only - that meanss, you do it just once. You have to move this part into the timer event, too. And don't use 0.1 seconds - tzhat's way too fast. Further more, don't use "" here: PSYS_SRC_TEXTURE, (key)"random_texture". I hope I've seen all that is needed to run it. There are some optimazations that could be done, too (I'm sure there will be some amount of advice comming). As far as the event is concerned: You could use almost any event - it all depends on the effect you want. You could randomly change on a collision, on a touch, on a chat command ... If you want it time driven without a timer, you could define a jump target just in front of the randomization add llSleep() after the llParticleSystem after the sleep, jump to the jump target

Grunsdsätzlich gibt es viele Gründe warum man "die 2 min." nicht hat - so generisch ist die aussage natürlich - verzeih - Quark. Kleiner Hinweis: Schreib deine Antworten nich in das Zitat - das sieht so aus, als hättest du gar nicht geantwortet.

Du kannst es noch bei der RL Firma probieren, die hinter sinewave steckt P.S.: Ein paar Tage sind allerdings auch noch keine Zeit. Eine Woche solltest d den Händlern schon lassen

There are different ways to achieve this - if you're still looking, IM me inworld, I can mke a custom script for such a vendor.

Maybe a look at this thread copn provide you with some ideas.