69 replies to this topic

[Tempest]

in addition to the post here
http://www.quickplay...p?showtopic=237



Butter100fly wrote:

Quote

I've always been confused why there are two mamehistory processes in qp - firstly you put the history.dat in the DATS folder and secondly you link to a history.dat file per system in the media panel - right now I've got my mamehistory in the DATS folder but I've realised I'm telling QP to link to the 'real' mamehistory.dat in my mame folder in the media panel (see attached) and mame history still works - oddly it is linking to the former (if I take mamehistory out of the dats folder, it stops working)- so is it just completely ignoring the file location in the media panel?!?)

From uMediaTabClass.pas

    jtabMameInfo :
    begin
      tmpStrings := TStringList.Create;
      try
        if FileExists(SettingsPath + 'mameinfo.dat') then
          ROMObj.GetMAMEInfoFromFile(tmpStrings, SettingsPath + 'mameinfo.dat')
        else
        begin
          tmpStrings.Add('MAMEInfo File not found.  You can download it from:');
          tmpStrings.Add('http://www.mameworld.net/mameinfo/');
          tmpStrings.Add('and then copy the file to the DATS directory');
        end;
        tTabTextOnly(useTab.Controls[0]).LoadText(tmpStrings, _TextOpt);
      finally
        FreeAndNil(tmpStrings);
      end;
    end;

Unless 'SettingsPath' is being changed somewhere (and if it is, I can't find where) then I don't see how QP could be using more than one path.

Once again, I have very limited knowledge of Delphi, and apologize in advance if any of my posts today do not make sense.

[ulao]

I get two thing are needed here.

1) use the mameinfo and mamedat for other emulators for the same type of data.
2) allow the user to specific there own location for these file.


---------------------------------

1)Why does what we have not work? As long as you make the dats for each system the same format is shoudl work right? If not tell me how to make it better.

2)Looks to me like the default location is /dats/mameinfo.dat and the medial panel there is an option to specify a different path. Now I looked in to this a bit and I found a way to look in the default (/dats/mameinfo.dat) , and if there is a define in media panel use that instead. This version is up for anyone to check it out. This should work for info and dat.

[Tempest]

I will take a look.

Edited by Tempest, 13 March 2011 - 07:48 AM.

[Tempest]

It works!

A few things that could be improved.

1. The error message could be changed for Non Arcade systems:
"MAMEInfo File not found. You can download it from: http://www.mameworld.net/mameinfo/ and then copy the file to the DATS directory"
2. Could the name of the tab for Non arcade systems be changed from Mame Info to Game Info?
3. Could the path in the media panel include the filename so that all of the dats will NOT have to be named Mameinfo.dat

The history.dat is still broken in the same way that mameinfo.dat was, and It looks like the data that I have for the systems would more closely match history.dat.

I will get a dat done today so you can see this in action.

[ulao]

1) change to what?
2) yes, shall I do the same to mameHistory?
3) I think so, will report back

[Tempest]

ulao, on 13 March 2011 - 09:46 AM, said:

1) change to what?

Eventually, I think the dat files would be hosted on the QP site. Maybe they will be included in the download, and the user will need to told to set the path to them in the media panel?

[butter100fly]

Nice going guys...I'll check this out shortly I'm a bit tied up

ulao, on 13 March 2011 - 09:46 AM, said:

2) yes, shall I do the same to mameHistory?

TEMPEST said:

It looks like the data that I have for the systems would more closely match history.dat.

I had never considered that mameinfo would play a part in this at all - I guess it could, sure, but I instinctively thought history was the obvious one - it looks to me as if Tempest perhaps you unintentionally called this thread 'mameinfo' instead of history? My 2 cents is that mamehistory has game description in it for arcade, and mameinfo has rather more obscure information for arcade, so wouldn't history be better so that you always know that the game descriptions for arcade and console are on the history tab

TEMPEST said:

The history.dat is still broken in the same way that mameinfo.dat was

