This release includes some minor bug fixes and improvements in Gui handling logic, but the main change should be unnoticeable to users: The UI layer has been rebuilt on top of the recent service container. GUIs are now late-loading and created by a factory which allows them to be extended or replaced by third-party code easily.

Soon, I plan to rebuild the module manager and entity managers to be based on the service container and to extend entities themselves to be services that can be loaded generically from definitions just like other components in Launchpad.

At that point, modules and service files will be able to provide or extend any and all functionality in Launchpad, and the focus will shift to enhancing the Entity UX. The goal is that modules should be able to do things such as define individual fields on entities, as well as how to render, retrieve, and store the data for that field. This will allow much finer-grained control, and will allow most functionality to be moved into modules while maintaining a unified user experience.

As always, let me know if you run into any problems with this release!

Configuration Galore!

Launchpad has a brand spanking new configuration system, rebuilt from the ground up to be based on flexible and overridable container parameters introduced in version 9.2! This has far-reaching implications for the future of the application and the level of flexibility that can be provided, and this has required touching a huge number of files and hopefully not introducing too many bugs.

Launchpad now looks for a Launchpad.json file instead of Launchpad.ini. To ease this transition and keep this change non-breaking, there is a migration wizard that will detect your old Ini settings and offer to automatically migrate them to the new format for you.

This release has a noticeable performance improvement--Instead of a long delay upfront, there is now a short delay before accessing certain features for the first time, and if you don't use those features, they are never loaded. This makes Launchpad feel a bit more snappy and responsive, especially initially.

With all the recent changes, Launchpad is also able to scan for third-party modules and rebuild your module include file automatically if it detects changes. This feature is mostly untested, and no known third-party modules exist yet, but one of the primary goals now is to convert as much existing and upcoming functionality as possible to separate modules and to create a module manager that can be used to enable or disable them.

Changes:

• Entity creation is now handled by a generic factory service, and a container-injected static method is called on the entity class to allow for any type of custom third party entities to be created
• Third-party modules are automatically detected and an include file built to allow them to load properly
• Include files for Launchpad and for the builder are now all built from one generic set of classes
• Base test classes have been simplified a bit to make them easier to use and extend
• The Launcher.template.ahk template file has been simplified a bit so there are no extra global variables
• ServiceContainer now has a new base class, ParameterContainer, so that the concept of parameters can be separated from services if desired
• The configuration layer has been made more flexible and generic and rebuilton top of the ParameterContainer system
• Launchpad's configuration file has been changed from Launchpad.ini to Launchpad.json
• An automatic migration path has been added to Launchpad's new configuration format

This is another big under-the-hood release. Launchpad should be speedier and more stable for users, and much easier to maintain and less error-prone for developers.

First of all, as usual, the last major release of Launchpad broke a couple things. These have been fixed:

• When using the Advanced editor and editing either the Managed Launcher or Managed Game, you would previously get an error if changing the value of the Exe file. This has been fixed so that it works without any errors.
• Recently, string sanitizing was added to many places in the backend, and it highlighted a problem with how we are applying data processors. Sometimes, the processors were being applied to objects they weren't designed for and causing unintended results. They now filter themselves to only apply to certain types.
• Sometimes the hidden console window that Launchpad uses for certain tasks isn't visible when Launchpad tries to hide it, and that was causing an error. This has been fixed so that Launchpad only hides the console if it's actually shown.

Changes and Enhancements:

• Launchpad now uses real dependency injection to access the majority of its services, and a lot more classes within Launchpad are now considered services. This has several benefits, such as services only being loaded the first time they're actually accessed, and the fact that almost any service in the deepest depths of Launchpad can be replaced from the top level of the application, and soon from configuration files as well. Not only are services injected, but any arbitrary parameters can be injected independently of the service definitions, so things like private data can be passed in from outside Launchpad in a secure way. This functionality is modeled loosely after how the Symfony framework in PHP handles dependency injection, except built from the ground up for AHK.
• As a bonus to fixing the way data processors work, they now can actually apply to arrays and maps, where they originally only supported strings. Now, more strings in Launchpad are automatically sanitized and expanded with placeholder values!
• Launchpad's class library has been heavily refactored and moved around recently, and this process is still ongoing. The goal is to split off most of Launchpad's shared libraries into independent libraries that are not so tightly coupled so that they can more easily be swapped out and/or contributed back to the AHK community in a way that is easier to digest. This also helps massively with maintainability--as Launchpad's codebase continues to expand and get more complex, keeping things as uncluttered as possible is a big priority.

