[mame2003/-plus] Removing individual per-game bindings via Tab menu

[grant2258]

to answer your question no i cant think of a reason to nul mame input in games this game only show the inputs the games use why would you need to disable it

[grant2258]

on a final note the code to set it to none has been linked all you need to do is provide a scenario for me to to add it as a pull request.

That is something that has not been answered from the very start. Its not me doing any dancing round anything. You are not providing a proof of concept use. So all i can do is say i where the code is and let the team deiced because im really stumped without this is all.

I rarely use this core only when testing this feature doesnt not make a difference to me if its added or not.

I wont add something on a general comment without real a proof on concept of why its needed. Thats why I passed it on I cant justify why i would do this I asking you to help with that so it can be added its not about right and wrong.

[Clyde]

@grant2258 said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

you havent mentioned anything in particluar just they need rebinds

Yes I have:

@Clyde said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

In Assault, for example, there are normal bindings P1 Up, P1 Down etc. next to P1 Up/Right etc. who interfere in some control schemes. The normal directional bindings have to be removed for some schemes to work like 1-stick mappings. This is one of the real use cases where none would be ideal and more elegant than dummy keys.

To be more specific, I used this guide to set up single stick controls in Battlezone and Assault. For the latter, I had to "remove" (i.e. rebind to dummy keys) the pre-bound P1 Up, P1 Down etc. because they interfered with the rest of this binding scheme.

@grant2258 said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

you can rebind a input. what has to be set to none on these games ? if I get clarification ill put a pull req in with a reason

I also adressed this already:

@Clyde said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

Of course I could use any key as a placeholder for none, but I like my bindings to be clear and self-explaining. Any placeholder isn't as clear about its meaning of "none" than none itself, especially some time after setting it, when the memory about its meaning is long since gone.

Our apparently different perception what's already said is why @Riverstorm and I get the impression that we don't get through to you with our arguments, and that more arguments would only suffer the same fate. Playing the "I said so", "no you didn't", "yes I did" game is a waste of time and beneath the three of us in my opinion. So I'm at the point of agreeing to disagree in this matter, if my last attempt at a real use case above still isn't enough for you.

All this I say in the uttermost respect for your ongoing contribution to Retropie. 😌

@markwkidd said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

First and foremost, thanks for tuning in.

Grant is one of if not the most prolific contributor so he has a lot of credibility with all three of us.

It's the same with us (as @Riverstorm do not tire of pointing out), but even the most prolific contributor can be wrong or unnecessary demanding sometimes. Just make sure you don't fall into the argument from authority trap.

That said, I agree with you that communication is the main problem here.

My primitive understanding at the moment from reading this thread is that there might be a game with a control that users don't ever want to use out of preference. By setting the control to None, you can avoid accidentally triggering the control in-game.

From my perspective, that nailed one of my main reasons for preferring a none binding to a random dummy binding perfectly.

Besides, you suggested the Del key to "none" a binding yourself in the main mame2003-plus thread, but it doesn't work in both mame2003 and -plus. Is that inherited from MAME 0.78 or is it a bug? In either case, would it be a good idea to put that (back) into the 2003 mames for consistency with newer versions that people like us are familiar with? Just some food for thought.

[grant2258]

its the same on mame078 delete will use use the default in this game.

ill read that guide and see where its says to set an input to none rather than something else. That exactly what i needed to know thanks.

im just wondering how you ever managed to to this before when it never set to none

[grant2258]

@wilsonstorm said his self the not mapping is working so you are setting it to something else. I read that guide no where does it say set the key to none.

[grant2258]

Ill need to actually test these games out never played them if there is a need for set to none ill make the case in the pull req.

[grant2258]

~@clyde can you give me your setup for bzone and assault please just one if they are the same including the keys you are setting to none. I just want to understand this issue with this game

[Riverstorm]

@markwkidd - Taking it to the supreme court! I was wondering if you had time to take a look at the suggestion of adding the ability to map NONE in Input (this game) and made your final ruling?

Sorry if the earlier point didn't makes sense. I know you guys collaborate on the important features. I also know Arcadez doesn't care about input in fact he said he skips over input discussions altogether but I understand too he is a one man show because he does some serious driver work and memory mapping.

