Jump to content

Ela Talaj

Resident
  • Posts

    874
  • Joined

  • Last visited

Posts posted by Ela Talaj

  1. There may be an additional independent timer in the script, implemented via llSensorRepeat() if one wants to go into such trouble. Just scan for something definitely not there and use no_sensor() event as an additional timer.

    Preferably to that,  you may consider your timer event as a "system clock", set it to a 1sec tick and then if some occurance requires 20sec timing and another one 30 sec timing, count down from 20 and from 30 respectively in the timer event.

  2. This should be pretty trivial. In default state entry call llListen() 4 times, first time with word 1, second time with word 2, etc. Also define a global variable, let's say integer lock = 0;

    In the listen event your conditions would be: If word 1 is detected, increment lock by one  but only if lock was zero prior to detection. If word 2 is detected, increment lock by one but only if it was 1 before and so on. When the lock value is 4 all words have been spoken in proper order so the door opens.

    There is a little more to it. The lock value is basically the number of the next expected word, so if the word 3 was spoken when the lock is 1 (word 2 expected) you'd need to reset lock to 0

    That's all there is to it but you'd have to write the code implementing the above yourself :)

  3. It is not "evil LL" that makes people shop in the Marketplace. In fact, the Lab has never tried to force users to shop via Marketplace. The users overwhelmingly selected Marketplace shopping for their own reasons, one of which is convenience, so the users voted with their feet. A merchant should listen to customers not vice versa, so merchants not having a Marketplace store simply don't care of their sales volume and are merchants as a hobby.

  4. It appears the server creates a by name "black list" of objects it has problem rezzing so if there are several temp objects named the same and one fails to rez it doesn't even bother trying to rez the rest because this name is on the black list. Perhaps it always been this way but in the latest server upgrades there appears some kind of a timing glitch when rezzing temp objects while server is still in the process of restart. So one fails to rez and is put on the black list and the bunch of other with the same name are not even rezzed but give a rez error msg right from the list check.

  5. There is no need to purge the list Rolig, make a circular buffer. Basically, we need to store the user id and a unix time integer so we could audit every hour or so. A circular list (buffer) could store up to 500 unique users given these conditions.

  6. Can't imagine why you would need a scriptset like that, but if you do, here's a way to do it:

     

    default{    state_entry()    {         llSetTimerEvent(10);    }
    timer() { llMessageLinked(LINK_SET, 1, "", NULL_KEY) }}and the "listener" is:default{ link_message(integer src, integer num, string str, key id) { if(num) { llWhisper( 0, "more!" ); } }}

     

  7. The marketplace does not have functionality to interact with in-world objects, excluding of course a specifically designed for that purpose "Magic Box" which would soon become obsolete. I don't think the Lab will even consider adding such functionality, it is a can of worms.

    I've an audio-stream rental vendor which works via Centova API, if interested inquire in-world.

  8. Ohh... this is a lovely question! Worth some elaboration. The problem is of course with gifts = gifts++ as Rolig pointed out, but why? In fact, it is one of the very frequent interview questions and the number of entry-level programmers not getting a job because failing to evaluate i = i++ is probably a few too many.

    The answer has to do with something called sequence point. It is well defined in here:

    http://en.wikipedia.org/wiki/Sequence_point

    The article might be a lil too complex for LSL wannabees but would mighty help in preparing for that interview for whoever has it scheduled :)

    • Like 1
  9. For obvious reasons there isn't an LSL method to attach to avatar either "permanently" or temporary until the agent gives a manual permission so this is not going to work seamlessly. There may be some wearable attachment that agents already wear and it catches on fire on avatar's collision with something. Other than that a follower seems the only feasible option. To make it follow anyone you need to include a scanner that would get you the keys of agents in vicinity. A follower follows by key.

  10. My color/texture changing products come with API where a user can set their own number of colors and/or textures. Builders using these products can set whatever number of colors/textures they seem reasonable but then leave the API full perms so their customers could set their own preferences.

  11. There is no difference in execution. Moreover, in most C/C++ compilers (though not all) you'd get exactly the same assembly code. It's as I said originally a matter of programming style. Most software companies would have programming style rules handbooks where they codify even a number of spaces curly brackets should be positioned at in respect to the previous lines :)

    The idea is mostly to prevent typos and missing things. In our specific case you are not going to forget "else if" and if you do a compiler will remind you, but it is easy to forget "return", which may lead to a whole program being executed somewhat differently than you think and in complex systems with many modules and thousands of line of code in each bugs like this are hell to find.

    (Of course in the real world no one going to write a lot of "else if" but would use a switch statement.)

  12. Don't write code like this. It is a very bad style.

    listen( integer channel, string name, key id, string message )    {        if (llToLower(message) == "finished")        {            llListenRemove(listen_handle);            llSetTimerEvent(0.0);            return;        }             if (llToLower(message) == "green1")        {                llSetColor(<0.22353, 0.70980, 0.29020>, face);                return;        }        if (llToLower(message) == "green")        {                llSetColor(<0.00000, 0.58039, 0.11765>,face);                return;        }        if (llToLower(message) == "green-1")        {                llSetColor(<0.00000, 0.36863, 0.12549>,face);                return;        }    }

     

    Should be:

    listen( integer channel, string name, key id, string message )    {        if (llToLower(message) == "finished")        {            llListenRemove(listen_handle);            llSetTimerEvent(0.0);        }             else if (llToLower(message) == "green1")        {                llSetColor(<0.22353, 0.70980, 0.29020>, face);        }        else if (llToLower(message) == "green")        {                llSetColor(<0.00000, 0.58039, 0.11765>,face);        }        else if (llToLower(message) == "green-1")        {                llSetColor(<0.00000, 0.36863, 0.12549>,face);         }    }
×
×
  • Create New...