[Feature request] Refresh the ftl.dat backup if an update has been installed

[heydojo]

Would it be possible for slipstream to check the version number of the installed copy of FTL (or possibly in the future ITB) when it runs and then refresh the ftl.dat backup it keeps if it detects an application version update? Application updates typically come through steam and I usually only notice that there has been an update after the game has loaded.
There is a thread over on the subset forums asking about if they will add version meta data into the main exe so that it can be more easily checked : https://www.subsetgames.com/forum/viewtopic.php?f=9&t=32805
I don't honestly know of any other obvious way to check for this because FTL does not have a -version application switch and the data files in ftl.dat do not contain any version information.
Is this check and refresh something that could be added to slipstream?
Mod makers obviously want to be testing their mods against the latest code. As also users want to be using the latest code. If there is an update to ftl.dat and then slipstream is used to re-apply mods, the copy of ftl.dat from the backup is used and not the updated code. Unless you manually delete the backup first.

Having to manually delete the backup before you re-apply any mods after an update is not obvious and I would like to think that it is something that could be taken care of automatically by the mod manager.

How about adding a single descriptor file into slipstream created ftl.dats and checking for updates using that? If the file is not there in the ftl.dat inside the game's directory, then the ftl.dat in the game's directory can only be the very latest unmodified version of ftl.dat and that file is then copied and becomes the new slipstream ftl.dat backup. Do you think that would work?

[Vhati]

Would it be possible for slipstream to check the version number of the installed copy of FTL

Nope. It's only hard-coded inside the game's code, to be printed on-screen.

A further concern is that false positives would result in making new backups - of already-patched resources.

Example: A cached MD5 of patched resources presumes there's only one copy of Slipstream. Two copies would surprise each other, when the value circa the last patch disagrees with the current resources.

I don't honestly know of any other obvious way to check for this

Warning: Platforms vary.

Locating and caching an MD5 of the appropriate binary executable would be inelegant but not as inelegant as the mess probing for metadata the proper way for each platform would entail.

On Windows, metadata can be embedded inside an exe.

On Linux, FTL's got a basic launch script that, in turn, points to 32/64 bit binaries. I don't know if there's even a place for metadata.

On OSX, I don't remember what the true executable is, but everything's inside bundle dir with metadata in an xml plist.

On Steam, there's a file with a numeric "buildid" field, also a "LastUpdated" timestamp field. Dunno how stable Steam's internals are to rely on. That might alleviate the primary complaint: Steam betas. Standalone players would know when they run an installer.
"Steam/steamapps/appmanifest_212680.acf"

[heydojo]

Nope. It's only hard-coded inside the game's code, to be printed on-screen.

Yeah. I know it's embedded inside the compiled binary. I was asking because I was hoping you might know that there is a version switch you can pass to the exe to get the version information.
I guess not.

A further concern is that false positives would result in making new backups - of already-patched resources.

Eliminate this by adding a file containing meta data signature information to every repacked ftl.dat
And then reading it back into the application every time slipstream makes changes.

Example: A cached MD5 of patched resources presumes there's only one copy of Slipstream. Two copies would surprise each other, when the value circa the last patch disagrees with the current resources.

This is something that the registry in Windows is for. I understand that this is a platform specific solution. But you could also use the user profile directory to make slipstream aware of multiple instances, configs, etc. User profile is something present on Linux. The use case for multiple instances seems limited. As far as; I think the major edge case is developing slipstream.

Warning: Platforms vary.

I don't doubt it would be naive to assume otherwise.
What remains constant is that FTL has a main application executable which is compiled specifically for each system. Both Windows (EXE) and Linux (ELF) executable binary formats support the inclusion of meta data.
Checking for that meta data would be possible if Subset did add it.
IMO Mac is prohibitively expensive to develop for unless you are already invested. So I really have no suggestion other than to find someone who has OSX and plays FTL in this case.

I am inclined to think that FTL should just behave like all other well crafted binary executables and print a version string, then exit when run with a /VERSION or --version switch.

