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

Reintroduce achievement changes + new save compatibility system #200

Open
wants to merge 6 commits into
base: dev
Choose a base branch
from

Conversation

ChronoQuote
Copy link

@ChronoQuote ChronoQuote commented Aug 28, 2022

This branch now features the previously-reverted achievement changes in addition to the new save compatibility system that resolves the issues the changes had with saves. For an alternative option that reintroduces the achievement changes using the vanilla CompatibleNumber system instead, see #258.

e1ee4c0 Improve save compatibility system + extra changes

  • Replace CompatibleNumber system with CompareVersions utility function to improve version checking; with the new OldestSupportedVersion global, this also makes it simpler to check whether a save is outdated

A save file's CompatibleNumber represented the oldest version whose saves were still compatible with the given save's version without any modifications to Save.bb. If an update to the game didn't affect save compatibility, not updating CompatibleNumber allowed devs to update VersionNumber without having to add any checks for the new version in Save.bb. This is because version checks in Save.bb used CompatibleNumber instead of VersionNumber.

For example, suppose 1.3.11 added a new byte to the save file. A feasible way to ensure 1.3.10 saves could still be loaded would be to only read the new byte if the save's version is 1.3.11. But if the game were updated to 1.3.12, devs would have to remember to add 1.3.12 as another version to read the new byte on. And if the game were updated all the way to 1.3.20, suddenly there is a cumbersome piece of code in each load game function that checks whether the save's version is one of 10 different values. The solution was to introduce a CompatibleNumber equal to 1.3.11, store it in every save, leave it alone every update, and check the CompatibleNumber instead of the VersionNumber when reading a save. This way, all saves from versions 1.3.11 to 1.3.20 have a CompatibleNumber of 1.3.11, and so only that original check for version 1.3.11 was all that was ever needed.

But say 1.3.21 adds yet another new byte to the save file. We now have to update CompatibleNumber to 1.3.21 to accommodate the new byte, which means we now have to check for a CompatibleNumber of either 1.3.11 or 1.3.21 when reading the original new byte. If 1.3.22 adds yet another new byte, this becomes a check for a CompatibleNumber equal to 1.3.11, 1.3.21, or 1.3.22. Ideally we'd want to forget about that original new byte already and just read it if the save's VersionNumber is at least 1.3.11. This is exactly what CompareVersions can do. While CompatibleNumber only lets us check whether a save's version falls within a specific period of compatible versions, CompareVersions lets us check any range of versions we want. CompareVersions is based off of the compare functions of other popular languages.

CompareVersions

  • Fix VersionNumber not being stored in save files

When CompatibleNumber was introduced, it took the place of VersionNumber in save files because CompatibleNumber was the only version number we wanted to read from them. But saves in the main menu's load game list show their version number, and we want this number to be the version the save is from, not the CompatibleNumber. Luckily, now that CompatibleNumber is gone, adding VersionNumber back into save files doesn't change the save file structure.

  • Update VersionNumber to "1.3.12dev" to allow us to start fixing compatibility issues with 1.3.11; note that CompareVersions has no issue with letters after a version number!

34fb78c Fix compatibility with new 066 achievement

1.3.11 saves now load again.

@ChronoQuote
Copy link
Author

ChronoQuote commented Sep 1, 2023

Note: the achievement changes were removed from the dev branch, so this PR (specifically e525bb3) should only be accepted if the achievement changes are added back in.

Edit: the achievement changes have now been reintroduced into this branch so it's safe to merge.

@ChronoQuote
Copy link
Author

ChronoQuote commented Sep 16, 2023

6bc5993 Revert "Reverted achievement changes because they break compatibility with older save files"

4d8dfc3 Revert "Removed leftover bits of the SCP-066 achievement (the addition of this new achievements was reverted in accc960, but these changes were accidentally left in). #251"

These revert commits accc960 and 75eee99.

Summary of reintroduced changes:

  • Add SCP-066 achievement that unlocks when the player gets close enough to 066 for it to perform an action; icon by Jabka666
  • Fix achievement order and update DrawEnding to make "SCPs encountered" value on ending screen more accurate (since it is based on achievement order); now 990 is the only SCP missing from this value because it has no achievement
  • Move AchvConsole to last page of achievements next to AchvKeter so that the only achievements on the last page are ones that are unlocked after beating the game
  • Capitalization and punctuation corrections to achievement strings

