1. Please return the name of the resource-download on DownloadFinished
2. Stop sending endless DownloadFinished commands with name="Skipping..." (see. beneath)

After starting a resource-download with arguments:

• name = "105.1.1-1354-g72b2d55 BAR105",
• type = "resource",
• resource = {
  url = "https://github.com/beyond-all-reason/spring/releases/download/spring_bar_%7BBAR105%7D105.1.1-1354-g72b2d55/spring_bar_.BAR105.105.1.1-1354-g72b2d55_windows-64-minimal-portable.7z",
  destination = "engine//105.1.1-1354-g72b2d55 bar",
  extract = true
  }

1. launcher returns DownloadFinished without an identifying parameter once

• isSuccess = true
• isAborted = false

3. then sends endless returns of DownloadFinished with

• isSuccess = true
• isAborted = false
• name = Skipping C:\Beyond-All-Reason\data\engine\105.1.1-1354-g72b2d55 bar: already exists.

Currently it just says "engine crashed, error: xxxxxx", we should redirect users to report the issue on discord etc.

Feature request for integrated Gamemode support on linux flatpak. Currently, the only way to have gamemode running is by executing the appimage with gamemoderun. Having an option or toggle in the application would be nice to have and may allow some additional performance improvements on the linux flatpak.

From one of users logs after error:

[2024-02-18 10:21:40.275] [error] Prevented navigation to: https://discord.gg/beyond-all-reason

We now have patching instructions in https://github.com/beyond-all-reason/BYAR-Chobby/blob/master/.github/workflows/launcher.yml#L45-L62 and in https://github.com/flathub/info.beyondallreason.bar/blob/master/info.beyondallreason.bar.yml#L34-L49 which is the supported method after the original one https://github.com/gajop/spring-launcher#how-do-i-generate-a-new-installer was turned down.

We should refactor is into something more reusable so we don't do copy pasting.

Please change the game's config directory from $HOME/Desktop to $HOME/.config.
And please change the game files directory to /opt/ or simple $HOME.

Idea from Jaz: https://discord.com/channels/549281623154229250/549282587487502347/1088898287827947680

Has there been any consideration about adding the .exe to a package manager?
Could be msft's new winget or a chocolatey package.

AppImage installs, updates and downloads studd to user's "Documents" directory.
Sometimes user has another disk volume with appropiate space, or even faster for games.
And sometimes "Documents" directory is a network drive, inconvenient for software or rapid i/o.

AppImage should ask where to install files on first run.

Launcher should support https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html instead of putting things in home directory/documents.

Per spec there isn't a best single directory because we mix config and data, but engine can load contents from multiple locations so maybe we can leverage that.

From user log:

