Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

backward/forward compatibility #196

Closed
ZwodahS opened this issue Mar 12, 2013 · 3 comments
Closed

backward/forward compatibility #196

ZwodahS opened this issue Mar 12, 2013 · 3 comments
Labels
(S3 - Duplicate) Bug that is duplicate of another one

Comments

@ZwodahS
Copy link
Contributor

ZwodahS commented Mar 12, 2013

I know this is a long forgotten problem but I really hope this is implemented. I have stop playing because of this as well.

So anyway, I thought about the problem and read the code. I can help in coding it but if there is a better way(or if someone else is doing it) then I would like not to do the extra work.I am not sure if this is the best way to do it but here is the proposal.

We could add another array(itype_string) to store all the unique strings of all items, such that each value in itype_id will have a corresponding value in itype_string.

During gameplay, we do not use the string, we will use itype_id as per normal.
During saving, we will create an additional itype_id and itype_string mapping file.
During loading, we will check if the mapping file corresponds to the mapping we have in the current version. If it is similar, then proceed to load normally. If it is different, we can use the mapping file to know what is the id that we need to change.

This way, we can allow for forward/backward compatibility for items without changing any of the gameplay code.

Am I missing anything important here ?

@kevingranade
Copy link
Member

This isn't forgotten, it's issue #40
So basically the game would scan through the mapping file to check if it matches its item array*, and if it doesn't, do a enum->string->different_enum mapping on everything it reads in. Personally I'd prefer to just store the string in the savefiles in the first place and convert them to the appropriate enum when we load. We'd need to be careful to keep she unique string for each type relatively short so we don't kill performance, but that's mostly a separate issue anyway.

*for true backwards/forwards compatibility we need to do the same for player, terrain, overmap, monster, NPC, skills, and who knows what else.

@ZwodahS
Copy link
Contributor Author

ZwodahS commented Mar 13, 2013

I think the performance part is not really an issue, since we only do the check on loading and once it loaded and the savefile is converted, the mapping strings are rarely used.

I am not sure about the other stuffs but It is pretty funny when I load my old save file and my potato chips became a book. I think item_id changes too much from version to version which makes this more of an issue than the other data.

@kevingranade
Copy link
Member

With the json-ification of items, the item issue is dealt with, and this is a duplicate, see #40

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
(S3 - Duplicate) Bug that is duplicate of another one
Projects
None yet
Development

No branches or pull requests

2 participants