4.1.0

This rolls in major changes to how and when scoring can happen. In prior patches introduced a new boolean for only setting score and status on finish which is SCORM for cmi.exit of '', normal, timeout and logout. There are cases where some platforms leave you in 'review' mode even though you suspended your attempt. And if you built your content to stop taking student answers in other modes than normal that could wreck your user expierience.
Corrected a boolean vs string comparistion on startup. If SCOBot cannot initialize the Runtime API it will now throw an exception.
Another important note, it is very important before you begin interacting with SCOBot, that you only do so after the 'load' event is fired. This means the page 'loaded' event has triggered, and SCORM has been initialized. You can take alternative action if an exception is thrown, but this commonly means something went wrong.

4.0.10

This update patched SCOBot with a more strict check on whether it was able to initialize. Previously 'true' and 'false' were returned, and the statement was checking for a boolean. This corrects a situtation where technically there was no LMS API present.

4.0.9

Adjustment to SCOBot Managed Status. When you 'setTotals' and are using interactions and objectives, SCOBot was calculating the score for you. You also may just call 'happyEnding' if enabled which will auto-score the attempt to satisfactory. Lastly, you may not want to status the attempt until the very end, commonly called finish or timeout. Certain platforms launch your suspended attempts in review if they think they've been graded. The 'doNotStatusUntilFinish' boolean was added to stop SCOBot from reporting status and score until the very end if and when the need arises.

Do to the complex nature of platforms, use-cases and interpretations of 'graded', 'finshed' and other terms used throughout this genre it's not surprising these situations occur. Updated WIKI to support more information about SCORM Modes, Credit and Behaviors for more info on this.

4.0.8

Within both SCORM 1.2 and SCORM 2004 the specifications left it open to how a Platform would behave in both 'review' and 'browse' modes. Past customers did not want students changing answers in review mode, and commonly in browse mode, you are looking at something not assigned to you. Regardless, SCORM calls it out the following way -

• Normal - meant this was a tracked attempt. LMS usage is required to put 'cmi.credit' as 'credit' or 'no-credit'.
• Browse - meant that you were looking at something not assigned to you without the intent of it being recorded. LMS usage is required to put 'cmi.credit' as 'no-credit'.
• Review - meant that you or a teacher was reviewing a scored attempt without the intent of it being recorded. LMS usage is required to put 'cmi.credit' as 'no-credit'.

So this modification will allow Set Value calls to make it past SCOBot Content API without it stopping the requests as it did in prior versions. It will however, continue to warn you the devleoper in the logs if this occurs.

There are rammifications to this issue outside of the SCO. Had you been disabling user input in 'review' mode for example, certain platforms like Moodle launches your prior suspended attempt in 'review' mode. This would make it hard to continue to answer questions had you built your content out like that.

Also allowing answers to be changed after they are submitted gets dicy. Again, the platform can choose to ignore the SetValue requests but its something to watch out for.

4.0.7

This update adjusts SCORM 1.2 support. There was a situation where the spec didn't direcly call out how the platform (LMS) was to behave setting modes and or restricting set messages when not in 'normal' mode. SCORM 2004 was more direct with the language on how a LMS should implement these modes and how to behave. So this now has the ability in SCORM 1.2 to keep attempting to set data in other modes than just 'normal'.

4.0.6

This update patches the recent base64 capability of suspend data. The 'glyph bomb' test was failing due to some characters breaking it. encodeURIComponent and decodeURIComponent solved this within SCOBot. The 'glyph bomb' was meant to stress the suspend_data string and it actually did just that.
This issue can crop up with authored content that may have been copy/pasted from Office products or things with control or special characters that don't survive the encoding process.

4.0.5

Updated Dates to 2015.
Modified new features to enable/disable the happyEnding API Method.
Added the ability tor SCOBot to ignore suspend data formatting in cases where something else manages it.
JSLinting cleanup
Modified debug internally to return true when disabled. This allows some other features to continue to succeed with QUnit tests in production.

4.0.4

This release was focused on some status and state cleanup. When and how SCOBot decides to change completion and success status. Blended some SCORM 1.2 scoring tweaks to be more friendly going backwards if you deploy from 2004. Tweaked the ability to opt out of exposing 'happyEnding' if you do your own scoring. Removed several calls from re-occuring after they were cached. This is handy when your on a LMS with a non-cached Runtime API (laggy round trips to the backend)

The question of cheating and security came up a number of times this year. Analysis was done on this a number of times in the last few years, and it was determined nothing could be done from the SCO perspective/angle. Between watermarking the student attempt, or constantly validating cached values against ones sent against the LMS. All of it could be force committed and terminated before the SCO even gets a chance to stop the cheat.
Best advice - know what SCORM features within the student attempt you are using, and write some reports on the LMS to back track suspicious activity. Extra SCORM errors thrown from a students session? Time on task (if tracked independently) maybe can highlight the issue too. Or any other criteria you know your SCO's report that aren't present in content submitted from potential cheatlet/bookmarklet or command line/console entries. Shift the post-analysis to the LMS. Even directly outside the content, students have placed key loggers on teachers computers and manipulated their grades. Where there is a will, there is a way.

4.0.3

Added ability to encode/decode to base64 by default. Please note, if you target IE < 10 the window.atob/btoa functionality is not supported. You'll need to use a 3rd Party library to gain that base support, and there are plenty to choose from. Since these projects exist, adding it to SCOBotUtil did not make sense. Rather, I leave the option to carry this extra code in your project up to you. You can even do it with conditional code, rather than making all browsers deal with the extra code to make it work.
2 new options for SCOBot now exist. 'base64' true or false, and 'useJSONSuspendData' true or false. Both default to true. SCOBot attempts to parse the suspend data, and if you are using a hash or some other format it would result in a error. Wiki will be updated with this information as of 4.0.3.
Modified some of how mastery or scaled passing score is handled. I felt there could be cases where a SCORM 1.2 style '75' could be returned, vs '0.75' for SCORM 2004. Built out a safety check for that just in case. This allows content packaging to include the score the student needs to achieve in order to be 'passed'.

4.0.2

Rolled in updates for SCORM 1.2 like reverting exit 'normal' to '' (blank) and ignoring 'unknown' or 'not attempted' statuses since they are un-supported when rolling SCORM 2004 back to 1.2.
Found a rogue console.log which would of effected older versions of IE 7 and back.
Found a $.triggerEvent left over from jQuery removal.
Made some completion_status tweaks so when SCOBot is closing out a session it doesn't set it to 'incomplete' based on some logic it was making. Also had to build that up a bit since SCORM 1.2 uses cmi.core.lesson_status as success_status and completion_status.