Mame 108 XML Schema Question

[Boz]

Does anyone know for *certain* what the following XML element would represent in any given game? This is a result of the "mame -listxml" command. It doesn't follow any logic that I can see in about 30 minutes of checking so I'm guessing it's a code of some sort.

(for those just guessing, it does NOT coorespond with the number of players allowed, buttons used, or coins required)

:defender
<input players="1" buttons="5" coins="3" tilt="yes">   (defender has five buttons and 3 coin mechs, but can have 2 players)

:puckman
<input players="2" buttons="1" coins="2"> (puckman has no buttons)

:subhunt
<input players="1" buttons="2" coins="1"> (sub hunter has four buttons)

[Silver]

Nope, you have it right, input players does indicate the number of players. Defender has two ALTERNATING players - not at the same time. i.e. I believe it only says 2 players when it is 2 simultaneous players.

Puckman - This is the type of reason the ControlDat project got started. A lot of the information on games in Mame is incorrect or inaccurate. I believe a lot of it stems from either hacking certain controls or simply using macros or whatever from other games to save time.

e.g. From ControlsDat.XML:

:puckman
 numPlayers="2" alternating="1"
<player number="1" numButtons="0">

which correctly identifies Puckman has having no buttons.

The only catch is the ControlsDat project does not yet have info for all games (everything that goes in is verified off actual cabs or pics of control panels I think).

[Pi]

I seem to remember that the button in Puckman is actually the double speed "cheat", which can be wired to a button (either by making a new button in the control panel, or using an existing button like 1P). However, this extra button in MAME is listed as an independent input, classified as a button. So, there is a reason for MAME listing Puckman with one button, from the hardware point of view, it has one.

Most of the things which people points as "innacuracies" have their reasons, although from a "gaming" point of view they look quite meaningless or simply wrong. That doesn't mean that MAME doesn't have errors, just that it doesn't have as many as people think... 

[Howard_Casto]

I seem to remember that the button in Puckman is actually the double speed "cheat", which can be wired to a button (either by making a new button in the control panel, or using an existing button like 1P). However, this extra button in MAME is listed as an independent input, classified as a button. So, there is a reason for MAME listing Puckman with one button, from the hardware point of view, it has one.

Most of the things which people points as "innacuracies" have their reasons, although from a "gaming" point of view they look quite meaningless or simply wrong. That doesn't mean that MAME doesn't have errors, just that it doesn't have as many as people think... 

Not true.  Puckman doesn't have any buttons.  A speedup cheat in mame uses a button toggle though.  The actual hardware (which is all we care about) didn't have any buttons.  Inaccuracies are just that.  Trust me, sirp and I head controls.dat and a lot of stuff in mame is plain out wrong.  Ask the mame devs for that matter, they'll agree.  Some stuff was added to toggle cheats, some stuff is macro errors, some games have extra inputs hacked in because the original control was "goofy" and the driver author wanted to add support for a normal joystick ect.....  There are a few exceptions, and those are noted in the controls.dat, but generally when mame lists a game with a button and you know that it doesn't have one, mame has added a "fake" button for some reason. 

Don't confuse mame cheats with hardware hacks.  Cheats are the mame equivelent of game genie codes, they don't have anything to do with real hardware. 

[Howard_Casto]

Oh btw..... then number of players thing... that is actually consistant most of the time.  Puckman has cocktail mode and thus has two sets of controls.  Defender doesn't. When mame lists players, it really means the number of independant controls per player.  So 2 player alternating games show up as 1 player games UNLESS they have a cocktail mode. 

[Boz]

Ok... so the reason I was checking this out was my serious lack of enthusiasm with a very popular front end that people use. In fact, after futzing around with most of them, I've come to the conclusion that while their ideas and vision are well intended, the implementation leaves a LOT to be desired, at least on a Windoze machine. None of them aim to impress IMHO, no offense intended.