The steam option looks like a good idea. buildid looks like it might be a solution but only for steam users. My guess is that GOG has it's own updater and that won't provide that file.
Also, the FTL.log has the version string. IDK if the log is created on platforms other than Windows and if it is in the same location. But it is created every time FTL is run. Just not the first time it is installed.
The log file will only provide accurate version information for the last time FTL was run.

The main reason I raised this issue is because if you re-install mods into the latest version of FTL using slipstream without deleting the backup first, the ITB advert does not display properly because the resources are missing from ftl.dat.

[kartoFlane]

Out of curiosity, I checked the buildid on Steam -- it seems to be pretty reliable, as this number is automatically incremented every time the application is updated. Storing the last value, and then comparing it every time Slipstream runs seems like a doable solution.

GOG's own client - Galaxy - also provides very similar appmanifest files with buildid information, though its version string is much longer than Steam's and does not fit in a 32-bit integer. Important to note, Galaxy allows the user to intentionally downgrade to a previous version of the game, so backup refresh would need to be triggered whenever buildids from this platform do not match, not just when the stored one is lower than the most recent.
The file is GOG Galaxy/Games/FTL/goggame-#########.info -- numbers being FTL's appid on GOG, which I do not know.

Edit:
Gist with a proof-of-concept

[Vhati]

@kartoFlane:

GOG's own client - Galaxy - also provides very similar appmanifest files with buildid information

Gah, another meddling app. I've got HumbleBundle (manual download) and Steam.

@heydojo:

I am inclined to think that FTL should just behave like all other well crafted
binary executables and print a version string, then exit when run with a /VERSION
or --version switch.

That would be nice.

adding a file containing meta data signature information to every repacked ftl.dat

Good idea! I once suggested that FTL embed its own version like that, but hadn't considered leaving my own notes in the resources.
.
.
How about this?

During every patching, insert a "THIS_WAS_MODDED.txt" file into the resources containing a hash of the original backup.

If Slipstream ever sees resources that lack that file, the current and backed up dats' hashes ought to match. If they don't, assume there was an update, and fresh backups are needed.

If Slipstream sees resources that have that file, and the backup's hash doesn't match. Warn that the backup is likely stale - and the current dats are modded (ex: by another copy of SMM, or SMM's been pointing to various editions of FTL and has mismatched dats). So FTL needs a reinstall or its Steam cache verified or whatever GOG does. Then fresh backups can be created before patching can occur.

No platform-specific version tracking of FTL's executables, nor DRM parsers needed.

[heydojo]

I would personally choose slipstream.xml inside the data folder with the following xml entries:

• Time and date the ftl.dat repack was started
• Slipstream version number
• Title of each mod successfully installed into the ftl.dat (optionally list each file and whether it was lazy parsed.)
• sha256 hash of the original ftl.dat backup

<modmanager>
	<timestamp date="10/03/2018" time="22:32"/>
	<ssmm_version number="1.9.2" release="beta"/>
	<mods>
			<mod title="PIE15's Planets 1.1r.ftl">
				<file name="img\stars\planet_ice_nebula.png"/>
				<file name="img\stars\planet_habitat_1.png"/>
				<file name="data\events_imageList.xml.append"/>
				<file name="data\events_boss.xml" lazy_parse="true"/>
			</mod>
	</mods>
	<ftldat_checksum sha256="739e80c68fb23be0b616fc4eb9a1928069ab4e8ec7866ecc9ab79aa9840b85c0"/>
</modmanager>

Obviously, the FTL application version number in the mix here would also be wonderful but I like your solution and I am sure that however you decide to implement tracking of the repacks will turn out great.

[kartoFlane]

One advantage of putting the hash in a file inside of the ftl.dat archive is that when FTL receives an update, the entire ftl.dat will get overwritten, and the hash file will not be present anymore. This allows SMM to reliably detect that the game has been updated (or reinstalled/verified), and has not been modded yet.

Steam's updates and verify option do not change or delete files that are not included in the game's vanilla distribution, so slipstream.xml would remain unchanged. As such, the hash stored in it would be effectively useless, as we'd need to compute hash of the game's ftl.dat during every patching anyway to decide for sure whether the game was updated or not.