Jump to content

Ela Talaj

Resident
  • Posts

    874
  • Joined

  • Last visited

Posts posted by Ela Talaj

  1. On April 9, SL Account Transaction History shows a Marketplace item sale and correct amount received.

    Marketplace Orders transaction history shows this order was paid for and delivered on March 15.

    A thing here is that this product did not exist on March 15, it was listed no earlier than March 21. How could it be sold on March 15?

  2. People who want a script and "don't know where to start" should not be starting in the first place. They should either buy a script in the marketplace or order a custom script via "Wanted" subforum.

    Your (and Innula's) earnestly answering such people does not promote knowledge but encourages ignorance.

  3. I released a new product on March 21, just when the DD fiasco started but by March 31 or so the marketplace loading speed was restored and the product moved to the top of my first page by relevance.

    The point here is that relevance was working just fine after the page loading speed was restored. Why it doesn't work now... your guess is as good as mine and no announcement was made whatsoever in respect to this matter, which does hurt business.

  4. Please learn once and remember always that llRequestPermissions() regardless what permission you're requesting, is meaningless without processing run_time_permissions event. This is true even if a permission is supposed to be granted automatically. Even more so in case of PERMISSION_CHANGE_LINKS because this permision is NOT granted automatically.

    Your llGetPermissions() does not do anything at all, it is an idle code line. Read the function's description in the wiki and figure out why as a home work :)

  5. This is not entirely correct. llSetRegionPos() should indeed work in all cases.

    Old warp would fail on return if along its path (by 10m moves) it encounters a no entry parcel or a parcel that is full prim-wise. On its original trip an avatar is sitting on TP prim so the prim would move thru such parcels, but it returns alone so gets stuck.

    The number of prims on the parcel is dynamic, whatever the owner puts there up to the parcel limit so one day a parcel might become full and does not allow TP's via it any longer. That's the problem with old warp. I encountered it long time ago, long before llSetRegionPos() so I was forced to get rid of return trips altogether by making the TP object temp-on-rez and one way.

  6. There are 2 types of LSL rotation methods: server-side and viewer-side.

    llTargetOmega() in most cases causes only the viewer-side rotation effect (though not always) but in all cases the rotation becomes a property of the prim.

    llSetRot() is the server-side rotation. If set in a timing loop it will rotate the object via a script, and if the script is removed will stop. Visual effect of this server-side rotation differs because the method has 200msec built-in delay.

    llSetLinkPrimitiveParamsFast() also allows to set the server-side rotation which does not become prim property  but without 200 msec delay so a resulting effect is the same as if llTargetOmega() were used.

     

  7. When you make an LSL llDialog() call you specify a list of strings which would be displayed on the buttons. You also specify a channel on which the server will send you a response when a button is clicked. You must listen on this channel, otherwise you would not hear responses. So llDialog() call and llListen() call must come together, one after another and have the same channel. It does not matter which one is the first and which one is the second, but there must be both of them.

    You must also have a listen event via which you would get responses. In the listen event you make what programmers call  "switch". In some programming languages there is a specific syntax for that but not in LSL. An LSL a switch is just a bunch if else if's So it will look like this:

           listen(integer chan, string name, key id, string mes)
           {
             if(mes == text1)                          //whatever text you put on the first menu button
              UserFunction1();
            else if(mes == text2)                 //whatever you put on second menu button
              UserFunction2();
            else if(mes == text3)                //whatever you put on third menu button
              UserFunction3();                   
            else if...                                       //and so on as many else if's as you put button in the menu   
          }
             

    In user functions you put whatever processing code you need. for instance UserFunction1() may include code to change prim size, UserFunction2() may have code to change prim color, etc.

    You may code these User Functions, either separately above default state, or in-line within the listen event itself.

     

     

     

  8. It is possible and, in fact, rather trivial to write a script that would recognize words entered either in a script itself or in the notecard. There may be up to several hundred such words.

    The rest however is a different matter. It is not clear from your post where such a "tool" would reside. If it resides in a wearable object it is indeed easy to make it play an animation to the wearer. If it is a stand-alone object it cannot animate an avatar unless the avatar specifically grants permission to animate. A stand-alone object can "push" an avatar with a given amount of force but the visual effect would not be the same as animating.

    If want such a script written, call me in world to discuss particulars.

     

     

     

  9. It is possible to make "real money" by programming in SL. However it is not exactly "scripting". You will be making complex systems consisting of SL objects communicating with off-world web servers for real programming wages of 25USD per hour and up. However for this, in addition to LSL, you need to know databases (like mySQL) and at least PHP programming language. In other words you need to be an experienced professional programmer in real life.

    Unless you are, don't quit your real life job, if you have one :)

     

  10. If you use some kind of a flag to check if a dialog is already opened like it was suggested in other replies, you will not have more than one dialog open at a time so no need to be concerned with more than one.

    I usually store user id (key) when the dialog opens and clear it (set to NULL_KEY) when it closes, but  a simple flag DIALOG = TRUE/FALSE would do just fine.

     

  11. The Lab can do no right... at least according to some. When it sends emails it is "spam" and when it does not it is "customers neglect".

    Perhaps if self-styled prosecutors didn't crowd the aisle rushing to the podium to demand conviction every time the Lab does attempt to comunicate it would be doing it more often.

  12. Making a script that plays animations from a menu is more or less trivial but still more complex than just making a menu of animations in the object content (and that is all the mAPI does). You got to deal with requesting permissions and therefore permissions event and you got to figure out what would stop animating, it's not a good idea to do it on a menu "Exit" button.

    What I don't understand is why you wouldn't just order the script from someone instead of "messing with that script for a LONG time". A script of this complexity should be under or around 10 USD. Isn't it worth one-day lunch money to save yourself "LONG time" and a lot of frustration?

  13. The script is bad to begin with. If several people are chatting all you gonna get displayed is gray because the picture would be changing too fast without enough time for the texture to rez.In other words, the only pic that would be displayed for a reasonable time is the one of the last chatter before a long pause.

    A professional script would store chatters id's in a list, display a picture for a certain period of time (1 min or so) and then check if there are more id's in the list to send http profile query. 

  14. The "Pay" option of object menu raises the LSL "money" event processed by a vendor script. The "Buy" option does not have an associated event and there is nothing for a script to process, as it is unaware that the "Buy" button was clicked... Or so it seems...

    In reality however if a user clicks the "Buy" button to buy a copy of an object, the LSL "changed" event is raised with change = CHANGED_OWNER. It is raised in the original object even though a copy of it is the one actually changing ownership. So whatever sales information is collected on "Pay", it can also be collected on "Buy" (excluding the price paid but you know the price paid because you set the object to be sold for this amount). This only works if an object is set to buy a copy, not to buy the content.

    Call me in-world and I'd be happy to write you a script to collect such info... for a price of course :)

     

  15. It should look like this:

    In the HUD code in global variables:

    COMCHAN = -6443634;                                              // or whatever number you like, negative number recommended

    In the HUD code after button "Boom is touched:

     llWhisper(COMCHAN, "Boom");                               // whisper cuz you are not gonna be further than 10m from attachment

    In the launcher code in global variables:

    COMCHAN = -6443634;                                              // must be the same as in HUD

    In the Launcher code in the state entry:

     llListen(COMCHAN, "","", "Boom")

    NEW EVENT in the launcher code :

    listen(integer chan, string name, key id, string mes)
    {

         start_launcher_ from_here();

    }

  16. Honey, the furthest thing from my mind was trying to offend you... I don't even know you :) The point here is that the LSL compiler is not very predictable when it comes to memory usage and unless tests are run it is hard to say what it is going to do.

    For instance very recently I defined a function of about 10 code lines instead of repeating same 4 times in the module and it cost me 5K of memory. I've no idea why. The function does deal with lists search and have some loops but so does the inline code and I didn't pass it any arguments... go figure.

    In another instance I had something like this: llInstantMessage(id, text_string) and the same text_string was sent in many instances in the code. So instead of putting the same text in quotes every time I defined a global: string text = "whatever text I was sending". I fully expected some memory savings on this... indeed I reserve the memory for text only once, not 15 times.... I got exactly the same memory usage with the global or without it. Once again, go figure.

    That's what my reply meant. In LSL wouldn't really know until you try.

  17. Why don't you try yourself both ways and see how memory usage differs? I'm not gonna run tests for you :)

    I would however expect that by using a function in this case you would not win any memory but on the contrary may lose a few bytes. Not very many though, so unless every byte is precious (the script is dealing with large lists or things like that) it would not make any noticeable difference.

     

  18. Hmm... I guess it is possible that you're a better developer than I am because I've never participated in or was a lead on a project that would not bring a mile-long CSR's list from QA. Yet whatever your qualifications are, you cannot really say that the commerce team "put out code that [is] THIS bad" because you haven't seen their code and neither have I. In fact I more and more lean to an opinion that the commerce team does not have adequate testing facilities and is forced to release without much QA at all.

    As for the rest, I do not believe SL was originally intended and designed for in-world shopping. There will always be an enormous difference in time spent between shopping in-world and shopping in the marketplace. That is why the marketplace should be the main shopping channel while in-world activities would remain mostly what SL was intended for - social interaction.

×
×
  • Create New...