Button Assignment Seems to get Overwritten... Help plz... (video inside)

[Mickelonis]

1. I have deleted any .cfg files pertaining to the roms.
2. I start a game, go into config menu, "input (general)", "user interface", and I set "pause" to "joy 1 button 16"
3. I exit the config menu, and the game plays fine, I can pause, unpause, etc...
4. I exit mame, and go back into a game and go into the config menu, and I look to see what "pause" is set to, and it's set to "joy 1 button 15" (not a typo '15')
5. I've even deleted default.cfg and reconfigured everything... Still, for some reason pause always goes back to the wrong button!

Any ideas?

Thanks ahead of time!

-Pete

[loadman]

Sorry, Posting error

[youki]

May be it would be good to say what software you are using?

Are you talking about Mame?  or a Front End?

[Mickelonis]

May be it would be good to say what software you are using?

Are you talking about Mame?  or a Front End?

I'm talking about Mame.... Executed via Maximus Arcade.

[dafelandry]

And when you dont use Maximus Arcade to execute mame does it save ur button assignment?

Because I am randomly having that problem with Atomic Fe, when no more then two days ago it was fine.... But its my player 1 "movement controls"... When i "reset the controls" and use mame (without AtomicFE) they save... but when I launch mame via Atomic FE my player1 "movement" controls read "None".. I need to reconfigure something..

Edit: Not trying to jack... but if i find out whats going on with mine i will help you... kinda in the same boat.. Now could FE controls affect mame controls?? (for example if i use my keyboard arrows to navigate my FE, does it cancle out my mame keyboard arrows "controls" in mame?)

[u_rebelscum]

... "joy 1 button 16" ...

Does this only happen to button 16, or do lower button numbers (or higher if you have them) also drop by one?  What version number of mame are you using?

FWIW, someone else here had a simular problem with button 16, but IIRC we didn't figured the problem. (and can't find the thread.)

Now could FE controls affect mame controls?? (for example if i use my keyboard arrows to navigate my FE, does it cancle out my mame keyboard arrows "controls" in mame?)

FE could effect mame, but the ones I know about don't match either of either your cases.
- If the FE grabs the gamepad controller in exclusive (directInput) mode and doesn't let go when mame is started, the controller won't show up in mame at all.
- There were rare cases when the Old mame32 (now called mameUI) used a different directInput version than mame where the inputs cfgs didn't stay correctly.  I'm not sure about with FEs with different directInput version than mame, though.
- IIRC, there were some issues with two apps running at the same time, getting inputs from the same joystick, but I can't find the sites, and MS current web site says it should work fine if the first running is in nonexclusive mode, and the second grabs it in exclusive mode (which mame does). 

[Mickelonis]

Does this only happen to button 16, or do lower button numbers (or higher if you have them) also drop by one?  What version number of mame are you using?

FWIW, someone else here had a simular problem with button 16, but IIRC we didn't figured the problem. (and can't find the thread.)

I will try to re-assign it to a different button tonight, however I do believe it is only button 16 that will do this and here is why.

If I go into default.cfg and manually config the pause button to be 17, then restart MAME, look at the config menu, my pause button will be set to 17 (properly, works fine). If I re-assign it to button 16 in mame (which is actually my pause button on my control panel), exit mame and look at default.cfg the file will properly now reflect button 16. HOWEVER, when I go into Mame and look at the config menu, it magically reflects button 15 (even though default.cfg reads button 16)

I will try executing mame directly without Maximus Arcade to see if the issue still exists tonight.

I am using .135

Thanks for the help!!!!!

-Pete

[Mickelonis]

Ok, I just tested....

Without Maximus Arcade, the problem still exists!

If I set my pause button to button 16, then exit mame, default.cfg will read button 16 (proper). If I re-enter mame, my pause button is mysteriously back to button 15.

What.
The.
Heck!

I am uploading a video now to Youtube to show details of my issue... I'll post a link here when it's done uploading.



-Pete

[u_rebelscum]

Thanks for the video.  Since I don't have a 16+ button gamepad encoder, it helps a lot.

It looks like it's the same problem mame had before.  Mame's internal numbering is inconsistant, and (half) differs from DirectX's DirectInput's (aka dInput for short) numbering.

Nomenclature: You are using "button 16" only if the numbering starts with zero.  You are using "button 17" if starting with one (1), as shown in the control panel screen shot.  I will call your pause button "button 17", since it's more normal to start with one.  I will talk about button numbering starting with zero, too, and in these cases I'll call your button "button o16", with the small "o" in front of the number, otherwise I'll get even more confusing than I ofen do.  If I'm quoting something the "o" will be inside parentheses, ie "button {o}16", since the normally used brakets to show stuff added to quotes makes

• this.

Okay, mame has internal names for buttons 1-16, and uses dInput's names for buttons greater than 16.  So button 17, your pause button, is the first button to use its dInput name.

Mame internal names start with one, since it uses these name in the cfg files, the numbers used in cfg files also start at one for buttons 1-16.  However, the UI menu numbering starts at zero, as does the code used inside mame to generate the dInput names.  IOW, the number you see in the UI menu when first changed (before exiting mame) is "Joy 1 Button {o}16", aka button 17.

