Thief Fan Mission Manager Now a Mission Loader

tolsen64 on 25/7/2011 at 23:44

Just an update on my progress....

Due to the difficulty of incorporating the feature requests into the existing code, i'm starting over from scratch. It's slow-going as summer is really busy (my wife is keeping me busy doing things other than programming). But here's what I'm working on (in addition to the feature requests):

* The main window is a WPF window and uses the Microsoft Ribbon instead of a main menu bar.
* Working on replacing the SharpZipLib.dll with the SevenZipSharp.dll. I like the SharpZipLib.dll better, but people have requested support for 7z and rar.
* I'm experimenting with and planning to use the ObjectListView instead of the DataGridView to improve the display of the mission list.
* There will be no separate list for installed missions. If you choose to play a mission that's not installed, it will be installed automatically.
* Can define an "installed missions" directory for each type of mission (SS2, T1, T2, T3).
* Option to only install one mission at a time like DarkLoader (to save disk space). If the option is enabled, the mission will be installed to a folder named "Default" inside the installed missions folder for that mission type. When a different mission is installed, it will overwrite the mission currently installed in the "Default" folder. This will not uninstall any missions installed outside the "Default" folder.
* Moving strings for menus, messages, etc to text files named for the culture they represent (en-US, de-DE, nl-BE, etc). This will allow anyone to translate the strings into the local language.
* Attempting to improve the "optimization" of the games as they are added. To dectect if they are a "fresh" install. If so, mod the appropriate .cfg files to set the resolution (avoids the ddfix error about invalid resolution in cam.cfg).
* May or may not switch from Microsoft Access Database to Sqlite Database. What's your vote and why?

Let me know if you have any additional requests or questions.

Terry

fxdwg on 26/7/2011 at 02:53

It's good to hear you are still moving forward.
Believe it or not, but your latest version (11.7.7.1) is working for me.
I got past the zero byte cam.cfg problem (I manually copied it from my source folder) and ever since, TFMML works correctly. This makes no sense but it now copies cam.cfg on it's own.
I also got past not being able to uninstall a file because 2 other cfg files had been copied with the Read attribute set even though the source was not. That too seem to go away after awhile.
And TFMML no longer crashes every time after exiting from Thief 2.

There was one other weird problem that I never reported. It's been awhile but it had something to do with trying to cancel some operation that was a spawned thread and then that dialog box couldn't be closed. I had to kill the entire TFMML process to get out of it. I don't recall other details.

