Prefs and savefiles

[Magnate]

I'm going to try and solve some long-standing pet peeves with preferences for 3.1.3. I think this means a fairly fundamental review of the whole setup, but I thought I'd gather some views here on what other people want. I'll start with a list of things that need saving somewhere, broken up as logically as I can:

1. current character: name, stats, equipment/inventory/quiver, flavour knowledge, squelch settings, autoinscriptions, macros/keymaps, options, randarts, history/notes
2. current dungeon level: map, monsters, floor items, traps, doors, glyphs, terrain etc. (could also include monster drops if predetermined)
3. current store status: owner, inventory
(current home inventory could go with character or stores)
4. object knowledge: metagame "everseen" status of base objects, egos, artifacts
5a. squelch settings for new characters
5b. autoinscriptions for new characters
5c. macros/keymaps for new characters
6. visual preferences (monster/feature symbols/colours etc.)
7. monster memory
8. hall of fame
9. message history
10. artifact memory (not currently used)
11. store history: buy/sell data for market pricing, owner relationships etc. (not currently used)

Currently the savefile stores 1, 2, 3, 4, 7 and 9. The pref files store 5 & 6, and 8 is separate.

I'm interested in your views on how to store these. My thinking is that the savefile should store a bare minimum, i.e. 1 & 2. I think 4, 7 & 10 should be stored separately as metagame data carried across characters. 5 should be organised on a per-class basis, one pref file per class (does anyone really adjust any of these by race?). 6, 8 and 9 should all be stored separately (does anyone adjust visual prefs by class?).

Stores I leave to MarbleDice, or someone else who's going to work on them. The as-is behaviour is to include 3 in the savefile and ignore 11, but if we're moving towards any kind of market pricing system or fixed inventories, or dungeon stores, or whatever, I think they should be saved separately.

I'll stop there and see what people's initial views are. I'll come back with some more specific ideas for changes to pref files (my remit doesn't really extend to messing with the savefile, but I included it for completeness of thinking). For now, have I captured everything we need to save, and grouped it sensibly?

[Marble Dice]

Maybe you should add...

12. All non-adult option settings, including life warning, base delay, etc
13. Adult option settings

...to your list?

It would make the most sense to me to have all "game state" information in the save file, with configuration type stuff in a settings file (options, knowledge, etc), and macros/keymaps, squelch, and inscriptions in a per user/class pref file hierarchy. The way I see it, this would mean:

Save file = 1, 2, 3, 9, 11, 13
Settings file = 4, 6, 7, 10, 12
Scores file = 8
Pref files = 5

[joelsanda]

As long as 3.1.3 can read 3.1.2 savefiles and 3.1.4 can read 3.1.3 savefiles my ranger will be dancing a jig.

[Magnate]

More thoughts

Maybe you should add...

12. All non-adult option settings, including life warning, base delay, etc
13. Adult option settings

...to your list?

Yes, though I'd split them along the lines of

12. All option settings people leave unchanged from game to game
13. Option settings that people change for a different type of game

... these are perhaps equivalent, though I would put the cheat options into 13. I presume "adult" means birth options?

It would make the most sense to me to have all "game state" information in the save file, with configuration type stuff in a settings file (options, knowledge, etc), and macros/keymaps, squelch, and inscriptions in a per user/class pref file hierarchy. The way I see it, this would mean:

Save file = 1, 2, 3, 9, 11, 13
Settings file = 4, 6, 7, 10, 12
Scores file = 8
Pref files = 5

Yes, I pretty much agree with this. What I think this means, and really the whole reason I got interested in this in the first place, is that macros, keymaps, squelch settings and autoinscriptions need to prompt the user to "save for this character only" or "save for all {class}s" (or even all chars). Now, rather than make the user remember to save them, my suggestion is that on exit we check whether any of them have changed and prompt at that point: "squelch settings have changed - save for this character only, all {class}s, all characters, or discard changes (t/c/a/d)". Ditto for macros, keymaps and autoinscriptions (four prompts might get tedious - perhaps one prompt for all four, and we can save them all in the same file).