[2024-02-18 10:17:47.744] [error] Unexpected error occurred.
[2024-02-18 10:17:47.745] [error] {
  createIssue: '[function] function () { [native code] }',
  error: 'Error: spawn UNKNOWN\n' +
    '    at ChildProcess.spawn (node:internal/child_process:414:11)\n' +
    '    at spawn (node:child_process:784:9)\n' +
    '    at Launcher.launchSpring (C:\\Users\\user\\AppData\\Local\\Programs\\Beyond-All-Reason\\resources\\app.asar\\src\\engine_launcher.js:170:18)\n' +
    '    at Launcher.launch (C:\\Users\\user\\AppData\\Local\\Programs\\Beyond-All-Reason\\resources\\app.asar\\src\\engine_launcher.js:137:9)\n' +

Hey,

I got bored and created a basic bash script to autoinstall this depending on their linux distro, is this something you worth having?

When the game is loaded various artifacts are downloaded from online resources, e.g updates.
In case there is no active internet connection when the game is started the loader seems to get stuck.

IMHO this should be addressed by either checking the internet connection of the machine or by adding a "reconnect" button that the user can use when the internet is active again.

Until beyond-all-reason/spring#355 and pr-downloader (some new bugs there..) fully support unicode paths, we should show warning in spring-launcher

This is continuation of the discussion that started in beyond-all-reason/spring#701 (comment)

Iff we decide if/how to proceed here with two different approaches to implementation, it would be good to implement it in a way that is easy to integrate in github.com/beyond-all-reason/bar-lobby if we don't consider this just a short-term hack.

Feature request from Fireball to pass more information from replay parser back to Chobby so it can show more details.

For now ask is for:

• which team won

When updating launcher, before we start installer, we should pop up a dialog with information about the new release to make it less confusing for the user and provide more details.

Github has outage, and even though we ignore errors: https://github.com/beyond-all-reason/spring-launcher/blob/master/src/launcher_wizard.js#L216 it looks like error propagation in electron updater is broken, so it still blew up in players face with this:
spring-launcher-20230629T174721.log

Flatpak https://github.com/flathub/info.beyondallreason.bar and some other versions need to patch code currently to disable updates, this is to add switch to not have to do that.

https://github.com/beyond-all-reason/spring/wiki/ClientGameState-ServerGameState-state-dumps

On engine updates, antivirus software sometimes drops the spring.exe. This issue is to add better handling of this case in the launcher, similar to like how missing pr-downloader case is handled.

Due to us lingering very long on one engine, with a large player influx since then, it might be wise to implement the loadsavegame wrapper function to run for alternate engines.
Here are some notes regarding this:

Each save game has an associated lua file with metadata, which contains the engine version used :

return {
	description = "20220907_102607",
	engineVersion = "105.1.1-1158-g27934d7 BAR105",
	gameName = "Beyond All Reason",
	gameVersion = "test-20718-cbf3397",
	gameframe = 31594,
	map = "Comet Catcher Remake 1.8",
	playerName = "[teh]Beherith",
	totalGameframe = 31594,
	date = {
		day = 7,
		hour = 10,
		isdst = true,
		min = 26,
		month = 9,
		sec = 7,
		wday = 4,
		yday = 250,
		year = 2022,
	},
}

However, the way save games are loaded, they can only load on the most recent engine, due to being loaded via:
WG.Chobby.localLobby:StartGameFromString(script)

Replays on the other hand, support being launched from older engines, as they are launched via the wrapper:
https://github.com/beyond-all-reason/spring-launcher/blob/master/src/exts/start_new_spring_handler.js

local engine = string.gsub(string.gsub(startEngineVersion, " maintenance", ""), " develop", "")
local engine = string.gsub(startEngineVersion, "BAR105", "bar") -- because this is the path we use
local params = {
	StartDemoName = string.sub(startReplayFile, 7), -- TRUNCATE 'DEMOS/' FROM THE PATH!
	Engine = engine,
	SpringSettings = WG.SettingsWindow.GetSettingsString(),
}
WG.WrapperLoopback.StartNewSpring(params)

This wrapper is implemented by the launcher, and works fine usually, except it does not work for savegames, as the launcher hard codes the demos/ folder.

https://github.com/beyond-all-reason/spring-launcher/blob/master/src/exts/start_new_spring_handler.js

Proposed solution:
I'm going to remove the hard-coded 'demos' from this, to allow loading of save games on old engines too.

When users selects during installation custom directory that doesn't exist e.g. C:\BAR, it is allowed, and the game is installed directly there. Unfortunately on update/reinstall installer correctly detects the install path but appends Beyond-All-Reason into the path, and users ends up with 2 installations, old one in C:\BAR and a new one inside that in C:\BAR\Beyond-All-Reason.

Steps to reproduce:

1. Download old launcher
2. Install in custom location, doesn't matter if user or machine e.g. C:\BAR that doesn't exist
3. It puts files in C:\BAR without a subdirectory
4. Download newer launcher
5. It picks up C:\BAR
6. It actually installs in C:\BAR\Beyond-All-Reason

This is a bug in upstream electron-updater used to create installer: electron-userland/electron-builder#6885. No known workarounds at this time.

Please return name of resource-download on DownloadProgress instead of destination

after starting a resource-download with arguments:

• name = "105.1.1-1354-g72b2d55 BAR105",
• type = "resource",
• resource = {
  url = "https://github.com/beyond-all-reason/spring/releases/download/spring_bar_%7BBAR105%7D105.1.1-1354-g72b2d55/spring_bar_.BAR105.105.1.1-1354-g72b2d55_windows-64-minimal-portable.7z",
  destination = "engine//105.1.1-1354-g72b2d55 bar",
  extract = true
  }

launcher returns DownloadProgress with name = destination

• progress = 0.2568467
• total = 16441672
• name = engine//105.1.1-1354-g72b2d55 bar

How it's done currently, a broken update of the config.json, can make some update steps to fail, which can in the end cause the config.json update to be canceled effectively borking the launcher.

Players on Windows have sometimes failing rename due to "operation not permited". It's fault of not great antivirus implementation and disabling antivirus helps.

I don't have clean setup where we can reproduce this, but it's possible that cause is the same as in: rust-lang/rustup#1870 antivirus is scanning files after closure which on windows blocks moves.

Idea here is to try to workaround it by retrying all renames with backoff until some deadline and see if it mitigates the issue...

This could be useful to be able to select from launcher some parameters that then chobby can read, so that user can more dynamically configure chobby without having to deal with lua files.

When running the application under wayland (--enable-features=WaylandWindowDecorations --ozone-platform-hint=auto), the window dimensions are off and bottom of the application is cut off:

When trying to download the game on Ubuntu 23.04 ARM (within a VM on a mac, if its important) using the flatpak launcher, I get the following error:

[warn] /app/main/bin/pr-downloader: /app/main/bin/pr-downloader: cannot execute binary file
[error] byar:test: Download failed: byar:test: 126

Flathub lists compatibiilty with aarch64, but is that just for the launcher?

Small visual issue with the progress in taskbar icon.

It seems to be one step off