Launch Behavior: A Tale of Two Settings


Due to their impact on the launch process, 'PlayerLaunchType' and 'PlayerScoLaunchType' are two of the most commonly configured Engine settings. An Engine launch includes three pieces:

  • The launch page.
  • The player page.
  • The course content.

In short, the 'PlayerLaunchType' setting controls how the launch page navigates to the player, and 'PlayerScoLaunchType' controls how the player launches content. However, we can demystify this a bit further.

*** Note: This article will often refer to Engine pages with an ".aspx" page extension. This applies to those running the .NET Framework version of Engine. If you're running the Java version of Engine, you can safely assume that those extensions are ".jsp".


A launch does not begin with the player. Instead, when you use the V2 API's BuildRegistrationLaunchLink endpoint to generate a launch link, you'll see that it points to 'launch.aspx'. Your LMS may use JavaScript to open the 'launch.aspx' page in a new window, or you may set the launch link to an iframe's "src" attribute. In any case, the request to 'launch.aspx' enables Engine to handle a few important steps - like concurrent launch detection and course versioning. After finishing this preliminary processing, the 'launch.aspx' page will navigate to the client-side player page, 'modern.html'.

*** Note: If you're using the "legacy player", the main player page is 'deliver.aspx' rather than 'modern.html'. The "modern player" has been the default since Engine 2016, and the "legacy player" was removed entirely from Engine 22. Prior to Engine 22, one could override the default use of the "modern player" by setting UseModernPlayer to "false" or using the "player=legacy" query parameter in a launch link.

'PlayerLaunchType' controls the way in which 'launch.aspx' navigates to 'modern.html'. Click this link to view 'PlayerLaunchType' in the settings documentation, and notice the five available options. You should also note the default value for this setting, which is "FRAMESET". This means that the 'launch.aspx' page will redirect to the 'modern.html' page. In contrast, if 'PlayerLaunchType' is set to any of the "NEW_WINDOW" options, then 'launch.aspx' will open 'modern.html' into a new window. Consequently, at that point, you would have a minimum of two windows - one displaying 'launch.aspx' and a separate one for 'modern.html'.


If you're SCORM-savvy, you know that "SCO" stands for "Sharable Content Object", but that wisdom is not terribly relevant to understanding the purpose of 'PlayerScoLaunchType'. After the 'launch.aspx' page navigates to the player's 'modern.html' page, the next step is opening the content - regardless of the learning standard involved (e.g., SCORM, AICC, TinCan, etc.). The 'PlayerScoLaunchType' setting specifies how the player opens the content.

Click this link to view 'PlayerScoLaunchType' in the settings documentation. The default value is "NEW_WINDOW", but the setting offers the same five options as 'PlayerLaunchType'. If 'PlayerScoLaunchType' is set to "FRAMESET", the player will display the content in an iframe located on the 'modern.html' page itself. If it's set to any of the "NEW_WINDOW" settings, the player opens in the content in a new window.

If 'PlayerLaunchType' and 'PlayerScoLaunchType' are both set to NEW_WINDOW, you'll have three windows! One for 'launch.aspx'; one for 'modern.html'; and the third displays the actual course content.

In contrast, if both are set to "FRAMESET", you'll have one window. This is because 'launch.aspx' redirects to 'modern.html', and 'modern.html' displays the content on its page within an iframe.

Conditional Defaults

Most Engine settings have a default value. For example, the default for 'PlayerLaunchType' is "FRAMESET". However, notice that some Engine settings have a "conditional default". These indicate that Engine's default switches to a different value if a certain "condition" is met at runtime. For example, for most learning standards, the default for 'PlayerLaunchType' is "FRAMESET". However, for xAPI courses (e.g., TinCan, CMI5), the default value at runtime changes to "NEW_WINDOW".

xAPI (TinCan) Caveat

SCORM is unique in that it is the only learning standard that - per the specification - absolutely requires a player to function. This is because each SCORM course contains an algorithm that searches for an API variable and fully expects the player to provide it. SCORM communicates with the player via this API, and the player communicates progress back to Engine.

The above SCORM-like workflow does not apply to other standards like TinCan. In contrast, the content is what communicates directly with Engine and does not require a player-provided API like SCORM. Consequently, prior to Engine 20, Engine did not launch xAPI content from the player. Instead, 'launch.aspx' opened the content. One could always change this behavior by setting UsePlayerForTinCanLaunches to "true". However, beginning with Engine 20, we changed the default value from "false" to "true". Therefore, if you're upgrading from Engine 2019 or below and never configured 'UsePlayerForTinCanLaunches', you'll see a difference in TinCan launch behavior. Specifically, you'll see an extra window because the player is now launching the content, and the 'PlayerLaunchType' setting's conditional default for xAPI courses is "NEW_WINDOW". To revert back to something more familiar, you can explicitly set 'PlayerLaunchType' to "FRAMESET" or even set 'UsePlayerForTinCanLaunches' back to "false".


Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request
Powered by Zendesk