ctrlr / cfg file parsing

[Minwah]

As I've been out of the loop for a while, could someone please jog my memory a bit...

I want to figure out which controls (keycodes/joystick/mouse inputs) are used by each game.  I recall the order of priority is general, driver, parent, clone but I can't quite remember what happens if settings are present in both ctrlr and cfg files.  I *think* cfg files over rule ctrlr files in terms of game specific entries, but I'm not sure about the general entries etc.

What I am after is exactly which order I should parse the files.

Thanks for any help!

[u_rebelscum]

Think two lists: general & local (aka "this game").  This lets mame keep the defaults for all games even when editting specific games.

The general list is every input, the local is just the inputs included in the game.  Usually the local list has everything set to "default", which means "look in the general list" (in pseudo code, of course).  However, if the game driver sets the input to something else, then that local starting setting isn't "default" but whatever the driver sets.  The general list defaults are also set in the source code, but there's only one for all games.

The ctrlr file changes the general list.  The ctrlr file is read once for top to bottom, and any relevant changes are added in the order they are read.  (This is different than the first ctrlr files, which had the priority you listed.)
Then the default.cfg changes the general list.  (aka overriding the ctrlr file)
Finally the gamespecific.cfg changes the local list.  (Almost always overriding the ctrlr and default.cfg files, see next paragraph for the exception)

The weird case is with driver set game specific inputs.  For cfg files, only inputs set to something different from the starting settings are listed.  In this case the starting input is not "default", but since it's the starting input, it's not included in the cfg file.  However, since it's not "default", mame uses it instead of the general setting.  To use the general setting, set that input to "default", which will be saved in the cfg file; sort of "un-overriding" the general list.  And the only way to find them is to look at the source AFAIK.

Ignoring them, it's pretty easy.

[Minwah]

Thank you, that helps a lot....

It seems like it ought to be more straightforward.  Is there any reason why one shouldn't create a default.cfg, and game-specific .cfg's with all relevant inputs? ie so no ctrlr file is needed.  By 'create' I mean manually or otherwise generating the files, rather than using the Tab menu.  I don't much like the 'new' ctrlr file system.

Edit: Yes there is, they get wiped :p Not sure how it can tell tho, maybe the port index's...

[u_rebelscum]

Thank you, that helps a lot....

It seems like it ought to be more straightforward.  Is there any reason why one shouldn't create a default.cfg, and game-specific .cfg's with all relevant inputs? ie so no ctrlr file is needed.  By 'create' I mean manually or otherwise generating the files, rather than using the Tab menu.  I don't much like the 'new' ctrlr file system.

Edit: Yes there is, they get wiped :p Not sure how it can tell tho, maybe the port index's...

The game specific cfg files are much more strict that default.cfg or the ctrlr file; if the port index, mask or default are different that the source, mame considers it invalid and removes it.  This allows for the drivers to have rare cases where, for example, there are two player 1 button 1s, or the inputs are hacked with "original" and "playable" & both using player 1 joystick type.

The default.cfg & ctrlr file do not use the index/mask/default values, so you can copy from a game's cfg file to default.cfg or ctrlr file, but not the other way around.  Even copying between or within a game cfg might not work without the correct index/mask/default values, but works fine with the default.cfg & ctrlr file.


Aaron has expressed openness toward changes to the input structure, but not interest in doing it himself.  How do you suggest making it more straightforward?  Without removing ctrlr support? 

If you want everygame to list every input, whether changed or not, for your project, it's a simple change in scr/emu/inptport.c, diff attached.  The cfg files will include special and dipswitches.  Looks like I get memory overload if I try the same changes to default.cfg, though (in the function above the one edited for the games).

[headkaze]

MinWah, this thread might be helpful. Also me and Howard are working on the "Mame Input Bible" which will go into detail how everything works. Hopefully we can see a release in the near future. It should be very helpful for this sort of thing.

[Minwah]

Aaron has expressed openness toward changes to the input structure, but not interest in doing it himself.  How do you suggest making it more straightforward?  Without removing ctrlr support? 

Remove those defaults set by drivers for a start...that is a pain just when you think you have all your ctrlr file done & ready to go.  I must admit though aside from that it is not easy and needs a lot of thought...

Personally I think ctrlr files should be seperate, game-specific (or general/driver/parent) files similar to before.  Add an option to disable the .cfg files so the ctrlr files are read and used throughout.  Then if any edits are made to controls in the tab menu, it writes them to the ctrlr file instead of the .cfg file.  This would also mean that analog settings/reverse etc. would need to work in ctrlr files, which would be handy even the way it stands now.