What is broken? Am I just missing something in your exchange or are you pointing out an existing problem with the MAME history and Info process? (I ask solely because Ulao and I looked at this process just last week and found that problems in the actual mame data itself were to blame for some existing problems I thought we had...)

thanks for this

[Tempest]

butter100fly, on 13 March 2011 - 10:32 AM, said:

What is broken? Am I just missing something in your exchange or are you pointing out an existing problem with the MAME history and Info process? (I ask solely because Ulao and I looked at this process just last week and found that problems in the actual mame data itself were to blame for some existing problems I thought we had...)

thanks for this

QP doesn't use the path from the media panel. It defaults to dats\mamehistory.dat. Or so it seems to me. Ulao has the Mameinfo working correctly, and just needs to make the same changes to the Mame History code.

Yeah, I should have said Mame History from the start. I was playing with it, and actually changing Mameinfo, without giving it any thought. Hopefully you guys will get used to this sort of thing. AS you know my focus is scripting, and not QP or emulation.

Edited by Tempest, 13 March 2011 - 10:41 AM.

[Tempest]

Is the MameName field in the romdata.dat used for anything for Non-Arcade Emulators?
I would like to write a script that would fill in that field using the romname, but stripping off information in brackets. That way in the history.dat files that I will be creating, '3 Ninjas Kick Back (U)' and '3 Ninjas Kick Back (USA)' will both be a match for '3 Ninjas Kick Back' in the dat file.

From uRom.pas:

    if _MAMEName <> '' then
      GameName := _MameName

[butter100fly]

Tempest, on 13 March 2011 - 11:00 AM, said:

Is the MameName field in the romdata.dat used for anything for Non-Arcade Emulators?

nothing, no....always blank

[ulao]

Ok I didnt know this thread grew so much? Please see new version and see how you like it. Please look for bugs. It should be very intuitive.

I just guessed and left the functionality for mameinfo as well.

Please note: when loading a custom dat you will get the option for zips. Just use the drop down for dats. This is because its the same code that loads for screen shots. I dont really see this being confusing and its a lot of work to make a special case.

FYI: I think these paths are stored in the exe. AFAICT its not save to any file. My guess is he did this for speed. If its is stored in the exe would it not get erased each upgrade? Maybe I'm wrong, but if you use notepad++ and search in the exe for the path you just saved, its there. He may be putting this in the registry some where and then on load its imported to the exe. I'm just a bit confused by that atm. It also may be offloading to the documents and settings folder.

[Tempest]

That works Great Ulao. I had no problem Getting everything setup. A screen shot of everything working together.


In the attached System History.zip file is a program called 'Modify Romdata.exe' Run the program to change this:
007 Shitou - The Duel (Japan)¬¬¬¬D:\Emulators\Sega Genesis\Roms\007 Shitou - The Duel (Japan).zip¬Fusion¬¬¬¬¬Japanese¬¬¬0¬0¬<IPS>¬</IPS>¬¬¬
to this:
007 Shitou - The Duel (Japan)¬007 Shitou - The Duel¬¬¬D:\Emulators\Sega Genesis\Roms\007 Shitou - The Duel (Japan).zip¬Fusion¬¬¬¬¬Japanese¬¬¬0¬0¬<IPS>¬</IPS>¬¬¬

Any line with Mame Win32 or [BIOS] in it will be unchanged. Also, your current Romdata.dat file will be renamed to Romdata.dat-copy.

Once that has been done, point to the System History\Sega Genesis\history.dat file in the Media Panel Options for Sega Genesis.

Butter100fly has been working on renaming the entries to match the current file names for each system in QP. Once that is done, I will convert the files to the history.dat format. Also, once everything is renamed, I will be providing a program to enter the data (Rating, Language, GameType, Year, Company, Players) in the roms list as well, so that games will be able to be sorted by those fields.

I have to say this is pretty cool. I am excited!
 System History.zip   890.74K   127 downloads

Edited by Tempest, 13 March 2011 - 03:57 PM.

[ulao]

Hey cool, I wish there was a way to find this saved path data so we could pass it around. I will flag this as a closed bug but let me know if there is anything I messed up or missed.

