Scripting Questions.

Hello,

I am new to linden script / second life. I am working on an interactive learning module which may or may not be plausible in second life.

I am having difficulty with linking objects.

Here is what I would like to accomplish.

Have a cylinder with an X number of holes. Have an X number of smaller cylinders that will be fitted into the holes.

Have a user place the enter data into some of the smaller cylinders.

Have the user place the smaller objects into the larger object, in a correct order. (By I guess clicking on the objects in the order they want them to be placed, the user can also be prompted for the data at this point as well I guess). If the order is correct after all objects are placed in the cylinder will light up. If its incorrect, have the cylinder eject all of the objects and have the user try again.

Once the object is completed, have the user sit on the object or place the object on a vehicle and based on the data entered into some of the smaller cylinders earlier on, have the vehicle / cylinder drive to a destination Y or Z.

As of right now I am not worried about texturing as that can be worked out later on, just functionality. I am having difficulty getting objects to interact.

Here is some code I have: I am working with small squares.

Object 1:

Object 2:

What this does is have object 2 move on top of the other one once object 1 is clicked. However, I would like the two objects to become linked when this happens.

Ive tried to use http://wiki.secondlife.com/wiki/LlCreateLink but have had no luck with that as the examples deal with rezing objects. I was thinking maybe have the starting cylinder rez the smaller cylinders around it to get started but have no clue how to go about that.

Any help / feedback would be appreaciated particullary regarding the plausibility of what I am trying to accomplish. (as well as how long it might take). I am also new to second life and my exposure to what is capable in second life limited. I am not too familiar with object keys, parent objects, and such.

It's difficult to know where to start with this question. My first reaction is that the overall plan is quite ambitious, especially as a starting point for using LSL.

My second reaction is that the instructional goal of all this mechanism isn't very clear (to me, anyway). I guess I mean that, however elegantly it's implemented, the end user interaction seems inordinately complex, such that the students will have to learn a whole bunch of stuff about how to use the thing before they can start learning anything that the thing is trying to teach them (whatever that may be; I'm supposing that learning to operate the device is not the end goal here).

For the immediate problem of getting objects to link, though, it's not that complicated. The examples for llCreateLink() happen to get the key of the object to be linked by virtue of having rezzed that object, but it could know that key in lots of other ways. In the code cited here, for example, the listener knows the key of the object that sent the message (the "id" parameter of that event handler), so a minimal change to that second script might be something like:

integer listen_handle;

default
{
    state_entry()
    {
        llRequestPermissions(llGetOwner(), PERMISSION_CHANGE_LINKS);
    }
    run_time_permissions(integer perms)
    {
        if (PERMISSION_CHANGE_LINKS & perms)
            listen_handle = llListen(-25321, "", "", "");
    }
    listen( integer channel, string name, key id, string message )
    {
        vector position = (vector)message;
        position.z = position.z + .5;
        llSetPos(position);
        llCreateLink(id, TRUE);
    }
    touch_start(integer total_number)
    {
        vector position = llGetPos();
        llRegionSay(-25322, (string)position);
    }
}

or presuming that the object that is being moved is considered the child linked to the parent, simply use qie's changes in a listen in the parent object

(all I could get from the decription was something similar to a shape board, with the addition of user input for something like color? :hrug:

I am not sure why you want to link the two prims together.
To get this done you will have to ask permission to do so.
For non attached objects, this will bring up a dialog window.

At the moment, your large prim (the prim bucket) is shouting out
its position. In order to link them together it is necessary for the small prim
to reply so we know its key.

This goes in the small prim:


default
{
state_entry()
{
llListen( -25322, "", "", "" );
}
listen( integer channel, string name, key id, string message )
{
vector position = (vector)message;
position.z = position.z + .5;
llSetPos(position);
float wait = llFrand(5);
llSleep(wait);
llRegionSay(-25322, (string)position);
llListenRemove(-25322);
position.z = position.z - .4;
llSetPos(position);
}
}

-------------------------------------------------------------------------

This goes into the prim bucket:

key target = NULL_KEY;
integer chan_1 = -25322;

default
{
state_entry()
{
llListen(chan_1, "", target, "";
}
touch_start(integer total_number)
{
vector position = llGetPos();
llRequestPermissions(llGetOwner(), PERMISSION_CHANGE_LINKS);
llRegionSay(chan_1, (string)position);
}
listen(integer channel, string name, key id, string message )
{
llSay(0,"received message from prim: " + (string)id);
target = id;
}
run_time_permissions(integer perm)
{
if (perm & PERMISSION_CHANGE_LINKS)
{
llCreateLink(target,TRUE);
llSleep(1.0);
target = NULL_KEY;
}
}
}

A simpler approach would be to have the pieces pre-linked, and toggle their visibility using llSetLinkAlpha() or llSetAlpha(). That way the linking and moving is eliminated.

Touching the part on the ground (or wherever it is), would send a message to the pre-linked copy of that part and tell it to show, while the part clicked would hide itself. This gives the illusion it moved, and would accomplish the same result.

I'll guess we have to wait for Zib to tell us what he exactly has in mind
and where he wants to take it.

Haha, you have no idea how ambitious this is. This is only a small part of a larger "theme park", which I am the sole person building, with a deployment date for preferably Fall 2009 but most likely Spring 2010.

I guess I should have gone into the purpose a bit more. This is the 2nd module of a research project that will be used quantify the impact of virtual worlds on learning.



Right now, module 2 has been scaled down a bit and to get started it will be a module used in a 200 level college cyber security course to reinforce some basic networking concepts. The large cylinder will represented an internet packet, with the smaller cylinders representing the different parts of a packet such as the header information.

Students (working in teams) once they correctly assemble the packet will be taken to a blown up version of a router, which will send them to a switch... then the internet... switch... and back to a router again. If they input the incorrect header information / incorrectly assemble the packet, then the packet obviously wont work.

I came on this project as an undergraduate researcher in march to do PHP programming for e-commerce websites as a part of module 1 and said I was willing to learn some linden script as well to help out. Our person who had been working on module 1 doing second life work for over a year is gone doing an internship with Boeing and we are finishing up module 1 so I am essentially being thrown to build module 2 with no prior experience in linden script. I am completely clueless how feasible this is considering the man power we have (me lol). The learning curve for linden script also seems to be atrocious.

Anyway, I am going to take a look at some of the scripts you guys posted as well as some of the suggestions you made.

best of luck on this. it's a really interesting project, that has lots of potential for some folks (tcp/ip has to be one of the dullest driest class subjects ever created) the concept you're playing with has definite potential to make it more accessible to visual learners, so it'll be interesting to see where it goes.