controls.dat (control label info in mame)

[SirPoonga]

I asked mame.net what they thought about adding a controls.dat to mame.  R.Belmont, as usual, is against the idea because it serves no purpose to mame.  Though I responded neither does hiscore, history, and cheats then (This is just a joke mamers, don't flame me)

Some people are interested in the idea.
I've been looking into how to add a dat file to mame.  I don;t think it is that hard.  Just will take time.

First, we need the controller info.  Like HC said, KLOV is 90% accurate.  We need people to start filling in a dat file then.  So this will have to be organized.  Any suggestions?

Here's a suggested idea for the controls.dat
[romname]
P1 BUTTON1=JUMP
P1 DOWN=CROUCH
...
[end]

The left side should be listed just as the ctrlr files list them.  Look at std.ini in /mame/ctrlr.
[end] really isn't needed, just makes coding it ALOT easier.  You will see ends in mameinfo.dat and history.dat.

So, what could we do with this then.  Well, we all know how cool it would be in an FE to actually display the controls.  (That has become a little harder if you want to accurately portray them with your CP if you use ctrlr files)
However, this also would be useful in mame.  In the Config Controls UI instead of saying "P1 BUTTON1" it would say "P1 JUMP".  It would make understanding the controls of a game much easier.

Also, for the majority of the clones andsuch, they use the same labels.  So we should focus on the parents first.

Now, I don't have the facilities to host something like this or organize it.  We might have to figure that out.  If you are interested, PM me, I'll get a group of us together in the chat room to talk about it.

BTW, I've been playing with the mame source code lately, HC, that -lisfe taught me abit on how dto do a project like this.  Maybe we can talk PJ into letting us have a forum for this at mame.tk or planetjay.com.

[rampy]

All though it wasn't an orignal idea... *sniff* I'm so proud the thread I started kicked this off...

Anyways... if need be I can create a forum on randomdrivel's forum... or add a total separate forum in the same webspace...  or if it was an gpl type license of this dat file sourceforge supplies all the same stuff for "Free"

*Shrug*
let me know what's needed.

rampy

[SirPoonga]

All though it wasn't an orignal idea... *sniff* I'm so proud the thread I started kicked this off...

This idea has been around long before you were a member here too.  But it was all talk, Action needs to take place.

Anyways... if need be I can create a forum on randomdrivel's forum... or add a total separate forum in the same webspace...  or if it was an gpl type license of this dat file sourceforge supplies all the same stuff for "Free"

The problem with CVS, one person would have to be in control of it.  You couldn;t just let a bunch of people directly edit a file.  Problems occur then.  Though it may not be a bad idea.  Like mame, as long as there was one person to approve of a change that person can then add it to the final source.

I'd also like to add, part of the process then would be people would submit controls along with proof that those controls are accurate.

[knobunc]

I have started on this process.  I have done 108 out of 477 driver files over the last week.  I can post my current work if anyone is interested (is there a way to attatch files using this forum or should I stick it on a web site)?

Below is a sample of the format that I am generating:

---
[atarigt.c:primrage]
URL: http://www.klov.com/P/Primal_Rage.html
MOVE_URL: http://db.gamefaqs.com/coinop/arcade/file/primal_rage.txt
GAMEFAQID: 3575
LAYOUT: 2
PLAYERS: 2
IPT_JOYSTICK: Movement 8-way
IPT_START1: High Quick
IPT_BUTTON1: High Fierce
IPT_BUTTON2: Low Quick
IPT_BUTTON3: Low Fierce
NOTES: Hidden bowling game (look at gamefaqs.com for info)
---

Each block starts with the driver filename and the input definition (there are sometimes the specific game names as a further qualifier if each game that uses the same input has different controls).

I have been putting the gamefaq IDs in and the KLOV url for the game so that a front end can provide links if wanted.  Some games have the MOVE_URL if they have complicated button combinations that can be used.  Finally you can say BASE: filename:inputdef to establish a parent/child relationship between the input defs (occasionally useful when there are multiple clones of a game that are in a driver file that has input definitions that are generic and each game has different behaviors).

Anyway, I plan to keep chugging on this and hope to have it done in a couple of weeks.  Then I plan to write another program to validate the klov urls (sometimes I biff them when going from gamefaq to klov to the file).  If people have ideas for a better format or other information that would be useful to capture.

-ben

[SirPoonga]

[atarigt.c:primrage]
URL: http://www.klov.com/P/Primal_Rage.html
MOVE_URL: http://db.gamefaqs.com/coinop/arcade/file/primal_rage.txt
GAMEFAQID: 3575
LAYOUT: 2
PLAYERS: 2
IPT_JOYSTICK: Movement 8-way
IPT_START1: High Quick
IPT_BUTTON1: High Fierce
IPT_BUTTON2: Low Quick
IPT_BUTTON3: Low Fierce
NOTES: Hidden bowling game (look at gamefaqs.com for info)

Interesting.  A little too much info needed for a controls.dat for mame.  For a FE, that would be ok.
A couple things I don't like about the format.
[driver:romname]  - Uhg, makes it fun trying to find a specific game in  language that doesn't have regular expressions.
Button nameing, IPT_BUTTON1.  What's the IPT?  I think it should follow the names in the ctrlr std.ini file.  The reason being amme used that, so it is a simple if statement to replace the text in the UI.
What's "IPT_JOYSTICK: Movement 8-way"  IS that to just get the type of controls?  True, mames -listinfo isn't 100% accurate, but I wouldn't call it LPT_JOYSTICK then.
Players, not needed, neither is the driver, all can be gotten in mame.
The URLs are good for an FE, if it wants links, but for controls.dat that acts like hiscore.dat it is information not needed.  Though I can see adding it.


knobunc, I'm not against your efforts.  I do like the URL stuff and the stuff in it for FEs, that can be skipped over in mame but it also useful information.  I just look at the format as a programmer and go eeeek.

I don't understnd the BASE thing, show and example.  

I would like to see what you have done.  My email is on my website, attach it.  You can not atach files here, just link to them.

[knobunc]

I figured that more information is better especially if it is easy to get now (whereas later it would suck to have to reget).  Haveing the IDs and URLs allows you to see the sources (besides the driver code and playing the games) that were used.

The format is a windows config file format.  I can easily rework it into a different form if needed (perl is good at that stuff).

The IPT_BUTTON1, etc. style comes from the input definitions in the drivers themselves.  They are the internal names mame uses (with some simplifications).  Again, they are easy to translate from if a different format is required.  I only put P1, P2 on them when the player controls are different for each player.  I do note how many sets of controls there are in the layouts (simultaneous players) and how many players can play total.

IPT_JOYSTICK: Movement 8-way indicates that the joystick for each player is a control for movement and allows you to move it in 8 directions.  I envision all of this being shown by a front-end (not necessarily mame) so it would signal to me that I need to make sure my controls are in 8-way position, not 4-way or 2-way.

As a note, the [atarigt.c:primrage] is the driver source file and the input definition, not the source file and driver name, there is an optional third item that allows you to specify a driver when multiple drivers use the same input.  Look at cave.c for instance.

I have mailed you the complete file as it stands now.  The links have not been validated yet and there are a bunch of notes to me where I need to complete the controls.

-ben

[SirPoonga]

Well, it looks like a controls.dat file will never be officially in mame.  Sigh, amazing wht the mame team allows and doesn;t allow into mame.

So most likely it will have to be an offshoot build.  This would probably be easier than other custom builds.  as this would really only affect the UI in mame and that rarely changes dramaticiclly enough that a build that supports controls.dat.

I'm looking into sourceforge.  I know HC, you don't like it, but it has its good points:)
I don't know who would be in charge, but I think you can setup sourceforge like this.
There would be a main build of mame that uses the controls.dat and the source.  That should only be updated by one person who can add final changes, like nicola with amme and torvalds with linux.  However there should be a few people that can add submissions to controls.dat to keep up with the initial demand.  The submissions would have to go through a process of verifying the controls are accurate.

[SirPoonga]

I figured that more information is better especially if it is easy to get now (whereas later it would suck to have to reget).  Haveing the IDs and URLs allows you to see the sources (besides the driver code and playing the games) that were used.

The format is a windows config file format.  I can easily rework it into a different form if needed (perl is good at that stuff).

The IPT_BUTTON1, etc. style comes from the input definitions in the drivers themselves.  They are the internal names mame uses (with some simplifications).  Again, they are easy to translate from if a different format is required.  I only put P1, P2 on them when the player controls are different for each player.  I do note how many sets of controls there are in the layouts (simultaneous players) and how many players can play total.

IPT_JOYSTICK: Movement 8-way indicates that the joystick for each player is a control for movement and allows you to move it in 8 directions.  I envision all of this being shown by a front-end (not necessarily mame) so it would signal to me that I need to make sure my controls are in 8-way position, not 4-way or 2-way.

As a note, the [atarigt.c:primrage] is the driver source file and the input definition, not the source file and driver name, there is an optional third item that allows you to specify a driver when multiple drivers use the same input.  Look at cave.c for instance.

I have mailed you the complete file as it stands now.  The links have not been validated yet and there are a bunch of notes to me where I need to complete the controls.

-ben

First, IPT_JOYSTICK.  That might better be named IPT_CONTROLS??  I could see since this controls.dat file will be used in mame and in FEs that having the CORRECT controls would be done here too.  I hate how dotron says trackball!!

Like I said, I am seeing who is all interested in contributing and getting a chat together.

The reason I suggest having that format I mentioned in the first post is that one, it can be parsed by any ini reader, the [end] will never be used and will not have any vars in it.  But for systems/languages that can;t use an ini reader and the dev has to make a parser the end makes it alot easier.  remember, this will have to be parsed in mame too for the control info.

