Main > Software Forum
ctrlr / cfg file parsing
Minwah:
--- Quote from: u_rebelscum on August 01, 2007, 07:51:22 pm ---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? ;)
--- End quote ---
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 ;D
u_rebelscum:
--- Quote from: Minwah on August 02, 2007, 04:58:57 pm ---
--- Quote from: u_rebelscum on August 01, 2007, 07:51:22 pm ---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? ;)
--- End quote ---
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...
--- End quote ---
Or write them to the cfg files. IMO, it's too ingrained for it to be removed, unless by aaron himself.
--- Quote ---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.
--- End quote ---
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:
--- Quote from: u_rebelscum on August 03, 2007, 08:00:47 pm ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[*] Previous page
Go to full version