I like your idea for item #4.
I seem to no longer get that invalid resolution problem (item #8).
I can't wait to see your implementation of the ObjectListView. It is so much prettier than the standard DataGridView.
I can't comment (or vote) on Item #9 since I'm not familiar with SQLlite. I only build my db apps with a MS SQL Server back-end.
Overall, I'm pretty happy with what you have done so far. I still like the editable comments column like darkloader so I can insert notes for my own reference but not worry about them getting overwritten with a file synchro operation.
I can't recall if you were planning on incorporating TDM missions, but that would be a plus.
For me, running T2 missions has been essentially flawless for the past month or so. Keep up the good work!!

tolsen64 on 26/7/2011 at 03:38

Quote Posted by fxdwg

There was one other weird problem that I never reported. It's been awhile but it had something to do with trying to cancel some operation that was a spawned thread and then that dialog box couldn't be closed. I had to kill the entire TFMML process to get out of it. I don't recall other details.

Was it with a later version? Because you used to be able to close the "Long Running Process" window in the middle of it doing something. I changed it in a later version to not allow closure until it reached a "safe" condition. This was to keep it from partially installing a mission or corrupting a zip file.

Quote:

I still like the editable comments column like darkloader so I can insert notes for my own reference but not worry about them getting overwritten with a file synchro operation.

Yes, that's still in the works.

Quote:

I can't recall if you were planning on incorporating TDM missions, but that would be a plus.

That is is my "long term" plans. Right now, I can't even get TDM to run for me. I can choose it in the list of MODS from the Doom 3 menu, but it doesn't run. I get a blank screen and I can hear the menu sounds as I move the mouse. But I haven't successfully launched TDM. Doom 3 itself works fine though.

tolsen64 on 26/7/2011 at 04:10

Quote Posted by fxdwg

I can't comment (or vote) on Item #9 since I'm not familiar with SQLlite. I only build my db apps with a MS SQL Server back-end.

Ya know...I've also been thinking about SQL Server for quite a while. I have multiple computers in my house running TFMM and the fan mission directories are shared from a server which runs SQL server. It would be nice to have all the TFMM's all point to the SQL server so that only one needs to synchronize (or write a small server app that would monitor the folders for changes and update the database automatically)

So i'll add that to my todo list. Allow the user to choose SQL server or local file as the database for the Fan Missions.

But what if you had a laptop like I do and took it on trips? You would not have access to the SQL database. Maybe then only show installed missions...

gnartsch on 26/7/2011 at 07:36

Thanks for the update, tolsen64.
My two cents regarding whether to use SQLServer or stick to a small Access database:
- I am playing Thief on my one and only PC and would not like the idea of having a service running all the time to keep the database up and running just in case I decide to play a FM
Not sure what footprint a SQLServer lite install would have and whether it needs to register & run any services ... but for sure I would not appreciate any overkill application consuming my system like a succubus for no good reason.
- With a 'shared database': How would one distinguish whether yourself has played a mission already or maybe your wife, kids or someone else ?
- Since sharing such a database makes little sense without the FMs residing on a shared drive as well, why not simply allow the user to move the Access database to that drive as well ?

fxdwg on 26/7/2011 at 12:52

I wouldn't recommend using MS Sql Server for the point made by Gnartsch. As you know, it installs another service that always runs in the background (i.e., more overhead). I wouldn't think that every would have MS Access installed. I don't. I just happen to use OpenOffice. If SQLlite doesn't require a service to be installed and has a low-overhead with good performance, it might be worth investigating. But performance-wise, what you've done so far works well.

tolsen64 on 26/7/2011 at 16:15

I wasn't talking about installing SQL server on your pc. But in cases like mine where I already have a server sharing the missions and SQL server is already installed on the server, a shared database could be created on that SQL server. This would only be for the shared missions and mission downloads. All PC specific information would still be stored on the local pc.

Again, this could be an option. It would default to the local database file unless the user specifically wanted to point the application to an SQL database.

gnartsch on 26/7/2011 at 21:39

Quote Posted by tolsen64

Ok. This was not clear from your initial posting.
What exactly would this mean :

Quote:

This would only be for the shared missions and mission downloads

Would it contain only the meta-info for the missions or also the downloaded FM-zips ?
Probably not, since it would be interesting to see how SQLServer light deals with ~18GB of files just for all T1,T2,TDS FMs.
Maybe I just don't get what you have in mind.
Anyway, I would not mind having options that might be useful to others.

tolsen64 on 27/7/2011 at 00:33

Quote Posted by gnartsch

Ok. This was not clear from your initial posting.
What exactly would this mean :

Would it contain only the meta-info for the missions or also the downloaded FM-zips ?
Probably not, since it would be interesting to see how SQLServer light deals with ~18GB of files just for all T1,T2,TDS FMs.
Maybe I just don't get what you have in mind.
Anyway, I would not mind having options that might be useful to others.

(http://www.sqlite.org/) SQLite is not a server. It's a datafile like an Access file. The reason I was thinking of switching to that was because I was unaware there was a field type of "Memo" in Access which allows a character length of more than 255 characters.

I believe the SQL Database (SQL Server, not SQLite) would be useful for the following scenario:

* More than one PC on a LAN is running TFMM and the dark engine games.
* The fan mission zip files are stored on a networked shared directory, on a PC designated as a server.
* The server PC also has SQL server running on it. (Using a data file over a network connection is slow and prone to corruption).
* The SQL database would contain the fan mission list as you see in the first tab of TFMM. The file name, the mission title, file size, path to the file. When one of the TFMM's updates the database, all TFMM's would see the update.
* The SQL database would also contain the download list that's under the 2nd tab of TFMM.
* The TFMM's are all configured with the networked shared directory as the root fan mission folder. So when you install a mission, the source is the zip file from the shared directory and the target install folder is on the local hard drive.

fxdwg on 27/7/2011 at 02:41

I was just reading about SQLite from the link you provided. It looks pretty darn good; being free makes it even better. I like the idea of a flat file that is still an RDBMS without needing something like sql server or even ms office. It might be a good way to go for your app. This would work well for your traveling scenario. You could even make changes to your "offline" copy and merge them back to the main copy later.