Keep unit tree info when updating to a new version.

[phendo]

The problem:
In a given download of Wesnoth, the only unit descriptions to which you have access are only those which you have seen in battle. This means that when you download a new version, the unit descriptions vanish. This is irritating for those of us who like to be able to read the descriptions but also keep up with the present version.

My suggestion:
In the install process, have the option to transfer over the unit descriptions from a previous install. This method keeps the idea of the naturally expanding unit description list as you discover more units, but doesn't make you start over when you update to a new version.

While I am not an expert coder, I think this should be fairly straight forward process. The only potential problem I can think of is what happens when a unit is tweaked between versions, but this shouldn't be an issue within a given stable branch.

My apologies if this is an old problem,
Phendo

[Thanatos]

Why don't you just copy your user data folder and use it for the newer version of the game?
Problem solved. No further effort needed.

Also there are numerous threads in this forum showing how to unmask the unit descriptions manually.

[melinath]

My suggestion:
In the install process, have the option to transfer over the unit descriptions from a previous install. This method keeps the idea of the naturally expanding unit description list as you discover more units, but doesn't make you start over when you update to a new version.

I think you may misunderstand the things involved here... the idea of transferring unit descriptions doesn't make sense. The unit descriptions are all there in the new version, it's just that the list of which ones you've seen in battle that isn't transferred.

I guess that if you like the slow-reveal-feature and purposely have it on, then it would make sense to have some sort of thing to import settings etc. from the last version of wesnoth installed, but that'd require coding and probably isn't a very high priority...?

[Thanatos]

I guess that if you like the slow-reveal-feature and purposely have it on, then it would make sense to have some sort of thing to import settings etc. from the last version of wesnoth installed, but that'd require coding and probably isn't a very high priority...?

As I said earlier: Importing settings from the previous installed version doesn't require coding at all.
Just copy and paste your user data folder (or the parts of it that you need).
You can find the location of your user data folder, using this guide.

[Max]

by default wesnoth puts the users data directory in a user specific folder named after the major (or is it minor?) version, e.g. Wesnoth1.6. so the preferences shouldn't be lost if you update e.g. 1.6.4 to 1.6.5.

[Pentarctagon]

entering into debug mode will also allow you to see every from every era. won't work in mp, but is useful for campaigns/local games.

[Zarel]

Why don't you just copy your user data folder and use it for the newer version of the game?
Problem solved. No further effort needed.

Also there are numerous threads in this forum showing how to unmask the unit descriptions manually.

Ah, remember the Apple Human Interface Guidelines? You know, "the computer should never make the user do things the computer can do itself"? You know, because the entire point of a computer is to do things for the user?

Man, those were the times, right? Too bad the computers are the owners, and we're the slaves now.

[Thanatos]

Ah, remember the Apple Human Interface Guidelines? You know, "the computer should never make the user do things the computer can do itself"? You know, because the entire point of a computer is to do things for the user?

Man, those were the times, right? Too bad the computers are the owners, and we're the slaves now.

I'll take this comment seriously when you have coded the requested feature.
See if it's worth the effort.

[Zarel]

I'll take this comment seriously when you have coded the requested feature.
See if it's worth the effort.

I'll take this comment seriously when I don't code many times more features than I request. How many requested features have you coded?

Seriously, this is getting tiring. The "do it yourself" response is meant only for people who expect others to code their requested feature despite giving nothing in return. Not that I've requested many features, either; I haven't requested a single one here - all I've done is express support for others' feature ideas, and I've done that far fewer times than I've coded up feature requests, too. Heck, I've done that fewer times than I've contributed to Wesnoth, much less OSS in general.

It's not so much that I'm unwilling, but that someone more familiar with the Wesnoth codebase could probably do it better and/or more easily than I could.

[Thanatos]

You don't get my point: I am just being realistic. I use the possibilities which are available at the time.
Sure, this feature would be nice to have. But as I watch this forum for four years now, this feature request will get a low priority because there is an easy solution to that problem which needs no work by the coders at all while at the same time there are a lot of other things to work on with much higher priority. So the effort of time and possibly other ressources is not worth the effect gained - or so I think.

[Iris]

My suggestion:
In the install process, have the option to transfer over the unit descriptions from a previous install. This method keeps the idea of the naturally expanding unit description list as you discover more units, but doesn't make you start over when you update to a new version.

While I am not an expert coder, I think this should be fairly straight forward process. The only potential problem I can think of is what happens when a unit is tweaked between versions, but this shouldn't be an issue within a given stable branch.

Notice that this is more of a feature request for the Windows/other platforms' package installer than anything else.

In general, it's possible to use the same user configuration directory when upgrading an old stable version of the same series (e.g. upgrading 1.6a to 1.6.5) and this is what is done in Windows at the moment IIRC; it's also possible to do this with stable -> development, development -> next stable or old stable -> next stable or copy the configuration directory every time, but saved games and installed add-ons may stop working and you may need to delete them (or upgrade every add-on to their newer versions, in the case of add-ons). Some preferences may be forgotten in case they were renamed/removed between development cycles.

[Noy]

Well since this is an Feature Request, and in the interests of keeping it civil, lets just lock it here.