No to those who are calling for backward savefile compatability.
I'm not sure if anyone is calling for backwards compatibility - if they are then never fear, it will be fruitless
My understanding is that the chief reason for keeping savefile compatibility is maintaining monster memory, and that has basically gone away now that monster memory is no longer in the savefile.
No to those who are calling for backward savefile compatability. This is a major new version and major code change here. It was made explicit that there would not be backward compatability, nor do I recall previous major version changes having it either. Start a new savefile. Plus, it's Beta anyway.
I don't think I've had a randart with any speed boosts. I'm used to +2 here, +4 there etc.
I had a search through my randart spoilers from a couple of games back and speed boosts do exist, but they seem to be rarer: I count 9 artefacts with speed boosts in my 4.0 game (not including the One Ring) vs. 21 in a random spoiler file I just generated from 3.5.1.
...Oh, wait, I think I've just figured out why. There are no randarts being generated with multiple stat boosts. So speed (and all other stat boosts) are presumably correspondingly rarer because if a randart already has one stat boost, even if it's infravision or searching, it won't get any of the others.
Originally posted by MattB
Here's the thing, though. I was desperately searching for the Palantir, as my Arkenstone had zero light. But I've just looked at the randart spoiler for this run, and there was no Palantir...
Wasn't the standart Palantir removed from the game a couple of versions back? I think it's been gone since about 3.4...
Here's the thing, though. I was desperately searching for the Palantir, as my Arkenstone had zero light. But I've just looked at the randart spoiler for this run, and there was no Palantir...
I always thought this was one of the things that Tome 2.x got right. (Although this may not have been the intention.)
Angband 3.x went to extraordinary lengths to preserve savefile compatibility. That explicitly went right out the window with 4.0 because the changes to the codebase are simply too huge for it to be worth the effort -- it easily could have added a month or more (in terms of hobbyist-level time commitment) just to maintain backwards compatibility.
I can see the argument for not having 4.0 trounce 3.x's settings, but 4.0 shouldn't be able to read 3.x files. On the other hand, ideally 4.7.9, if/when we get there, should ideally be able to read 4.0 files.
So, you want me to mess around with everyone's (well, the minority running on *nix) pref file settings, window layout, screen dump etc for a little minor temporary convenience for you? Have I got that right? Huh? Is that what you want from me?
</de Niro>
(Sorry for the separate reply, but...)
Yes. You should mess around with them. (I realize that this may be a provoked response, but if so... let's be all-Socratic). Specifically, I think it should be possible to have your Angband settings and UI-independent preferences to be independent of your version-specific savegames. So there!
So, you want me to mess around with everyone's (well, the minority running on *nix) pref file settings, window layout, screen dump etc for a little minor temporary convenience for you? Have I got that right? Huh? Is that what you want from me?
</de Niro>
Seriously, even easier than the -d switch is the -u switch. So what I'm doing when I need to run 3.5.1 to check stuff is angband -u351_char_name.
Heh, like the de Niro impression, but I naively ran Angband 4.x and got some rather "interesting" results. Well, alright it told me, it couldn't load the character, so there's that. If you run without the -u option you just get the default character... which, guess what, Angband 4.x cannot read now.
I always thought this was one of the things that Tome 2.x got right. (Although this may not have been the intention.)
Your save characters were always (hypothetically) safe.
Originally posted by Nick
BTW, savefile names don't have the uid at the front now - it's just the raw name.
Not sure what you mean here. It means nothing for savefile compatibility...?!?
EDIT: Oh, and yes... about prefs &c. Copy them from a previous version if you feel confident that they'll still work! This should not be difficult!
EDIT#2: I do realize that there's a little matter of programming, but as a user.. JUST DO IT ALREADY! HOW HARD CAN IT BE!
@Nick: Just a little feature request: Would it be possible to get Angband 4.x to use a "~/.angband/Angband-4.0" (or similar) version-numbered directory for savefiles &c? It would be nice to be able to run both v3 and v4 in parallel for a while without having to muck about with file systems .
So, you want me to mess around with everyone's (well, the minority running on *nix) pref file settings, window layout, screen dump etc for a little minor temporary convenience for you? Have I got that right? Huh? Is that what you want from me?
</de Niro>
Seriously, even easier than the -d switch is the -u switch. So what I'm doing when I need to run 3.5.1 to check stuff is angband -u351_char_name.
BTW, savefile names don't have the uid at the front now - it's just the raw name.
Can't say I like this, but another, less far-reaching, option would be to tag the actual savefile with the version that created it. so instead of 1000.charname, it'd be v351.1000.charname, but then, what to do with the players that want to upgrade angband, but play on with the same savefile? You wouldn't want to force them to rename the file, or use an import command switch.
In short, I think you should be stuck with the -d option for wanting to play with two different versions
I specifically said "incompatible", so I'm so not sure where you're coming from...? If savefiles can be gracefully upgraded, then there's obviously no problem, and a version bump would specifically not be warranted.
Leaking information. Perhaps the fix for learning obvious effects from aiming wands at walls went to far? Just had a !CSW identified by quaffing even though @ not wounded and had no status ailment.
Thanks, fix will be in the next update - it was IDing by its food properties.
Leaking information. Perhaps the fix for learning obvious effects from aiming wands at walls went to far? Just had a !CSW identified by quaffing even though @ not wounded and had no status ailment.
That's been happening with C*W potions all along in 4.0, I think. I'm not sure I'd really consider it a bug - actually, I'd be in favour of having all non-obvious 'curing' potions (boldness, cure poison, restore mana) always auto-ID on quaffing rather than making it a bit of a tedious extra ID minigame where an experienced player will be almost certain what potion it is already but still have to wait for the right status ailment to prove it. It only affects a small percentage of potions, most of which are trivially cheap and plentiful in the early dungeon anyway, and I'm not sure it's adding anything to the game - the player's already taken the risk by quaffing an unidentified potion, and having to jump through extra hoops after that just seems like unnecessary faffing about.
(I'd argue the same for scrolls of Detect Invisible and Trap/Door Destruction, actually. Everybody who's played Angband for any length of time of time already knows that stack of {tried} scrolls they picked up in the early dungeon is Detect Invisible, so is there really any purpose being served by making the player go and find a Clear Icky Thing to stand next to when they read them before the ID is officially confirmed?)
In fact, I'd actually like to extend this to just bumping the "save directory" revision number every time a save incompatibility is introduced. (Perhaps even in the very commit that breaks compatibility, but perhaps that might be going too far -- though I don't think it occurs that often, even in "master"?)
Can't say I like this, but another, less far-reaching, option would be to tag the actual savefile with the version that created it. so instead of 1000.charname, it'd be v351.1000.charname, but then, what to do with the players that want to upgrade angband, but play on with the same savefile? You wouldn't want to force them to rename the file, or use an import command switch.
In short, I think you should be stuck with the -d option for wanting to play with two different versions
Leave a comment: