Cricitism by Giga, which is spot-on:
What I dislike about lix is the constant having to move the file [1] then replace it with a new version and set it up again. This is why I never touch Lix that much because i do more maintaining with it than actually playing with it. [...]
[I encourage, for NL, that] to update from a previous version, you can select the smaller download file and not have to do much or not have to set up everything from start again.
[1] I don't know what file is meant, and I should ask, but ultimately it doesn't matter for our program design and method of distribution. We see people getting stuck during updates and want to fix the confusion.
This is several related issues that all have the same symptom: It feels easier to re-configure 20 hotkeys or ditch the entire culture than to investigate the hidden ways in which Lix tracks its config, then preserve that between updates.
2006-2017 workflowExtract new version over old version, overwriting all files.
2006-2017 alternative- Extract new version into separate directory.
- Copy both the file data/config.txt and the directory data/user/ from old version into new version.
- Copy replays/ into new version.
- If you have custom levels or tilesets that aren't yet in the main Lix download, dig into levels/ and images/ and copy them yourself.
How to fix?One solution is to explain this every time, everywhere I announce updates. I'd rather not. Updating must become easier.
Problem 1: The config is not visible in the top-level directory. It's all hidden in
data/ which has a terrible name.
Problem 2: It's concocted to copy both a directory
and another file, but
not anything else in
data/. Here, we want to copy
data/user/ and
data/config.txt, but certainly not
data/images/ that has GUI button sprites.
Problem 3: Should the userdata be outside of the installation? Lix already has a virtual file system: It can merge separate level trees and generate "the" level tree from it, with the user tree overriding the shipped tree if both have a file in the same relative position. This works for all resources, not merely for levels. It's already used in Linux packaging: The game installs e.g. to
/usr/local/games/lix/ and reads the second tree from
${HOME}/.local/share/lix/. The Windows equivalent is
%appdata etc, should we use it or not?
Problem 4: I don't like malware in the game (self-updating programs, programs that terminate once they detect a new version), must decide whether 100 % manual download is still correct. And how manual download fits into other problems.
Problem 5: Linux systems have package managers, Windows has...?
-- Simon