On Tue, 23 Jan 2001 21:29:54 +0000, Maarten ter Huurne wrote:
>That would only work if there is only one package per game, right? I'm not
>sure such a centralized approach is what we want.
This is the "best way" for non-technical users. And, if the target is
advanced users, so we do not need a new standard. (^=
>Also, it would require the emulator (assuming that the update functionality
>is in the emulator) to be able to build a new package in which the info file
>is replaced. Until now, emulators are only required to read information from
>a package, not to modify it, and I would like to keep it that way.
No! (^= The emulator may say "Hey, your package is outdated! Look at
Internet Database - or click HERE to open your browser on it - to see
where you can get the newest version."
That's all.
>> > I think the database should only provide URLs for info related to a
>> > certain GameID. For example, I could query "GameID=snatch Type=music" for
>> > Snatcher game music or "GameID=penadv Type=cover" for Penguin Adventure
>> > cover scans.
>> This will be confusing, I think.
>Which part do you think is confusing?
A non-technical user will never know what is the best version he
will use. Besides, it may have a version with texts only on japanese
(made by a japanese guy) when there is already a version with the
text in japanese AND in english.
Also, this open space for a version with texts in japanese and spanish
and another in english and german... it would be nice if there was only ONE
version with texts in spanish, japanese, english and german. Note, I'm talking
about INI texts, not game texts.
>> Only the INF file would be uploaded to the site. The idea is the .MSX
>> could be uploaded to some place else, like FUNET, only if the .INF *is not*
>> from a know game.
>That would decouple the info file from the package. Again, that would only
>work if there is only one package.
More than one package will bring us to that "This game works but the save game
don't. On the other, the save game works, but the game not". This is confusing.
Errors on mapper descriptions, assing of using GameMaster and others may appear
in different ways in different distros.
The idea is having one only INI for each game, so it can be safely
bugfixed and everyone may benefit from this.
I don't see what is the benefit of more than one Package for the same game
(and I mean the same GameID).
>For example, some ROMs have been modified to run on existing emulators. Many
>people (including emulator authors) consider this ugly and prefer to have
>unmodified ROMs.
The modifications could be done using patch system (which may be present on
the INI... Adriano did it on EXECROM and it works pretty well.)
>It's possible that a modified ROM is spread in a .msx
>package, such a package would have an info file describing the MegaROM mapper
>of the modified ROM image.
It's possible but, if the patch is implemented on INI also, this is not
desired.
>When the mistake is noticed and corrected, there
>will be a different ROM file and a different MegaROM mapper description in
>the info file. The new info file won't work with the old ROM image. That's
>why it's not a good idea to separate the info file from the package.
I think if we have the same game "so patched" that it needs another INI
(like a MegaROM game adapted to Mapper... even I think this can be done
with a patch on INI also) this would require also a different GameID (the
second number will change, I think).
>> Well... they may fight about FUNET also.
>You've got a point there. Although on an FTP site it's easier to discuss a
>part of it (a subdirectory) than for a database, which isn't that transparant
>to the outside world.
The database will contain nothing different from what is inside the .MSX
files. If the database is "out of law", so are the .MSX files.
>I agree that some kind of auto-update would be useful. I'm just not sure
>whether there is a practical way to do it. For now, I think it's best to
>include an identifaction of package versions and then later decide exactly
>how to use that.
Lets make this way... There should be "lots of versions", identified by
names and so on. But it should be one that is classified as the "official"
one. This one will be, in most cases, the most perfect version. This should
follow a numbering version, which may be called DataBaseEntryVersion. This
can only be changed by Database manager, and this field SHOULD NOT be
present on INIs that are not Official versions. Only official versions
(pointed by the database) should have this entry.
So, this way we can support multiple versions of the same package and
support the automatic update info system.
Anyway, I still thinking this is kind of confusing for non-technical/
non-nsx/newbies.
If the target user is myself, any of those will be great, mainly because
I'll edit most of my INIs by hand, if I do not like them.
----- AbraçOS/2, Daniel Caetano ([EMAIL PROTECTED])
/| | | |\
\| ___ |/ OS/2: http://www.quasarbbs.com/daniel/
\/ ----- \/ MSX: http://www.fudeba.cjb.net/
| | Drawings: http://www.djgallery.tsx.org/
-- -- ...Programming to solve the mistery of life!
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