So, not that we need YAFFE (Yet Another %!#@$ Front End), I'm considering making one for myself that does just what I want it to do.

What would I use to ensure I have *accurate* data since the game listing coming out of Mame has a number of inconsistencies? Can I assume that ROM name, description, date, MFG are mostly accurate from the Mame XML?

Oh... and the history on defender says that they released a cocktail version of Defender, which, following the logic presented here, would mean that <input players="1"> is inaccurate. Right?

Also, what's up with coins="3"? Is that a reference to coin mechs? What could we possibly use this information for?

[Howard_Casto]

What would I use to ensure I have *accurate* data since the game listing coming out of Mame has a number of inconsistencies? Can I assume that ROM name, description, date, MFG are mostly accurate from the Mame XML?

Oh... and the history on defender says that they released a cocktail version of Defender, which, following the logic presented here, would mean that <input players="1"> is inaccurate. Right?

Also, what's up with coins="3"? Is that a reference to coin mechs? What could we possibly use this information for?

The non-control data in mame is usually 99.99% accurate.  It is actually archived while the control info is generated via a macro that looks at the input port defined for the driver. 

No, defender doesn't have a cocktail dipswitch, so the parent rom only has one set of controls as it doesn't have a cocktail mode.  So defender's entry is accurate. 

Coins is the number of coin slots.  This is useful as multiplayer games often have a dedicated slot for each player, but a few "pool" coins, meaning that everyone playing can take a credit just by pressing start.  It isn't terribly useful but the data is printed out because it's part of the macro mame uses for the bookkeeping files.


The thing about displaying controls data inside a fe is... well it's a dumb idea.  Some very basic info might be ok but there simply isn't enough room to show that much data.  That is why I always reccomend calling johnny 5 from within the fe when you are curious as to controls.  Now the other data doesn't take up as much room and I like to put that in a skin sometimes. 

[Minwah]

Ok... so the reason I was checking this out was my serious lack of enthusiasm with a very popular front end that people use. In fact, after futzing around with most of them, I've come to the conclusion that while their ideas and vision are well intended, the implementation leaves a LOT to be desired, at least on a Windoze machine. None of them aim to impress IMHO, no offense intended.

I could be wrong but it sounds to me like you are disappointed with fe's based on inaccuracies or flaws in the information given by Mame, since that is the only problem you really mention.

While I know the control types given from Mame are not always exactly 'realistic', they do give a very good starting point for filtering games lists (particularly since v0.107 when this info has become more detailed).  As Howard says, there is no too much point displaying this data, you would be better off using controls.dat.

I personally in the past have used Mame's control info and catver.ini to filter games lists for my various control panels, with very good results.    There are normally a few games which need manually sorting just due to inaccuracies or inconsistent info, but generally it works OK.

[u_rebelscum]

What would I use to ensure I have *accurate* data since the game listing coming out of Mame has a number of inconsistencies? Can I assume that ROM name, description, date, MFG are mostly accurate from the Mame XML?

The mame XML is as accurate as mame, ignoring the few generalizations done to simplify for human readability.

The control area has the most generalizations.  For example, as mentioned before, "players" is really "the highest player number used in the input stack in the game's driver".  Another example, "buttons" really is "the highest button number used in the input stack in the game's driver".  If a button number is skipped, it's not noted (AFAIK, no driver skips more than one button).  If a button is used as a hack for something it can effect the button number (if it pushes the buttons numbers up, like pacman) or the players number (if a different player is used to keep the button count correct).

The easier stuff (name, description, etc) have a much higher accuracy rate, and are changed if found and agreed to be wrong.  The high accuracy is mostly because they are easy to check, verify, and change.

Oh... and the history on defender says that they released a cocktail version of Defender, which, following the logic presented here, would mean that <input players="1"> is inaccurate. Right?

No, defender doesn't have a cocktail dipswitch, so the parent rom only has one set of controls as it doesn't have a cocktail mode.  So defender's entry is accurate. 

Looks like one of the following: mame doesn't have the cocktail version ROM dumped (if it was a different ROM), that part is not emulated, or the history is wrong.  I'm guessing the first one.

... Some very basic info might be ok but there simply isn't enough room to show that much data.  That is why I always reccomend calling johnny 5 from within the fe when you are curious as to controls.  Now the other data doesn't take up as much room and I like to put that in a skin sometimes. 

Yes, the controls can be too much sometimes, while the basic info is easy.  Take the 50 or so different input types (from controls.dat), and the hundreds of different combinations they have been used, even after mame's simplification of the inputs to a dozen types, and you've got a tangle to mess with.