Jump to content
Sign in to follow this  
ChaosFear

What am I doing wrong?

Recommended Posts

string group_id = "44459af0-a7e3-ebce-5d9d-e15ab8d66be1";
string message = "Click Here To Join Club Malvado:";
integer channel = 13563;
key gAV;

 

default
{
state_entry()
{
llListen(channel,"","","");
}
collision_start(integer num_detected)
{
gAV = llDetectedKey(0);
llDialog(gAV, "Welcome to Club Malvado!! Please select from the following:", ["Get LM", "Join Group", "Club Info", "Get All"], channel);
}
listen(integer chan, string name, key id, string mes)
{
if(mes == "Get LM")
{
llGiveInventory(gAV, "Club Malvado");
} else if(mes == "Join Group")
{
llInstantMessage(gAV, message + " secondlife:///app/group/" + group_id + "/about");
} else if(mes == "Club Info")
{
llGiveInventory(gAV, "Club Malvado Info");
} else if(mes == "Give All")
{

}
}
}

Share this post


Link to post
Share on other sites

you forgot to fill in what give all dose.

} else if(mes == "Give All")
{
        "something goes here"
}

 

Share this post


Link to post
Share on other sites

In state_entry you open a listen - why? - it's not used.

In collision_start you send a menu to the avatar that triggers it and open a listen. So far so good. The If's are useless though. If the avatar clicks an option the avatar chats the button text on the specified channel.

Your script can't hear that since you have no listen event.

So make a listen event and thats the place to check the buttons and do the actions.

Dont forget to close the listen.

What you do if the avatar doesnt click an option? For that you need a timer event to close the listen for example after 30 seconds of inactivity.

What you do if multiple avatars collide? Things like timers and closing listens get complicated if you need to keep track of multiple avatars. Postpone that problem. Make it 1st run for one avatar.

Not closing the listens is no option: It's a waste of resources and once the script has 65 listens open thats it. No more listens, it's locked now.

 

Share this post


Link to post
Share on other sites

Well, I think the confusion is mostly caused by lack of text formatting. The script doesn't open a new llListen() in the collision_start() event handler; rather, that's a listen() event handler. And it's generally okay to just keep one listener open forever, rather than managing a fresh one each time a dialog is raised. (Yeah, it's primitive but it will work, and given an obscure enough channel, there will never be enough crosstalk for the listener to have any impact.)

Besides the listen() handler simply having no code to handle the "Get All" input, as Calamari points out, the script is also using a global variable as if the avatar who last collided with the object will always be the next one responding to the dialog -- which means the script will be texting and sending stuff to the wrong person much of the time. Luckily, there's no reason for it. Just delete the gAV global variable and instead use "id", the locally-bound variable in the listen event.

Share this post


Link to post
Share on other sites


Qie Niangao wrote:

... it's generally okay to just keep one listener open forever, rather than managing a fresh one each time a dialog is raised. ...

 

You can have that opinion. But until someone can prove listens don't consume server resources, my attitude regarding them is the same as I have for the lights in my home:

Turn 'em on when needed, off when done.

Share this post


Link to post
Share on other sites

Oh, I'm sure a listen consumes some server resources just being open -- at least a few bytes of memory somewhere as record of the script's interest for when an event is raised on the subject channel. I, too, would love to know more about the detailed performance effects of an open listen, along with everything else. Then we'd be equipped to make some better decisions -- although not necessarily easy rules-of-thumb.

For example, the alternative to an open listen is some code (using more memory -- or maybe less? -- than that needed for a persistent open listen) that calls a timer -- where an interval timer (or, more precisely, a homegrown scheduler approximation of an interval timer) instantaneously consumes more CPU to insert and remove than does the very listener entry it may delete on expiry. So then the tradeoff involves the dynamics of demand: if the frequency of user interaction is greater than once a TBD interval, leave the listener open, else spend the extra resources for a timer (plus creating and deleting the listener again), where we don't know if "TBD" is best expressed in minutes, fortnights, or half-lives of the universe.

So yeah, in lieu of some really detailed performance data about the script engine, it's a judgment call, and I'm only guessing that an open listen on an obscure channel is less like lights left on than it is like an LED night light left plugged in during the day.

Share this post


Link to post
Share on other sites

I have have no disagreement with any of that. judgment call based on one's opinion is different than a general rule based on facts though, which is all I was pointing out.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...