Help with javascript to show layers - too much processing using built-in SL360 variables/triggers/layers

@Mary - one last thought...

Rather than 3 big games in one unwieldy storyline course, you could use a Multi Sco package and link them via the LMS?

I like Phil's idea of states. I envision a little work in the graphics program, but basically, Hat with visible/invisible state, Coat with visible/invisible state. etc. Can be done with one character, 6 objects with two states each, and 12 triggers (change state of hat to visible if Hat = True, and change state of hat to invisible if Hat = invisible. Each state can add to the total picture.
Of course, programming is much more glamorous, but stop and think a bit about what you have been through to learn the js. Unless you keep programming every day, in two months, if you have to do maintenance on this project, you'll have to learn the js all over again. And if you leave, and they need to make changes, will they have hired someone who can do js? Js is great for producing magic, but can be a nightmare for future maintenance.

And while Phil's usually (as in always) right, the way triggers are sequenced, and what they do, can slow processing. [Edit In retrospect, my slowing may have been caused by animations or motion paths, rather than triggers] Still in this case, my vote is the graphics.

Oh dear Walt! This is like the polar opposite to how I consider JS. :)

I will jump to the defence of JS here a bit, but only to try to encourage you that a small investment of time now - just simply to learn the very basics of JS (variables, operators, if/else statements) - will pay dividends time and again down the line as you start to adapt to a more dynamic and updatable way of working.

You are right, you can do some cool things with it, but for me the big advantage with JS is the ease of updating certain content and assets within courses. Maintenance becomes a breeze if, say, a client requires an additional button/state/layer to be shown and we dont need to worry about copy/pasting and editing all those triggers or states.

And no, Javascript has not paid me to say this ;)

I am wrong more than I am right (or at least that is what my wife tells me).

Her JS skills are strong  ;)

Looking back through this thread, I would also suggest that using boolean logic would make this much easier to figure out. Rather than use a true/false variable for each item, assign each item a binary value. Item 1 = 1, item 2 = 2, item 3 = 4, item 5 = 8, and etc. It's fairly easy to enable or disable each value using a bit of binary math, as well as to determine which state to display. This method can be used with or without JS.

The transparent objects method is also a really good way to build image layers, and PNG images still support transparency.

When I do need to add JS to a project, I find that a good practice for maintenance is to include a layer on the first slide with developer notes about how to republish the project. The layer is never shown when the project plays, and remains with the project for future developers to see. You can also add a note in the margin of you storyboard for developers to go look at that layer.

Andrew,

I love programming, and I love the freedom and flexibility JS gives me.

But when I look at this original post, and look back over the opportunities I've had to help people on this forum with JS (some of it quite simple), it is obvious that a lot of us here lack programming skills. Then when I look at job descriptions, I find companies want to hire people with educational skills, or (even graphic) design skills. Sometimes they mention HTML5 or CSS, or even LMS, but I've never seen one ask for JS. So the bottom line for me is that any time I include JS, no matter how fun and easy, or even necessary it may be for me, I know that down the line I'm setting somebody up to fail. Either the owner will have lucked out and accidentally hired somebody like me with programming skills (if they hire according to their job descriptions, any degree of programming skill is a serendipitous accident), or some poor designer will have to learn JS, or they may even have to scrap it and start over entirely. Although if I were still teaching, I would definitely give Dave an A for his documentation!

Back in a previous century, when 4K was enough memory for anybody, there was usually one way to get something done. Now we have the luxury of making things work using any number of methods (witness this discussion). Given that, we owe it to those who follow us to think of them. Whether it is going to be I in two weeks, or an unknown person in an unknown amount of time, they will thank us if ease of maintenance was very high on our priority list when we created this project.

That is my point of view for calling JS in SL a maintenance nightmare, and something that ought to be used only as a last and only resort.

Hi walt

Thanks for the call out. I try to be clear when I document how to do something. After all, that is big part of what I do for a living :-).

And yes, I remember back to those days when we had to program for limited memory space. Sometimes the techniques that we used back then still provide a good solution for solving a problem.

I love that i can use JS to enhance SL. But I agree with you, that we should only add JS when that is the only solution. If there is any way that I can accomplish a task in Storyline without resorting to JS, I will do that. And the way that SL supports triggers, layers, states, and variables,  there is a lot that you can do in storyline without having to resort to JS.  But I'm still glad we have JS for when we need it, and I know that those of us that are comfortable with it will continue to help those that are JS challanged.

Thanks for your observations,

Dave