Database support for unrecognized disks?

[Vaude]

I'm using FS-UAE Launcher 2.3.99beta2, so I'll ask my question here.

Frode, you said here http://eab.abime.net/showthread.php?p=937672#post937672 that

Originally Posted by FrodeSolheim

The Launcher only shows the games it finds on your system (among those recognized by the database). So if a game does not appear, either you don't have that game, or you don't have the floppy disks the database expects.

Some games have a multitude of alternative disk versions - not all are supported - and additionally, modified disks (say if highscores or savegames are stored on the game disks - won't be recognized).

I hadn't yet noticed that game disks with highscores or savegames aren't recognized. That's certainly unfortunate, because I know I have such disks (can't remember them all, though), and it's only natural to save highscores and such in them. Sometimes in-game keyboard configs can be saved to disk as well (Slam Tilt, for example), and I find that very useful.

Is there some way to add support in Launcher to those disks as well? I find it to be a noticeable downside in Launcher if it can't be done.

(I originally asked this question in the said thread as a quick response, but later on I figured I probably should post my question here instead, so I deleted my original post there.)

[Goingdown]

Originally Posted by Vaude

I hadn't yet noticed that game disks with highscores or savegames aren't recognized. That's certainly unfortunate, because I know I have such disks (can't remember them all, though), and it's only natural to save highscores and such in them. Sometimes in-game keyboard configs can be saved to disk as well (Slam Tilt, for example), and I find that very useful.

I think the FS-Uae launcher & Game database is meant to be used so that you always have the original disks and the system keeps them unmodified. All saves & modifications to disk contents are done only to "overlays" (eg. copies of the originals)... This way you always have original unmodified image available.

Downside of this is if you need to copy the modified content to somewhere - it is not so easy to pick up what you need to copy.

[Vaude]

I see, thanks for the reply.

Yes, there's certainly sense in keeping the original disks unmodified, it's safer. Now that you put it that way, it's all logical. After all, if I want to use my original disk image instead of "overlay", I can still load it separately in Launcher. But that does take away some of the fast & easy use of FS-UAE, which I find to be one of its strong points. But it would be quite unfair to really nitpick about it, as the "trouble" of opening few directories to open a disk image isn't trouble at all. I can also understand that when checksums are based on spesific unmodified disk images, it might be difficult to implement checksum-based recognition to include modified disks as well, because the different checksums would grow somewhat infinitely as even small modification in different disk images would have to be taken into calculation - not to mention that in this way users would probaby have to check/verify their disks against the database record somewhat constantly through internet connection to keep track of changes in disks (If I've understood here correctly how the checksum-verifying works in FS-UAE. I don't know how accurate those checksums are, and what they are precisely based on.) Still, I was hoping that there was some handy way around this. But if it is like I just described, then the current state of things is the most sensible.

But yes, in my case the "damage" is done, because some of my disks are modified. I guess I'll just have to watch closely what's "missing" from my collection when using game database to launch games

[Vaude]

Now that I've had time to think about it (and personally noticed how some games indeed aren't recognized by the database due to high score saves etc.), I really think that this is something that should be looked into in further development. Having two separate set of games (one for unmodified games, the other for modified games) really isn't a good solution. Sure, you can create different personal configurations in Launcher for various modified games or setups, but that sort of defeats the purpose of database - not to mention that it adds extra hassle for the user. However, I'm glad that such option exists, because it's definitely useful.

Would it be possible to include file name-based recognition system to database as well, in addition to current checksum system, or something? Database would first scan the game collection using checksums, and then also list unrecognized games (read: modified games) based on file names or something. Because checksums would be reliable source of identification, scanner could suggest name-based games as being probably this-and-this game, and maybe ask user to verify that. This system would also be useful for user to quickly find out which games in his collection have been modified - trying to do that manually may be a lot of work, if there are several disks with saves on them. Some people don't want to save anything in their disk images, and others do - both approaches are fine. I think it's good that FS-UAE uses these so-called "overlays", that way disks don't get modified by accident. However, I don't understand why database "forces" user to use overlays instead of actual disk images on the hard disk. As I said, using separate configurations for that is clumsy. Wouldn't it be best to let user decide which way to go and still have the database's functionality?

Of course, if this could be accomplished using only checksums, that would be best, because relying on file names isn't reliable. If checksum could recognize the game despite saved high scores etc., that would be excellent. However, I'm not an expert in this, so I can't judge how viable this suggestion is in this regard.

Anyway, what do you think? Do you agree and could it be done?

[FrodeSolheim]

Technically, it isn't a problem to implement alternative matching algorithms:
1) As you say, matching by disk name is one alternative
2) Another option is to not match disks at all, but construct sets of disks entirely on the client side (parsing TOSEC names etc) and associate these with game entries based on extracted game names. I already use such an algorithm to create initial disk sets for the database.

The problems with these approaches is that they don't identify specific disk sets, and therefore the database cannot be used to provide correct variant-specific options (or notices/warnings). For example, information such as that a specific disk set does not work with slow memory cannot be reliably registered in the database and applied to the correct disk sets.

Of course, one could have disk/game matching routine which only pulls in game information and images, but that's another problem than the one I'm trying to solve. I'm more concerned with having behavior which can be accurately reproduced on all users' computers.

In short, I don't plan to significantly change how the online game database works for the foreseeable future. But it is possible I'll make a feature to associate local game entries with database game entries somehow. That would open the door for other people to create tools to perform such game recognition if anyone wants to do that.

[Vaude]

Okay, so the suggestion I've made isn't so simple to implement. Too bad

Obviously some casual gamers and newcomers might not feel strongly about it, but the said addition would certainly be useful. I'm sure that there are other players as well who would appreciate it. That said, I'm surprised that no-one hasn't commented on this, even though this forum consists mostly of straightforward troubleshooting and not idea-based discussions. Or maybe others were just waiting for your reply

Well, thanks for taking time, though Unfortunately I don't have the skills to help here, but I'll keep my fingers crossed and hope that this will somehow get realized in the future.