Jump to content

What am I doing wrong?


ChaosFear
 Share

You are about to reply to a thread that has been inactive for 3627 days.

Please take a moment to consider if this thread is worth bumping.

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")
{

}
}
}

Link to comment
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.

 

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3627 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...