Some settings would be helpful to have as per-user defaults, not per-launcher defaults.

There should be a global default launcher config that overrides the default values for an entity, but can still be overridden by changing the default for each entity.

(Description mostly copied from the task for Origin)

Launchpad launches Epic games with a fairly generic and forceful method--it closes Epic if it's running, then launches the game (which opens Epic itself), then after closing the game it closes Epic again. There is planned functionality to optionally launch Epic again (through a scheduled process so it doesn't hook into the Steam overlay) at the end so you can keep it running.

It does this because otherwise process hooks such as the Steam Overlay typically won't work. Steam has to be the thing that launches the game process, but if Epic is already running, then Epic , which is a sibling of Steam and not a child, is what launches the process. Closing Epic first means Steam can own the Origin process, which makes the overlay work.

However, having to forcefully close Epic is not ideal. It can mean cloud saves aren't fully uploaded, and it means you won't get game updates until you run Epic next, which might be when you're trying to play the game that needs updates.

Blizzard game launching works much better by contrast. It happens like this:

1. Launch Battle.net's exe with an argument which goes to the game's correct page and click the Play button automatically
2. Wait for game process to exist, and then immediately close and re-launch it with the exact same process info

This causes Battle.net to still know you're playing the game, but Launchpad now owns the game process so Steam's overlay can hook in regardless of whether Battle.net was already running or not.

A similar solution should be found for launching Epic games if possible.

(Description mostly copied from the task for Origin)

Launchpad launches Bethesda.net games with a fairly generic and forceful method--it closes Bethesda.net if it's running, then launches the game (which opens Bethesda.net itself), then after closing the game it closes Bethesda.net again. There is planned functionality to optionally launch Bethesda.net again (through a scheduled process so it doesn't hook into the Steam overlay) at the end so you can keep it running.

It does this because otherwise process hooks such as the Steam Overlay typically won't work. Steam has to be the thing that launches the game process, but if Bethesda.net is already running, then Bethesda.net , which is a sibling of Steam and not a child, is what launches the process. Closing Bethesda.net first means Steam can own the Origin process, which makes the overlay work.

However, having to forcefully close Bethesda.net is not ideal. It can mean cloud saves aren't fully uploaded, and it means you won't get game updates until you run Bethesda.net next, which might be when you're trying to play the game that needs updates.

Blizzard game launching works much better by contrast. It happens like this:

1. Launch Battle.net's exe with an argument which goes to the game's correct page and click the Play button automatically
2. Wait for game process to exist, and then immediately close and re-launch it with the exact same process info

This causes Battle.net to still know you're playing the game, but Launchpad now owns the game process so Steam's overlay can hook in regardless of whether Battle.net was already running or not.

A similar solution should be found for launching Bethesda.net games if possible.

Files that a launcher might depend on, such as a shortcut file or an external .exe tool, should optionally be able to be included within the build launcher .exe itself and extracted upon use (and then deleted afterward).

This will help to keep the launchers more portable and there won't need to be a shared place where all launcher resources are kept.

The Launchers view in the main window shows launcher icons if they exist, but if a launcher doesn't have an icon, then the ImageList for the ListView no longer matches the list items, so some icons are mismatched.

The Is64BitOs check is currently not smart at all. It simply checks for the existence of "C:\Program Files (x86)" and assumes you're using a 64-bit OS if it exists.

We should instead find a reliable way to detect that with the tools available in AutoHotKey v2.

Change the window icon to be that of the game icon

Currently the version numbers detected for managed platforms may or may not be 100% accurate--they are what is reported in the platform's uninstaller entry in the registry.

There is a button which either says Install or Update when you select a platform, but currently in both cases it simply sends you to the download page for that platform.

There are a couple possible ways this could be used instead:

• Actually get the latest version from somewhere, and if the installed version is outdated, download a new release. This might not be ideal because most platforms offer self-update methods which are easier than re-installing.
• When Update is pressed, open the platform and automate the process of checking for updates however that is done

When you open a child window and then close it, the main Launchpad window goes behind any other open windows.

Some games I play require me to keep a custom patch or set of override files, and whenever the game is reinstalled, I need to install that patch or copy over the custom files to the game directory.

It would be nice if Launchpad let you provide a list of assets that get applied to a game's install directory if certain conditions are met (or unmet).

Currently, the only Bethesda games detected are those installed in launcher's main "games" directory.

It would be much better to find a way to read a list of installed games, or at least to detect other directories where Bethesda games are installed.

As Launchpad has grown, it's acquired some similar concepts that are tough to justify keeping separate, and also may cause some confusion if kept separate.

Currently:

• Launchpad creates Launchers that each represent a single game
• Launchers have a "Managed Launcher" which refers to any launcher that the game itself might have (e.g. Battle.net)
• Launchers have a "Managed Game" which refers to the game itself (not its launcher if there is one)
• Launchpad managed a list of Platforms which end up being almost the same as Managed Launchers but used on the backend for detecting installed games

This seems somewhat confusing and arbitrary, and there seems to be overlap between concepts.

To provide clarity, consider merging concepts and/or changing terminology.

One possible idea:

• Launchpad creates Launchers which represent a launch configuration for a single game
• Launchers optionally have a Platform selected which will preconfigure as many settings as possible
• Launchers optionally have a Managed Launcher which would NOT be the platform, but rather, the extra layer of launcher that some games come with (Often a menu that lets you launch the game or verify the files)
• Launchers have a Managed Game which gives it the details of the game it's launching

This would mean that Managed Launcher and Platform no longer overlap, and Platform as a concept is brought into launchers and not used only for detecting games.

The Launcher DB is currently a "dumb" API, it is simply a set of JSON files living in a GitHub repository and served through GitHub Pages.

This is not very sustainable, especially when considering users of Launchpad, which might not have GitHub accounts or be open to creating a PR or an issue, should be able to easily contribute their launcher configurations for the community to make use of.

After updating Launchpad, the state file should know that the version changed and it should automatically flush the cache and delete temporary files on startup before updating the state file with the new version. This will help avoid any stale files getting used or causing problems.

The Launchers list currently only shows the Details view, which I think makes sense if you want as much info as possible.

However, it might look nice to support a tiled icon view where you just see the name and icon of each launcher in a grid.

The browser should:

• Optionally take a default icon source to pre-select
• Allow browsing the filesystem for a .ico or .exe file, or choosing from a list of free game-oriented icons
• If a .exe is chosen, show an additional browser that lets you choose between the icons in the .exe if there is more than one
• Store a main reference to the source that is selected and return it at the end
• Optionally extract the chosen icon to a destination

First time trying to use this. Same issue running as admin.

Launchpad 4.3.0
Windows 10 Pro 64bit - English International

Creating a new platform can be done by looking at how the existing platforms are implemented. Copying Origin or Epic as a starting point, depending on which one is more similar, may be beneficial.

Launchpad doesn't know whether the game your launcher is supposed to launch actually exists or not. Additionally, you could have an invalid combination of options which prevent the launcher from launching and/or monitoring the game properly.

There should be a Launcher Validator bulk oeration run from the Tools menu which shows you a list of all issues with your current launchers.

Additionally, validation should be taken into account when showing the launcher status in the main window.

Finally, don't allow an invalid launcher to actually be built--hide the build button for invalid launchers.

For some reason the GDI+ buttons that are drawn on GUI windows sometimes don't appear. If the issue is present, then when the initial Launchpad window loads, no items drawn with GDI+ will show up. Restarting Launchpad sometimes fixes it, but sometimes several restarts are required.

It seems to occur in spurts--if I've been restarting Launchpad a lot, then that evening my buttons might stop appearing more often. Typically earlier in the day or when I'm not using Launchpad as much, the buttons work every time I open it.

It seems to be a race condition of some kind, but I do not yet know why.

Launchpad launches Origin games with a fairly generic and forceful method--it closes Origin if it's running, then launches the game (which opens Origin itself), then after closing the game it closes Origin again. There is planned functionality to optionally launch Origin again (through a scheduled process so it doesn't hook into the Steam overlay) at the end so you can keep it running.

It does this because otherwise process hooks such as the Steam Overlay typically won't work. Steam has to be the thing that launches the game process, but if Origin is already running, then Origin, which is a sibling of Steam and not a child, is what launches the process. Closing Origin first means Steam can own the Origin process, which makes the overlay work.

However, having to forcefully close Origin is not ideal. It can mean cloud saves aren't fully uploaded, and it means you won't get game updates until you run Origin next, which might be when you're trying to play the game that needs updates.

Blizzard game launching works much better by contrast. It happens like this:

1. Launch Battle.net's exe with an argument which goes to the game's correct page and click the Play button automatically
2. Wait for game process to exist, and then immediately close and re-launch it with the exact same process info

This causes Battle.net to still know you're playing the game, but Launchpad now owns the game process so Steam's overlay can hook in regardless of whether Battle.net was already running or not.

A similar solution should be found for launching Origin games if possible.

After thinking this through some more, here are some notes:

• Launchpad could recompile itself when the modules change
• Using modules would require downloading basically a full copy of the Launchpad source repository at the current installed version (either tag version or {{VERSION}} = master)
• The Launchpad installation files and main .exe should probably not be overwritten, so user-compiled Launchpad should probably end up in a different location
• When Launchpad proper runs, it can check that alternate location for an exe file first and run it instead if it exists
• There could be a module manager with checkboxes for each module, and if you change the options then you can recompile the custom Launchpad version right from there

At a minimum, every operation should report the number if items successfully processed and the number of items failed (if any). If any items fail, it should ideally log a reason why.

Currently Launchpad doesn't have the concept of a "disabled" GUI button.

Where a GUI button would normally be disabled, Launchpad hides it. This is not a bad solution, but it can leave ugly gaps if there are buttons on either side.

Launchpad should be able to gray out a button and make it unhoverable and unclickable.

For some games, you need to remap keys, map mouse buttons to keyboard keys, map a game controller to work with games that don't support one, etc. You can sometimes do this elsewhere, but for cases where that isn't enough, Launchpad should allow extensive key mapping and hotkey support.

You should be able to create profiles in which you can:

• Remap keyboard keys, controller buttons, mouse buttons, joysticks, etc so that they emulate any other type of control
• Select from existing common controller mappings
• Choose a hotkey in Launchpad's settings that, when pressed, will overlay your current mapping

The ultimate goal should be self-documenting code and a document build process. However, a good initial goal is just updating the README.md file with current information about the options and features.

The state file should store a schema version for each launcher. When the launcher configuration changes, either manually or through the data determined automatically, the launcher's schema should increment which will then mean the state file's schema version is lower.

When launchers are shown in the main window, any launcher with a lower installed schema version than the available schema version should show as outdated.

Anytime a launcher is rebuilt, its installed schema version should update to the latest.

Launchers should probably also show as Outdated after updating Launchpad itself.