You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ?
The text was updated successfully, but these errors were encountered:
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.
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.
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 ?
The text was updated successfully, but these errors were encountered: