How do guys feel about list generators that...

[Howard_Casto]

How do guys feel about list generators that automatically parse mame?  The reason I ask is because starting next version.. all mame data has to be parsed and dat files for mame and only mame will no longer be supported.  

I did this because the 3darcade cabinets need the driver.c name to help filter for generic cabs such as my mvs and cps cabs.  I didn't want the user to have to bother with making  both a listinfo.dat and a list details.dat so this seemed the only way to go.  

Anyway I've always been leary of this for flexiability reasons, so I was wondering what kind of success the other fe developers have had with this method.

I would appreciate any comments/suggestions.    

[Chris]

How about parsing MAME by default but allowing the user to create a DAT file to override MAME?  GLauncher does this, and I take advantage of it to just put game names so my game list doesn't have things like (Set 1) or (Bootleg on Galaxian hardware) in it.

--Chris

[SirPoonga]

I do that with my FE.
When I get a new mame I just have to feed it the exe and catver.ini.  It does all the -listinfo stuff to get what it needs.
It's really nice.

I don't understand this statement

only mame will no longer be supported.  

[Howard_Casto]

I don't understand this statement

only mame will no longer be supported.  

What I meant by that is you can no longer supply your own dat file for mame.  The driver.c files are crucial for the 3dcab plugin and the only way I can assure that your listdetails.dat matches your listinfo.dat is to generate them myself.  

Chris:  You could do those alterations you mentioned to the masterlist after you generated it.... no need to bother with the orignal dat file.

[Lilwolf]

I might be interested in it at some point.  

btw, why aren't they named after the parent rom for the 3d cabinet?

You also probably want to allow for you to describe the cabinet you want to use if none are given.   I was planning on allowing you to define a default from catver.ini... so you can say that all fighting games by default will use the SF model....  But it would be great if you could just take all the games based on SF and only do them.  So MK and others wont use a SF cabinet

[)p(]

I might be interested in it at some point.  

btw, why aren't they named after the parent rom for the 3d cabinet?

You also probably want to allow for you to describe the cabinet you want to use if none are given.   I was planning on allowing you to define a default from catver.ini... so you can say that all fighting games by default will use the SF model....  But it would be great if you could just take all the games based on SF and only do them.  So MK and others wont use a SF cabinet

I do all the things you describe in 3darcade  
Howard allready does check for the parent. In a lot of cases the games that use the same driver have a similar cabinet but have not the same parent in mame's sense.

Peter

[SirPoonga]

yeah, there will be a heirarchy of where to look for the cabinet.

First, look for the game it self.  Then look for it's parent (like pacman would then look for puckman), then manufacturue (if there was such a thing as a namco or midway cabinet, cocktails would do that for sure), then driver, like neogeo.c or cps1.c.

[)p(]

yeah, there will be a heirarchy of where to look for the cabinet.

First, look for the game it self.  Then look for it's parent (like pacman would then look for puckman), then manufacturue (if there was such a thing as a namco or midway cabinet, cocktails would do that for sure), then driver, like neogeo.c or cps1.c.

Actually the way I do it and Howard plans to do it also, is a customizable hierarchy...

-top level is a specify entry to use a psecific cab for the game
-game's name
-parent's name
-a list of user definable criteria based on any item in a games gamelist entry...You can specify up to 3 elements...so you can associate cabinet for example with all horizontal vector games made by atari etc.
gencab1|Pinball/10/pinball/10/pinball/10/pinball|
gencab6|cps2a/25/cps2.c/25/cps2.c/25/cps2.c|
-a default cab when no match is found
defcab|Emulaxian|

Peter

[Lilwolf]

Man, it really is starting to sound like we need to create and maintain a new file similar to catver.ini that is just for the cabinet crowd.

Every few weeks we start talking about something similar.   Something that new information could be added by everyone, then a file (whatever form) be generated that can be used by different frontends.

the trouble is that all front need different information, but a lot could be used if it was available. Or can be used in 1/2 the frontends.

As an idea, how about someone putting up a web access to a database that could be updated by different people.  Then, we could use that database to generate a standard XML, or whatever format file that could be sent out and used by multiple frontends.  

Similar to catver, but with more information.  About actual input devices, cabinet style, whatever we want to add.  But make it so that if we add two columns for a new frontend, we would still work in the old ones.

trouble is, this file would get large pretty quick.

[SirPoonga]

Man, it really is starting to sound like we need to create and maintain a new file similar to catver.ini that is just for the cabinet crowd.

Every few weeks we start talking about something similar.   Something that new information could be added by everyone, then a file (whatever form) be generated that can be used by different frontends.

the trouble is that all front need different information, but a lot could be used if it was available. Or can be used in 1/2 the frontends.

As an idea, how about someone putting up a web access to a database that could be updated by different people.  Then, we could use that database to generate a standard XML, or whatever format file that could be sent out and used by multiple frontends.  

Similar to catver, but with more information.  About actual input devices, cabinet style, whatever we want to add.  But make it so that if we add two columns for a new frontend, we would still work in the old ones.

trouble is, this file would get large pretty quick.

HC and I have been thinking about that.  What would be great is to somehow update controls INSIDE of mame.  I sent him code that adds -listfe as a mame options.  Does listinfo but adds driver info also.
I know mame right now is pretty dependant on the current controls listings, I don't know how much work would be involved to go through the games and "correct" the controls.  I'm actually not sure where all the stuff is stored right now.  However, I was thinking that it might e nice to put the actual control names in mame.  so say like you bring up the key config in mame for double dragon, it will say jump, kick, punch, etc...  Unfortunately that will require some intuative changes to mame.  Like how would ctrlr ini files be handled then.

ACTUALLY!.  it would be cool to make a controls.dat file for mame.  It'd be like history.dat and cheat.dat, if it exists it will use the info from that file.  So when you go to config controls menu it would use the labels in controls.dat instead of the default.

[Lilwolf]

I would like to see something that others could add.  An example could be number of controllers (since mame only has number of players... and sometimes thats not the same).

but I would also like to see additions for other emulators.   Might even take input from other sources like dat files.

IE, something that could be added... but the output files would be well defined (and in the definition you would expect infomation that you arent' interested in, so you would skip it... so adding new fields, properties wouldn't effect frontends).

I think if this ever worked, we would want to take information from multiple sources, combine them, and save it to a standard format.  

but whos going to maintain it, whos going to define the fileformat, whos going to host the HUGE file, whos going to ok the additional information added.....

it might be easier to agree on a language for a universal opensource frontend  (hehe)

[Howard_Casto]

We are getting there.....   The cabinets really aren't a biggie.. As far as genric cabs are concerned, pretty much the driver name goes with the cab, so no need for a dat there.  Like for the mvs cab, you simply srach for neogeo.c since all neogeo games have teh same drivers.  For dataeast it's dec0.c and karnov.c and ect... it's really simple and sicne there aren't a lot of cabs yet, it's best to simply document as they are built.  

As for the controls.... the next lazarus is a biggie and I won't want to touch that thing for a LOOONG time after I get it out.  

I will concentrate on the input type project after that.... I've been looking at klov and it's pretty accurate.... with some help I should be able to extract the controller info from them and make controller files from it.  I can modify my list parser to extract mames controller data and setup a blank template for each game based on it's controller type and number of buttons, ect.  Then I can take that and merge it with the klov data to get the captions.  It looks like klov lists the button descriptons int he order in which they are numbered in mame, which should make things very easy.    Since about 90% of the games out there simply use a joystick and buttons, it will go fairly quickly.  The only time consuming part will be the  special controllers.  Since these really stick out, it might be that everyone can do their favorite odd-ball game and we will be done with it.    

SirP I think perhaps that listfe we were talking about could be made external as well.... We could have it read from a dat file as well when it outputs it's data so that any new one's since the last compile would be included as well. Just a thought.  

[SirPoonga]

SirP I think perhaps that listfe we were talking about could be made external as well.... We could have it read from a dat file as well when it outputs it's data so that any new one's since the last compile would be included as well. Just a thought.  

I'm going to start a new thread.  Some people at mame.net are interested too.