Also I suggest the P1_BUTTON1 format because the ctrlr files use that and the code to parse is already in mame, copy and paste baby!
AND it's what shows up in the UI so a simple text replacement is easy to code.  With the IPT format there's alot of extra coding that really isn't needed then.  that's my reasoning.  Plus, just thought of this, for FE devs it's easier to.  Most likely if controls are going to be showed in an FE eache joy/button will have a value, like p1joy8way, p1button1.  So it will be really easy to map the controls.  

Oh, there is a twist to this, especially with my ctrlr hacks.
I see an FE doing this.  Somehow someone can map out their control panel (like arcadefx util).  this would involve placing the default locations of buttons.  IE like on my panel the buttons are
456
123
But with my hacks for any 4 button game it it
XX4
123
and for 6 button games it is
123
456.
For mvsc its
123
4X5
This is all done in ctrlr files.  BUT if it was done in cfg files getting at the configs is near impossible:)  So, the FE would have to know about the ctrlr files (and/or the cfgs) to accurately dipaly the controls the user uses.  Then with controls.dat to accurately labels.  Which is pretty difiicult.  I think some sort of setup file is actually needed for the FE then, that would remap where P1_Button1 is according to the layout, number of buttons etc of the game.  

That means what I said earlier is incorrect.  If we put the CORRECT controls in controls.dat (IE dotron will say it has a spinner and a joy with buttons) we will need the number of players, number of button from -listinfo.

[knobunc]

Since I am parsing the raw driver.c files I am effectively generating the same info as -listinfo, but mine happens to be more detailed about the specific control info.

I see that my .ini file format is bust, I should have =s rather than :s, but that can be fixed later.

The reason that I do not have 1 input definition per game is that that would generate a ton of definitions, this seems to cut it down by a quarter which makes maintenance a bit easier for the moment.  Internally mame knows which input definition it is dealing with (look at the code for -listinfo).   If needed we can expand the file out later, getting an input name to game name mapping is easy and then rewriting the definitions is easy too (but makes maintenance harder).

I am not sure waht you mean by renaming IPT_JOYSTICK to IPT_CONTROLS.  I would rather document the controls that mame has at the moment (and I plan to fix the controls if they are obviously bust in mame as doing this complete scan will turn up errors).

In the future I would love to add a more sophisticated controls mechanism to allow you to define your controller and have the controls be automapped to the mame ones in a more sophisticated manner so that if I have a spinner it will use that, if I don't I can choose to map it to buttons or a second joystick...  but that is a big task for the future.

So for dotron:

[mcr3.c:dotron]
URL: http://www.klov.com/D/Discs_Of_Tron.html
GAMEFAQID:
LAYOUT: 1
PLAYERS: 2
IPT_JOYSTICK: Movement 8-way
IPT_DIAL: Aim
IPT_TRACKBALL: Aim (Y) (hack)
IPT_BUTTON1: Fire
IPT_BUTTON2: Deflect
IPT_BUTTON3: Aim Down
IPT_BUTTON4: Aim Up


-ben

[SirPoonga]

Since I am parsing the raw driver.c files I am effectively generating the same info as -listinfo, but mine happens to be more detailed about the specific control info.

Could you modify that to create a skeleton controls.dat file?  Like output the control info for each game, leave the right side of the = blank?

the driver file is nice for FEs, I added it to -listinfo for HC.  But it shouldn't be in the [] for ini files for FE use.  that way the FE just needs to use the romname as the key to the INI file parser.

The reason that I do not have 1 input definition per game is that that would generate a ton of definitions, this seems to cut it down by a quarter which makes maintenance a bit easier for the moment.  Internally mame knows which input definition it is dealing with (look at the code for -listinfo).   If needed we can expand the file out later, getting an input name to game name mapping is easy and then rewriting the definitions is easy too (but makes maintenance harder).

1 input defination per game, when would you have more???
Also, technically mame doesn;t know the imput definition, it needs to be derived fromt he GameDriver object, hence that huge case statement:)

I am not sure waht you mean by renaming IPT_JOYSTICK to IPT_CONTROLS.  I would rather document the controls that mame has at the moment (and I plan to fix the controls if they are obviously bust in mame as doing this complete scan will turn up errors).

Ahhhh, I get it now, with one example I didn' understand what that was.
Shouldn;t it be IPT_JOYSTICK=JOY8WAY, what mame uses??  Or DOUBLEJOY8WAY, that use list of constants in that one source file....

In the future I would love to add a more sophisticated controls mechanism to allow you to define your controller and have the controls be automapped to the mame ones in a more sophisticated manner so that if I have a spinner it will use that, if I don't I can choose to map it to buttons or a second joystick...  but that is a big task for the future.

Right, like that stuff I was talking about.  That can get very complicated, I have an idea to implement something like that, but it all depends on the final format of this project.

So for dotron:

[mcr3.c:dotron]
URL: http://www.klov.com/D/Discs_Of_Tron.html
GAMEFAQID:
LAYOUT: 1
PLAYERS: 2
IPT_JOYSTICK: Movement 8-way
IPT_DIAL: Aim
IPT_TRACKBALL: Aim (Y) (hack)
IPT_BUTTON1: Fire
IPT_BUTTON2: Deflect
IPT_BUTTON3: Aim Down
IPT_BUTTON4: Aim Up

Yeah, I can see how the IPT stuff is better inside of mame.  That;s why I need to get together people interested in this, and FE devs interested in this.  I see this being used more in FE than in mame, it;s just nice to add to mame, looks all pretty.  So it should be a format that makes life easier for the FE dev but still useful inside of mame.

[SirPoonga]

Well, and FE devs want to reply with what they'd like to see the format as?

[knobunc]

Could you modify that to create a skeleton controls.dat file?  Like output the control info for each game, leave the right side of the = blank?

Sure, can you provide a snippet so I get an idea of what you want?

the driver file is nice for FEs, I added it to -listinfo for HC.  But it shouldn't be in the [] for ini files for FE use.  that way the FE just needs to use the romname as the key to the INI file parser.

I think we both agree that the current format is not the final one.  Is a convenient format for the moment because each input definition requires quite a bit of hand editing.  I cna transform it later when I am done with the thing, and we come up with a good final format.

1 input defination per game, when would you have more???

No. the other way around.  Some games share the same input definition.  Often these have the same control meanings so that it is easier for me to just do one input definition rather than duplicating it for all 3 games.  I can rewrite the file into a different format later.

Also, technically mame doesn;t know the imput definition, it needs to be derived fromt he GameDriver object, hence that huge case statement:)

Agreed.  Again it is way easier for me to do it this way.  This is not the final format and was never intended to be.

Ahhhh, I get it now, with one example I didn' understand what that was.
Shouldn;t it be IPT_JOYSTICK=JOY8WAY, what mame uses??  Or DOUBLEJOY8WAY, that use list of constants in that one source file....

Nah..  the stuff to the right of the : is simply a text string that is intended to be displayed to the user as is.  I happen to try to keep the terminology consistent as much as possible.  I suppose I can add more fields that actually tell you what all of the attributes on the inputs are (toggle, 8-way, cheat, etc).

Right, like that stuff I was talking about.  That can get very complicated, I have an idea to implement something like that, but it all depends on the final format of this project.

Cool.

Yeah, I can see how the IPT stuff is better inside of mame.  That;s why I need to get together people interested in this, and FE devs interested in this.  I see this being used more in FE than in mame, it;s just nice to add to mame, looks all pretty.  So it should be a format that makes life easier for the FE dev but still useful inside of mame.

Sure.  The IPT stuff is just a convenience for me at the moment.  I can transform that later, I hadn't realized that the ctrlr/std.ini had a different format.

Did you get the file I mailed to you with my current working copy?

-ben

[Minwah]

Well, and FE devs want to reply with what they'd like to see the format as?

Hows about this for eg:

tron
noplayers=2
nocontrollersets=1
description=8-Way Trigger-Stick & Spinner
controller1=joy8way
controller2=dial
JOYSTICK_UP=UP
JOYSTICK_DOWN=DOWN
JOYSTICK_LEFT=LEFT
JOYSTICK_RIGHT=RIGHT
DIAL=AIM LEFT
DIAL_EXT=AIM RIGHT
BUTTON1=FIRE

sf2
noplayers=2
nocontrollersets=2
description=8-Way Joystick
controller1=joy8way
JOYSTICK_UP=UP
JOYSTICK_DOWN=DOWN
JOYSTICK_LEFT=LEFT
JOYSTICK_RIGHT=RIGHT
BUTTON1=LIGHT PUNCH
BUTTON2=MEDIUM PUNCH
BUTTON3=FIERCE PUNCH
BUTTON4=LIGHT KICK
BUTTON5=MEDIUM KICK
BUTTON6=FIERCE KICK

Here's how it works:

noplayers: obvious

nocontrollersets: just means how many complete controllers there are - ie 1 for 2 player turn-based games, or 2 for 2 player simultaneous play etc).

description: this need only apply to games with wierd controllers, or controllers not catered for by MAME itself, eg '8-Way Rotary Joystick'.  It could be specified for ALL games tho (note my SF2 eg), for FE display purposes (?)  OR it could be used in similar format to MAME's: eg stick8way+dial ??

controller1,2 etc: this refers to how MAME handles the input for the game.  eg 'joy8way' AND 'dial' for say Ikari Warriors.

JOYSTICK_UP etc: this is the description for each input direction/button etc, in the ctrlr.ini format.  Note that P1_ would be used in front of these, and P2_, P3_ & P4_ if applicable (determined by noplayers).

Whaddya think?  

[SirPoonga]

