Quistess Alpha

Posted February 14 · February 14

A fancy replacement for cycleList might be something like:

list = llList2List(list,1-llGetListLength(list),0);

Posted February 14 · February 14

40 minutes ago, Estelle Pienaar said:

Can anyone spot the mistake, that I am making? I don't get it.

LSL is pass-by-value, and will never pass-by-reference. In other words, cycleList (content1); cannot change the value of content1. you have to return the value and do an assignment:

list cycleList (list c_list) {
    if(llGetListLength(c_list) > 0)
    {
       string first_entry = llList2String(c_list, 0);
       c_list = llDeleteSubList(c_list, 0, 0);
       c_list += first_entry;
       llOwnerSay("Debugging. New list order is: " + llList2CSV(c_list));
       //return c_list; // returning here but not outside the if() will result in an error:
       // functions that return a value must return a value in all cases.
    }
    return c_list;
}
// later in the script:
some_list = cycleList(some_list);

Consider also:

default
{   state_entry()
    {   integer x=7;
        llOwnerSay("X="+(string)x);
        // scope-creation does not need a reason, like an if/while/for 
        {   integer x = 9; // removing 'integer' from this line leads to more 'expected' behavior.
            llOwnerSay("X="+(string)x);
        }
        // when scope is exited, x has its previous value: (because was re-declared in new scope)
        llOwnerSay("X="+(string)x);
    }
}

February 14

17 hours ago, PheebyKatz said:

The only drawback is that having it attached limits their ability to interact with objects by clicking on them,

Very recently, llSetClickAction(CLICK_ACTION_IGNORE); was introduced, which fixes that exact problem: when CLICK_ACTION_IGNORE is set, clicking behaves as if the object which ran the command doesn't exist. (I haven't tried it though, not sure how it interacts with right-clicking)

February 14

6 hours ago, Shashi Winterwolf said:

llOwnerSay("@shownames[:except_uuid]= yes");

should just be llOwnerSay("@shownames=y");

also, you can combine multiple commands into a single string:

for example: llOwnerSay("@shownames=n,shownametags=n,setdebug_renderresolutiondivisor:10.0=force");

February 14

17 hours ago, xJoni said:

vision pixelated

That's a RLV-specific thing that changes a debug setting, llOwnerSay("@setdebug_renderresolutiondivisor:8=force"); where 8 is the amount of pixelation.

Some combination of environment lighting settings can make a 'trippy' atmosphere. play with your personal environment settings, then see llSetAgentEnvironment

February 12

4 hours ago, PheebyKatz said:

Somewhere in this forum there's even at least a few examples of how to do this

I was prompted recently to post a rather old script I wrote that did such in the LSL library. It's actually rather subtle and tricky to do in a way that 100% won't crash in a room full of people with crazy (long&/funny symbols) names. (said example does crash)

February 12

2 hours ago, Karmaveat said:

is now no longer animating the "Kick" of the wearer.

you need the attach event from your first script to request the permission to play the animation before you play it (you can remove the permission to take controls).

February 10

2 minutes ago, Love Zhaoying said:

I am mostly referring to messages sent between scripts

I've never had occasion to rapid-fire messages from one script to another, but I'd assume script-to-script order is somewhat more reliable than script to viewer?

February 10

19 minutes ago, Love Zhaoying said:

AFAIK, any function that uses "queueing" Events, is pretty reliable to get delivered "in order" since that is part of..the point..with "queuing". IMO.

No matter what happens server-side (in LSL) I don't think there's any order verification in the client, (nor does the client send back received verification AFAIK) so, "pretty reliable" is the best you can hope for. I'm not sure what you mean by a "queueing event" but if you mean something like a timer() then it would be more reliable, if only because each event runs in a different 'frame' of computation, which adds an imperceptible delay.

February 10

2 minutes ago, Love Zhaoying said:

I have only NOTICED an issue with llSay() and messages arriving "out of order".