[butter100fly]

You're damn right this is exciting! look at the potential of that!

I'm sorry to be a moaning minnie here (I have just been SIFT-ing with goodmerged romsets) but I must point out that the screenshot posted is an UN-merged list. how can this work for a MERGED list?

[ulao]

huh? confused whats that got to do with anything? This data is triggered based on the rom name. You set it up just like you do screen shots ( the many options to choose from ), so how would it not work?

[butter100fly]

ulao, on 13 March 2011 - 08:42 PM, said:

huh? confused whats that got to do with anything? This data is triggered based on the rom name. You set it up just like you do screen shots ( the many options to choose from ), so how would it not work?

Sorry Ulao yes this my fault I can see why you're confused, I'm getting lost in threads here, and I have been 'moaning' to Tempest separately (well, trying to advise but not being able to, basically)

The two problems we are having with merged sets are 1) Parentheses on many sets i.e.: (1998) (Atari) and 2) finding the merge logic/set names

So this post should indeed be resolved, thanks for the modding.

However, I've got one observation and one thing to ask, so apologies for posting them here but I can't think of a more suitable place atm:

1) I think that for arcade games QP seems to do this:
* it looks first in field three of the Romdata to find a match to a screenshot/asset IF you have turned on 'for MAME clones use parent ROM for scan'
* it then looks in field two of the ROMdata to find a match
* if it still can't find a match there, it will then default to looking for the romname ie ROMFILENAMENOEXT to find a match
So if this is the same for console sets, and if you had an unmerged set, my suspicion is that populating field two and three would break the link to any existing screenshots/titles, since your Screenshot would have parenthesised info to match the romname. Not sure how much of a problem that is in practise as its only the smaller sets that people will generally have UN-merged, so would be quite quick to rename, or in fact (thinking out loud here) using 'filename must start with ROM filename' would work in precicely this situation, wouldn't it, because the image name would only have ADDED parentheses on the end?

2) So assuming we can ignore the paretheses entirely on all entries: To make the entries for the historydat we will need to know every merged set name for every goodmerged set. We have have lists for the good name and the goodmerge XMDB as our only input files. However in neither of these can we find the actual merging instructions themselves. Here is my example of a problem ROM from the Good2600 merge set:

Space Battle (2006) (Homebrew)
Space Battle - BossTest010 (Dave Neuman)
Space Battle - BossTest100 (Dave Neuman)
Space Battle - BossTest101 (Dave Neuman)
Space Battle - BossTest110 (Dave Neuman)
Space Battle 1.0 (2006) (Dave Neuman)
Space Battle 1.0a (2006) (Dave Neuman)
Space Battle 2006-12-15 (Dave Neuman)
Space Battle 2006-12-15 (Dave Neuman) (PAL)
Space Battle 2006-12-15_fixed (Dave Neuman)
Space Battle 2006-12-15_fixed (Dave Neuman) (PAL)
Space Battle 2006-12-15_fixed2 (Dave Neuman)
Space Battle 2006-12-15_fixed2 (Dave Neuman) (PAL)
Space Battle 2006-12-15_fixed3 (Dave Neuman)
Space Battle 2006-12-15_fixed4 (Dave Neuman)
Space Battle Beta3 (Dave Neuman)
Space Battle Beta3 (Dave Neuman) [a1]
Space Battle Beta3 (Dave Neuman) [a2]
Space Battle Beta3 (Dave Neuman) [a3]
Space Battle Beta3 (Dave Neuman) [a4]
Space Battle Beta3 (Dave Neuman) [a5]
Space Battle Beta3 (Dave Neuman) [a6]
Space Battle Beta3 (Dave Neuman) [a7]
Space Battle Beta3 (Dave Neuman) [a8]
Space Battle Beta3 (Dave Neuman) [a9]
Space Battle Beta3 (Dave Neuman) [aa]
Space Battle Final (Dave Neuman)
Space Battle Final (Dave Neuman) (PAL)
Space Battle Final 1211 (Dave Neuman)
Space Battle Final 1211PM (Dave Neuman)
Space Battle Final 1211PM1 (Dave Neuman)
Space Battle Final 1212PM (Dave Neuman)
Space Battle Final 1213EX (Dave Neuman)
Space Battle Final 1213PM (Dave Neuman)
Space Battle Final 1214 (Dave Neuman)
Space Battle Final 1214PMBoss (Dave Neuman)
Space Battle Final 129PM (Dave Neuman)
Space Battle Final 2 (Dave Neuman)

