Opened 13 years ago

Last modified 10 years ago

#518 assigned change

Maintain savefile compatibility when editing monster.txt

Reported by: GabeCunningham Owned by: GabeCunningham
Milestone: v4 Keywords: recall


In my personal copy, I'm working on moving monsters around (so that they appear in ascending order of depth), and also on adding new monsters. However, doing so really screws with my monster memory, because everything is keyed on the monster's index in the edit file. It would be nice if we could lessen this effect. I'll be thinking of how we might approach this.

Change History (7)

comment:1 Changed 11 years ago by magnate

  • Keywords recall added

comment:2 Changed 10 years ago by GabeCunningham

Come to think of it, there are other problems with modifying monster.txt. If you change the non-obvious flags, for instance, I think you could end up with a situation where the recall for a monster says something that is no longer true. (For example, if you remove a spell from a monster when you've previously observed that spell.)

I guess it just bothers me that even relatively minor changes to monster.txt breaks savefile compatibility, even if your character isn't in the middle of a dive.

I think the potential flags problem shouldn't be too hard to fix -- just compare the flags that the player knows with the actual monster flags, and AND them together.

One idea for dealing with the monster order issue is to let the entries of monster.txt not necessarily be in order of index. In other words, monster.txt might first list monster 32, then 1, then 13, etc. Then, any time we're going to break savefile compatibility anyway, just go through and adjust the numbering of the monsters so that it is in order again. Or, if we want to be really clever, have the save/load code automatically renumber the monster.txt file when it notices that things are out of order.

comment:3 Changed 10 years ago by takkaria

I think the obvious way is just to use monster names as an index. This requires that monsters don't have duplicate names, but I think that's a good restriction to have.

comment:4 Changed 10 years ago by GabeCunningham

If we use monster names as the index, it just moves the problem: then anytime you rename a monster, you mess with the memory.

comment:5 Changed 10 years ago by takkaria

Sure, that's the problem with any index, but renaming monsters should be pretty rare within any given variant after you're past alpha. You're always going to need some key, and using the name seems a lot better than an index.

comment:6 Changed 10 years ago by GabeCunningham

It turns out that with the new parser system, the entries of monster.txt no longer have to be in order by index. But there are other issues (like the flags one mentioned above) where modifying monster.txt breaks savefile compatibility. I'll update the ticket.

My main concern isn't so much with variant maintainers, but with people (like me) who just want to make some changes or additions to their monsters from time to time. (Of course, making things easier for variant maintainers too is a big plus!)

comment:7 Changed 10 years ago by GabeCunningham

  • Owner set to GabeCunningham
  • Status changed from new to assigned
  • Summary changed from Lessen the effect of moving monsters in edit files. to Maintain savefile compatibility when editing monster.txt
Note: See TracTickets for help on using tickets.