Same with me, but there are too many variables to make general claims. It could even be weird internet connection flukes.

February 10

16 hours ago, prootoxy said:

I don't understand what's going on with my script, does anyone have a solution?

the order you receive messages in is not guaranteed to be the order in which they were sent. Adding a short sleep after each message can increase the probability of a correct order, but in most cases, it shouldn't matter, and you can often consolidate the messages into a single message:

test() {
   integer i = 0;
   string send;
   for (; i <= 6; i++) {
        send+=(string)i+"\n";  
    }
   llOwnerSay(send);
}

February 9

8 hours ago, Wulfie Reanimator said:

Marketplace already has an API to get, create, modify, and delete listings for 10 years.

Perhaps I missed it in a quick skim, but the API seems to only be intended for the viewer to interact with, not a LSL script; It's unclear how the protocol validates that the requester is in-fact the merchant in control of the listing. Someone with intimate knowledge of the viewer could probably figure it out, but it doesn't seem like an intended use-case.

February 9

5 hours ago, LissomePrey said:

There is something odd about an object rezzing a copy of itself that is not a true copy but thinking about it, it is probably a good thing to stop griefing as objects that could rez multiple copies of themselves forever would be a gift to griefers, so good that it doesn't work.

I'm not old enough to remember "grey goo", but it's certainly possible if you're clever enough. Check out llRemoteLoadScriptPin(). it's a bit of a pain, but it mostly solves the matryoshka doll problem.

February 9

11 minutes ago, Katherine Heartsong said:

Yeah, the more I think about it it's really just a texture change, and turning off the object's "touch to buy" flag.

llSetLinkTexture(link_number,"texture's UUID (in quotes)",face_number);
// only one of the following 2 lines is really neccessary:
llSetClickAction(CLICK_ACTION_DISABLED); // or:
llSetScriptState(llGetScriptName(),FALSE);

somewhere in the money event right after a line that has llGiveInvenyory...

February 9

15 minutes ago, Katherine Heartsong said:

just want a script that works in world, attached to my painting on the wall, no tie into the MP at all

In that case, sounds like a fairly standard custom vendor script. If you already have a the code for a vendor script that already does most of what you want, I think some nice people might offer to add simple additions for free. From scratch on the other hand. . . Talking about exact prices is sticky territory, but I can't imagine it would take more than an hour or two of someone competent's time.

February 8

Making a script react/interact with the marketplace is very hard if not impossible. I'd be a bit wary of anyone who says they can (ask about other web-interaction projects they've done, chat with their references/actually look at said project). (MP-> inworld direction is much easier than inworld-> MP)

Just texture-change after some trigger is very easy.

February 8

8 minutes ago, Rolig Loon said:

this isn't a particularly difficult thing to script. It's simply a matter of modifying the money event in your current vendor script to trigger a texture change

The hard part that you might have glossed over is that she wants the in-world item to respond to a transaction happening on the marketplace.

Off the top of my head, I think the most practical way to get that to happen would be to forward marketplace emails to an in-world 'controller' object that could then send a message to the specific painting that had been sold. That could get mildly complicated, (and would differ a bit depending on whether a personal email forwards only relevant messages, or if the in-world script is set to receive all marketplace messages) but certainly not impossible.

The problem is making the marketplace take down a listing that has been bought in-world. I think it might be possible to have a 'bot' agent delete an item from their marketplace folder, thereby removing the listing, but if that doesn't work, making the script interact with the MP in any way would be very difficult if not impossible.

February 8

30 minutes ago, Rolig Loon said:

Just put a script into each rezzed object that kills it a specified time after it is rezzed.

default
{   on_rez(integer i)
    {   llSetTimerEvent(600.0); // die after 600 seconds == 10 minutes
    }
    timer()
    {   llDie();
    }
}

2 hours ago, Tyrak Gyranaut said:

when the person, that requested the Item is leaving the sim

To do that, the rezzing script would need to tell the rezzed object who requested it, which would require changes to the rezzing script. Alternatively, die if nobody is nearby:

float distance = 9.0; // how far away before de-rez. (in linden-meters)
default
{   on_rez(integer i)
    {   llSensorRepeat("","",AGENT,distance,PI,20.0); // check every 20 seconds.
    }
    no_sensor()
    {   llDie();
    }
}

February 7

14 hours ago, Extrude Ragu said:

I think Quiestess was saying you'd use an animation to offset the animesh, not to rotate it. ie you can still use target omega but you need a 1 frame animation that moves the whole animesh away from center

*coughs* Yes, I'm glad I considered that such would be much better than using the animation without omega.

February 6

SL linking doesn't have any 'heirarchy', so when you link the red box+animesh to the plywood cube, the animesh becomes linked as a child of the plywood cube.

The only solution I can think of would be to make an animation that moves the center joint, and apply that animation to the animesh.

February 5

1 hour ago, Wulfie Reanimator said:

Example?

Ignore me, I confused myself in testing by using scripts that had already been running and had triggered the timer before being rezzed, which resulted in confusing behavior.

February 4

Apparently, the attach event triggers before permissions are even accepted? anyway this seems to work as a toy example:

integer gHandleListenRLV;
integer gChanListenRLV = 1728;

integer gTriesGetRLV = 0;
default
{
    on_rez(integer n)
    {
        if(!llGetAttached())
        {   llRequestPermissions(llGetOwner(),PERMISSION_ATTACH);
        }
    }
    run_time_permissions(integer perms)
    {   if(perms&PERMISSION_ATTACH)
        {   llAttachToAvatarTemp(ATTACH_HUD_CENTER_1);
        }
    }
    attach(key ID)
    {   gTriesGetRLV = 3;
        gHandleListenRLV = llListen(gChanListenRLV,"",llGetOwner(),"");
        llSetTimerEvent(0.5);
        llOwnerSay("@camdistmax:10=n,getstatus="+(string)gChanListenRLV);
    }
    listen(integer Channel, string Name, key ID, string Text)
    {   llOwnerSay("RLV activation confirmed: \n"+Text);
        llSetTimerEvent(0);
    }
    timer()
    {   --gTriesGetRLV;
        if(gTriesGetRLV>0)
        {   llOwnerSay("RLV not received, retrying");
            llOwnerSay("@camdistmax:10=n,getstatus="+(string)gChanListenRLV);
        }else
        {   llOwnerSay("RLV failed. No more retries.");
            llSetTimerEvent(0);
        }
    }
}

February 4

27 minutes ago, ItHadToComeToThis said:

might have to fudge it using camera params

camera params don't work if the camera is unlocked from the avatar, which, depending on how one uses the camera, could be most of the time.

February 4

I haven't but given that you're doing testing at the moment, I'll presume there is some issue there.

The alternatives to tempAttach are regular llAttachToAvatar, and #RLV folder attaching. llAttach is a pain, because it doesn't handle ownership transfer, you have to get the recipient to buy the object (for 0L$) before it can attach, and #RLV folder attaching has all kinds of timing and communication issues that need to be handled delicately in the script.

For being stubborn in a temp attachment, you could try @getstatus to confirm/deny the rlv was successfully applied, and retry if no/unexpected response received.

February 4

11 hours ago, Jenna Huntsman said:

Which should always point (+Y axis) at the user's camera while keeping the object's +Z axis aligned with the camera's UP axis

couldn't you just take the camera's rotation and left-multiply by a 90 degree turn on the z-axis?

rotation point_y_to_camera = <0, 0, 0.70711, 0.70711>*camera_rotation;

Forums

Blogs

Knowledge Base

Posts posted by Quistess Alpha

Linden Lab

Tilia

Second Life

Connect With Us

Partner With Us