So I think this is not so much about rewriting pref file handling (though the format could be improved), it's about improving the macro interface. Squelch settings and autoinscriptions are both shown in the knowledge menu - I think the macro/keymap interface needs to list the current macros & keymaps, so you can easily modify or delete them. You also need to know which pref file a particular setting comes from: global (user.prf), your personal (chrisc.prf), this class (ranger.prf) or this char (Explorington.prf) - so that you can save changes to the correct file.

My other thought is that the settings file probably needs to be in plain text, like pref files. Yes this means people can cheat and hack their monster memory (or whatever), but I think editability outweighs that.

Anyone have any views on any of this?

[Pete Mack]

macros cannot be saved in a save file, though keymaps can.
macros are OS-dependent; you really don't want to create a bogus macro from Linux on Windows, etc.

[Marble Dice]

I presume "adult" means birth options?

Well, if you want to get technical, birth options are the options you can change in the = menu. Adult options are fixed at character birth, based on your birth options. You can change birth options any time, but they have no effect on your game - other than to set the adult options for a new character, which in turn affect that character throughout its lifetime. So birth options are a setting, but adult/cheat options would probably be in the savefile (since they do affect game state).

My other thought is that the settings file probably needs to be in plain text, like pref files. Yes this means people can cheat and hack their monster memory (or whatever), but I think editability outweighs that.

That's no sweat off my back, people already have an option to cheat for complete knowledge - and and option to cheat for complete knowledge without flagging their character, but it requires they generate or reference spoiler files. You could also split the settings file into two, along these lines:

Save file = 1, 2, 3, 9, 11, 13
Knowledge file = 4, 7, 10
Settings file = 6, 12
Scores file = 8
Pref files = 5

Knowledge and settings have the same scope (both are per-user files), but might behave differently enough to warrant it - knowledge tends only to get added to, and has no direct need of a non-binary format. Settings should be in plain text and easy to edit, and it might get changed periodically at the player's whim.

[fph]

Just a small usability glitch. I think the two names "settings file" and "pref file" are too similar and do not convey meaning to the final user.
I suggest this renaming:
-save file -> character settings "CharacterName.angband" (yes, we do need an Angband-specific extension)
-knowledge/settings file -> player settings, "player.prf"
-high scores -> global settings, "global.prf" (or highscores.prf is ok if they only include those)
-pref files -> class settings, "warrior.prf", "mage.prf", ...

[bio_hazard]

What about the term windows? I keep having to set them up every time I launch the game, which is kind of annoying.

Also, having some canned, pre-installed options for things like squelching might be nice. If there are common settings that lots of players use, maybe they could be included.

[Magnate]

What about the term windows? I keep having to set them up every time I launch the game, which is kind of annoying.

Also, having some canned, pre-installed options for things like squelching might be nice. If there are common settings that lots of players use, maybe they could be included.

Agreed.

Term window management is port-specific: which port do you use?

[takkaria]

Save file = 1, 2, 3, 9, 11, 13
Knowledge file = 4, 7, 10
Settings file = 6, 12
Scores file = 8
Pref files = 5

These are the groupings I agree with, though I don't understand why preferences and settings are separate. The knowledge file should be stored as a binary, mostly for efficiency reasons (storing bitflags in ASCII is pointlessly verbose when there are cheat options), and also because there's no reason to edit it.

[bio_hazard]

Agreed.

Term window management is port-specific: which port do you use?

I'm on OSX. When I launch Angband the additional windows appear, but aren't assigned.

[Pete Mack]

They shouldn't appear every time. They should start closed the first time; they should keep the state after restarting, and on subsequent new games. (It's supposed to be stored in the ~/Library/Preferences angband settings file.)

Otherwise, it's a regression.

[bio_hazard]

They shouldn't appear every time. They should start closed the first time; they should keep the state after restarting, and on subsequent new games. (It's supposed to be stored in the ~/Library/Preferences angband settings file.)

Otherwise, it's a regression.

Thanks for the reply. Would it make sense to delete the file and have the program recreate it?

Also, could you explain what "regression" means in this case?

[d_m]

Also, could you explain what "regression" means in this case?

In software development a regression usually refers to the following situation:

1. Bug is found
2. Bug is fixed
3. Same bug is later spotted again (a regression occurred)

[bio_hazard]

In software development a regression usually refers to the following situation:

1. Bug is found
2. Bug is fixed
3. Same bug is later spotted again (a regression occurred)

Ahh- thanks. More of a psychiatric analogy than a statistical one...