Using this method there would only ever be 1 thing you would need to be concerned with as far as controls go...ctrlr files, or if you do not use them, .cfg files.  As for input port index's etc, this could be added to the ctrlr file by MAME if neccessary.  If the index specified is wrong (ie if someone copied it from another game's file), MAME should rectify it and still use the mapped key/input, rather than removing it altogether.  .cfg files could still be used as there are now, with the exception that ALL defaults would be taken from default.cfg, which would be generated by MAME when missing.

Thanks for the info and the link, I guess I am trying to do something you have already done headkaze!  I haven't got very far yet, but at least I now know what I am doing...I think 

[u_rebelscum]

Aaron has expressed openness toward changes to the input structure, but not interest in doing it himself.  How do you suggest making it more straightforward?  Without removing ctrlr support? 

Remove those defaults set by drivers for a start...that is a pain just when you think you have all your ctrlr file done & ready to go.  I must admit though aside from that it is not easy and needs a lot of thought...

Or write them to the cfg files.  IMO, it's too ingrained for it to be removed, unless by aaron himself.

Personally I think ctrlr files should be seperate, game-specific (or general/driver/parent) files similar to before.  Add an option to disable the .cfg files so the ctrlr files are read and used throughout.  Then if any edits are made to controls in the tab menu, it writes them to the ctrlr file instead of the .cfg file.  This would also mean that analog settings/reverse etc. would need to work in ctrlr files, which would be handy even the way it stands now.

Using this method there would only ever be 1 thing you would need to be concerned with as far as controls go...ctrlr files, or if you do not use them, .cfg files.  As for input port index's etc, this could be added to the ctrlr file by MAME if neccessary.  If the index specified is wrong (ie if someone copied it from another game's file), MAME should rectify it and still use the mapped key/input, rather than removing it altogether.  .cfg files could still be used as there are now, with the exception that ALL defaults would be taken from default.cfg, which would be generated by MAME when missing.

Careful there.  I don't suggest you phrase it so to MameDev.  It sounds like you want ctrlr and cfg to do the same thing.  But if they do the same thing, then why have both.  IMO the outcome would be removal of the ctrlr file.

If mame applied the different levels in the ctrlr file in the hierarchical order, would one file be okay?  I don't like having a whole folder for different games ctrlr files, but I do like the general/driver/parent/game order of the old way.

I would like a ctrlr file editor, but that could be done outside of mame.  Copy this map to those games' ctrlr, clean inputs in ctrlr not used by that game, show result of X ctrlr file on Y game, ect.  Heck, write cfg files that unable the in code remaps.  All possible outside of mame.

Could I do that?  Not at the moment.

[Minwah]

Careful there.  I don't suggest you phrase it so to MameDev.  It sounds like you want ctrlr and cfg to do the same thing.  But if they do the same thing, then why have both.  IMO the outcome would be removal of the ctrlr file.

I was more thinking out loud really...but yes I see what you mean.  I would actually love there to be only one....but it would need to be able to use user generated mappings (like ctrlr) and MAME UI edited mappings (like cfg).  At the moment that's not really a possibility it seems.

[Howard_Casto]

As Headkaze already said we are working on a guide on how to parse cfgs/ctrlrs/ect.  Although the new ctrlr files read from top to bottom I (we?) consider this to be a bug more than anything else and expect users to define ctrlr files in hierarchy manually (with more generic entries at the top, working down to game specific entries.)   It's FAR more complex than simply reading the files in a hierarchy unfortunately.  You have 15 or so command-line/ini flags that totally change the meaning of a mapping based on the combination of settings set.  Now with multiple keyboard support and the re-introduction of a unified mouse as an option, it gets even more complex.  I suggest you get into contact with HK and he can send you what we have so far.  Which reminds me, I have some more data to send him. 


Btw, my now ancient (and probably non-working) ini2xml converter automatically grouped all driver/parent/rom settings together when building a ctrlr cfg file.  It would be quite simple to build a ctrlr editor that made this process automatic and do bonus things like allowing you to transfer your cfg settings to the ctrlr and delete them.  I'm not terribly good managing xml though, so it'd probably be best for someone else to write such an app.

Rebel is right btw, the hardcoded defaults for a few drivers/games would be really difficult to remove.  At one point though (when cfg files first got re-worked into xml) mame printed all the defaults for a game, even if they weren't changed.  This is impractical as the resulting cfg files would be huge, but what would be a good idea is to have an internal flag that can be set for a game at the driver level to print the cfg file at startup with the defaults.  Then we at least know what the remappings are.  Adding said flag to the listxml would then give us a list of "problem games" as well.  Of course for this to work driver writers would have to adopt it and all the current drivers would have to be manually checked (UGH).  Sounds like a job for aaron actually.  At one point I wanted to collect this info for controls.dat but man, there are a ton of games that use this silly, internal, remapping.