Listener or flow issue?

[Artorius Constantine]

This is a matching game. The brain rezzes a bunch of gravestones and renames them all.

Touching one of them rezzes an object, like a bat or a skull, that object uses llRegionSay to swap messages with other objects and the rezzing object.

Regionsay "I'm a cross" on rez then listens.

if message = "I'm a cross" Regionsay "me too" and do stuff

Then if message = "Im a cross too" do stuff.

Now the problem is the rezzing object, after the touch event that rezzes the llRegionSaying object it stops listening, I think.

Works great for me, not for the next owner. I do have the new owner check first.

This is the Rezzing object script. The "clear" message is from the brain to clean the playing field.

default
{
    changed(integer change)
    {
        if (change & CHANGED_OWNER)
            llResetScript();
    }
    on_rez(integer start_param)
    {
        llSay (0, "Ready");
        llSetPrimitiveParams([PRIM_NAME, "Tombstone"]);
        llListen(-3333,"","","");  
    }
    touch_start(integer total_number)
    {
        llRezObject("Small Cross", llGetPos() + <0.0,0.0,1.5>, <0.0,0.0,0.0>, <0.0, 0, 0, 0.0>, 0);
        llListen(-3333,"","","");
    }
        listen(integer channel, string name, key id, string msg)
    {    
    if (msg == "clear")
    { 
    llSay (0, "Clear check");
    llSleep(.5);
    llDie();
    }
    if (msg == "me one")
    { 
    llSay (0, "me too check");
    llSleep(.5);
    llDie();
    }
}
}

The rezzed objects is giving it's messages fine. I added the Listen after the touch event to try and fix the issue. that wasn't in the first draft.

the rezzing object only has to do stuff on a Clear command from the brain or a match command from a rezzed object. It doesn't need to hear anything else.

[Emma Krokus]

Just wondering if the object to be rezzed has transfer permissions to be rezzed by the next owner...

[Ruthven Ravenhurst]

in the on_rez event you're opeing a listen, but in the changed event, if it's a new owner the script is being reset, basically removing that listen. in the touch event you have it open the same listen, so until the new owner touches the rezzer, it won't be able to listen for anything. the thing is, there's nothing here that seems to rely on the owner, so the changed event seems un-necessary. I would move the llListen to a state_entry, or use a llListenRemove, which also seems un-necessary as it's still going to listen on the same channel, otherwise it will continue to stack listens, and you'll get a too many listens error.

[Artorius Constantine]

Yes on Transfer permissions. That's tricky enough on games, especially with prizes.

This one is simple, it's all full copy for the next owner and nothing else.

I got lost in the listeners I think. I have always added the changed owner reset because listeners tend to stick to the last owner. Even when not assigned that way. It's kind of a catch all for me when I use listeners.

I normally close them too but in this case the object dies right after most messages so didn't think it was needed.

You think it's flow then? I started moving the listen around late last night and adding new ones.

I just did one where I slowed down the messages coming from the rezzed object and that seemed to work.

Maybe it just wasn't getting time to change states before the message was being sent?

I'll move the listen to a state entry and see what happens.

[Rolig Loon]

Listens will not "stick" to the last owner unlesss you have written something like

llListen(my_channel,"",gOwner,"");

and then neglected to clear the owner's key from gOwner before transfering ownership. Even then, it's generally smarter to write

 

changed (integer change){    if (change & CHANGED_OWNER)    {        gOwner = llGetOwner();    }}

than to restart the whole script.  In this case, as Ruthven points out, there's no point in doing either one, since there isn't anything in your script that depends on knowing the owner.  She's also right that you are creating problems for yourself by putting llListen in the touch_start event.  Every time someone touches your object, the script will open a new instance of llListen.  After 65 clicks, you will have hit the cap and the script will jam.  Read http://wiki.secondlife.com/wiki/LlListen#Caveats carefully.

 

[Artorius Constantine]

Pulled all the listeners and added a state entry with one in it.

Originally I only had one listener in the On_Rez state. I added the others tweaking but that didn't help anything.

Seems to work. Ran the alt test and it passed but now the rezzed object is acting up! I didn't even do anything to it grrrr.

At least the base is listening now yay!

Edited to add, that was definitely the issue. I did the same thing to the rezzed object, ie moved the listener to a state_entry instead of the on_rez event. Works perfectly for everyone now Thx!

[Ela Talaj]

There is no need in 'changed' event if you call the llListen method as  llListen(my_channel, "", llGetOwner(), "");

By the way, I just wonder where this "g" comes from in your llListen(my_channel,"",gOwner,""); Seen it in many scripts... gThis, gThat... What's so magic about the letter "g" ? Seems to me llListen(my_channel,"",owner,"") would be just fine.

[Ruthven Ravenhurst]

copied from one of my threads https://community.secondlife.com/t5/LSL-Scripting/Listener-or-flow-issue/td-p/3061744

---

Rolig Loon wrote:

Heh... You're right.  I should have decrimented num at the end of the loop, not at the start. You should reach num = 0 then.  Sorry about that.

Oh, and I'm following a common practice of identifying glocal variables with the "g" prefix.  When I am more careful, I also use a prefix of "i", "s", "f", "k", "v", "r", or "l" to identify the variable type.  It can be easy to get confused about what your variables are when they are scattered over several hundred lines of code, so a helpful label can be important.

---

 

[Rolig Loon]

---

Ela Talaj wrote:

[ .... ]

By the way, I just wonder where this "g" comes from in your

llListen(my_channel,"",gOwner,"");

Seen it in many scripts... gThis, gThat... What's so magic about the letter "g" ?

Seems to me

llListen(my_channel,"",owner,"")

would be just fine.

---

That's a fairly common convention among LSL scripters.  There are no "rules" in LSL itself about how to name variables, but it can be convenient to create rules for yourself.  In this case, many scripters use the prefix "g"  as a way to remind themselves that a variable is global and can therefore be affected by actions outside of the immediate scope where we may use it.  There's absolutely nothing "magical" about it.  Because so many scripters use that convention, though, it can make reading another scripter's work a little easier.

[Madelaine McMasters]

---

Rolig Loon wrote:

---

Ela Talaj wrote:

[ .... ]

By the way, I just wonder where this "g" comes from in your

llListen(my_channel,"",gOwner,"");

Seen it in many scripts... gThis, gThat... What's so magic about the letter "g" ?

Seems to me

llListen(my_channel,"",owner,"")

would be just fine.

---

That's

a fairly common convention

among LSL scripters.  There are no "rules" in LSL itself about how to name variables, but it can be convenient to create rules for yourself.  In this case, many scripters use the prefix "g"  as a way to remind themselves that a variable is global and can therefore be affected by actions outside of the immediate scope where we may use it.  There's absolutely nothing "magical" about it.  Because so many scripters use that convention, though, it can make reading another scripter's work a little easier.

---

It's a fairly common convention among all coders...

https://en.wikipedia.org/wiki/Hungarian_notation

The notable opinions at the bottom of the page are interesting.

[Artorius Constantine]

The final script came out beautiful. There is definitely an art to it. Thx again!

default{    on_rez(integer start_param)    {      llSetPrimitiveParams([PRIM_NAME, "Clamshell"]);    }    state_entry()    {       llListen(-3332,"","","");     }    touch_start(integer total_number)    {       llRezObject("Seahorse", llGetPos() + <0.0,0.0,1.5>, <0.0,0.0,0.0>, <0.0, 0, 0, 0.0>, 0);    }    listen(integer channel, string name, key id, string msg)    {         if (msg == "clear")       {        llSleep(.5);       llDie();       }     if (msg == "me five")       {        llSleep(.5);       llDie();       }   }}

 

Yesterday I added a notecard to an object script so the user can define messages the Fairies say when you catch them and added 3 choice dialog boxes for the first real time. Now you can release the fairy, keep the fairy or feed it to the Troll. First time using either of those functions. Worked out well! I wish I had learned ll years ago.

[Ela Talaj]

Maybe in Hungary

Usually every more or less sizeable software company or department would have a coding style manual. I've seen many of those and participated in writing some, yet never encountered anything remotely comparable to this Hungarian style. Commonly a variable name is expected to show what this variable is for not how it's declared. Indeed considering that in most programming languages global varuiables are  '#include'-ed there is absolutely no need in such convention.

[Madelaine McMasters]

---

Ela Talaj wrote:

Maybe in Hungary

Usually every more or less sizeable software company or department would have a coding style manual. I've seen many of those and participated in writing some, yet never encountered anything remotely comparable to this Hungarian style. Commonly a variable name is expected to show what this variable is for not how it's declared. Indeed considering that in most programming languages global varuiables are  '#include'-ed there is absolutely no need in such convention.

---

I never worked for a software company. The smaller shops where I worked/consulted were all doing embedded hardware/software design and the naming conventions were as varied as the engineers writing the code. The first person I saw using this technique was my father. Identifiers were limited in length (eight chars or so, as I recall) so highly descriptive names were out of reach and he had a shorthand all his own.

As languages become more type safe such gimmicks are less useful, but there are still people (Rolig included) using this technique to avoid type-ing errors.

[Rolig Loon]

Not necessarily to defend the practice specifically, but I would point out that:

1. LSL doesn't have a native #include function, although you can certainly use editors that have one as an add-on.

2. With only a few exceptions, scripters in LSL are not employees of a more or less sizeable software company or department.  Most, in fact, are not professionals coders at all.

3. Although Linden Lab itself has a coding standard, residents are not required to use it and, in fact, are largely unaware that it exists.

4. As the article that Maddy quoted says, there is quite a range of opinion about whether to use a Hungarian style, but it is far from uncommon.