Minwah, very simular to my first.  Here' the problem I see with that format, games like firetruck that use different labels for 1 and 2 player, need to support that.
Plus, to be ini file compliant (vb, vcc, m$ have ini parsers, makes life easier) the romname would be in brackets.  Makes it easier to search for a rom then too:)

Otherwise yeah, including the actaul control info is needed.  This will most likely incluse something from everyone;s idea.

[SirPoonga]

Could you modify that to create a skeleton controls.dat file?  Like output the control info for each game, leave the right side of the = blank?

Sure, can you provide a snippet so I get an idea of what you want?

Well, you'd end up with a file with all the games in it, nothing on the right side fo the =.
Like
[mvsc]
BUTTON1=
BUTTON2=


etc, but in your format for now.  You say you get that info formt he driver.c so you'd end up with more correct controls for games like tron.

1 input defination per game, when would you have more???

No. the other way around.  Some games share the same input definition.  Often these have the same control meanings so that it is easier for me to just do one input definition rather than duplicating it for all 3 games.  I can rewrite the file into a different format later.

That's what I thought, like parent-clone information, for now unles the clone is undefined, it's use the parent's format.  Will save on work filling outall the data too.

Did you get the file I mailed to you with my current working copy?

-ben

Yeah, been busy today, haven;t looked at it yet, just file size, alot of work I see.

[)p(]

Well, and FE devs want to reply with what they'd like to see the format as?

I like the klov link...my fe can embed html pages in the info menus...a shame klov does not let you use their data straight then you would be able to make a custom look that fits with the fe skin. I love klov but think it looks ugly ;-)

Peter

[Minwah]

Minwah, very simular to my first.  Here' the problem I see with that format, games like firetruck that use different labels for 1 and 2 player, need to support that.
Plus, to be ini file compliant (vb, vcc, m$ have ini parsers, makes life easier) the romname would be in brackets.  Makes it easier to search for a rom then too:)

Otherwise yeah, including the actaul control info is needed.  This will most likely incluse something from everyone;s idea.

Yeah, you're right, I'd assumed that P1 & P2 controls are always the same  

How about this:

[tron]
noplayers=2
nocontrollersets=1
P1description=8-Way Trigger-Stick & Spinner
controller1=joy8way
controller2=dial
P1_JOYSTICK_UP=UP
P1_JOYSTICK_DOWN=DOWN
P1_JOYSTICK_LEFT=LEFT
P1_JOYSTICK_RIGHT=RIGHT
P1_DIAL=AIM LEFT
P1_DIAL_EXT=AIM RIGHT
P1_BUTTON1=FIRE

[sf2]
noplayers=2
nocontrollersets=2
P1description=8-Way Joystick
P2description=8-Way Joystick
controller1=joy8way
P1_JOYSTICK_UP=UP
P1_JOYSTICK_DOWN=DOWN
P1_JOYSTICK_LEFT=LEFT
P1_JOYSTICK_RIGHT=RIGHT
P1_BUTTON1=LIGHT PUNCH
P1_BUTTON2=MEDIUM PUNCH
P1_BUTTON3=FIERCE PUNCH
P1_BUTTON4=LIGHT KICK
P1_BUTTON5=MEDIUM KICK
P1_BUTTON6=FIERCE KICK
P2_JOYSTICK_UP=UP
P2_JOYSTICK_DOWN=DOWN
P2_JOYSTICK_LEFT=LEFT
P2_JOYSTICK_RIGHT=RIGHT
P2_BUTTON1=LIGHT PUNCH
P2_BUTTON2=MEDIUM PUNCH
P2_BUTTON3=FIERCE PUNCH
P2_BUTTON4=LIGHT KICK
P2_BUTTON5=MEDIUM KICK
P2_BUTTON6=FIERCE KICK

[firetrk]
noplayers=2
nocontrollersets=2
P1description=360deg Steering Wheel + Pedal + Buttons
P2description=360deg Steering Wheel + Button
controller1=dial
controller2=dial
P1_DIAL=STEER CAB LEFT
P1_DIAL_EXT=STEER CAB RIGHT
P1_PEDAL=ACCELERATE
P1_BUTTON2=HORN
P1_BUTTON3=TRACK SELECT
P2_DIAL=STEER TRAILER LEFT
P2_DIAL_EXT=STEER TRAILER RIGHT
P2_BUTTON1=BELL

??

OK so for games where P1 & P2 controls are the same (see sf2 above), there is a lot of stuff repeated (ie larger file size) - this just seemed the easiest way to me atm.

I'm not sure how MAME gets the descriptions 'Gas', 'Horn', 'Bell' & 'Track Select' in the tab menu (for Firetruck).  Could you enlighten me?

Also, I've never actually done any .ini file parsing - I realise this is the way to go, so I've added the brackets, and I'll do a little research on how to do it when I get a chance.

[knobunc]

I like the klov link...my fe can embed html pages in the info menus...

Good.  I hoped FEs would do that.  BTW the gamefaq ID is enough to make a URL from too...  Just replace the XXX in the following URL: http://www.gamefaqs.com/coinop/arcade/game/XXX.html

-ben

[Howard_Casto]

Minwah, very simular to my first.  Here' the problem I see with that format, games like firetruck that use different labels for 1 and 2 player, need to support that.
Plus, to be ini file compliant (vb, vcc, m$ have ini parsers, makes life easier) the romname would be in brackets.  Makes it easier to search for a rom then too:)

Otherwise yeah, including the actaul control info is needed.  This will most likely incluse something from everyone;s idea.

Yeah, you're right, I'd assumed that P1 & P2 controls are always the same  

How about this:

[tron]
noplayers=2
nocontrollersets=1
P1description=8-Way Trigger-Stick & Spinner
controller1=joy8way
controller2=dial
P1_JOYSTICK_UP=UP
P1_JOYSTICK_DOWN=DOWN
P1_JOYSTICK_LEFT=LEFT
P1_JOYSTICK_RIGHT=RIGHT
P1_DIAL=AIM LEFT
P1_DIAL_EXT=AIM RIGHT
P1_BUTTON1=FIRE

[sf2]
noplayers=2
nocontrollersets=2
P1description=8-Way Joystick
P2description=8-Way Joystick
controller1=joy8way
P1_JOYSTICK_UP=UP
P1_JOYSTICK_DOWN=DOWN
P1_JOYSTICK_LEFT=LEFT
P1_JOYSTICK_RIGHT=RIGHT
P1_BUTTON1=LIGHT PUNCH
P1_BUTTON2=MEDIUM PUNCH
P1_BUTTON3=FIERCE PUNCH
P1_BUTTON4=LIGHT KICK
P1_BUTTON5=MEDIUM KICK
P1_BUTTON6=FIERCE KICK
P2_JOYSTICK_UP=UP
P2_JOYSTICK_DOWN=DOWN
P2_JOYSTICK_LEFT=LEFT
P2_JOYSTICK_RIGHT=RIGHT
P2_BUTTON1=LIGHT PUNCH
P2_BUTTON2=MEDIUM PUNCH
P2_BUTTON3=FIERCE PUNCH
P2_BUTTON4=LIGHT KICK
P2_BUTTON5=MEDIUM KICK
P2_BUTTON6=FIERCE KICK

[firetrk]
noplayers=2
nocontrollersets=2
P1description=360deg Steering Wheel + Pedal + Buttons
P2description=360deg Steering Wheel + Button
controller1=dial
controller2=dial
P1_DIAL=STEER CAB LEFT
P1_DIAL_EXT=STEER CAB RIGHT
P1_PEDAL=ACCELERATE
P1_BUTTON2=HORN
P1_BUTTON3=TRACK SELECT
P2_DIAL=STEER TRAILER LEFT
P2_DIAL_EXT=STEER TRAILER RIGHT
P2_BUTTON1=BELL

??

OK so for games where P1 & P2 controls are the same (see sf2 above), there is a lot of stuff repeated (ie larger file size) - this just seemed the easiest way to me atm.

I'm not sure how MAME gets the descriptions 'Gas', 'Horn', 'Bell' & 'Track Select' in the tab menu (for Firetruck).  Could you enlighten me?

Also, I've never actually done any .ini file parsing - I realise this is the way to go, so I've added the brackets, and I'll do a little research on how to do it when I get a chance.

Minwah... as we discussed before simply putting joy8way won't work... we need to define each axis/input for a controller seperately.   So controller1, controller2 wouldn't work....

Also it would be a lot of repetition....  

Firetruk would be a very special case so we would have to ignore it for now.   This is one of maybe 3 games out there that have this special case so I don't think it's worth worrying about just yet.  

Probably what we will do is like the ctrlr .ini file and allow inputs like
p2xaxis=

when a game is two player simultaneous it only looks for player one by default and clones it....
but if player 2 is found it makes seperate inputs for each player.  That way typing can still be reduced.
   

[knobunc]

OK so for games where P1 & P2 controls are the same (see sf2 above), there is a lot of stuff repeated (ie larger file size) - this just seemed the easiest way to me atm.

Ugh.  The approach that I decided to take is if the controls are generic then I simply put the number of layouts in the file and the number of players total.  Then if the controls differ for some reason then I put a P1_ (or P2_ etc.) on the front.  There are also some controls where a single player's input spans multiple players in MAME due to limitations of the input system (e.g. cnemat.c's speedfrk).  In those cases I also prefix the controls with P1_, etc.

I am opposed to simply duplicating the control information because it makes the file huuuge and really hard to maintain.  However, I am not arguing my method is the best.  At the very least I should probably introduce more information about how the controls map to layouts to accomodate the three cases we have discussed (each layout is a duplicate of the others, different layouts for each player, one layout uses controls from multiple players).

I'm not sure how MAME gets the descriptions 'Gas', 'Horn', 'Bell' & 'Track Select' in the tab menu (for Firetruck).  Could you enlighten me?

It is possible to put an optional description in the input definition.  Very few drivers do this.  I am thinking about adding strings to most of them and submitting that as a patch.  However, I think putting the control type in the string is useful e.g. 'P1 - B1 -  Gas' otherwise it is difficult to tell at a glance what button the control is associated with.  Whereas when the descriptions are not present it is easy to tell what controls are in use but not what they do.

-ben

[Minwah]

Minwah... as we discussed before simply putting joy8way won't work...

I think I was asleep during that part  

Seriously tho, I only just really started thinking about HOW it would work within our FE's...

Harder than it first seems

[SirPoonga]

Minwah... as we discussed before simply putting joy8way won't work... we need to define each axis/input for a controller seperately.   So controller1, controller2 wouldn't work....

I like Minwah's format.  It does define each axis/input seperately, AND you also need to know what type of control, like joy8way.

Just take out the controller1 and controller2 stuff.
I'd see soemthing like

[tron]
CONTROLS=DIAL|JOY8WAY

Then if the game had somethign like up was jump add
P1_UP=JUMP

[Howard_Casto]

I read that one post a little wrong... the controller type=joy8way would be ok, but I think that it would only be useful for reference and not using the dat file to display a layout. But since we also want to preseve the contoller information that should also be in there.  


Btw I am almost finished with a skeleton dat file maker so no one has to bother with that... I only have to add the trackball and spinner generation and it's done.

[SirPoonga]

I read that one post a little wrong... the controller type=joy8way would be ok, but I think that it would only be useful for reference and not using the dat file to display a layout. But since we also want to preseve the contoller information that should also be in there.  


Btw I am almost finished with a skeleton dat file maker so no one has to bother with that... I only have to add the trackball and spinner generation and it's done.

Ahhh, but it is useful information.  Especially if FEs are goin to start allowign a person to layout their CP in the FE.  If someone has a dedicated 4way...


Make the dat file thing accept a list of of drivers/games so whena  new version of mame is out you can just generate the new stuff.

[Howard_Casto]

I read that one post a little wrong... the controller type=joy8way would be ok, but I think that it would only be useful for reference and not using the dat file to display a layout. But since we also want to preseve the contoller information that should also be in there.  


Btw I am almost finished with a skeleton dat file maker so no one has to bother with that... I only have to add the trackball and spinner generation and it's done.

Ahhh, but it is useful information.  Especially if FEs are goin to start allowign a person to layout their CP in the FE.  If someone has a dedicated 4way...


Make the dat file thing accept a list of of drivers/games so whena  new version of mame is out you can just generate the new stuff.

Well it's good for putting a caption on a graphic but that's about it.   I'll explain that one later, it's complicated.  

Anyway... I've finished the app, which rihgt now simply takes one of my masterlist files and converts it.  I can eventually convert this again to parse directly form mame, but for now this is good.

I have a skeleton file ready that I will make available and link on this post.  It includes all working drivers from .61, even the ones that are commented out.

Based on what we had talked about I added a few extra fields.  I added the game name for obvious reasons, and [end] bracket as we had discussed earlier, and a Misc entry for special case games that need an explaination about the controls.

[Howard_Casto]

Ok here it is....

http://www.oscarcontrols.com/lazarus/files/controls.zip

It's completely blank and ready for you to fill in...

Btw, I've also started work on a klov extractor but it needs some work.  So far I can extract button labels, the number of simultanious players and the controller type fairly well, but the problem is actually finding the name of the page for a given romname....

Klov doesn't use the revision names as does mame, so it's hard to extract data... I'm looking into a way of removing the revision information on the mame descriptions.  I will probably split at "(" and use the first field in the array as the url to search for.  any other ideas on this?

[)p(]

Ok here it is....

http://www.oscarcontrols.com/lazarus/files/controls.zip

It's completely blank and ready for you to fill in...

Btw, I've also started work on a klov extractor but it needs some work.  So far I can extract button labels, the number of simultanious players and the controller type fairly well, but the problem is actually finding the name of the page for a given romname....

Klov doesn't use the revision names as does mame, so it's hard to extract data... I'm looking into a way of removing the revision information on the mame descriptions.  I will probably split at "(" and use the first field in the array as the url to search for.  any other ideas on this?

Mmm...I will look if I still have it somewhere but I actually had a conversion table for a lot of games made for a personal build of my fe that did retrieve the html page and converted it to something fitting the Emulaxian theme...
format was simple
romname|klov url|

Peter

[SirPoonga]

I read that one post a little wrong... the controller type=joy8way would be ok, but I think that it would only be useful for reference and not using the dat file to display a layout. But since we also want to preseve the contoller information that should also be in there.  


Btw I am almost finished with a skeleton dat file maker so no one has to bother with that... I only have to add the trackball and spinner generation and it's done.

Ahhh, but it is useful information.  Especially if FEs are goin to start allowign a person to layout their CP in the FE.  If someone has a dedicated 4way...


Make the dat file thing accept a list of of drivers/games so whena  new version of mame is out you can just generate the new stuff.

Well it's good for putting a caption on a graphic but that's about it.   I'll explain that one later, it's complicated.  

You;ll have to explain more then.  Cause I see it useful for mapping the FE to the controls.dat to the joy4way, joy8way, trackball, steering wheel, etc on the control panel.  Otherwise think about it, if a person has a dedicated 4way, how will you distinguish between the player 1 8way and the player 1 4way??

edit: after looking at your skeleton, I think we are tlaking about sperate things....

[SirPoonga]

Ok here it is....

http://www.oscarcontrols.com/lazarus/files/controls.zip

I took a look at it, cool, but issues.  As knobunc is doing he'd getting the controls out of the drivers, not mame.  That's why his dotron is a more correct.  I think a combo of the two will be needed.

A couple of issues I see with HC's format, but I like it.

First
[vsyard]
Description=10 Yard Fight (Vs. version 11/05/84)
numPlayers=2
alternating=
P1ControlType=8-way Joystick
P2ControlType=8-way Joystick
P1ControlType=4-way Joystick
P2ControlType=4-way Joystick
P1_JOYSTICK_UP=Up
P1_JOYSTICK_DOWN =Down
P1_JOYSTICK_LEFT =Left
P1_JOYSTICK_RIGHT =Right
P1_BUTTON_ 1=
P1_BUTTON_ 2=
MiscDetails=
[end]

So, what control type does it use???


Yep, had to bring this up:)
[dotrone]
Description=Discs of Tron (Environmental)
numPlayers=3
alternating=
P1ControlType=Trackball
P2ControlType=Trackball
P1_TRACKBALL_Y=Up
P1_TRACKBALL_Y_EXT=Down
P1_TRACKBALL_X=Left
P1_TRACKBALL_X_EXT=Right
P1_BUTTON_ 1=
P1_BUTTON_ 2=
P1_BUTTON_ 3=
P1_BUTTON_ 4=
MiscDetails=
[end]

And finally there is really nothing correct in
[firetrk]
Description=Fire Truck
numPlayers=3
alternating=
P1_BUTTON_ 1=
P1_BUTTON_ 2=
P1_BUTTON_ 3=
MiscDetails=
[end]


I know I am bringing up the difficult ones, but I noticed with knobunc's it is much more correct.  It has to be a format that can support unique control interfaces, who knows what additional games are going to put in mame in the future anyway?  
(what's upt with the '_ ' at the end of P1_BUTTON_ 1 =)

I do like the alternating idea, that;s a very good thing to know.


So, I suggest,, we list the requirements and uses people will get out of the controls.dat first.  Then from there start to decide a format that is best suited for those requirement.

What I can think of off the top of my head

Should use label type found in std.ini, will make it really easy inside of mame to replace labels in the config UI.  That I think is the only reason to have it in mame, unless someone else has a bright idea.

For the future (and now), the format will need to be flexible enough to handle odd controls.  this might me redundance like labels for P1_BUTTON1 and P2_BUTTON2 even though the label is the same.  Hey, these only have to be edittedonce, theoretically so I don;t think a copy and past would hurt:)  (I noticed HC you don;t incluse other player controls in your skeleton file, not flexible enough in my opinion)

What other info can FEs use?  I like the alternating HC put in, that means in an FE just one joystick can be highlighted and both player start buttons too to indicate 2 players.
KLOV link is interesting, some FEs will probably use that.

Has to be in ini format for windows dev, the [end] is nice for non-windows apps, makes it easier for manual parsing.

It will have to list multiple control types, like for dotron.  So something like P1CONTROLS=DIAL|JOY8WAY or for firetrk P1CONTROLS=DIAL  P2CONTROLS=DIAL and another line would say P1_PEDAL=ACCELERATE.  Unless one thinks PEDAL should be listed in the CONTROLS sting so FE's don;t have to look for P1_PEDAL, P2_PEDAL, etc....


Edit:
Oh, one might think,since DIAL can mean many things, in mame, like steering wheel, spinner, etc.  I don't think that belongs in this file, especially if the file is used to change the UI in mame.  Another file formatted somthing like
[romanme]
control=MAME_CONTROL
Description=description

[firetrk]
control=P1_DIAL
description=360 Wheel

That format will work for not just DIAL, obviously.  It's be a simple lookup then.

[SirPoonga]

Ok, I started looking in mame on how the UI labels are displayed.  Here's what I got.
look in /src/inptport.h and .c
line 381 (of .61)
struct ik input_keywords[] =

Interesting struct.  The ik struct is just name, type, value.  Example:

   { "KEYCODE_A",               IKT_STD,      KEYCODE_A },
   { "KEYCODE_B",               IKT_STD,      KEYCODE_B },
   { "KEYCODE_C",               IKT_STD,      KEYCODE_C },

