controls.dat (control label info in mame)

[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.