Every once in a while, I run across someone who is a professional coder in RL and who has a peculiar distain for the relaxed, inconsistent style of most LSL scripters.  That has always seemed odd to me.  There's no good argument for being deliberately sloppy, of course, and there are plenty of arguments for having well-accepted standards.  At the same time, though, one of the most attractive features of Second Life is that it welcomes amateurs.  It's an open environment, presented for users to play with, not just play in.  In that spirit, I find it refreshing that LSL scripters develop their personal style conventions and experiment with "rules" that make sense for them.  In the end, the practical measure of whether a script is "good" or not is how well it works, not how pretty it is.

[Rhonda Huntress]

If I could I would define constants in the header and not use global variables at all.  Ever.

Without the benefits that come with object oriented languages like encapsulation and method overloads, sometimes you need to keep up with a variable's scope and what it really is despite how it was declared.  bAmountRecieved and nAmountReceived are noticeably different; one will tell you if an amount was received and the other tells you how much that was.  Both are usually declared as integers tho.

You will probably see more older code monkeys using this since it was all the rage at Redmond, Washington way back when.  However it is mostly archaic trivia in modern programing.

[Madelaine McMasters]

---

Rhonda Huntress wrote:

If I could I would define constants in the header and not use global variables at all.  Ever.

 

---

In tiny systems, globals can be pretty efficient, if a bit dangerous. I did use b/n type prefixes until my compilers started supporting bitfields. Now I park booleans in things like Flags.AmountReceived.

One of these days I'll try my hand at an OOL. They've always been too full of bloat (both in code size and learning curve) for the tiny systems I worked on. My first and last OOP experience was with SmallTalk.

[Rhonda Huntress]

I had a parallel algorithms class a long time ago.  There were not many multi-cpu machines back then and certainly not in a computer lab.  So we had to "estimate" the total time by counting the time of each seperate process.

I wrote my lab in C++ without all the includes and crap.  I just made a CPU object that kept track of ist own usage time and method pointers so it could take whatever the next step was.  All of the functions that would be bound to the methods at run time (the actual algorithm's process) were then #included from a separate file.  That separate file was the actual program I expected to graded on. 

Anyway, like all the other upper level professors I net at the time, I had to explain what object orientated programming was.  This was in the 90's and OOP was not new.  There was OO Cobol for heaven's sake.  Something about being a PHD means you suddenly to high up to be concerned with things like technology. ... OK, side track there .. back to story.  The professor was so stunned because I could simple say, lets use 52 CPUs on the next run and all I was dong was increasing the number of instances of the single object that he started cal C++ C for multiple Computing.  I never had the heart to tell him that we could have done it all easier making it multithreaded in the compiler but I needed to keep track of each CPU's total run time.

 

Anyway. leave all the bloated headers out of the project and just play with a few objects some time.  Especially if you are used to C and keeping up with pointers and variables through function calls.  When all the data is global to the functions that need them and nothing else it just suddenly clicks.  At least it did for me.

[Artorius Constantine]

My first computer language was Fortran. Yes that's right. I fed punch cards into a binary "computer".

One card out of place and it didn't work. So pretty much the same as ll. =)

[Rolig Loon]

---

Artorius Constantine wrote:

My first computer language was Fortran. Yes that's right. I fed punch cards into a binary "computer".

One card out of place and it didn't work. So pretty much the same as ll. =)

---

Mine too. Fortran II, on a machine that you had to boot with sense switches and a paper tape reader.  I'm glad we're past those days.

[Madelaine McMasters]

---

Rhonda Huntress wrote: a bunch of computery stuff.

---

Apple has open-sourced Swift, and there's a port for the RaspberryPi. That'll be my re-introduction to OOC. There's a lot of fun to be had with the "Internet of Things"... after I redo the mistress bathroom.

[Madelaine McMasters]

---

Rolig Loon wrote:

---

Artorius Constantine wrote:

My first computer language was Fortran. Yes that's right. I fed punch cards into a binary "computer".

One card out of place and it didn't work. So pretty much the same as ll. =)

---

Mine too. Fortran II, on a machine that you had to boot with sense switches and a paper tape reader.  I'm glad we're past those days.

---

I wasn't far behind you. I grew up watching paper and mag tape scoot around here in Dad's office. I'm sure there are still paper dots hidden in floorboard cracks. I watched a punched card sorter somewhere when I was little. I wanted it. (I wanted everything... still do.) The first machine I programmed was a PDP-11 with floppies, via RT-11 BASIC. I learned enough Fortran to make me hate it.

I like assembly language, stick shift cars and cotton clothing. It's all about the feel.

[Rhonda Huntress]

Anyonw who has used Fortran should feel right at home with strided lists

[Madelaine McMasters]

---

Rhonda Huntress wrote:

Anyonw who has used Fortran should feel right at home with strided lists

---

I think the first Fortran I encountered was IV, which had multi-dimensional arrays. I took a compiler design class where we were to write one using Fortran 77. I thought that was crazy and did something else. That earned me a "D" which I got raised to a "B" by the dean, putting me near the top of that class.

You can't make me write in Fortran. Nuh uh.