...

   { "P1_JOYSTICK_UP",         IKT_IPT,      IPF_PLAYER1 | IPT_JOYSTICK_UP },
   { "P1_JOYSTICK_DOWN",      IKT_IPT,      IPF_PLAYER1 | IPT_JOYSTICK_DOWN },
   { "P1_JOYSTICK_LEFT",      IKT_IPT,      IPF_PLAYER1 | IPT_JOYSTICK_LEFT },
   { "P1_JOYSTICK_RIGHT",      IKT_IPT,      IPF_PLAYER1 | IPT_JOYSTICK_RIGHT },
   { "P1_BUTTON1",            IKT_IPT,      IPF_PLAYER1 | IPT_BUTTON1 },
   { "P1_BUTTON2",            IKT_IPT,      IPF_PLAYER1 | IPT_BUTTON2 },

This struct is used witht he ctrlr files to match the name, then set the controls based on the value.  So in a ctrlr file you will see

P1_BUTTON1  "KEYCODE_A"

What the ctrlr parser will do is look at P1_BUTTON1.  It will see that in the srtuct is is of type IKT_IPT (input) and has the value of the TWO constants, IPF_PLAYER1 and IPT_BUTTON1 ORed together.
Note: that's how the driver defined controle, from topspeed driver

PORT_BIT( 0x80, IP_ACTIVE_HIGH, IPT_BUTTON1 | IPF_PLAYER1 )   /* main accel key */

OK, we know what control to set, now what to set it to.  that's the next value in the input, KEYCODE_A.  So, we look that up in the struct, It is has a name of "KEYCODE_A", type IPK_STD, value of KEYCODE_A (A constant holding some value).  Well, now we can assign the control to the constant:)

Now, you want to know why I bring this up?  If we want controls.dat to work in mame UI, It is alot easier to keep witht he ini file format if we use the name and not value.  (knobunc, this is why I wouldn;t use IPT_XXXX in the dat file).
If you use the IPT format in the dat file because then we probably would have to nest data, like:

[firetrk]
IPT_PLAYER1:
IPT_BUTTON1=Horn
IPT_PLAYER2:
IPT_BUTTON1=Bell
[end]

Ahh, that won't work with an ini parser:(
However this will

[firetrk]
P1_BUTTON1=Horn
P2_BUTTON2=Bell
[end]

Now, there is issues.  We know -listinfo lists "wrong" controls.
That is because in the driver they do this (dotron example)

   PORT_START   /* fake port to make aiming up & down easier */
   PORT_ANALOG( 0xff, 0x00, IPT_TRACKBALL_Y, 100, 10, 0, 0 )

But also in that driver we know dotron uses a dial and joystick

   PORT_START   /* IN1 */
   PORT_ANALOGX( 0xff, 0x00, IPT_DIAL | IPF_REVERSE, 50, 10, 0, 0, KEYCODE_Z, KEYCODE_X, 0, 0 )

   PORT_START   /* IN2 */
   PORT_BIT( 0x01, IP_ACTIVE_LOW, IPT_JOYSTICK_LEFT  | IPF_8WAY )
   PORT_BIT( 0x02, IP_ACTIVE_LOW, IPT_JOYSTICK_RIGHT | IPF_8WAY )
   PORT_BIT( 0x04, IP_ACTIVE_LOW, IPT_JOYSTICK_UP    | IPF_8WAY )
   PORT_BIT( 0x08, IP_ACTIVE_LOW, IPT_JOYSTICK_DOWN  | IPF_8WAY )
   PORT_BITX(0x10, IP_ACTIVE_LOW, IPT_BUTTON3, "Aim Down", IP_KEY_DEFAULT, IP_JOY_DEFAULT )
   PORT_BITX(0x20, IP_ACTIVE_LOW, IPT_BUTTON4, "Aim Up", IP_KEY_DEFAULT, IP_JOY_DEFAULT )
   PORT_BIT( 0x40, IP_ACTIVE_LOW, IPT_BUTTON2 )

so, if we can make a skeleton file that uses the info from the drivers, it's more correct, but still not 100%.  It will still take man power.
Oh, I think I could have mame itself output the skeleton file.  Kinda like -listinfo.  This might help out too, since, with the dotron and firetrk examples, some of the labels are already.
Actually, MAMe can store the labels!!!  That;s what PORT_BITX is.  It's an extended version of PORT_BIT.
Someone want to do an experiment for me., I'm a little busy right now with other tasks (this post took me forever to right)  Take a game where you know the control labels.  Replace PORT_BIT with PORT_BITX in the driver.

Like fine
INPUT_PORTS_START( ddragon )
Ok, this might be a bad example, but do this anyway.
You see in INPUT_PORTS_START(ddragon) there is
COMMON_INPUT_PORTS and
COMMON_PORT4
If you look just above you see that's where the buttons are defined for ddragon.  hehe, this won;t work well with the ddragon example since ddragon1 and 2 are slightly different labels.  Anyway, do this.  Replace
PORT_BIT( 0x10, IP_ACTIVE_LOW, IPT_BUTTON1 )
with
PORT_BITX( 0x10, IP_ACTIVE_LOW, IPT_BUTTON1, "Punch", IP_KEY_DEFAULT, IP_JOY_DEFAULT  )
compile, run ddragon.  See if in the UI it says Punch for button 1.  If so, hmmmm...  I'm not suggesting all the drivers need change, I doubt mamedevs will will allow that.  Just curious.

[Howard_Casto]

Actually my skelton file includes all of the std entries with the exception of vertical spinners and paddles.  

The other things you saw were glitches in the program that i didn't catch simply because those few games you choose are so freakin wierd.  Btw those example would have to be entered manually anyway, so I don't see the big deal there.  There isn't any way you can get the information of those particular games automatically.  

Remember sirp this is beta... I posted it so others could find glitches.  

[SirPoonga]

Actually, thinking about it, having labels in the MAME UI will make things confusing.  Though P1_BUTTON1 is easier to use in the ini file format:)

What do you guys think?  If you have the label, you don't know which button number in mame it is, SO it would be confusing to know exacly which button on your CP should be the "jump" button, etc...

Plus this really does have more of an advantage in FEs than in mame itself.

[SirPoonga]

Actually my skelton file includes all of the std entries with the exception of vertical spinners and paddles.  

The other things you saw were glitches in the program that i didn't catch simply because those few games you choose are so freakin wierd.  Btw those example would have to be entered manually anyway, so I don't see the big deal there.  There isn't any way you can get the information of those particular games automatically.  

Remember sirp this is beta... I posted it so others could find glitches.  

And I pointed out the glitches:)  I know it isn't final!
yeah, there's alot that would have to be updated.
Hence there would have to be a process to update it.  Like a CVS type thing with submissions.  A couple of people in charge verify the submissions and add them to the master dat file.

[Howard_Casto]

Download the controller.zip again... i fixed the bugs in the parser and those games you mentioned are much more accurate now...

As for your above comment I have no clue where you are going.  The inital idea of this project was to make a file that a front-end or similar program could parse and display a control panel layout based upon it's findings.  Other than using the ctrlr files to get the actual keyboard keys assigned to said controls, I don't think mame has any relivance.  (Although it would be really nice to be able to get the data via parsing mame.)  Yes descriptions would be nice, but the user interface of mame would have to be reworked in order to make use of it in mame.  Think about it, anything longer than a few characters gets cut off in mame's ui.  And as you pointed out the only way to add these would be to also show the button number along with it's descripton, which would be way too long to display in mame.  I wish it could be done, but right now I don't think it can.  

[SirPoonga]

HC is right, I went off in lala land there:)  To sum up, this looks like it will only be a FE thing, IMHO.  It isn;t that relevant in mame.

[SirPoonga]

HC has a cool idea of putting alternating in it.  That means the game alternates between players, and in most of those games in mame you use the same controls for player 1 and player 2.

I'll let him explain his idea on how the dat file should be formatted and the algorithm a FE would use to get at the info.


Here's my idea.  180 degree turn.  The labels will look like mame labels, but don't think of them that way, IF we believe this actually doesn;t have a usefulness in mame.  Labels would be too big for the UI.  These are descriptions for the FE, it will look like mame descriptions BECAUSE it is easy to get the control info from mame:)  But if you look at my firetrk example you will see it doesn't match what mame says it's controls are, more like what they are in real life.

First, examples to work with

[firetrk]
Description=Fire Truck
numPlayers=3
alternating=0
P1ControlType=Dial
P2ControlType=Dial
P1_DIAL=Left
P1_DIAL_EXT=Right
P1_BUTTON1=Horn
P1_BUTTON2=Track Select
P2_BUTTON1=Bell
START1=Player 1 Start
START2=Player 2 Start
START3=Both Start
MiscDetails=
[end]


[ddragonb]
Description=Double Dragon (bootleg)
numPlayers=2
alternating=0
P1ControlType=8-way Joystick
P2ControlType=8-way Joystick
P1_JOYSTICK_UP=Up
P1_JOYSTICK_DOWN=Down
P1_JOYSTICK_LEFT=Left
P1_JOYSTICK_RIGHT=Right
P1_BUTTON1=Punch
P1_BUTTON2=Jump
P1_BUTTON3=Kick
MiscDetails=
[end]

Ok, here's how it would be used (my idea) in an FE.
The FE will first look at the number of player.
If players > 1 then
Check for alternating
If alternating only label controller 1
if not alternating
get controls into some structure.
the structure will contain labels for all the CP objects.
So ther would be in that structure a P1_BUTTON1 and P2_BUTTON1.
now, in ddragon, no P2_BUTTON2 is defined.  So in the structure it will be left blank.  Now, when it comes time to display 2nd playe controls in the FE, since it is blank use P1 labels.
int he firetrk example P2_BUTTON1 is defined so that structure's P2_BUTTON1 value will be set, no need to us P1's label.
Final step, go throught he structure updating the labels the user sees in the GUI of the FE.

[Howard_Casto]

Ok my big fancy search routine, as requested.

for each game you have soem supplimentary data that is used for outputting the display that looks something like this:  

numPlayers=2
alternating=No
P1ControlType=4-way Joystick
P2ControlType=4-way Joystick

What this entry tells us is this....

There are two players and they both play at the same time.  Also they both use the same type of controller, so we can assume that the layout is mirrored for player 1 and 2.  Therefore we only have to define all of the inputs for player 1 and the fe will duplicate the same inputs for player 2  

Now for those special case games in which player one doesn't have the same type of controller as player two, we ntoe that in the controller type and the fe knows to look for both players input definitions and NOT to mirror them.  This system should work with 95% of the games.  Also this controller type is useful for displaying graphics... in mame a steering wheel is the same as a dial, but obviously they look different.  If you have both a wheel and a spinner on your control panel it would be useful to know which one the game actually uses.  

And the inputs are just like mame, so remember how the graphics are linked to the outputted layout is irrelevant to our data collection.  If we can accutately document a good descripton of the controller and the actual input definition that mame uses, I can take care of the rest.  The viewer I make will be totally open source too, so it's logic can be integrated into front ends or used to develop fancier viewers.  

[SirPoonga]

yah, my algorithm is VERY simular to HC's, the only difference really is dat file format.

i forgot to put my dotron example,
the thing I wanted to show in that example it the contorls.
P1CONTROLS=DIAL|JOY8WAY

My format would work for practically all of the games.  Try and find something it wouldn;t work wit, so we can tweak the format.
The format needs to be flexible, as we don't know what mame will have in the future.
That's why I think my way of overdising players > 1 labels is more flexible, it;s an override system, not a system based on just characteristics of the game.


What do others think?  Is there something HC and I overlooked?

And the inputs are just like mame, so remember how the graphics are linked to the outputted layout is irrelevant to our data collection.
[/qiote]
Right, but since eventually someone will use it to do jsut that, to me my way is easy (in my opinion).   Actually,  HC's idea is a subset of mine, you can still implement HC's idea with my style of formatting, putting the P2, P3, P4 labels in the dat.  HC's algorithm wouldn't look at that as much, but still could be done:)

Which brings up another point, it;s flexible enough to use different implementations.  

BTW, I'm writing an ActiveX dll to handle the dirty work of parsing this.  It will work alot like the XML 4.0 stuff form M$.

[u_rebelscum]

Small, non normal questions:

What about mahjong games?

They don't use mame's BUTTON1...9 input types, but make their own custom inputs with no reference to a standard mame input (see the zero (0), below):

Code: [Select]

PORT_BITX( 0x02, IP_ACTIVE_LOW, 0, "P1 Kan", KEYCODE_LCONTROL, IP_JOY_NONE )

#define PORT_BITX(mask, default, type, name, key, joy)

Also, I don't understand the games with one real player, but use player 2 (and higher) inputs because of mame's limits.  Take Pole Position for instince: gas is P1_PEDAL and brake is P2_PEDAL and steering is P1_DIAL.  P2_DIAL is not used.  Will:

Code: [Select]

[polepos]
Description=Pole Position
numPlayers=2
alternating=no
P1ControlType=Dial
P2ControlType=Pedal
P1_DIAL=Left
P1_DIAL_EXT=Right
P1_PEDAL=Gas
P2_PEDAL=Brake
MiscDetails=Player 1 uses both pedals
[end]

be the way to do this?  (Should Pedal be added to P1ControlType?  Or should Pedal be removed from P2ControlType?)

[SirPoonga]

Small, non normal questions:

What about mahjong games?

They don't use mame's BUTTON1...9 input types, but make their own custom inputs with no reference to a standard mame input (see the zero (0), below):

Code: [Select]

PORT_BITX( 0x02, IP_ACTIVE_LOW, 0, "P1 Kan", KEYCODE_LCONTROL, IP_JOY_NONE )

#define PORT_BITX(mask, default, type, name, key, joy)

No, don;t think in terms of mame labels, this is probably no longer for mame, just for FEs.  It uses mame labels because we can generate a skeleton easily form mame.
so for a majong you might have
[maj]
P1_BUTTON1=Kan
...
P1_Button23=Ugh
[end]

The user of the FE, if he has a majong panel defined, would know where to put those.

Also, I don't understand the games with one real player, but use player 2 (and higher) inputs because of mame's limits.  Take Pole Position for instince: gas is P1_PEDAL and brake is P2_PEDAL and steering is P1_DIAL.  P2_DIAL is not used.  Will:

Code: [Select]

[polepos]
Description=Pole Position
numPlayers=2
alternating=no
P1ControlType=Dial
P2ControlType=Pedal
P1_DIAL=Left
P1_DIAL_EXT=Right
P1_PEDAL=Gas
P2_PEDAL=Brake
MiscDetails=Player 1 uses both pedals
[end]
be the way to do this?  (Should Pedal be added to P1ControlType?  Or should Pedal be removed from P2ControlType?)

That might be the way to do this, but like I said, since this is most likely no going to only be for FEs that can be defines like

P1_PEDAL1=Gas
P1_PEDAL2=Brake

Read up, I say why I think this won;t go in mame anymore, summary, label for the UI would get too long for mame.  essentially, there's more to it than that.

Could you give a full example of what would be in the dat file for a majong game?

See, there needs to be a standard punched out, for most games that's easy, but it also needs to handle interesting setups too, and future games.

[Minwah]

But what happens then when you lookup in the ctrlr.ini file?  If Pole Position uses P2 Pedal for brake, then this controls file MUST refer to P2_PEDAL in order to find out what key is configured for this control.

I think  

[Howard_Casto]

I'm not sure what you guys are referring to in pole position... it ueses
P1_PEDAL                
P1_PEDAL_EXT

As far as I know it no longer uses player 2 inputs.  If it does use player 2 then that is silly as mame allows at least 2 axis and 9 buttons for player 1.  The steerting wheel would be one axis and the pedals on all arcade machines share an axis via a network of resistors.

Also when games use shared inputs from players (like xmen 6 player, which steals some inputs from player 1 and 2) We will put a special switch in the controltype fields,    Telling us to look for inputs from all 4 and not to mirror anything.  

If I'm wrong on this please correct me as I need to rework some things if that is the case.  

[Minwah]

I just had a look in the TAB menu and Pole Position/2 have:

P1 Pedal 1 (Left Ctrl)
P2 Pedal 1 (Left Alt)

I don't think P2 Pedal 1 does anything (?) which goes with your P1_PEDAL/P1_PEDAL_EXT but why is it shown in the TAB menu?

[Howard_Casto]

Your guess is as good as mine.... probably the descriptions were entered manually ages ago and were never changed.  My guess is that it actually is P1_PEDAL_EXT but it's been improperly labeled.  Remember if you are using a keyboard then it actually won't appear to do anything as the ext one is the brake and when you let off of the gas it completely decellerates.  

[Minwah]

Howard: I just had chance to look at your controls.dat file.

Firstly, why is the game description there?  I guess to make it easier when manually editing the file.

What happens for the ControlType's for games like Ikari Warriors?  Would it be changed from:

P1ControlType=Dial  to:

P1ControlType=Dial:8-Way Joystick ?? (the colon is supposed to be the 'pipe' - how do you type that?)

OR, inventing new controller types:

P1ControlType=Rotational 8-Way Joystick

Sorry if you've already explained

[Howard_Casto]

The inputs below the control types are the meat and potatoes that we will use to get the assigned keys from mame. The control type is excatly for what you referring, mainly giving control explainations to those odd-ball games.  So yes you would put something like rotary joystick there..... And when the viewer is made it will see this and call it a rotatry joystick in the descripton. But in mame at least, the rotary joystick is simply and 8-way with a rotate left/right axis. We do this so that we can still split up inputs  (Like most people will use a standard 8-way and two rotation buttons for their layout and we will wnat to show this graphically.)  and yet be able to create functions to logically combine controller inputs.  

Btw I looked at pole postion again and realized that the original cab only had a gas pedal.  So why the pedal 2 is put in it's menu is beyond me, it serves absolutely no purpose.  I'm betting there are probably other games like this.  

[knobunc]

I'm not sure what you guys are referring to in pole position... it ueses
P1_PEDAL                
P1_PEDAL_EXT

As far as I know it no longer uses player 2 inputs.  If it does use player 2 then that is silly as mame allows at least 2 axis and 9 buttons for player 1.  The steerting wheel would be one axis and the pedals on all arcade machines share an axis via a network of resistors.

Also when games use shared inputs from players (like xmen 6 player, which steals some inputs from player 1 and 2) We will put a special switch in the controltype fields,    Telling us to look for inputs from all 4 and not to mirror anything.  

If I'm wrong on this please correct me as I need to rework some things if that is the case.  

I dunno what you are parsing, but accoring to polepos.c line 260 of the make 0.61 sources, the Brake is mapped to player 2.  This is backed up by hitting tab in the game.

The ctrlr/.ini files allow the _EXT extension as a shorthand for the extension to the control (usually to input the hey that is the other direciton for the control).  I just took a quick look at the control definitions and they are more poweful that I expected!  If we do this correctly then a FE will be able to do all of the config for controls!

-ben

[knobunc]

Rather than use the relatively flat .ini format, how many FEs parse the -listinfo format at the moment?  It might be a good format to consider since it allows for arbitrary trees of data to be captured.

I have been thinking about the format of the stuff we need to capture and I think I have been assuming that the formats that we have all been kicking around are a little too simple.

Perhaps the correct model is one where you can define control blocks, then say which players use which control blocks.  As an example take that game 1942 which has 2 players who alternate at the controls which are an 8-way joystick, and 2 buttons (fire and loop).

I propose we capture this information as follows:
CDEF1=JOYSTICK|8WAY,BUTTON1,BUTTON2
CDEF1_JOYSTICK=Movement
CDEF1_BUTTON1=Fire
CDEF1_BUTTON2=Loop (3 per board)

Then you associate the controls with the players:
[1942]
PLAYERS=2
SIMULTANEOUS=1
PLAYER1_CONTROLS=1
PLAYER2_CONTROLS=1
CONTROL1_DEF=1
(controls from above)
[end]

The CONTROL1_DEF line maps the control location to the actual raw definition.  I hope the meaning of this will become more clear in the next example.  This is for 1943 where 2 players can play simultaneously:

[1943]
PLAYERS: 2
SIMULTANEOUS=2
PLAYER1_CONTROLS: 1
PLAYER2_CONTROLS: 2
CONTROL1_DEF=1
CONTROL2_DEF=1
CDEF1=JOYSTICK|8WAY,BUTTON1,BUTTON2
CDEF1_JOYSTICK=Movement
CDEF1_BUTTON1=Fire
CDEF1_BUTTON2=Special Attack (uses energy)
CDEF1_BUTTON1+CDEF1_BUTTON2=Loop (uses energy)
[end]

Then for one of the more screwed up examples:
[firetrk]
PLAYERS: 2
SIMULATANEOUS=2
PLAYER1_CONTROLS: 1
PLAYER2_CONTROLS: 2
CONTROL1_DEF=1
CONTROL2_DEF=2
CDEF1=DIAL,BUTTON1,BUTTON2,BUTTON3
CDEF1_DIAL=Front Steering
CDEF1_BUTTON1=Gas
CDEF1_BUTTON2=Horn
CDEF1_BUTTON3=Track Select
CDEF2_DIAL=Rear Steering
CDEF2_BUTTON1=Bell
[end]

Then there are the games like nstocker that have controls for P1 mapped into P2:

[nstocker]
PLAYERS: 2
SIMULATANEOUS=1
PLAYER1_CONTROLS: 1
PLAYER2_CONTROLS: 1
CONTROL1_DEF=1
CDEF1=P1_LIGHTGUN,P1_BUTTON1,P2_DIAL
CDEF1_P1_DIAL=Steering
CDEF1_P1_BUTTON1=Trigger
CDEF1_P1_LIGHTGUN=Aim
[end]

Another perverse case to consider is spclords (test driver) which as a joystick with left/right/up defined but not down (see also atetcktl for a working case of this)!  And the 6 player X-men with scavenged controls for players 5 and 6.

The reason that I call out the number of simultaneous players is that some games define 2 sets of controls but only 1 player can play at a time (dunno if these are missing COCKTAIL flags, see ajax, armedf, ...).

I have deliberately left out additional information that I think we want to capture (URLs, GameFAQ IDs, etc.) to make the control discussion the real focus.  At some point we need to decide on what ancillary information to add.

Things that the above format accomplishes:
- Accurately documents the controls on a real cabiner (i.e. P1 and P2 shared the same controls or used different sets)
- Avoids duplicating the descriptions
- Is confusing to read :-)

-ben

[knobunc]

Btw I looked at pole postion again and realized that the original cab only had a gas pedal.  So why the pedal 2 is put in it's menu is beyond me, it serves absolutely no purpose.  I'm betting there are probably other games like this.  

Look at KLOV: http://www.klov.com/P/Pole_Position.html

It notes the following:
The sit-down version of the game uses separate accelerator and brake pedals while the upright only uses a single pedal.

And the comment in the driver indicates that the second button is a brake.

-ben

[Howard_Casto]

Rather than use the relatively flat .ini format, how many FEs parse the -listinfo format at the moment?  It might be a good format to consider since it allows for arbitrary trees of data to be captured.

I have been thinking about the format of the stuff we need to capture and I think I have been assuming that the formats that we have all been kicking around are a little too simple.

Perhaps the correct model is one where you can define control blocks, then say which players use which control blocks.  As an example take that game 1942 which has 2 players who alternate at the controls which are an 8-way joystick, and 2 buttons (fire and loop).

I propose we capture this information as follows:
CDEF1=JOYSTICK|8WAY,BUTTON1,BUTTON2
CDEF1_JOYSTICK=Movement
CDEF1_BUTTON1=Fire
CDEF1_BUTTON2=Loop (3 per board)

Then you associate the controls with the players:
[1942]
PLAYERS=2
SIMULTANEOUS=1
PLAYER1_CONTROLS=1
PLAYER2_CONTROLS=1
CONTROL1_DEF=1
(controls from above)
[end]

The CONTROL1_DEF line maps the control location to the actual raw definition.  I hope the meaning of this will become more clear in the next example.  This is for 1943 where 2 players can play simultaneously:

[1943]
PLAYERS: 2
SIMULTANEOUS=2
PLAYER1_CONTROLS: 1
PLAYER2_CONTROLS: 2
CONTROL1_DEF=1
CONTROL2_DEF=1
CDEF1=JOYSTICK|8WAY,BUTTON1,BUTTON2
CDEF1_JOYSTICK=Movement
CDEF1_BUTTON1=Fire
CDEF1_BUTTON2=Special Attack (uses energy)
CDEF1_BUTTON1+CDEF1_BUTTON2=Loop (uses energy)
[end]

Then for one of the more screwed up examples:
[firetrk]
PLAYERS: 2
SIMULATANEOUS=2
PLAYER1_CONTROLS: 1
PLAYER2_CONTROLS: 2
CONTROL1_DEF=1
CONTROL2_DEF=2
CDEF1=DIAL,BUTTON1,BUTTON2,BUTTON3
CDEF1_DIAL=Front Steering
CDEF1_BUTTON1=Gas
CDEF1_BUTTON2=Horn
CDEF1_BUTTON3=Track Select
CDEF2_DIAL=Rear Steering
CDEF2_BUTTON1=Bell
[end]

Then there are the games like nstocker that have controls for P1 mapped into P2:

[nstocker]
PLAYERS: 2
SIMULATANEOUS=1
PLAYER1_CONTROLS: 1
PLAYER2_CONTROLS: 1
CONTROL1_DEF=1
CDEF1=P1_LIGHTGUN,P1_BUTTON1,P2_DIAL
CDEF1_P1_DIAL=Steering
CDEF1_P1_BUTTON1=Trigger
CDEF1_P1_LIGHTGUN=Aim
[end]

Another perverse case to consider is spclords (test driver) which as a joystick with left/right/up defined but not down (see also atetcktl for a working case of this)!  And the 6 player X-men with scavenged controls for players 5 and 6.

The reason that I call out the number of simultaneous players is that some games define 2 sets of controls but only 1 player can play at a time (dunno if these are missing COCKTAIL flags, see ajax, armedf, ...).

I have deliberately left out additional information that I think we want to capture (URLs, GameFAQ IDs, etc.) to make the control discussion the real focus.  At some point we need to decide on what ancillary information to add.

Things that the above format accomplishes:
- Accurately documents the controls on a real cabiner (i.e. P1 and P2 shared the same controls or used different sets)
- Avoids duplicating the descriptions
- Is confusing to read :-)

-ben

I refer you to the software designers code, eg KISS.  (Keep It Simple Stupid)  

Although I appreciate your input you are over complicating things.  You don't add a lot of extra parsing and rename all of inputs simply to accomidate 3% of the games that don't fit into the mold.  Well, you can but it seems really silly to me.  

Mame has a nice framework.  We want to get the users keyboard setup via mame, so we MUST stick to the ctrlr.ini format of nameing inputs and keep the special controllers up to the descriptions, which the fe/viewer will know how to handle.  Remember, the inputs and the atual physical controller are two totally different animals and we must keep them seperate in our data collection.  The purpose of this project is to be able to asociate inputs with graphical representations of controllers displayed on a screen.  Since we want to allow inputs to span over multiple controls (in case the user's layout doesn't have a trigger stick and a up/down spinner)  it it's crucial that we keep these totally seperate.   So gong back to my orignal layout...
the p1_input... ect should be kept in lien with mame while the p1controltype will have to have a new standardization made.  

Trust me on this... I have an idea in my head but it would literally take days to explain it in every detail.  I have accounted for everything that I know and so far everything is fitting in nicely.

Oh btw, my klov auto parser just finished.... Due to klovs unstandardized names and formats, it's only about 50% accurate, but I will sort out the bad one's tonight and post what it found.  It's looking very promising.

[knobunc]

So what are you parsing to get the control definitions from MAME?  And what language is your parser written in?

Right now my parser reads directly from the driver C files (and it is written in Perl).

Please note that I really want to reduce the number of duplicate definitions in at least the source file that human maintain.  I think duplicating all 4 identical controls for Gauntlet is a waste.  Also providing information for clones is a bit pointless.

My original format (and the one I am using at the moment to generate the control definitions) is pretty simple.  It refers to things by their internal MAME macro names rather than the ctrlr.ini ones, but I think that is easily rectified.goto-l

-ben

[Howard_Casto]

So what are you parsing to get the control definitions from MAME?  And what language is your parser written in?

Right now my parser reads directly from the driver C files (and it is written in Perl).

Please note that I really want to reduce the number of duplicate definitions in at least the source file that human maintain.  I think duplicating all 4 identical controls for Gauntlet is a waste.  Also providing information for clones is a bit pointless.

My original format (and the one I am using at the moment to generate the control definitions) is pretty simple.  It refers to things by their internal MAME macro names rather than the ctrlr.ini ones, but I think that is easily rectified.goto-l

-ben

