Jump to content

Tutorial videos for beginners - an experiment :)


xigaro
 Share

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

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

Recommended Posts

Hello! I'm trying an experiment and making some tutorial videos for scripting. I hope they're useful to beginners or people who want to brush up on the basics. Or they might be junk :) I'm not as excitable as Torley but I laugh too hard at my own jokes.

Part 1 - what is scripting

Part 2 - states

Part 3 - events

Part 4 - variables

 

If you find them useful or have ideas please let me know here or on Youtube and I will make some more :) I can also make videos on specific questions if you have any.

- xigs

Link to comment
Share on other sites

The reason touch event did not work in the begining of the event tutorial was because the default state  immediately sent the flow to the Dance State.  Events are only triggered in the State you are currently in.

This is the reason that good scripters always  try  avoid  doing any state changes.......state changes are not needed in any script. It does take a bit more skill  to not use any state changes  but once you learn to do without state changes  your scripts will run much more efficiently and  have far fewer bugs.

keep up the good work xigaro....its nice to see you trying to help new scripters :)

Link to comment
Share on other sites

Well.... I agree that it's wise to avoid overusing state changes.  It's very easy to lose track of variables or -- more to the point -- their values as they are passed from one state to another and, yes, multi-state scripts generally use more memory.  In general, you can write many scripts efficiently with only a default state.  However, there are several perfectly good reasons for having extra states.  For example, a script that reads setup values from a notecard or does other one-time tasks on start-up very often does those in state default and then passes control to a new "running" state from which it never (or rarely) returns.  As another example, a script that asks a user to verify access permission will often do that in one state and then pass control to another state once access is approved.  Those sorts of tasks can indeed be written in a single state, but separating them into two or more states makes it easier to isolate one task from another.  It also saves the scripter from having to carry a pile of flags around to switch events from doing one task to doing another one.  It's easy to think of many other examples of scripts that are made simpler/more efficient/easier-to-read by using states judiciously. 

Link to comment
Share on other sites

Sorry, this won't work for me and I can't see how it would work for anyone else. Visual video tutorials work for visual applications. However, LSL is a textural medium, it's written. It's not the same as Blender (a visual application) which makes visual tutorials appropriate.

 

Perhaps if you rethought all this into a series of text tutorials explaining how LSL uses scripts to express what is wanted into the SL virtual world; explaining basic computer science concepts such as logic flow and how LSL controls it, how LSL uses states and events to implement an application and then get deeper into the "workings" of it all (such as variable scope and what the difference is between Logical and Boolean operators) .

 

IMO, that effort would be more helpful than another series of videos that only go to show that "there might be something there, if you could only know when to pause & study the video and be able to refer back to that point later".

Link to comment
Share on other sites


dd Temin wrote:

The reason touch event did not work in the begining of the event tutorial was because the default state  immediately sent the flow to the Dance State.  Events are only triggered in the State you are currently in.

This is the reason that good scripters always  try 
avoid  doing any state changes.......
state change
s
are not needed in any script. It does take a bit more skill  to not use any state changes  but once you learn to do without state changes  your scripts will run much more efficiently and  have far fewer bugs.

keep up the good work xigaro....its nice to see you trying to help new scripters
:)

You are correct that the touch event would never be triggered because the default state_entry() sends it to a state that does not have a touch event handler (as shown in the code within that video).

 

However, saying "good scripters always  try  avoid  doing any state changes.......state changeare not needed in any script." is failing to grasp how "wise scripters" know when to use this feature of LSL.

Link to comment
Share on other sites

Rolig, leprekhaun

Yes i  admit  I did overstate ( no pun intended :) )  what i was trying to say.

My intent was only  to try and prevent new scripters  from getting in  the bad habit of using state changes  in the flow of every script they write.

 I do agree there is a time and place where state changes do make sense. Personally  I  create  1000's of scripts and rarely find it necessary to use  state changes ; but yes  i am sure there are times when  the state change  flow could make sense.

Link to comment
Share on other sites

Yeah, I see we're on the same page!

 

And I have also noticed that beginners seem to go through a stage where states are the answer to any programming problem. But, to my way of thinking, that's a good thing, introducing them to exactly what is happening but eventually (one hopes!) showing them that it is usually done a lot easier using variable switches.

 

But there is a point when the coder may find they're juggling too many such switches to modify the behavior of the application and an actual state change becomes preferable. When it's done under those circumstances, it may actually reduce the chance for error and simplify the code.

 

And, back to the topic of the thread: The State video by the OP misses the mark entirely imo, since it's not only doesn't illustrate when a state change might be preferable but the program is actually flawed as written.

Link to comment
Share on other sites

Awesome feedback everyone, thank you :matte-motes-big-grin:

There's nothing worse than a tutorial that gets it wrong, and I totally hear you all about the states thing. Bad code to boot. Jeez. I'll rethink that.

There's already some great text tutorials out there and personally prefer to watch video on any topic. Lazy I guess!

Thanks again for taking the time to post your thoughts

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3917 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...