Going forward, the big underlying changes still underway are:

• Turning more classes into injected services
• Creating factories for repeatable services so that even more classes can be injected properly
• Moving everything that isn't strictly required for basic functionality to separate modules which can be enabled or disabled at will
• Overhauling how API data is handled so that it's faster, more reliable, and results in less requests

On the front-end, the only change you should notice is that the platform name and icon have been added to the main window. This makes it easy to tell which launcher a game is running in without having to open the editor.

On the backend, big changes are underway which add flexibility to the underlying application architecture.

In recent releases, Launchpad introduced the concept of "modules" which can add functionality to the main application, however so far those modules are fairly limited in scope and could only be provided by the application itself. Additionally, all discovered modules have been automatically enabled.

Going forward, the module system has been expanded in the following ways:

• Module discovery is automatic (based on a set of search directories and the *.module.ahk naming pattern)
• The module loader checks whether each module is enabled or not before loading it (in the future, the GUI will allow toggling them)
• The module loader allows passing in arbitrary configuration values to each module (in the future, the GUI will also allow you to configure each module)
• There are now different types of modules, and a module can offer multiple types: Launchpad, LaunchpadLauncher, LaunchpadBuilder. This means modules can be made to be activated only within the environment they were designed for, so you can install a Launcher module that doesn't affect the main Launchpad application, or you can install a Builder module that affects only the build process and doesn't bloat the compiled launcher.

The next step is to create a Modules window where you can enable, disable, and configure each discovered module.

After that, a build system will be introduced so that 3rd-party modules can be used in one of two ways:

1. For the AHK (source) version of Launchpad, the build system will simply manage an include file which includes all AHK files from enabled modules
2. For the compiled version of Launchpad, the build system will manage the modules include file plus rebuild Launchpad itself to include any changes to 3rd-party module includes.

This build system is planned to run automatically when you start Launchpad, so that it can detect if you have changed your installed modules, rebuild your include files, rebuild Launchpad if required, and restart the application seamlessly. If you have not changed your modules, this process should be nearly instantaneous. If you have made changes and are using the source version, it might take a second or so. If you are using the compiled version and have changes, it will likely take 3-4 seconds for Launchpad to rebuild and restart.

There are several challenges remaining with implementing this system, but the recent changes mean we are closer than ever.

The biggest breaking change in Launchpad 9 is that it now uses the latest AutoHotKey 2.0 beta, which changes some syntax from previous alpha versions. Since AHK 2's code has stabilized more, that means Launchpad's future updates to AHK versions won't usually need to be breaking changes anymore.

Additionally, Launchpad 9 includes some changes and fixes over v8:

Fixes:

• Fixed attempting to click on Battle.net Play button before it is ready to be clicked
• AutoHotKey and Ahk2Exe were not always in sync after updating Launchpad, which could cause errors when building launchers. This should be resolved now.
• Fix authentication issues that were occurring in some seemingly random cases
• All HTTP requests now check for a status code of 200 instead of a return code of -1 due to inconsistencies in return codes
• Lots of small code fixes

Changes:

• Removed .bat files from codebase. If you use the AHK version of Launchpad, then simply double-click Launchpad.ahk now instead of Launchpad.bat.
• Retry login if refresh token fails
• Simplify some UI text, such as progress indicators
• Launchpad now checks for an immediate relaunch of a game process and monitors that if found to prevent Launchpad from thinking the game has exited
• For developers, the LaunchpadBuilder can now rebuild AhkBins.zip based on your current vendor files as part of the build process

Post any issues you find to GitHub, otherwise, launch on!

This release fixes a bug introduced in 8.0 where icons in the main list were displayed in the wrong order. This should be fixed now!

Happy Friday! It's time for a new Launchpad release!

Details!

Launchpad now includes a details pane showing more information right in the main window. This is just the start--now that the details pane exist, it will be better utilized in the future!

