Reasoning for MAME not having proper autofire

[MameHaze]

Well it sounds like if you could port it to be a lua script (and if MAME does need any extra hooks to support what you want cleanly, add them, as others who have been writing scripts have done) it would be easier for people here as they could just drop it in the plugins folder and turn it on.

That said, if you don't know lua / don't want to learn lua it's fair enough. It would be nice to see the community embracing the power they've been given tho

As for the rest, yes, interests are going to differ. I actually dropped system11 (the owner of this site...) a mail earlier today asking if he's ever looked into on of the plug and play shmups he owns so that we can know what is inside it, and who best to deal with it if we do decide to buy another one (or if he decides to dump it / donate it)

[BareKnuckleRoo]

and I can upload an updated version if there's interest.

I would love this if it's not too much trouble.

[donluca]

Never written a single line in LUA, but knowing several other programming languages (Java, C++, C#, Python, Ruby, etc...) I don't think that would be an impossible feat.
My issue is time, I won't be able to look into this until this summer (July/August). If no one has done the plugin by then I'll give it a shot.

EDIT: and I absolutely hate the entitlement some users have expressed here. Kids those days act like they are entitled to everything and everyone else just have to do what they're told.
And MAME focuses on preserving the original behavior of the games emulated and I don't recall Reco boards being in arcades back in the 80s-90s.

[maximo310]

EDIT: and I absolutely hate the entitlement some users have expressed here. Kids those days act like they are entitled to everything and everyone else just have to do what they're told.
And MAME focuses on preserving the original behavior of the games emulated and I don't recall Reco boards being in arcades back in the 80s-90s.

Besides the way some of the arguments were presented, they do have a point in regards to autofire being on arcade cabs even back in the 80s. Given how the JP high score history progression of some of these games are, it'd make sense why autofire would be used ( such as in Assault where big tanks on later levels have severely beefy hp and the game is already pretty long w/ 11 stages).

But given how different the mentality of the JP vs US arcade scene was at the time ( even down to instruction manuals asking the operator to alter the difficulty level to be harder, less comfortable buttons, etc, TG making weird business decisions), it's no surprise why autofire was only offered if it was internally programmed.

That's why I'll continue to use MAME offshoots, bc I don't feel like killing my fingers just to enjoy the games that I play.

[Shepardus]

I'm personally fine with people viewing external autofire as cheating even though I'll gladly use it myself, so I don't mind it being relegated to the cheats menu (as it is currently). I think that shouldn't stop people from supporting the feature better though, i.e. by making the autofire settings save. The main reason I bothered to port the MAMEPlus code in the first place (moreso than the custom buttons, which I also wanted) was that I didn't want to reconfigure the autofire every time I launched MAME - to me that's just inconvenient for no reason (unless being in the cheats menu prevents it from saving settings or something...).

and I can upload an updated version if there's interest.

I would love this if it's not too much trouble.

I'll do this tonight, producing a new build and diff on top of the current MAME 0.209. Maybe I should just start a separate thread for it so people don't have to dig it out of random threads like this...

I also encourage people to take that diff and enhance it in ways they want, e.g. an arbitrary number of custom buttons, separate autofire rates for each button, making it a plugin, etc. I personally have little interest in doing so myself since my build works perfectly fine for my own purposes, but there are a number of neat ideas floating around that just need someone to take the initiative in implementing.

[donluca]

There's nothing intrinsically wrong with autofire, but it was a mod added by third parties and not inside the original game.

It's perfectly fine to play with autofire (I do on some games as well), but, as Haze suggested, it should be something external to MAME, like it's now, a cheat, or a plugin.

I feel like this whole discussion would end if someone would step up and make the autofire plugin, it would end this whole mess in this very moment.

[Shepardus]

and I can upload an updated version if there's interest.

I would love this if it's not too much trouble.

I'll do this tonight, producing a new build and diff on top of the current MAME 0.209. Maybe I should just start a separate thread for it so people don't have to dig it out of random threads like this...

Here you go: ZIP with Windows 64-bit executable and diff file, diff file by itself (apply on top of mame0209 source checked out from Github)

Hopefully someone steps up to write a plugin so I don't have to rebuild this anymore.

Well it sounds like if you could port it to be a lua script (and if MAME does need any extra hooks to support what you want cleanly, add them, as others who have been writing scripts have done) it would be easier for people here as they could just drop it in the plugins folder and turn it on.

Yes, I do think this would make for a good plugin. Hopefully one of the people clamoring for this feature so much steps up to write a plugin so I don't have to keep rebuilding my patched executable.
I'll be disappointed if I end up being the first to do it

[theclaw]

Autofire is a game-specific issue. In some games it'll let you achieve scores humanly impossible on any original, authorized, arcade cabinet.
Other games it's useless.

[Despatche]

"original, authorized arcade cabinets" typically have autofire options, because basically everyone who takes these games seriously added this support to their "original" cabinets. The resistance to autofire is almost exclusively an American and European idea, as Japan (where most of these games are made and played) typically does not do this. Instead, Japan will play certain key games both with and without autofire, something the West also almost never does.

The correct solution is obvious. There simply shouldn't be a need for separate "automame" builds, nor for threads like this. There should also be more respect for playing these games without autofire. Instead we get whining about how Darius Gaiden is "better" without autofire (itself a very recent idea), even though it's a fundamentally broken game no matter how you try to play it.

[donluca]

Pardon me, but you've just stated, your own words, that adding autofire even at the game's release was common practice in Japan, but not in Europe and US.

And then you state that, as a consequence, the right thing to do is just adding an autofire option by default rather than a separate plugin?

LMAO.

I've always had huge motivation posting here and discussing with other members, but everytime MAME, autofire or some other topics come up I can't help but cringe at what people say.

I'll just stay away from this kind of topics from now on honestly. People which I admire and like to argue with just go full brainfart on those topics.

[theclaw]

Call it what it is. Modifying a cabinet with functionality not provided by the manufacturer is cheating.

However! The way most shmups are played, it's for the best. Button mashing that much is neither fun or healthy.

[Shepardus]

If all you want is autofire then a fork of MAME or a plugin would be sufficient. But no amount of plugins will make everyone agree with you that you're playing the game the proper way.

[BareKnuckleRoo]

donluca arguing that emulators should not feature decent autofire functionality built in and should require manual patches users have to install separately, lol

current main build MAME 0.209 has broken implementation that does not function properly for games with distinct tap shot and hold/charge shot functionality so either way it needs fixing

someone hurry up and please lock this dumpster fire thread already

[theclaw]

If all you want is autofire then a fork of MAME or a plugin would be sufficient. But no amount of plugins will make everyone agree with you that you're playing the game the proper way.

What MAME "must" do is implement autofire in games that officially have it. Otherwise they're willfully inaccurately emulating the game.

[Despatche]

Having proper custom button and autofire controls has no impact on the emulation itself. No "willful inaccuracy" ever appears, unless the developers do something ridiculous like force autofire on at all times. Oh no, I'm giving them ideas!

Pardon me, but you've just stated, your own words, that adding autofire even at the game's release was common practice in Japan, but not in Europe and US.

And then you state that, as a consequence, the right thing to do is just adding an autofire option by default rather than a separate plugin?

It's common practice in Japan because the vast majority of these games were developed and released by and for Japan, and also because Japan cared more about these games than anywhere else. Obviously these two things are directly related. Aside from pointing out how autofire competition actually works in Japan, these two things don't have direct bearing on the argument for proper support, but they sure do help, and those who "campaign" against autofire sure like to point out that "only" Japan did this as some kind of counter-argument. This forum is filled with such statements. This thread is not new.

MAME already has autofire itself, even if it's labeled as a cheat, so having a separate plugin is completely unnecessary. Arguing for a separate plugin as a best-case scenario while laughing at any justification for proper support only proves my point. Obviously the right thing to do is, in fact, have proper support.

You "cringe" every time MAME comes up because the MAME project is a mismanaged nightmare and the main figures behind it are actively hostile to the userbase, but people like you seem to think there's nothing wrong and that MAME is solid software for everyone. It's funny how MAME developers act so surprised that people use older versions for serious reasons when those same developers treat users like garbage. MAME is one of the biggest examples of the worst of FOSS culture in the world, made all the more worse by this awful mindset only really starting to appear when MAME actually went FOSS. I don't think it's the people arguing for autofire that are brainfarting here.

[Shepardus]

Explain to me how a plugin isn't "proper support"?

[Despatche]

"plugin" sounds nice, but what it really means is what looks to most people like some random bit of Totally Unofficial code stuffed on some website somewhere. That means a lot, especially on the internet where basically everything is dictated by how many people see it (i.e. what gets advertised the most). Making some weird plugin for weird people is not too far off from not making a plugin at all, because the vast majority of people will never realize that it actually exists. Also, being an unofficial plugin is the definition of improper support.

When you're talking about a feature that applies uniformly to almost all games, a feature that is partially in the software already, and a feature that is very important to playing many of the games it applies to, the above is a huge deal.

[Shepardus]

I get that if it's some random script posted on a website of questionable repute, but would it be different if, say, the plugin were distributed with MAME itself (like some plugins are today)? That's what I personally would like.

[Despatche]

That'd be great! But judging by the responses in this thread, that is exactly what won't happen. Of course, once again, MAME does have some form of autofire, so things could change.

[theclaw]

Having proper custom button and autofire controls has no impact on the emulation itself. No "willful inaccuracy" ever appears, unless the developers do something ridiculous like force autofire on at all times. Oh no, I'm giving them ideas!

I admit it's pedantic. But if the game was in fact released with autofire, and it doesn't work in MAME, then that's an inaccuracy.

[Bassa-Bassa]

There's been a Konami rewrite underway for years. It's hard.

Is there a place where one can learn more about that, please? Who is in charge currently? Does it cover from Sunset Riders to Sexy Parodius and everything in between?

The last proper arcade stuff I did at the turn of the year was fixing up some shmup stuff even (title screen / water effect on Ultra X Weapons)

Yet my main feeling about the arcade scene is one of toxicity, if you can't see that from the posts here I don't know what to say.

For every "toxic" commenter you have at least ten people elsewhere thanking your labor and showing happiness for this glitch or the other getting fixed. Not to mention every donation made to buy and dump the arcade games (and with the expectation that the emulation is spot-on some day, no doubt). Maybe this one just isn't the place for that, but they're out there and you're well aware. I don't think you're changing much by saying that you don't need people complaining about this and that. Those will arise even for emulation of plug-and-play devices or calculators if that ever deserves a fan club.

[MameHaze]

Explain to me how a plugin isn't "proper support"?

Considering a whole bunch of functionality is being moved to plugins I don't see why it isn't "proper support" either.

I guess it comes from the same camp that won't accept a separate frontend exe as proper and still insist on MAMEUI even if there are no benefits to that approach, the same people who think MAME can be updated by copying an .exe file because nothing else matters.

We're likely to see a lot more moved to lua based plugins in the future, I have a feeling all the dipswitch naming will be for example, making it externally editable without recompiling too.

[MameHaze]

There's been a Konami rewrite underway for years. It's hard.

Is there a place where one can learn more about that, please? Who is in charge currently? Does it cover from Sunset Riders to Sexy Parodius and everything in between?

https://github.com/mamedev/mame/commits/konami

although I think there might be a newer version somewhere. It's meant to cover *all* 16-bit / 32-bit Konami, although probably breaks just as much as it fixes at the moment.

[Plasmo]

The reality of autofire setups in Japanese arcades

I have lived in Japan for a while and have encountered various autofire setups of which I wanted to show some of them here. Generally speaking, any player who is serious about scoring plays exclusively on a cabinet with a proper autofire setup. This is also a selling point for some arcades: the best autofire setups attract the most players who are willing to spend a lot of money on the games. Noone wants to mash buttons. Even for casual players, these setups are very convenient.

We cannot say for sure when autofire setups became the norm in Japanese arcades, but already Tatsujin Oh in 1992 had a DIP switch for autofire that was ON by default. Moreover, from around the early 90s we see official scorekeeping magazines to split up tables for some older games into two categories: autofire and non-autofire. It is usually the former which is then considered the main category and has the most competition. While early autofire setups simply had a faster frequency for the Shot button, they became increasingly more complex in recent years, often culminating in setups specifically designed for only one game.

Some later titles never had a non-autofire category to begin with, so that autofire setups became mandatory for score-play. Even some games that differ dramatically with autofire only ever had one category (e.g. Darius Gaiden). This tells you just how widespread autofire setups must’ve been at that point in 1995 already.

Let’s check out some of these modern-day setups!


Example 1: Dragon Spirit (Hey game center)



You have the regular A and B buttons on top. Below that, you have one extra button each. Press them once to increase autofire on the above buttons respectively. Press them again to lower it down to normal.


Example 2: Fantasy Zone (Hey game center)



The button in the lower left works as explained above. To the right, you see two additional buttons with 15hz A and 30hz A, which you can hold down directly for that frequency, i.e. you don’t have to hold down regular A in the top left.


Example 3: Radiant Silvergun (Hey game center)



For this comparatively complex game, you even have the choice between two different autofire layouts with 7 and 8 different buttons each (Radiant Silvergun is originally a 3 button game). You can switch freely between them. The custom buttons of the first layout are 15hz A (even frame) and 15hz B (odd frame). These are to be pressed simultaneously to create a synchronized autofire for A+B (= blue laser weapon), which is relevant for scoring. The remaining two buttons are A+B+C mapped to one (= sword) and 30hz on A+C (= back shot).
The second layout is much more conservative and mostly puts the combined weapons on one button each (A+B, B+C, A+B+C). Additionally, you get A+C 30hz and B 15hz.


Example 4: autofire of directions



For some games, the world record scores make use not only of autofire of buttons, but also of the directions itself! The button in the lower left is used for autofire on the direction down, here used for Varth (to refill bombs quicker). US Navy uses autofire on direction right (for the shoplifter trick). On the picture above you also see simple autofire on A mapped to button C. This isn’t even marked anymore as it’s so common for virtually every single cabinet.


Example 5: Battle Garegga (Mikado)



A newer invention is a small switch to regulate several different autofire frequencies at once. This is called a synchronizer, here in blue. You can turn the switch to 7hz, 10hz, 12hz, 15hz, 20hz or 30hz. This frequency will be activated once you press auto A once. As you cannot decrease your autofire frequency again in Garegga, it is then best to switch back to regular A after you have selected the desired frequency. The red switch to the right of the synchronizer lets you choose whether you want auto A, B and C on the top row or on the bottom row of buttons. You can freely switch around during play. Additionally, the pink button to the right has A+B+C mapped to one button for an easier character selection.


Example 6: Battle Garegga (Hey game center)



While the above setup for Garegga is already very impressive, my favourite one is installed at Hey. The synchronizer feels much better to turn and moreover you have 30hz B (for bombing the birds with Gain) and auto C (for quickly activating fake wide options). Not related to autofire setups, but both cabs at Mikado and Hey have a reset switch so that the player can turn the game on and off to return to boot-up rank.

The modification of the control panel does not stop with autofire. Anything that is even remotely useful to scoring, will be fully exploited by arcade owners, usually in close contact with the top players. This way, we can see special buttons to move exactly one pixel (used for X-Multiply, R-Type Leo and some others) or a mapping of directions left and right simultaneously to one button (used in Donpachi to kill the 1-5 boss while staying in the top corner safespot).

It would be wonderful to have regular autofire support for MAME, as it is indispensable for playing arcade games (not only shmups!) with a proper and easily modifiable autofire setup. This has been the norm in Japan for the past 25 years or so. Let's catch up on this and maybe our scores will also increase! At the very least our hands will hurt less.

Here's a great site solely dedicated to autofire setups and related things: http://rapidturbo2000.blog.fc2.com/

(None of the images is my own. I'm a thief.)

[Despatche]

Thank you, this is the post we needed right now. I didn't know Darius Gaiden never had a no autofire category, but I'm not at all surprised. I'll say this now and forever, because it's true: mechanically it's a very silly game no matter how you play it, so you might as well play it in the least annoying way possible, which also happens to be a way that the developers of the game were supportive of.

I admit it's pedantic. But if the game was in fact released with autofire, and it doesn't work in MAME, then that's an inaccuracy.

Err, yes. This is absolutely true. I hope such a situation never happens. This isn't really relevant to the point though.

We're likely to see a lot more moved to lua based plugins in the future, I have a feeling all the dipswitch naming will be for example, making it externally editable without recompiling too.

This sounds good. If this is really the direction MAME is going in, if we get a serious plugin system and some would-be autofire plugin isn't endlessly maligned by MAME (as autofire has been by MAME for a very long time), then there's no issue. I really like the idea of being able to edit dipswitch labels so easily! The problem is that bit in the parentheses.

MAME does need a proper UI though. MAMEUI in its present state is not the answer, but it doesn't need to be. MAME+GUI was a pretty good effort, it's a shame those devs (who are also the last MAME Plus! devs) have kinda bowed out.

There's been a Konami rewrite underway for years. It's hard.

Is there a place where one can learn more about that, please? Who is in charge currently? Does it cover from Sunset Riders to Sexy Parodius and everything in between?

https://github.com/mamedev/mame/commits/konami

although I think there might be a newer version somewhere. It's meant to cover *all* 16-bit / 32-bit Konami, although probably breaks just as much as it fixes at the moment.

This is also very interesting and exciting, especially for Konami GX games.

[MameHaze]

The thing with a lot of those Autofire setups is they are 'after market' mods, something put in by the arcades, not the manufacturers.

There's a chance the more complex ones (especially game specific) are even being driven by their own I/O boards (with MCUs or the like) sitting between the usual JAMMA connector and the controls. In that case to 'accurately emulate' them MAME would need dumps of all that, not fake it using some HLE solution. I seem to recall that many years ago a Sega Flash Point bootleg board that showed up had some additional board (with extra Z80 + ROM etc.) soldered onto the JAMMA connector, we never knew why, maybe it was something like that tho.

They might be more popular (although outside of Japan I've literally *never* seen that) but unless Taito etc. were putting them out, they weren't exactly official either (not that emulating bootleg stuff is outside the realm of MAME)

Those and MAME having a generic autofire plugin aren't mutually exclusive things, I'm just saying, it's a more complex subject once you get into the type of thing being pictured.

One thing with MAME, since the merger of MESS, is the whole pluggable device system too, in theory, if there were 'auto fire' boards that connected and had their own CPUs + code, it might become possible to emulate them as pluggable devices. This was important for emulating console games (as you have pads, including non-standard ones that you can be added / removed) and this kind of thing is actually closer to that.

These are just thoughts of course, unless somebody makes it their work to prioritize documenting all this stuff (or developing a better plugin to replace the internal logic) I wouldn't anticipate any short term changes.

[OmegaFlareX]

(or developing a better plugin to replace the internal logic)

For those of you in this thread that have forked MAME to have better autofire, you are awesome, but I think your efforts would be better focused on making a plugin with a much longer shelf life than a single version of MAME. Assuming autofire and custom buttons can be handled by the plugin system. I know next to nothing about it. Is it how the cheats system works? I found a place that had a 7z of cheats for every single game and it was as easy as dropping it into the MAME directory. It's how I can play Zero Wing without wanting to run away screaming (I can't deal with the red flash).

[mycophobia]

I did get a more recent build by Shepardus which indeed has inconveniences with Neo Geo games. However, that was for 0.197 which had a nasty regression in Sengoku Blade (we spent half a year in 2018 with that...)
I know someone who has somehow been able to apply that patch to newer builds (still with the Neo Geo issues). Not very convenient stuff, let's just say.
I'll just leave this here:

lol

[mycophobia]

The reality of autofire setups in Japanese arcades

I have lived in Japan for a while and have encountered various autofire setups of which I wanted to show some of them here. Generally speaking, any player who is serious about scoring plays exclusively on a cabinet with a proper autofire setup. This is also a selling point for some arcades: the best autofire setups attract the most players who are willing to spend a lot of money on the games. Noone wants to mash buttons. Even for casual players, these setups are very convenient.

We cannot say for sure when autofire setups became the norm in Japanese arcades, but already Tatsujin Oh in 1992 had a DIP switch for autofire that was ON by default. Moreover, from around the early 90s we see official scorekeeping magazines to split up tables for some older games into two categories: autofire and non-autofire. It is usually the former which is then considered the main category and has the most competition. While early autofire setups simply had a faster frequency for the Shot button, they became increasingly more complex in recent years, often culminating in setups specifically designed for only one game.

Some later titles never had a non-autofire category to begin with, so that autofire setups became mandatory for score-play. Even some games that differ dramatically with autofire only ever had one category (e.g. Darius Gaiden). This tells you just how widespread autofire setups must’ve been at that point in 1995 already.

Let’s check out some of these modern-day setups!


Example 1: Dragon Spirit (Hey game center)



You have the regular A and B buttons on top. Below that, you have one extra button each. Press them once to increase autofire on the above buttons respectively. Press them again to lower it down to normal.


Example 2: Fantasy Zone (Hey game center)



The button in the lower left works as explained above. To the right, you see two additional buttons with 15hz A and 30hz A, which you can hold down directly for that frequency, i.e. you don’t have to hold down regular A in the top left.


Example 3: Radiant Silvergun (Hey game center)



For this comparatively complex game, you even have the choice between two different autofire layouts with 7 and 8 different buttons each (Radiant Silvergun is originally a 3 button game). You can switch freely between them. The custom buttons of the first layout are 15hz A (even frame) and 15hz B (odd frame). These are to be pressed simultaneously to create a synchronized autofire for A+B (= blue laser weapon), which is relevant for scoring. The remaining two buttons are A+B+C mapped to one (= sword) and 30hz on A+C (= back shot).
The second layout is much more conservative and mostly puts the combined weapons on one button each (A+B, B+C, A+B+C). Additionally, you get A+C 30hz and B 15hz.


Example 4: autofire of directions



For some games, the world record scores make use not only of autofire of buttons, but also of the directions itself! The button in the lower left is used for autofire on the direction down, here used for Varth (to refill bombs quicker). US Navy uses autofire on direction right (for the shoplifter trick). On the picture above you also see simple autofire on A mapped to button C. This isn’t even marked anymore as it’s so common for virtually every single cabinet.


Example 5: Battle Garegga (Mikado)



A newer invention is a small switch to regulate several different autofire frequencies at once. This is called a synchronizer, here in blue. You can turn the switch to 7hz, 10hz, 12hz, 15hz, 20hz or 30hz. This frequency will be activated once you press auto A once. As you cannot decrease your autofire frequency again in Garegga, it is then best to switch back to regular A after you have selected the desired frequency. The red switch to the right of the synchronizer lets you choose whether you want auto A, B and C on the top row or on the bottom row of buttons. You can freely switch around during play. Additionally, the pink button to the right has A+B+C mapped to one button for an easier character selection.


Example 6: Battle Garegga (Hey game center)



While the above setup for Garegga is already very impressive, my favourite one is installed at Hey. The synchronizer feels much better to turn and moreover you have 30hz B (for bombing the birds with Gain) and auto C (for quickly activating fake wide options). Not related to autofire setups, but both cabs at Mikado and Hey have a reset switch so that the player can turn the game on and off to return to boot-up rank.

The modification of the control panel does not stop with autofire. Anything that is even remotely useful to scoring, will be fully exploited by arcade owners, usually in close contact with the top players. This way, we can see special buttons to move exactly one pixel (used for X-Multiply, R-Type Leo and some others) or a mapping of directions left and right simultaneously to one button (used in Donpachi to kill the 1-5 boss while staying in the top corner safespot).

It would be wonderful to have regular autofire support for MAME, as it is indispensable for playing arcade games (not only shmups!) with a proper and easily modifiable autofire setup. This has been the norm in Japan for the past 25 years or so. Let's catch up on this and maybe our scores will also increase! At the very least our hands will hurt less.

Here's a great site solely dedicated to autofire setups and related things: http://rapidturbo2000.blog.fc2.com/

(None of the images is my own. I'm a thief.)

Excellent post, thanks

[Shepardus]

(or developing a better plugin to replace the internal logic)

For those of you in this thread that have forked MAME to have better autofire, you are awesome, but I think your efforts would be better focused on making a plugin with a much longer shelf life than a single version of MAME. Assuming autofire and custom buttons can be handled by the plugin system. I know next to nothing about it. Is it how the cheats system works? I found a place that had a 7z of cheats for every single game and it was as easy as dropping it into the MAME directory. It's how I can play Zero Wing without wanting to run away screaming (I can't deal with the red flash).

I agree, I don't want to keep rebuilding my build. And I completely forgot about that issue with NeoGeo games that was mentioned.

Autofire should be doable with the plugin system, in fact I did a quick Google search and found that there's already some work on it in this thread on another forum: http://forum.arcadecontrols.com/index.p ... c=155050.0

Custom buttons may be another story - the way it works in my fork is by hacking in some input ports and I'm not sure that the Lua API allows adding extra ports like that, just reading and manipulating the ones that already exist. That being said, it does allow you to read input and set the state of buttons (i.e. set whether they are pressed or not), which should be enough to implement an autofire system including separate buttons for autofire/non-autofire (which is the main thing custom buttons is useful for).

Making everything configurable through UI will take some more effort to design properly. As far as I can tell menus added by plugins are limited to the plugins submenu, so no doing something like adding custom buttons to the main keybindings menu. That's just one way of presenting the settings, though - it doesn't necessarily have to be that way.