Logo

Maggie · 07-17-2012, 12:20 PM

I have a project that I'm working where if a J Random avatar clicks on it, it hands them a LM. But if the owner clicks on it it tosses up a control menu.

From a simplicity point of view it would be simpler to break this up into 2 scripts. One for the LM giver and another script for the control menu. A more complex script could do both but would be harder to maintain. A single script would also be better on sim resources.

Chalice Yao · 07-17-2012, 12:25 PM

No. That's so utterly simple, breaking that into two scripts pretty much equals breaking into scripts every time an if() statement could be used.

Code:

integer iListener;
key kOwner;
default
{

  state_entry()
  {
    kOwner=llGetOwner();
  }

  on_rez(integer foo)
  {
    llResetScript();
  }

  touch_start(integer foo)
  {
    if(llDetectedKey(0) == kOwner)
    {
      iListener=llListen(12345,"",kOwner,"");
      llSetTimerEvent(10);
      //domenuhere on channel 12345
    }
    else
    {
      //Else give landmark <- Don't break up the script because of this.
    }
  }

  timer()
  {
    llListenRemove(iListener);
    llOwnerSay("Menu timed out!");
  }

  listen(integer channel, string name, key id, string message)
  {
    //Handle menu replies, possibly restart timer to wait for new button clicks.
  }

  changed(integer change)
  {
    if(change & CHANGED_OWNER)
      llResetScript();
  }
}

Really, that's not even close to being hard to maintain.

Adeon Writer · 07-17-2012, 12:37 PM

Quote:

Originally Posted by Chalice Yao

No. That's so utterly simple, breaking that into two scripts pretty much equals breaking into scripts every time an if() statement could be used.

You wouldn't believe the things this one person would go though to avoid using an if statement. I'm not sure if they had a learning disability, or what, but they got angry at me whenever I suggested using it, they said it makes them feel uncomfortable, and that and they didn't want to use it. Eventually they decided they'd learn to script somewhere else and didn't want my tutoring anymore.

I really meet the most interesting people.

Maggie · 07-17-2012, 12:41 PM

Oh I see. That is simpler that what I was planning to do. I was planning something with states. One state for owner and one state for everyone else.

Thanks.

Now I'm wondering why I didn't think of that.

Chalice Yao · 07-17-2012, 12:43 PM

Quote:

Originally Posted by Maggie

Oh I see. That is simpler that what I was planning to do. I was planning something with states. One state for owner and one state for everyone else.

Thanks.

Now I'm wondering why I didn't think of that.

:3

I can't remember the last time I used states. But that's personal preference. Usually I just use if()s for stuff like that. Changing states only makes sense if you really wish to radically change the entire behavior of the object, IMO.

Maggie · 07-17-2012, 12:46 PM

Quote:

Originally Posted by Adeon Writer

You wouldn't believe the things this one person would go though to avoid using an if statement. I'm not sure if they had a learning disability, or what, but they got angry at me whenever I suggested using it, they said it makes them feel uncomfortable, and that and they didn't want to use it. Eventually they decided they'd learn to script somewhere else and didn't want my tutoring anymore.

I really meet the most interesting people.

Really, its silly the thing that people get upset about. Sometimes its like learning something new can be fatal. The problem I'm having is I'm coming over from a system programming style to an event driven one. I'm not used to thinking in these terms. For some reason my brain is having issues with it, but I'll figure it out.

Adeon Writer · 07-17-2012, 01:07 PM

Quote:

Originally Posted by Maggie

Really, its silly the thing that people get upset about. Sometimes its like learning something new can be fatal. The problem I'm having is I'm coming over from a system programming style to an event driven one. I'm not used to thinking in these terms. For some reason my brain is having issues with it, but I'll figure it out.

It took me a while to realize they weren't trolling! They clearly had a rather good understanding of syntax, programing flow, and loop structures, yet they'd go out of there way to never use if(). Ridiculously insanely out of the way. Like the same way many choose to avoid goto/jump at all costs, only much harder. Like, *I'd* have trouble pulling it off.