That leaves Grant by himself, most days, banging away and coding this stuff and asks "Hey, can one of you guys push this PR though." It does give him the ability to wash his hands of any accountability and dump it on you. When he removed himself as a collaborator I thought it's brilliant really, still in control of updates, and rests the crap decisions on your shoulders. :)

I also understand Grant is probably the main contributor and definitely so for the past several weeks and does one hell'va good job but as @Clyde pointed out even the prolific are prone to error and bad judgment. Without Grant doing what he's doing updates would slow significantly to a crawl I imagine. It's hard to slap the hand doing the feeding and say overruled but everyone needs to be kept honest once in a while.

Anyway in this case I would think bad judgment as @Clyde has given what was requested and makes the point perfectly. A game with an example of why implementing NONE in Input (this game) is needed or a good decision.

I don't mean to put character on the table but this feels like ‘proving I am smart, proving I am right, knowing all of the answers’. There can be a huge difference between intelligence and wisdom. I think the latter serves a leader more effectively than the former. Smart people usually don't make good leaders but the wise do. Anyway you've always been the cooler head in the group and have made a great face for this core. Everyone gets rubbed the wrong way occasionally and probably go to bed regretting certain decisions but I have yet to see you get really pi$$ed off about a subject. We (grant and I) have certainly have had some intense conversation about certain aspects on Github and it does get taxing we have to go to extremes all the time to get small updates. Prove it to me, let's run in circles for a while or I'll just change the context of what you said entirely and bring it back to square one.

“For the great individual achiever, it is all about me. For the great leader, it is all about them.”

Anyway take Assault for example you need to 'nul' some of the direction keys in order for the tank to move properly. If you don't the controls do not work properly. If you set Up, Down, Left and Right to any non-used character (in my case I usually use backquote) then the controls work properly. It would have been preferable if I had the ability to set them to NONE ourselves. You don't need anyone's setup, the defaults are sufficient to present the example.

I understand it's possible to code and change these default mappings but I find implementing this feature would be very beneficial allowing the users to set Input (this game) fields to NONE. It would allow flexibility to do some simple remapping ourselves to address these types of situations vs calling out to you guys every time we need a code change to update the defaults or nul a field. Putting that ability into our hands seems reasonable enough.

Also a few weeks ago I started setting fields to NONE through Input (general) and I learned some new things about how RA works. It just seems like this would be a great feature that's a win-win.

There's thousands and thousands of games in this core and I know more that will fit this same category. Current MAME, AdvMAME and several derivatives use the same scheme of the Enter + Escape key alternates between NONE and defaults (pulled from Input (general)).

You could say that's an isolated incident or give me another example or just keep them coming but honestly then it could go on and on. I think Vindicators is another that falls into this same category. This feature does no harm to the existing setup and would only bring new flexibility to the core.

As it sits now you can set Input (general) fields to NONE and they inherit down to Input (this game). This change would allow fields in Input (this game) to be set to NONE also. If you choose so you may hit ESC/ESC or LEFT/LEFT to reset it back to the defaults from Input (general).

Anyway that's my two cents and exhausted my resources on the subject. I guess the rest is up to you and I'm ok with your decision and will move forward.

@Clyde I've enjoyed reading what you have written and I still chuckle at some of other comments you made early in the discussion. A great sense of humor, the best part of people! ;)

Don't forget to get out and rock the vote if it applies. It matters!

[grant2258]

@Riverstorm I done the code to enable to set to none. I continually asked for specific setups so i could understand.

I dont feel like we have made any progress none of you seem to be able to or willing to provide a detailed setup that to display what your trying to do just the symptoms. Yes I am a contributor only like any other person that puts pull requests in.

Your only option is through mark or arcadez because you didnt give me the information to make a case for you.

[Riverstorm]

&grant2258 - Play assault, the controls aren't correct. Up, down, left & right interfere with the tanks movement.

Set up, down, left, right to backquote (or a non-used key if you use backquote) and they work correctly.

I'm not sure what else you need to test?

[grant2258]

@Riverstorm @Clyde I did look into this myself and I checked whats going on. My issue never was the tab menu it was whats wrong with the game.

