Updating Lix is unclear (explain? rethink distro?)

[Simon]

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 workflow

Extract 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

[Forestidia86]

Simon, is it really true, that config.txt is overwritten (in the current version)? I've tested it and it didn't happen when I extract the zip in the folder where I have (as subfolder) the current lix version (even if I allowed to overwrite all). (Old laptop - Win 7)

There is actually no config.txt in data in the lix zipfile for Win, so it can't probably be overwritten.

I personally make a new instance each time to have a clean new version. But I don't use hotkeys that much and the ones I use are mainly default.

[Simon]

Indeed, the download has neither data/config.txt nor data/user/. In this regard, you're fine extracting new version into old version, overwriting all files, keeping files that aren't in the new archive.

Small downside: When tiles are permanently removed from the Lix download, you would keep old tiles. That's nice for back-compat, but it becomes your responsibility to not distribute/netplay custom levels that rely on removed tiles. Others would see a level with missing tiles and can't start the level.

That's why, in general, I'm hesitant to suggest extract-new-into-old. Still, in almost all the cases, it does exactly the right thing.

-- Simon

[Forestidia86]

If I'm not wrong, one big difference between the old NeoLemmix Player and Lix is that Lix comes with level packs and graphics etc. whereas old NeoLemmix relied on the level packs that come externally.
The new format has separate files for graphics etc. as well. And the styles you have to download separately, which I think is more user unfriendly (than in Lix where everything is included) since you often need them anyways.
That's actually the downside of having separate files for graphics etc. that you have to carry and update them through the instances as a player as opposed to everything is in one file. But I really don't want to speak against the Lix or the new NeoLemmix format. I think it's good that you can have a view inside the files and change them if necessary.

I can't say anything about the (NeoLemmix) editor and the upgrading system to what GigaLem probably alluded. But in Lix the editor is integrated, which is more user friendly I think as well. So an upgrade system would probably apply to the whole Lix release and not only the editor, I can't say how viable that is.

It's probably good to point the player to copying the old config.txt and data/user/ in the new instance to retain configuration since this is not obvious.

[Ryemanni]

I have no problem with manual download, but copying every custom level, tiles, wip files etc. can be a bit tedious. I don't think there's anything you can do about that though, because organizing personal files is up to the user.

Using %appdata% might work, but I don't personally like to use it. It just makes everything more compilcated when files are scattered all around the computer.

[Simon]

I agree, I don't like %appdata% either. Even on Linux, I don't have Lix installed either. Self-contained Lix is much better for development.

It's possible (though highly counterproductive) to recreate 2015-NL-format culture in Lix, and nonetheless allow easy inspection of all individual files. Instead of levels and tiles in separate trees, there would only be packs. Each pack contains its share of the level tree, and then a copy of the entire tile tree. It's possible to prune unneeded tilesets from the per-pack tile trees, but overall, you have a lot of tile duplication across all packs. Then pack maintainers are responsible to ship their packs.

The problem with Lix-all-included is scalability. If we had 50 tileset designers churning out ideas, I shouldn't be a necessary node anymore to get tilesets into culture. For now, everything is manageable, and I don't have to re-invent dependency management.

We could ditch user management by writing all user configuration, including the name, into config.txt, then put this file into the root dir. You probably don't share your operating system's user account with anybody who desires to play on a separate Lix user profile. And it would be only one file to copy, in a much more discoverable place.

-- Simon

[Simon]

As two extremes, there are two easy methods of updating with their own disadvantages:

• Always extract into new directory, copy manually from old Lix what you want to keep. You're bound to forget things.
• Always extract over old installation. You'll have duplicate levels from file moves lying around.

I'm considering the following layout, which I call user tree segregation, that improves the workflow in both of the extreme methods: Collect the distributed files in a completely different area than the user-added files. Comments?

0.9.7	User tree segregation
./data/config.txt	./user/config.txt
./data/user/	./user/config.txt (merge with user config)
./replays/	./user/replays/
user-added levels	./user/levels/
user-added tiles	./user/images/
user-added music	./user/music/

I'm not happy with this. Alternatively, all the distributed files
instead of the user-created files could go into their own subtree under ./internal/, which you would be expected to delete entirely on updating instead of copying ./user/. (Internal tree segregation)

Both internal and user tree segregation prevent new power users to look at the tree, then deduce where you're expected to add custom tilesets. The beauty of loose files is that in many cases, you don't need extra tools or instructions; instead, you can imitate what's there.

-- Simon

[Forestidia86]

This may not be helpful, but a more mild way seems to be to add something like "custom" folders, which point the users to put external stuff there, which can then be copied for a new instance. But since there seem to be three different places where custom things can go there would be much to be copied nevertheless.

Re power users:
Well you could include an example custom level, tileset etc. to allow users to reverse engineer the path.

[Simon]

"custom" folders, which point the users to put external stuff there, which can then be copied for a new instance. But since there seem to be three different places where custom things can go there would be much to be copied nevertheless.

Yeah, you'd still need to copy a lot, which is the exact issue with 0.9.7.

Examples in a user tree are a good idea.

I'll probably stick with the 0.9.7 design until I see something compelling.

-- Simon