bassoferrol on 18/5/2016 at 18:18
Well, tolsen64, now there's a message for you. Download file from link.
Have a good day!
Tannar on 2/6/2016 at 14:58
That looks amazing! It seems to do everything I could want it to do. Great work.
fxdwg on 3/6/2016 at 21:49
I just finished watching your video. You're making great progress.
I had a few questions for you.
1) How do you "uninstall" an FM?
2) What happens to saves from an FM when uninstalling it?
3) What happens when you go to update an FM with a newer version? Basically, how are updated missions handled?
3a) Does the new file get a new hash?
3b) How is user-added or custom info persisted when updating an FM?
The updating of FM's is my personal pet peeve of FMSel. I keep losing the meta-data I've added to the missions in the list when replacing with an updated mission file.
tolsen64 on 6/6/2016 at 07:46
Quote:
1) How do you "uninstall" an FM?
2) What happens to saves from an FM when uninstalling it?
I'm not that far yet. I would guess that you delete the folder. If the saves are in the folder, then perhaps delete everything except the saves, leaving the folder itself and the saves in place. Or I could move the saves to the folder with the archive file (named the same but tack on a ".saves" at the end). If you got a better idea, let me know.
Quote:
3) What happens when you go to update an FM with a newer version? Basically, how are updated missions handled?
Updated missions would most likely have a different filename and a different hash. So it would appear as just another mission in the list. I have several missions with different version numbers in my list. Is there a preferred method for dealing with these?
Quote:
3a) Does the new file get a new hash?
Yes. The hash is determined by a cryptographic function which calculates the hash by looking at each byte in the file. So the slightest change would cause a new hash.
Quote:
3b) How is user-added or custom info persisted when updating an FM?
The updating of FM's is my personal pet peeve of FMSel. I keep losing the meta-data I've added to the missions in the list when replacing with an updated mission file
It doesn't see a new mission as an updated existing mission. It just looks at it like a different mission. I know of no reliable way for the program to detect that something is an update. I suppose I could add some sort of UI for you to tell the program that this is an update of a mission so that the program will transfer meta data to the new record.
If you want to try out what I've got so far (uninstalling FMs isn't in it yet), you can get it (
https://github.com/tolsen64/TFMM-fmsel/blob/master/TFMM.7z?raw=true) here. Just unzip everything to a folder, and then point all your cam_mod.ini's and SneakyOption.ini to it: (P:\ath\to\TFMM.dll).
Also, I read on another thread about handling mods. I'm not up on mods so give me some ideas on what this would look like for a mission loader.
fxdwg on 6/6/2016 at 15:09
Thanks for answering my questions.
It is most likely my process for handling updated missions that cause my issues. I personally don't keep older versions of missions, i just replace the old archive file with the new one. So whenever I add custom information via the FMSel interface to a mission, I would have to remember to duplicate all of that to an updated mission file before replacing the old one. As far as I know, FMSel doesn't do this. I also never discovered where FMSel stores the meta-data. I was assuming it stores it within the FM archive file.
I the case of TFMM, you are using an external database. So that makes all of my update comments moot. The database stores the custom meta-data and a filename/path to the archive folder. so an update would most likely just change the FM name in the database.
I like how FMSel handles mission game saves when you "uninstall" an FM, with the option of keeping or discarding saves generated during gameplay. I don't know how popular this mechanism is with the community, but I do use it every now and then.
R Soul on 6/6/2016 at 15:18
FMSel's data are stored in {game folder}FMs\FMSel.ini
The sections of the file are of the form [FM={fm name}]. The {fm name} is based on the archive name, but with . + and ~ replaced with _. If you update an FM, and it has the same filename as the original, FMSel should keep the data.
fxdwg on 6/6/2016 at 16:27
Quote Posted by R Soul
FMSel's data are stored in {game folder}FMs\FMSel.ini.
Thanks, I wasn't aware of that.
So does it parse through your FM storage folder every time you launch Thief?
Is it aware if an archive has been manually deleted from the folder the next time it launches?
All I have noticed is that on some FM's with no "Display Name" set, it uses the file name. After setting a friendly display name, and later replacing the archive, it goes back to showing the file name instead. But honestly, I can't recall if the newer archive file had the same file name as the old one.
tolsen64 on 6/6/2016 at 16:41
Quote Posted by fxdwg
I like how FMSel handles mission game saves when you "uninstall" an FM, with the option of keeping or discarding saves generated during gameplay. I don't know how popular this mechanism is with the community, but I do use it every now and then.
I believe, and I could be wrong, that the old TFMM zips and copies the saves back to the archive folder with the same name as the archive. So it would be "archive.zip" and "archive_saves.zip". Then when you re-install the mission, it looks for that saves file and unzips it back to the mission folder. Either the old TFMM did that, or that was coded into the updated TFMM that was never finished.
R Soul on 6/6/2016 at 16:58
I can't be certain, but it appears to look at each archive and then see if there's an entry for it in the ini file. Deleting an archive won't remove the ini data, but it is quite common for authors to put version numbers in their filenames. I think Komag, when he was hosting T1/2 missions, would put the file date in there.
If an archive doesn't have an ini entry, one will be generated if you've selected the FM before pressing skip, play or exit.
If you have fmname.zip and fmname.7z you'll get two entries, one of them called [fm=fmname(2)].
Finally, new ini entries go at the bottom of the file. They're not sorted.
NewDarkLoader can use a copy of this ini file so users can quickly restore their data, but it can't use the actual file because FMSel seems to rewrite it, which removes some of the keys that are unique to NDL.
