(Tested on win7x64)

-QA Testing-

Update: the cache should live within ~/Library/Application Support/... on OSX to prevent breaking the .app code signature

Fair enough. I assume that this ultimately means OSX users need to:

• Backup valued game data prior to replacement of the .app
• CTRL-click to start the app, and manually OK when prompted by OSX's annoying Gatekeeper routines.

I am dropping launcher support for OSX until I can resolve this.
It is a severe issue, but as it is OSX-specific, it should not delay the release for the majority of our players.

From @lancake's priority increase, is it safe to assume this is also happening with the new launcher?

I guess this belongs in queue ;)

OK... putting back in queue as it seems that the initial path settup isnt catching the illegal characters in the same way as the input from the options menu does.

The next build fixes the broken use case of (2048+1024) initial+early not snapping to the 3,072 lower-bound. The math is also easier to read now, and slightly faster.

This is incorrect behavior.
The slider should always snap to the lower bound, the powers of 2 in between, and the upper bound.

-QA Testing-

ignore the timestamp ... didnt happen again on the following tests.

Yes, that cache location is a bug -- it should live within launcher/.cache as with Windows.

The launcher will auto-update, removing the need for the user to update it manually; however, I can see this being a problem in the unlikely event something breaks (from user error or otherwise), necessitating a reinstall. I very much prefer having the entire game self-contained, however.

-QA Testing-

-QA Testing-

Another use case regarding control over update-related backup behaviors:

I don't think this is possible without forking the greenworks library.

I will address this when consolidating the options windows (T1724)

-confirmed-

I never got an internet interruption during update with the new launcher. Might worth the try to see how react the launcher/files.