And since mame doesn't have an internal name for button 17, it uses the name generated from dInput's name to save in the cfg file.  And since these numbers start with zero, button 17 (aka button o16) has the same number in the name as the real button 16.  IOW, mame is confusing button 16 with button o16 since it doesn't have that "o" to tell the difference.

I'll have to look at saving/loading the cfg files to be sure, but by the time it's saved, it's already "wrong".  "JOYCODE_1_BUTTON16" in the cfg is the same as "Joy 1 Button {o}15" in the UI since the UI numbering starts with zero.

If I'm not making sense, it might help if you map button 1 to anything.  The UI menu will show "Joy 1 Button {o}0", but the cfg file will show "JOYCODE_1_BUTTON1".


To sum up:
Mame confuses button 17 with button 16 when saving the cfg file, and so currently cannot use button 17.  This is further confusing since the UI calls the buttons by different numbers.

For now, you can ry rewiring the button to any other button on the encoder than button 17 (if you have an unused one).  I can't test it, but I think button 18 will show as "JOYCODE_1_BUTTON17" in the cfg file

[protokatie]

The old classic "off by one" programming error. I was hoping it wasn't something as mundane as that... But looks to be so as per rebel's reply.

I have been guilty of this basic flaw before when I used to code. I made sure to never start loops at 0 unless the value itself had a significance. I always started at 1. This would work in many systems, but others a simple "For" type loop would misfire and not give me the number of loops I wanted. This is by far not the only reason why an "off by one" problem occurs.

Try skipping that button number and reassign it to another if you can.

Edit: Another example of an off by one error that I have also been (sadly) guilty of; forgetting that the upward bounds of an unsigned integer is (x^2)-1 with x being the number of bits. (IE that an 8 bit unsigned integer has a max value of 255, not 256). Also, got a few problems with signed integers, when I did not realise if the system used one's or two's compliment, and thought I could somehow get +128 out of a signed 8 bit integer...

[u_rebelscum]

I little OT:

The old classic "off by one" programming error. I was hoping it wasn't something as mundane as that... But looks to be so as per rebel's reply.

I have been guilty of this basic flaw before when I used to code. I made sure to never start loops at 0 unless the value itself had a significance. I always started at 1. This would work in many systems, but others a simple "For" type loop would misfire and not give me the number of loops I wanted. This is by far not the only reason why an "off by one" problem occurs.

Yeah, one reason I call it "dInput numbering" is because MS has the buttons in an array starting with zero.  Not much a programmer can do except start at zero and "+1 " when displayed in the human viewed places (or start with one and "-1" in all the array parts, a very bad idea).

I've been thinking on how to fix this.  Doing a "+1" in the UI is a must IMO, but all that does is make the numbering match the 1-16 button names used in the cfg files and in windows control panel.  It doesn't fix the "can't use button 17" problem.  Doing a "+1" for the dInput name for buttons outside mame's pre-named buttons might help, but matching "-1" needs to be placed in the right places, and I don't think I found them yet.

[AcidArmitage]

Wow, I'm having this problem myself and went online specifically to get help on this. So basically the only solution for now is to rewire that button? Also, I'm using Hyperspin and Mame32 but I noticed when I change the mapping for the game specifically (through "change inputs THIS GAME") it will stick but I have a lot of games.

[u_rebelscum]

Wow, I'm having this problem myself and went online specifically to get help on this. So basically the only solution for now is to rewire that button?

I'd would have said yes (besides fixing the source), but you say...

Also, I'm using Hyperspin and Mame32 but I noticed when I change the mapping for the game specifically (through "change inputs THIS GAME") it will stick but I have a lot of games.

 

I don't see why it will stick in the game specific cfgs but not the default.cfg file.  I'll check it out what I can this weekend, but as I said before, I don't have a 17+ button controller hooked up so can't do much real button 17 debugging.

[AcidArmitage]

i would tell you more about it but i just went ahead and rewired. Sorry 

[u_rebelscum]

i would tell you more about it but i just went ahead and rewired. Sorry 

It's all right; I used te $$ I was going to use to buy my brother a present, and got myself a gpwiz instead.

In my testing, the problem happens in both default.cfg and gamespecific.cfg, and confirm my guesses above.

When mapping, mame displays the button number one lower than us humans usually think, ie mame uses the C programming language's array index number.  So while mame displays "button 16" when first mapped, the issue is with button 17 in human numbering.

Mame has static names for button one through 16, but seems to use the index number for buttons >= 17. so Mame saves both button 16 and button 17 as "JOYCODE_1_BUTTON16" in the cfg file.  This is fine for the same game, as mame doesn't use the static naming used in the cfg files, and only looks at the cfg file at game load up.  When mame reads the cfg file at next start up, however, mame sees "JOYCODE_#_BUTTON16" and translates that is button 16 for both button 16 & 17.

I'm updating the bug at mametesters, and seeing if I can do anything about it myself.