Note that some pieces of these changes (like the update to DrawEnding) were mistakenly never reverted in the first place and so were not actually reintroduced by this commit, but everything is still listed above anyway.

Video showcasing some of these changes: https://streamable.com/5ypca8

c051ff2 Change version number to 1.3.12

VersionNumber had to be changed to 1.3.12 sooner or later, and with the new save compatibility system, I think this is a good time.

VersionNumber is what appears in the app title and in the corner of the main menu. With the new save compatibility system, it's also the number shown on save files in the load game screen.

@ChronoQuote ChronoQuote changed the title Save compatibility Achievement changes + new save compatibility system Sep 16, 2023
@ChronoQuote ChronoQuote deleted the Save-compatibility branch September 16, 2023 04:41
@ChronoQuote ChronoQuote restored the Save-compatibility branch September 16, 2023 04:43
@ChronoQuote ChronoQuote reopened this Sep 16, 2023
-Replace CompatibleNumber system with CompareVersions utility function to improve version checking; with the new OldestSupportedVersion global, this also makes it simpler to check whether a save is outdated

A save file's CompatibleNumber represented the oldest version whose saves were still compatible with the given save's version *without any modifications to Save.bb*. If an update to the game didn't affect save compatibility, not updating CompatibleNumber allowed devs to update VersionNumber without having to add any checks for the new version in Save.bb. This is because version checks in Save.bb used CompatibleNumber instead of VersionNumber.

For example, suppose 1.3.11 added a new byte to the save file. A feasible way to ensure 1.3.10 saves could still be loaded would be to only read the new byte if the save's version is 1.3.11. But if the game were updated to 1.3.12, devs would have to remember to add 1.3.12 as another version to read the new byte on. And if the game were updated all the way to 1.3.20, suddenly there is a cumbersome piece of code in each load game function that checks whether the save's version is one of 10 different values. The solution was to introduce a CompatibleNumber equal to 1.3.11, store it in every save, leave it alone every update, and check the CompatibleNumber instead of the VersionNumber when reading a save. This way, all saves from versions 1.3.11 to 1.3.20 have a CompatibleNumber of 1.3.11, and so only that original check for version 1.3.11 was all that was ever needed.

But say 1.3.21 adds yet another new byte to the save file. We now have to update CompatibleNumber to 1.3.21 to accommodate the new byte, which means we now have to check for a CompatibleNumber of either 1.3.11 or 1.3.21 when reading the original new byte. If 1.3.22 adds *yet another* new byte, this becomes a check for a CompatibleNumber equal to 1.3.11, 1.3.21, or 1.3.22. Ideally we'd want to forget about that original new byte already and just read it if the save's VersionNumber is at least 1.3.11. This is exactly what CompareVersions can do. While CompatibleNumber only lets us check whether a save's version falls within a specific period of compatible versions, CompareVersions lets us check any range of versions we want. CompareVersions is based off of the compare functions of other popular languages.

-Fix VersionNumber not being stored in save files

When CompatibleNumber was introduced, it took the place of VersionNumber in save files because CompatibleNumber was the only version number we wanted to read from them. But saves in the main menu's load game list show their version number, and we want this number to be the version the save is from, not the CompatibleNumber. Luckily, now that CompatibleNumber is gone, adding VersionNumber back into save files doesn't change the save file structure.

-Update VersionNumber to "1.3.12dev" to allow us to start fixing compatibility issues with 1.3.11; note that CompareVersions has no issue with letters after a version number!
1.3.11 saves now load again.
VersionNumber had to be changed to 1.3.12 sooner or later, and with the new save compatibility system, I think this is a good time.

VersionNumber is what appears in the app title and in the corner of the main menu. With the new save compatibility system, it's also the number shown on save files in the load game screen.
…n of this new achievements was reverted in accc960, but these changes were accidentally left in). Regalis11#251"

This reverts commit 75eee99.
@ChronoQuote ChronoQuote changed the title Achievement changes + new save compatibility system Reintroduce achievement changes + new save compatibility system Sep 25, 2023
ChronoQuote referenced this pull request Sep 25, 2023
…s new achievements was reverted in accc960, but these changes were accidentally left in). #251
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants