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.