Right now it reads from a pre-parsed listdetails dat.  Yeah, I noticed the format you are useing...  Since we want to be able to read mame's input files without bothering with the source (at runtime at least)  it's necessary to convert those to the ctrlr names ahead of time, which actually won't be so hard... I think it's something like removing the "def_" and that's it.  

My skelton dat generator isn't very accurate because of this, so yours would probably be better in that respect.  

But for standard 4 player or less games with joysticks and buttons, I am able to automatically generate the entries from klov.  I don't have a count yet, but just by glance I would say about 500 of the parent roms turned out ok.  

For sticks and buttons games, I simply put the layer one stuff in and the controller type for every player.  For the others we will most likely have to put in every single input without mirroring.  

I will post what I have checked so far tonight so that everyone can look at it... Btw I thought of a new field that might be useful....  How about we include the driver.c file?  I know that seems out of place, but if we include it we can make a cps2.ini that it defaults to for any game that doesn't have an entry and ect.  It could come in handy, but then again we could get this from somewhere else.  

[SirPoonga]

But what happens then when you lookup in the ctrlr.ini file?  If Pole Position uses P2 Pedal for brake, then this controls file MUST refer to P2_PEDAL in order to find out what key is configured for this control.

I think  

Ahhh, you bring up an interesting dilema.  First off, right now, alot of people don't use the ctrlr files, they reconfig games keys with the UI.  Second, what use would it have?  The only thing you could get out of it is the keyboard key assigned to something.  

Other than NeoGeo, unless you use my ctrlr file hacks (which aren;t ever going to be in the real mame) there isn't much you can do with the ctrlr files.

[SirPoonga]

Perhaps the correct model is one where you can define control blocks, then say which players use which control blocks.  As an example take that game 1942 which has 2 players who alternate at the controls which are an 8-way joystick, and 2 buttons (fire and loop).

I agree with HC, that is overly complicated, there are going to be ALOT of control blocks then.   Doesn't really make it worth while.

[Minwah]

OK well, no, I don't use the .ini files really.

But it would be quite cool to get the 'key' for each control/button tho.  Then you could use this for a 'test controls' feature in your FE, before you actually run the game.

[SirPoonga]

OK well, no, I don't use the .ini files really.

But it would be quite cool to get the 'key' for each control/button tho.  Then you could use this for a 'test controls' feature in your FE, before you actually run the game.

well, until ctrlr files get more popular (they rule btw).  Though one might want to think about the future.  So yeah, it should follow the mame labels.  Someone will come up with something interesting because of that.  Anyway, I've been thinking on how an FE would really use this project in the future.

Basically, it'd go like this.  A person would have to do one of two things.  Either use a CADish program built int he FE, like ArcadeFX's cp builder) or pic(s) of their cp(s).
For the first, when you add a control (button, joy, tball, spinner) you will be asked to associate it with what control labels (P1_BUTTON1, P1_DIAL) etc.    That way if a game uses that control you jsut have to somehow highlight those controls.
As for the pic, very sijular, though I don't know how you;d highlight the controls.  Might have to be multiple graphics.  ther would be a cp.png, then a png for each control where just the control is in the png and the rest is a 100% tranparent.  Then you just associate pngs to the control labels.

[Howard_Casto]

The reason I want to stick to controller files is because I hear that they will be expanded upon to add analog configurations.  When that happens then I figure that the old cfg files will be removed.  As sirp said I am just thinking of the future.   The ctrlr files are useful in that you can read them and see input changes... in other words if you redefine button 1 on one particular game it will be displayed properly in your layout for that game.  Of course if you don't use the ctrlr files then you are screwed, but this will definately encourage people to use them....  

What would be cool would be if someone made a hack in mame to where it mirrored your settings in a crtlr file when you edit them inside mame.  

[SirPoonga]

The ctrlr files are useful in that you can read them and see input changes... in other words if you redefine button 1 on one particular game it will be displayed properly in your layout for that game.  Of course if you don't use the ctrlr files then you are screwed, but this will definately encourage people to use them....  

Ahhh, but there is an issue with that.  Not only ydo you have to in the FE say button 1 on the cp is p1_button1 you also have to define in the FE what keycode it is.  I think it might be up to the FE dev.  If they want to use the ctrlr file or use their own format for setting up the graphical representation.

THEN what about people (alot of them too) that use the IPAC to chang the controls!  Though you can do that with ctrlr files too now.

[Howard_Casto]

Actually no.... everytime a layout is displayed you read the layout of the persons ctrlr file....  In some languages it's hard but in thers it's very easy... in vb for example, the keycode constant is simply "vbkey"
followed by the key name, which makes it veyr easy to parse. I believe that c++ has something similar.

Unless you have a fe that redefines mame keys for you, this shouldn't be an issue.  

As for the ipac, I use xp.  And more and more people are popping up with xp on their cabs. Since it's difficult to program the ipac on the fly in xp I figure a few years from now this won't be an issue.  Also Writing to the ipac that often isn't such a good idea as eprom chips have a finite number of writes.  It's a high number but still, better safe than sorry

[SirPoonga]

Actually no.... everytime a layout is displayed you read the layout of the persons ctrlr file....  In some languages it's hard but in thers it's very easy... in vb for example, the keycode constant is simply "vbkey"
followed by the key name, which makes it veyr easy to parse. I believe that c++ has something similar.

Unless you have a fe that redefines mame keys for you, this shouldn't be an issue.  

As for the ipac, I use xp.  And more and more people are popping up with xp on their cabs. Since it's difficult to program the ipac on the fly in xp I figure a few years from now this won't be an issue.  Also Writing to the ipac that often isn't such a good idea as eprom chips have a finite number of writes.  It's a high number but still, better safe than sorry

True, you'd still have to define in the FE the graphical representation of a control is a keycode AND one or more mame control labels.  That can get complicated, but you have to do what you have to do I suppose.

BTW, my hacks for the ctrlr will easily break any algorithm use for that based of default mame:(  Unless the FE dev saw enough ito the future where the user can define the order in which ini files are read, like in mame source.

[u_rebelscum]

P1_PEDAL                
P1_PEDAL_EXT

PEDAL is a funky-dunk compared to mame's other analog input types.  P1_AD_STICK_X is the negative half of the X axis, and P1_AD_STICK_X_EXT is the postive half like all other analog axes except for PEDAL.  Since a pedal is only "half an axis", mame defines PEDAL_EXT as the "Auto release" setting.  Look at the UI input settings of a game with pedal and compare to any other analog axis (DIAL, AD_STICK, or PADDLE) to see what I mean.

As far as I know it no longer uses player 2 inputs.  If it does use player 2 then that is silly as mame allows at least 2 axis and 9 buttons for player 1.  The steerting wheel would be one axis and the pedals on all arcade machines share an axis via a network of resistors.

Depends on the game.  Some arcade games had the gas and brake sharing an axis like you discribe.  With these games, pressing on both the brake and the gas (equally) would result in no-gas & no-brake.  With the gas pedal down, as you depress the brake, the gas input would decrease, but no brake until the brake was father down than the gas.  Almost all PC games (and thus PC pedals) are writen this way, and fake a seperate brake pedal with a "hand brake" button. (see next paragraph on why)

Other arcade games (Pole Position*, HardDrivin', and SF Rush for example) had the gas and brake independent of each other.  In these games, pressing the brake would not decrease the gas but would increase the brake.  Braking while keeping the engine RPMs up and "power slides" are then possible if the game software was written to do it (SF Rush does, I don't think PolePosition did, not sure about HardDrivin').  
(*Some PolePostion cabs had only gas, while others had both gas and brake, so this example only applies to those with both)

Okay, mame.  Many games that the arcade had with independent gas & brake are incorrectly emulated like you discribed with the gas and brake sharing an axis (the Y axis).

Oh ya, starting with mame .61, mame now has 3 (used) analog axes: X, Y, and Pedal.  A forth is coded in there too, but no drivers are written to use it yet (it's a shared Z / Pedal 2 axis).  So some games that now have P1_PEDAL and P2_PEDAL might have P1_PEDAL and P1_PEDAL_2 at some point in the furture, as well as some of those games that incorrectly emulate the gas & brake on a shared (Y) axis may be switched, too.  
Also the default mapping of PEDALs in mame are still buttons, but now will correctly handle analog joystick inputs, and with the analog remapping ability also added pedals now work like they should.   (hint: use the ctrlr pedal.ini to aplply to all games with PEDAL)

[SirPoonga]

Oh ya, starting with mame .61, mame now has 3 (used) analog axes: X, Y, and Pedal.  A forth is coded in there too, but no drivers are written to use it yet (it's a shared Z / Pedal 2 axis).  So some games that now have P1_PEDAL and P2_PEDAL might have P1_PEDAL and P1_PEDAL_2 at some point in the furture, as well as some of those games that incorrectly emulate the gas & brake on a shared (Y) axis may be switched, too.  
Also the default mapping of PEDALs in mame are still buttons, but now will correctly handle analog joystick inputs, and with the analog remapping ability also added pedals now work like they should.   (hint: use the ctrlr pedal.ini to aplply to all games with PEDAL)

Thanks to you for all that!

Yeah, whatever we decide on a format (hey, we are getting close if we are working on the nitpicking details) remember that this may not translate to into mame anymore.   It will most likely only be used by FEs.  And since most of us aggree that the control info is going to be part of this (what controls it has) what everything is labelled ISN'T that big of a deal is mame changes in the future.  As long as this dat file has a standard.
So we could use for pedals something like
P1_THETHINGYOUPUSHDOWN=Gas
P1_THEOTHERTHINGYOUPUSHDOWN=Brake

So, like I said before, the labels can be whatever.  Though keeping them close to ctrlr stuff someone might come up with a  cool idea, like using the ctrlr ini files somehow.