the XMDB has only this entry in it related to space battle:

<parent name="Space Battle (2006) (Homebrew)"><group reg="^Space Battle"/></parent>

Which is NOT a merging instruction. Its merely an instruction to change the set name which has already been created by goodmerge: Space Battle (2006) (Homebrew) to an unparenthesised version Space Battle
So Ulao I was wondering: Do you happen to know: Where is the instruction/logic in goodmerge that will know that Space Battle Final 2 (Dave Neuman) gets merged into a set called Space Battle (2006) (Homebrew)?

[ulao]

Quote

So Ulao I was wondering: Do you happen to know: Where is the instruction/logic in goodmerge that will know that Space Battle Final 2 (Dave Neuman) gets merged into a set called Space Battle (2006) (Homebrew)?

- From what I remember its based on the good merge XMDB . So its editable. The logic to make the XMDB ( AFAIK ) is not available. For all I know, it could have been hand made.

So your telling me that you can not use the gameInfo.dat with root roms that have (xxxx) in them because it can't get just the rom name without that extra crap in there, right?

Quote

using 'filename must start with ROM filename' would work in precicely this situation, wouldn't it, because the image name would only have ADDED parentheses on the end?

Ok, I remember adding a rom must include filename, but I dont see this now? I think that is the option you need.
'Filename must match ROM filename'
'Filename must start with ROM filename'
'Filename must include ROM filename'
'All Files From Directory')

didn't we add rom filename must match files name?

'filename must start with ROM filename' ::
file name> test.rom
rom file name> test ( usa ).rom
So no file name does not start with "test ( usa )"

Now that i look deeper the laoding of history and info does not use this at all. So I think its best just to trunkate any ( to ) or [ to ]. right?


BTW: I found a bug in that last release ( I fixed it).

[ulao]

Ok I think the truncation is working very well. See latest.

[butter100fly]

ulao, on 14 March 2011 - 07:41 AM, said:

From what I remember its based on the good merge XMDB . So its editable. The logic to make the XMDB ( AFAIK ) is not available. For all I know, it could have been hand made.

uh oh...

ulao, on 14 March 2011 - 07:41 AM, said:

So your telling me that you can not use the gameInfo.dat with root roms that have (xxxx) in them because it can't get just the rom name without that extra crap in there, right?

Actually getting all the info (the game descriptions to put in the history.dat and also the romdata field info) is involved here: It's a really simple problem that I can see you're getting - forget totally about parantheses here,ok, pretend they aren't there, its a more simple and fundamental issue than that: in order to make these entries we need to know what all the set names for all the goodmerged sets actually are. Simple as that....my example shows why: you can't always rely on the set name being the same as one of the roms in the set

what would you say is the easiest way to get that info? My sets aren't the latest or complete, and nor are yours (one example: those gba vids). So how to get a full list of all sets, and preferably what roms are in each set?

ulao, on 14 March 2011 - 07:41 AM, said:

didn't we add rom filename must match files name?

No we didn't - see your comments on the bugtracker for this

ulao, on 14 March 2011 - 07:41 AM, said:

So I think its best just to trunkate any ( to ) or [ to ]. right?

Thanks for making more changes, but not sure I understand - what have you done?

[butter100fly]

ah - glad I noticed this: your new exe brings back that 'range check error' when you try to scan a folder with a lot of roms in it (remeber we had this with the original 3.9.0)

The one you gave us yesterday ie: the immediately prior version to the latest, does not do this