Factorio Forums

I've never used the automatic updater, as before using the standalone version, I've just launched the game from Steam. But after not being able to turn off Steam multiplayer even through port forwarding (I did not report this issue, sorry!), I've switched to the standalone version, which made the huge multiplayer lag go away, along with other extra benefits (like not being chain-locked to Steam).
I prefer to version-lock things, that's why the version I've indicated in the title is so old. However, as per bug request rules, I've manually downloaded an one version older stable version, and it is still present in 1.1.107.
I found this issue when we wanted to play again a fresh world with fresh mods, and decided to try out the in-game auto updater instead of manually downloading the .zip again.


What I did:
- open game
- force update checking through the about menu manually (automatic update checks are disabled)

What I expect:
- game download update (.109 at the time of writing)
- game relaunches with new version

What happens:
- game downloads update (.109) successfully
- game asks for admin permission, even though it's installed through the .zip, not the .exe
- cancelling the admin prompt restarts the game as the previous version (.107), after acknowledging the "no admin permission" error popup

What should happen:
The game should check if it's installed (.exe) or extracted (.zip), and do in-place delta update without requiring admin permission for a portable install.

No idea what you mean with:

I've manually downloaded an one version older stable version, and it is still present in 1.1.107.

The log is from an install performed with an .exe not a .zip package and it is of version 1.1.107. So depending on what you did to get version 1.1.71 wasn't from the log provided or corrupted your installation.
If your OS settings require manual confirmation for the update and you deny that, then the update obviously will not happen, so either allow that or actually do a new .zip install if you for some reason do not want the update process to update the game.

The log is from an install performed with an .exe not a .zip package and it is of version 1.1.107

Weird, I've never installed the .exe though... would perhaps Steam do that? I don't remember ever downloading the .exe, I've always downloaded the .zip, so I could share the same drive across mutliple computers, without having to use any sort of save sync, or waiting ages to download the game again.

So depending on what you did to get version 1.1.71 wasn't from the log provided

Indeed, I lost the 1.1.71 files when trying to update to 1.1.109, so I couldn't re-try the test again. It's also not available for download anymore.

actually do a new .zip install

I already did that manually this entire time. I don't see anything Factorio-related in appwiz.cpl, and there is not a single Factorio-related file in any of the steamapps folders, not even the .acf file exists for Factorio


Edit:

No idea what you mean with: *snip*

It means, that to try this in latest version of the game (as per bug report rules), I had to download an one x older version, as it's impossible to repro otherwise.

I respectfully request this thread to be re-classified as a bug report.

While waiting for today's multiplayer session to be ready, I've decided to try Factorio on a completely fresh Windows install, and here below are my results.

It basically boils down to this: if I change ANY of the default portable install locations (even if all of the locations stay relative to __PATH__executable__), it will force the admin prompt.

It feels like, that the portability status is tried to be way too aggressively disqualifying, leading to the situation where I can't even organize my portable install in a way, where I don't want to mix UGC with read-only game data, even though all paths are relative to __PATH__executable__, and none go outside of the folder enclosing config-path.cfg.
I can understand the case without an explicit install type flag being persited, with no path being __PATH__executable__ -relative.
But all paths being __PATH__executable__ -relative, and not escaping the confines of the folder enclosing config-path.cfg for every game file (static or UGC alike), as an user, that sounds like un-intended behavior to me.

I have a feeling, that me pressing for "please let me have portable game files, but non-portable UGC files" might be a hard sell, but I humbly request portability qualifiers to be relaxed from a strict AND to a __PATH__executable__ -relative OR (so either config path, or write path being __PATH__executable__ -relative would qualify for the portability flag).
Or perhaps some "hidden" option to force enable the portable flag (preferably in config-path.cfg) would be more great instead.