I would have fixed the game to work both ways.

When I looked at it and the code i seen the problem right away the driver simply added a hack that shouldn't be there for single player control in the first place.

The problem is they have added a dual joystick and a normal joystick and they both mapped to the dpad in our mame input codes.

after looking into the problem myself just. I was going to add the lstick like i did the rstick and that way these games could work both ways by default but the thread continually ran on about the tab menu and side tracked the issue on the game.

So ill leave it up to mark about the tab menu. I was just interested in fixing the real issue we had that was causing this so we didnt run into it again or have to set keys to none. As for the tab menu i really dont care this issue can be fixed without that feature.

[grant2258]

normal controls

https://github.com/libretro/mame2003-plus-libretro/blob/240ef74756167e9d6bfc5821b10391f05f5eaded/src/drivers/namcos2.c#L1334-L1370

hack for single joystick
https://github.com/libretro/mame2003-plus-libretro/blob/240ef74756167e9d6bfc5821b10391f05f5eaded/src/drivers/namcos2.c#L1372-L1378

the hack cause the issue we can remove the single joystick hack if you like and it will work. Again not my choice alone i would have discussed this with mark and arcadez my gut feeling would be to just keep the original arcade controls and remove the hack

[Riverstorm]

You completely lost me. I thought the issue was the TAB menu AND the game. You said you're waiting feedback on an example and then feedback comes.

Now you're not going to fix it because the discussion was about the TAB menu and we did not discuss the games dual stick binding issue with you? An issue in the code we had no idea about.

Yes, the TAB menu is in the game, since they coincide (occur at or during the same time) they kind of go in tandem.

Sooo...you need another example is what you're saying?

[grant2258]

no ill fix the game that what im interested in doing all i wanted was the your setups you two never gave me them. I just looked it all up myselfs.

Ive already posted the code for set to none that issue is for you and mark to decide if it goes in or not.

Ill discuss with mark and arcadez what we will do fix this game we have a few options. This is regardless of teh tab menu

[Riverstorm]

So you've washed your hands of the issue entirely or you're saying you coded it and it's waiting to be pulled? Is your vote to implement the change or lobbying against? Every vote counts! ;)

Well, it was worth another shot to try and get it fixed. If I come across any other games I'll post them here. Thanks and heading out now to get a few hours of sleep.

[grant2258]

https://github.com/libretro/mame2003-plus-libretro/issues/464

@Riverstorm not washing my hands of anything following due process the problems been identified and a soloution will be worked out

[grant2258]

@Riverstorm
https://github.com/libretro/mame2003-plus-libretro/issues/451

the code has been ready to set the key to none for long time mark can add it any time if he chooses too.

if you guys just said you need to null out p1 up down left right for dual controls to work this would have worked a different way.

[grant2258]

fwiw @Riverstorm i dont really care what way tab menu is done. I wont loose any sleep either way I rarely use the damn thing unless i have to map over devices

[Riverstorm]

@grant2258 said in [mame2003/-plus] Removing individual per-game bindings via Tab menu:

if you guys just said you need to null out p1 up down left right for dual controls to work this would have worked a different way.

That's all we had to say? Just asking would have avoided all this conversation.

We need to null P1 dual controls, please! It didn't work to ask! ;) I'm just having a bit of fun with it because I know there's ZERO chance you'll fix it. I will post games as I come across them but I'm not going to hunt them down because that would be futile.

If those directions are hacks you can also nul them to get all controls working properly as an alternate workaround, that's what we are doing now to get clean them up.

Vindicators has the same issue.

Also a side note if you map the buttons on a controller it adds both the button and right stick name to the Input field but the right stick adds only the right stick name.

I'll post here in case the issue was missed but I updated it twice on Github. Sometimes notices seem to be getting caught in the spam filter. Robotron, Joust and Atari's Food Fight have bootstrap issues. Atari's Food Fight I can't even create a new .nvram file to get it to boot, so it's unplayable right now.

[grant2258]

@Riverstorm issue that caused this is fixed with no user intervention when the pull request is done if it is.
Im trying to be civil here. The pull Request is in for this fix for this game. Your attitude really needs a little work