But yeah. As a general rule, it's best to avoid breaking code into multiple scripts unless it's an absolute must due to some LSL shortcoming or a set/get link function that should exist but doesn't yet. (there's a few remaining)

**Void** · 07-17-2012, 01:42 PM

as a further note, states aren't really such a great thing to use in LSL... they seem like it, but they're really special purpose. the only time they really are useful is to limit/change what input events (rather than how they act) are available, and the side benefit of dropping all open listens... they have drawbacks like dropping queued events, and taking longer to set up though. for behavior changes on the input, simpler and more efficient to just use flags or tests.

it will probably help if you think of events in an object oriented manner of handlers for specific inputs, and treat states optional switches for the kinds of input you are willing to accept.

@Adeon:
You really DO meet "interesting" people o.O (and I would've thought troll too!)

about the only time I'll avoid using a test is if it makes me duplicate the same code, in which case I'll try to do it with a flag and inline math if possible.

ETA:
might want to avoid storing owner key for the check as in Chalice's example... if you check directly against the llGetOwner the performance loss isn't significant and you no longer need to reset or update it when the owner changes... I'd only use the variable if there's a need to reset on owner change or you find yourself needing that owner key to use a whole lot. but that's a style difference

Chalice Yao · 07-17-2012, 01:53 PM

Quote:

Originally Posted by Void

ETA:
might want to avoid storing owner key for the check as in Chalice's example... if you check directly against the llGetOwner the performance loss isn't significant and you no longer need to reset or update it when the owner changes... I'd only use the variable if there's a need to reset on owner change or you find yourself needing that owner key to use a whole lot. but that's a style difference

Yeah, I tend to do owner checks lots, hence I've built up the habit :3

Adeon Writer · 07-17-2012, 01:54 PM

Hm, I use states in my light switch examples. Having only two touch_start's, one in each state, each sending the code to the other, seemed to get people started quicker before learning global variables. And simple light switches/toggles seem to always get requested.

Chalice Yao · 07-17-2012, 02:07 PM

Quote:

Originally Posted by Adeon Writer

Hm, I use states in my light switch examples. Having only two touch_start's, one in each state, each sending the code to the other, seemed to get people started quicker before learning global variables. And simple light switches/toggles seem to always get requested.

Global vs. local variables in LSL is another thing that's just...counterintuitive and backwards compared to most other languages. I almost never use local variables and instead re-use global ones. Globals in LSL are faster, and it takes less work internally to use them :< Local variables just make maintaining things easier.

**Void** · 07-17-2012, 03:24 PM

heh I actually use the opposite approach there and use a global flag to get them more comfortable with the idea of boolean switches... once they're comfortable with those it's so much easier to explain bitwise operators and bit masks

(although then the hurdle becomes teaching the relation between bitwise operations and integer math, but hey one step at a time right?)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

07-17-2012, 12:41 PM	#4 (permalink)
Maggie Senior Member penguins rule! Join Date: Jan 2012 Posts: 1,364 My Mood: SL Join Date: 5/30/2011 Client: Firestorm	Oh I see. That is simpler that what I was planning to do. I was planning something with states. One state for owner and one state for everyone else. Thanks. Now I'm wondering why I didn't think of that.

07-17-2012, 01:54 PM	#10 (permalink)
Adeon Writer Senior Member Join Date: Apr 2010 Posts: 6,081	Hm, I use states in my light switch examples. Having only two touch_start's, one in each state, each sending the code to the other, seemed to get people started quicker before learning global variables. And simple light switches/toggles seem to always get requested.

07-17-2012, 03:24 PM	#12 (permalink)
Void That Bitch *SLU Supporter* Innocent as far as you know Join Date: Nov 2011 Location: Online Posts: 6,195 My Mood: SL Join Date: late 04... that account is deleted now	heh I actually use the opposite approach there and use a global flag to get them more comfortable with the idea of boolean switches... once they're comfortable with those it's so much easier to explain bitwise operators and bit masks (although then the hurdle becomes teaching the relation between bitwise operations and integer math, but hey one step at a time right?)

Logo

Site Navigation