AutoHotKey Version Change

This release also changes the core version of AutoHotKey that Launchpad uses internally, as well as to generate your launchers. This is the first time in a long time that Launchpad has done this, so it's a pretty big deal. A lot of code has changed that makes it incompatible with the existing AHK v2-alpha, so we're bumping up to 8.0 to signify the potentially breaking change for users.

If you run into issues, it is likely AHK-version-related. If you use the AHK version of Launchpad, try updating your version of AutoHotKey that you run Launchpad with.

Changes

• Updated Launchpad to version 2.0-a131-2327728b of AutoHotKey
• Update Ahk2Exe.exe dependency
• Add an asterisk next to launchers that need rebuilding
• Add a details pane next to the launcher list in the main window
• Force "Report" view mode for main window

Fixes

• Improvements to game support and stability of Launchpad Overlay
• Fix launching Blizzard and Riot games after changes in 7.2.0
• Better version handling for Launchpad dependencies
• Selection is maintained when editing a launcher

Known Issues

The AHK version change notably introduces a bug where clicking certain tray menu items shows a small window frame in the lower-left corner of your screen. This is the main AutoHotKey script window, and it's normally hidden. It will close with Launchpad and doesn't pose any issues, but I am working on getting rid of that.

Big release today! Hopefully not a breaking one, but here we go:

New Features

Launchpad Overlay

Thanks to inspiration and support from the author of the excellent Non-Steam-Overlay-Manager, Launchpad has incorporated a similar feature.

This allows the Steam Overlay to work in any application, even applications that refuse to work with the Steam Overlay normally.

Currently disabled by default, each launcher now has the following new options:

• Enable Overlay
• Force Overlay
• Overlay Hotkey
• Overlay Wait

When Enable Overlay is checked, the following behavior occurs when launching the game:

1. If Force Overlay is enabled, start the Launchpad Overlay immediately
2. If the Steam window is not open, it was likely not launched through Steam, and the overlay does not open
3. Launchpad waits up to "Overlay Wait" seconds to see if the Steam Overlay attaches to the game. If it does not, then the Launchpad Overlay runs

Using the Launchpad Overlay is as simple as pressing the key you have defined in the Overlay Hotkey setting for each launcher. By default, that is "^Tab", or Ctrl+Tab in human terms. Changing the hotkey requires a cursory knowledge of AutoHotKey hotkeys, but any HotKey that AHK supports should work.

You won't see notifications from Steam while you're playing when using the Launchpad Overlay, but the Steam Overlay will be available after you press the hotkey.

The primary quirk at this point with the Launchpad Overlay is that it will not function if your game is running in fullscreen mode. For games that you wish to use the Launchpad Overlay for, make sure to use Borderless Window instead of Fullscreen if possible.

This functionality is considered experimental for now and so must be activated manually. Once we're sure it's reliable enough to only run when it's appropriate and that it doesn't cause issues with most games, then it will likely be enabled by default for certain launchers or game configurations.

Changes

• Added Launchpad Overlay functionality (See above) with settings in each launcher
• Added LaunchpadOverlay application source code, and a compiled version, to the Launchpad code
• Refactored and optimized a lot of code, Launchpad should be faster than it has been for a long time
• Allow rebuilding LaunchpadOverlay from within the Launchpad Builder
• Log errors rendering theme buttons instead of showing a dialog
• Remove step count from launcher status window, since it was fairly meaningless and sometimes inaccurate
• Prevent storing parent and child data with each entity to reduce memory footprint and greatly speed up entity processing
• Revamp game monitoring loop for greater flexibility and reliability
• Progress window for LoadPlatforms bulk operation disabled since it's an extremely quick operation
• Added CheckboxControl control class to standardize handling of checkboxes

Fixes

• Fix bug running shell commands
• Fix error dialog problem after recent changes
• Added missing handler for changing the default launcher theme in the Settings window
• Reverting entity values to their default value now properly shows the original value instead of the same value

Another hotfix...

Fixes:

• Reverted change in 7.1 that limited auto-detection of the install directory. It needs to run to expand shortened .exe values.

Hotfix time!

Fixes:

• Fixed error with Bulk Operations in the latest update
• Removed duplicate "Logging Level" heading from launcher editors