Clarifying the birth process

[jens]

I have a collection of several nitpicks regarding the birth process, all served in one post :-)

#

The default race, i.e. the race that is chosen after you have chosen sex is Kobold, and the default class is Paladin. These should be Human and Warrior.

#

Creating a character
- Mage: add information about gloves and heavy armor reducing SP. I don't know the length limitation for this string, but here are some suggestions:

"Encumbered by gloves/heavy armor"
"Hindered by gloves/heavy armor"
"Hampered by gloves/heavy armor"

#

Reword birth options to increase clarity
- Change 'Restrict' to 'Prevent' (except for the ironman option, since that actually only restricts the use of stairs).

Restrict the use of stores/home
->
Prevent the use of stores/home

Restrict creation of artifacts
->
Prevent creation of artifacts

- Remove negations.

Don't stack objects on the floor	no
->
Stack objects on the floor		yes

Don't generate connected stairs		no
->
Generate connected stairs		yes

Don't show level feelings		no
->
Show level feelings			yes

#

The help text for birth_no_stores claims that you won't be able to buy any potions of restore stat. While true, I guess another example could be better.

[Nomad]

I agree the negations are awkward, but rather than necessarily inverting the options I'd suggest changing the wording to be more like the prevent examples, e.g.:

Don't stack objects on the floor	no
->
Prevent objects from stacking		no

[jens]

I agree the negations are awkward, but rather than necessarily inverting the options I'd suggest changing the wording to be more like the prevent examples, e.g.:

Don't stack objects on the floor	no
->
Prevent objects from stacking		no

Any reason to avoid inverting the options, other than for save file purposes which I just realised :-) The wording is clearer if any negative words are avoided, I agree that it's better to use 'prevent' than using 'don't', but it's even better to use neither.

[jens]

Is there any list somewhere with a compilation of stuff that can only change when we decide to break save file compatibility (i.e. when it's time for 4.0)? Because there are a bunch of issues that are stopped because of this, and it would be good if they could all be done when that time comes...

[Magnate]

Is there any list somewhere with a compilation of stuff that can only change when we decide to break save file compatibility (i.e. when it's time for 4.0)? Because there are a bunch of issues that are stopped because of this, and it would be good if they could all be done when that time comes...

There's no such thing as breaking savefile compatibility any more. Takkaria wrote a block-based savefile format, so if you change something that would have "broken" savefiles, you simply write a new loader for it, and increment the block version. That way, savefiles from before your change will still load.

[jens]

There's no such thing as breaking savefile compatibility any more. Takkaria wrote a block-based savefile format, so if you change something that would have "broken" savefiles, you simply write a new loader for it, and increment the block version. That way, savefiles from before your change will still load.

Loader, as in a program that fiddles with the values to get something that will work in the version after?

[myshkin]

Loader, as in a program that fiddles with the values to get something that will work in the version after?

No, there are different functions in load.c for reading different versions of saved objects, options, etc.