Reasoning for MAME not having proper autofire

[MameHaze]

so again it comes down to insults.

mods, please delete my account, I'm done here.

[DietSoap]

so again it comes down to insults.

mods, please delete my account, I'm done here.

Or you could just leave quietly without being a drama-queen.

[MameHaze]

I've tried to be nice to this community, tried to explain things.

I'd rather make it clear that I want no further part in this community, nor will I be taking on board anything coming from it in the future.

[DietSoap]

I've tried to be nice to this community, tried to explain things.

I'd rather make it clear that I want no further part in this community, nor will I be taking on board anything coming from it in the future.

Feel free to leave any time now.

[MathU]

Not sure why you stopped posting under your past account, Haze, but please feel free to come back any time. Some of us like hearing developer insights.

[KAI]

basically:

[gray117]

The 'justification' for anything that make does is that it's their tool and they do what they want.

It is not an entertainment product.

Yes most people use it as a game playing device, but it really only exists for the amusement of its developers.

You are welcome to do what you want with it as long as you don't sell it.

They limit their remits to keep the development of the project going. This includes limiting hoops/barriers and testing which would just create more work and put off contributions, contributions which the individual developers may or may have time to complete. Things will inevitably break. But that's what a tool's development rather than a product/game will often look like.

As a the typical/majority user-type your play feedback may be appreciated, but you are not a customer, and probably not even what may be described as the target audience.

This may seem paradoxical, and stubborn, but they've kept the project going, and if nothing else been pretty consistent in their decisions... Even if you disagree with some of them

It's great people are passionate, but you really shouldn't bite the hand that feeds (for free)...

[BareKnuckleRoo]

damn, I forgot that if something is free then all criticism of it is invalid. stupid me

[gray117]

damn, I forgot that if something is free then all criticism of it is invalid. stupid me

Of course not, but it does depend how you go about it.

This is an odd project, with odd objectives and it isn't necessarily about playing games. You can't argue with a dev like this and tell them what their intent is, even if the reality/common experience is be different to their intent, their intent is still their own... they're not after your custom. They like running this project.

Telling a dev there's no reason for not having something, or asking for a justification, is immediately somewhat adversarial. There's always a reason not to have something - one less thing to spend any time on, one less thing to go wrong, one less thing to accept responsibility for, hell maybe even it was something that was added and it just annoyed a key person when it was accidentally applied and from then on it basically purged.

It's super pedantic, and kind of reductive, and seems somewhat dismissive as a starting point; but welcome to common traits in approaches to coding. This is a project, for them, run by them... not teh playerz.

Not saying that this mentality is necessarily well applied in one circumstance vs another, but you have to respect the motivations here, and that these guys are not beholden to you in any manner. Without other interests/personnel running the project (which imho would have probably seen it either stall, or just gone over the cliff many years ago) this is kind of what you get. Yes that makes this whole thing a bit peculiar/prickly, but I think you always have to beware/respect the sheer bloody-mindedness that it takes to do any code, respect this is their ball, you get it for free, and that you can only really participate in what they are primarily interested in if you contribute code... And yep they get to run it the way they want, and they like that, and that's what keeps them at this particular project ...not our approval, or criticism - well maybe a little, nice to have a bit of motivation to go along with the control

[BareKnuckleRoo]

I don't think it's particularly unreasonable when you develop an emulator of arcade video games for people to expect to want to use it to play those arcade video games. It wouldn't be doing much of a job as an emulator if you're not able to use the software it's emulating as intended (i.e. to play the games). I'm pretty sure the MAME devs are not expecting people to just boot up games only to just stare at the attract screens for hours! Nor is it unreasonable to suggest it should have functionality built-in that's common for those arcade video games to have available nowadays.

The problem is an educational one; the people doing the development may not be fully aware of current norms and expectations in the modern arcade community, and as such, when it comes specifically to the availability of autofire being built in they are essentially not up to speed with what those expectations are. Platforms like MAMEPlus that have added proper, functional autofire support fill an important area of need that isn't being met adequately by the base MAME build. The solution being given here is, at best, "make a plugin, maybe it'll be included by default or featured, maybe not, who knows", which is essentially misunderstanding how widespread the demand is, why the demand exists, other emulator norms such as how autofire options are generally expected to be included, etc.

It's great to have a free-form plugin system to allow user customization; it's not great to purposefully cut out what are considered to be a relatively basic and important software feature because you don't personally understand the need to include it, and then use the excuse that "if players wanted it so much why don't they buy a rapid fire controller?". Let's assume someone makes a plugin that basically just adds MAMEPlus functionality to the emulation, and it gets widespread notice and installation by users. Great! The point remains that the plugin shouldn't have had to been made, shouldn't have the be sought out by the user and enabled; properly functioning autofire should have been in the core build as a basic functionality from the get-go. And it technically exists in MAME, just in a broken state where you have to manually enable it each time you boot up the game, where it doesn't work with shmups that have a tap shot and charge shot on the same button, etc. There's a huge swath of shmups that are vastly more playable, accessible, and (most importantly) enjoyable when their button mashing demands are removed.

It's important to stress that just because there is valid criticism being directed at a particular area of weakness of the MAME project, it doesn't mean that we're ungrateful for the efforts of the devs on the project as a whole. It's a complex and impressive project, but one that just happens to for some reason not have gotten itself sorted out with respect to its autofire functionality, which is regarded as a norm to play with in the shmup community (not just in emulation, but also on the actual arcade PCBs thanks to autofire circuit hardware). The autofire implementation in MAMEPlus/ShmupMAME/AutoMAME completely blows the base emulator build out of the water and is so well-implemented that it makes you wonder why they don't think it's a good enough of an idea to include in the main MAME build.

[Despatche]

Even if it is, does that mean they have to go out of their way to implement it? Especially when RetroArch is already doing it and there are bound to be spinoff projects that add them?

I don't know how to answer this, because you sound like you read a completely different post but my post is what's being quoted for some reason.

Either way, small features like autofire are significantly easier to add than solving an accuracy problem, as I've already said. They do not "compete" with each other. There's a hardline stance against autofire going on here, partially through raising it as "competition" against accuracy, and there's no sense in that behavior.

"Attempt to do right by a community by not doing something that could be damaging" *get attacked for not doing it by parts of the community that don't care about the dmaage*

"Don't go out of our way to please a community but instead work on what we care about" *get attacked for doing what we want by the parts of the community that would rather something else had priority*

"Hand power to the community so they can create / maintain things for their own niche" *gets attacked for not treating it as 'first class citizen' by those that don't want the power but instead want the developers to do everything for them*

"Listen to one section of a community and implement what they ask for the way they ask for" *get attacked by the rest who didn't want it that way but some other way instead*

Do you really not see how loaded and dead-end all of these lines of thinking are? You're setting yourself up. This is exactly what I was talking about. You get so concerned about what one or two people think, then choose to act in ways that go against both what the majority wants and what those one or two people want. This is spiteful. This is user-hostile. There is no other way to define this behavior.

Actual toxicity is that nonsense MJR posted. But you're now at the point where you'll equate being criticized for making bad decisions with hate speech. At no point did BKR insult you, but you claimed he did and now want your account deleted. Sorry, but someone telling you that you're beyond help for stubbornly refusing something very simple with reasoning that doesn't make sense is not an "insult".

It really does amaze me, by the way, that people genuinely believe there is no room for criticism if something is free.

No, MAME has not been consistent in anything. One of the most long-standing issues about MAME, the thing that has traditionally scared people away from contributing, is how inconsistent both the project direction and the entire codebase routinely is. Things have gotten somewhat better in the past few years, but not really to a point where what I said becomes untrue. This entire topic is an example of MAME being incredibly inconsistent with an implementation, and a MAME developer defending that by saying "we're about to deprecate the whole thing" does not make the situation better.

For the love of Christ, yes, MAME is about playing video games. Only recently have MAMEDEV tried to make it out to be anything else, and it has been argued countless times that what they want now really needs to be a separate project. That happened, once, before all of this mess! Guess what eventually happened to it? It got merged because the same few people were working on both and they wanted to come up with this narrative about MAME not being about video games anymore.

It's not really possible to "go make your own" arcade emulator anymore. MAME is too big and too all-encompassing, and it's scope was always too big for anyone to really copy so easily. Any new arcade emulator depends on MAME to get anywhere. Because of that, you can't just handwave any criticism as so many are willing to do for some reason. I don't understand why so many people repeatedly accept and repeat this "do you guys not have phones?" kind of rhetoric from MAMEDEV, over and over again, for years now, just because it's "free". Remember all that stuff I was saying about FOSS culture being so miserable? This is exactly what I was talking about.

[WelshMegalodon]

misunderstanding how widespread the demand is

in the shmup community

Pick one.

I'd argue that the niche circle representing "widespread" demand for autofire is small enough that something like a Lua plugin would get around without any problems at all. It isn't nearly as big of an issue as you're making it out to be. If anything, the attitudes presented in this thread constitute more of a deterrent to it getting implemented than the actual demand itself.

Either way, small features like autofire are significantly easier to add than solving an accuracy problem, as I've already said.

Yet we spent the better part of a week spitting vitriol at a dev (perhaps not the most agreeable one, but a dev nonetheless) instead of focusing our efforts on implementing it ourselves (like Shepardus did) or finding someone who could.

Do we actually want autofire in baseline MAME or do we just enjoy bitching about MAME devs being their usual difficult selves?

[Shepardus]

Implementing it as a plugin doesn't preclude it from also being submitted as a PR and included with MAME itself. I don't think anything Haze said suggests that that couldn't happen. In fact, it sounds more like mamedev would welcome such an addition if it gave them an excuse to tear out the existing autofire implementation from the CPP codebase. And for what it's worth, I'm sure that you wouldn't even need to extend the Lua API, the existing API is enough to implement autofire that's even more full-featured and customizable than what MAMEPlus offered.

[gray117]

I don't think it's particularly unreasonable when you develop an emulator of arcade video games for people to expect to want to use it to play those arcade video games. It wouldn't be doing much of a job as an emulator if you're not able to use the software it's emulating as intended (i.e. to play the games). I'm pretty sure the MAME devs are not expecting people to just boot up games only to just stare at the attract screens for hours!

Yes, and I'd agree specifically with autofire it *seems* to be of more practical benefit than not, but they're not running the core project for you, anyone is welcome to adapt it for players.

The problem is an educational one; the people doing the development may not be fully aware of current norms and expectations in the modern arcade community

You're not that special, they know. It just might not be something they agree with, top of their todo list, or something they are interested in. Any of those 3 will just be more important to them than a request in such a project.

It really does amaze me, by the way, that people genuinely believe there is no room for criticism if something is fre

Not at all; the problem is manners. Someone's letting you modify and drive their car while they maintain it, and you're telling them they're wrong, and asking what's the justification for them not having the mods you want pre-done and complain every time they might not have it in tip top condition each time you want to use it, or when they pursue a mod which you're not interested in.

Toxic doesn't have to be bottom-of-the-barrel-unreasonably-offensive-behaviour. It can be just an off putting tone... And any antipathy in repetition/exchanges will likely result in some kind of wierd downward spiral that becomes toxic to getting something done.

I think we can all appreciate there's many forms of criticism and many different ways of expressing it. If you want something from someone (free or not), you have to ask them for it in an appropriate manner, where someone's time/motivation is their own and not supplemented by, say, cash, this is even more important. You can try and reason with them if they disagree, but you'll obviously get no where fighting with them if they just don't want to do it.

[donluca]

For the love of Christ, yes, MAME is about playing video games.

Probably my last post in this thread, before I unsubscribe.

MAME has never been about playing games.
MAME is a preservation project and if you ever looked at the source code you'd realize that.

The fact that you actually get to play the game is a collateral consequence, because through the painstakingly effort of documenting every detail of each hardware, you get to know how each component of a PCB work with each other and, as a consequence, you're able to replicate it.

This is what separates MAME from the others: the others merely simulate what you see and try to give you an approximation without really knowing how that hardware works (Demul is a prime example of this), purely based on how a game acts (and reacts to your inputs) on screen.

MAME goes beyond that, it strives to understand why and when certain things happen which is why it doesn't emulate some boards which are already running on other emus.

Your (and many other people) problem is that you see MAME for what is not and hence you argue about how it should work (like you're entitled to tell developers to do what *you* think is best, one of the worst kind of thing born from the internet culture which went beyond "I want this because I think it's cool" and became "See? There are other people who think like me, so you have to abide to our request!").

*IF* MAME was born and developed to let people play games, I'd on board with you 100%.

But this is not the case. Your choice: either keep on being delusional and telling people what MAME is not, or just give it up or realize that you're wrong.

OR, and this would be the best thing really, you know, since you've been using this piece of software for god knows how many years, you could actually start to give back something, by learning LUA (which, being a bit pedantic, is not strictly a programming language, but rather a scripting language) and developing (and, most importantly, maintaining) an autofire plugin. I'm sure that the MAME team would be more than happy to have a repository of "semi-official" plugins on their website.

Anyway, that's really it from me, I'll try and stay away as much as possible from MAME threads from now on.

[MathU]

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).

As an expert on the levels, bosses, damage systems, and adaptive difficulty system of Darius Gaiden, this is exceptionally baffling to me because I can attest that the game is in fact balanced very well around its default shot rate. Taito implemented their own interal autofire rate while developing the game and clearly tested it enough to achieve a fine balance between shot rate and the damage of various weapons. Then, after release, arcade operators came in and implemented their own ludicrous 30 Hz circuits? If anything this is in fact a great example of the fallacious nature of arguing for autofire based purely on cultural norms. Let us call it argumentum ad nihonium.

[BareKnuckleRoo]

Could we please stop with the posts suggesting that emulating video games is somehow entirely divorced from playing those games?

MAME has never been about playing games.

Then why did you bother asking a GroovyMAME dev to include autofire support? I assume that's the same donluca; I don't mean to suggest you're a hypocrite, but if MAME has never been about playing games why would you care what game playing features a fork of MAME has? Should MAME never be used to play games and everyone resort to having to make their own "game playing" forks for the purpose of playing games? We might as well argue all that MAME should do is boot up the game, with all player input completely disabled, which of course is a completely ridiculous thing to suggest. Video games exist to be played, that was the whole point of the software! You can't seriously argue that an emulator of video games should treat being able to actually play and enjoy playing those games as somehow irrelevant or secondary to its purposes.

I'm not stalking you or anything mind you, I just happened to do a search yesterday for as many threads across the internet I could find about people asking about autofire support in MAME, or rather the lack thereof, and I remember seeing yours among the serious number of posts out there lamenting its absence, asking how to get it working properly, etc.

[donluca]

27 January 2016.

You found a post dated 3 YEARS AND A HALF ago. That's some serious dedication, I have to give it to you.

Back then I had different views about MAME and at that time, if a discussion like this would have arisen, I would have probably been with you.

6 months later, I've made a step which would completely change my life (for what retrogaming/arcade concerns): I bought a SEGA Astro City cabinet and shortly after, I got into collecting arcade PCBs.

While troubleshooting a System16 board, a user suggested I should check MAME's source for the s16 driver. When I opened it up my entire perception about what MAME was and what was its goal radically changed and I was infinitely grateful that such a project existed. Thanks to MAME I've been able to troubleshoot and repair lots of PCBs which would have otherwise been trashed by other unscrupulous people.

That's when everything changed and I understood the true importance of MAME and what they were doing. They were not just making an emulator (despite its own name: Multiple Arcade Machines Emulator), but they were studying and understanding how all these boards worked and thanks to them they've been able to properly document it, thus saving lots of PCBs from being trashed and sharing lots of knowledge which would then become crucial in developing several multiboard projects.

Call that an epiphany or what have you, it's something I really, *really* hope people will understand one day and stop bitching about features missing or MAME being too power hungry and scarcely optimized (guess what, 5-6 years ago I was the one bitching and moaning on mamedev forums about this very issue and how they broke several games with their latest update).

Times change.

[BareKnuckleRoo]

Congratulations, you own an arcade cabinet and PCBs now. So do I. What does any of that have to do with the fact that video game emulators inherently exist for the purposes of emulating software which was designed for the purpose of being be played? If you're not actively playing games on an emulator and encouraging people to play games on it, then there's no way to even confirm if the emulator is functioning properly!

Yes, emulation also has the goal of maintaining the games and that includes understand them so as to be able to keep them working on their original hardware thanks to understanding how to do backups, etc, but again, you're claiming that MAME shouldn't care whether or not people play the actual games using the emulator. If MAME isn't being used to play games, how would you even verify a game is functioning properly? How can we look for emulation issues if we're not supposed to be using the emulator to play games? How would that bug in Omega Fighter's emulation have been discovered if not for people playing it both on the PCB and in MAME? Why is minor criticism of a videogame emulator or a feature request for the sake of playability treated like such a big deal? Do you seriously not see how ridiculous it is to handwave those away with the excuse of "we don't really care about any of the functionality that relates to actually playing the game"?

Why is there such a total logical disconnect here? People want to play the games in the main MAME build to support the ongoing bugfixing and development in the emulation, but there's some key features that are absent that affect players who actively play these games, forcing us to resort to using older builds or builds with the functionality hacked in. Autofire is completely standard to see, whether you're at a proper arcade in Japan, playing at home where many people purchase autofire circuitry to play with their PCBs, many commercially-made Superguns feature it as a default, and pretty much every scoreboard here assumes that players are probably going to be using autofire.

Is it really that ungrateful of us to ask that autofire be treated as a built-in offering when it's a feature that's been shown to be both easy-to-implement and stable in MAME?

For what it's worth I'd also like to point out that basically all the people defending MAME's stance on this issue here have basically no posts in the Hi Scores section of the forum, including Haze's old forum account. That suggests there is significant disconnect between those of us who actually want to play the games seriously, and the people who apparently want to claim that we shouldn't argue that MAME could be even better than it already is with this key bit of functionality.

[donluca]

You (and many others) have been exchanging cause and consequence.

MAME's ability of actually playing games is a consequence (more of a side effect, really) of its own goal, it's not the cause which brought forth the cause of coding MAME.

Demul was made to emulate more modern and harder to emulate games which didn't work correctly (or weren't working at all) on MAME. That was its goal and as such it has never made accuracy one of its primary goals: Demul was made so that people could play and enjoy games which didn't work on other emus.

bsnes/higan has always strived for maximum accuracy regardless of CPU requirements, while ZSNES has always tried to be playable even on old toasters.

Each emu has its own goal and MAME's is preserving knowledge about all these old games. You might argue that fruit machines, slots, computers and chess boards were out of its scope, that's something we can debate, but in the end that's what the developer wanted to put their efforts on and who are we to criticize them?
They do it in their free time and out of their own free will, how can you go to such individuals and tell them "do this" or "do that" or "this is crap because <reasons>".

Anyway, I feel I've made my point (more than once, actually) so hopefully you won't mind me moving my attention elsewhere.

You think MAME is something which it isn't (and Haze has proved it once again – and he didn't have to) and I can't help you with that, other than show you my reasoning.

Now there's a very nice opening to get the community involved and have more features added. Be glad we have this choice and let's hope the community will take this chance to extend MAME's functionalities to their liking.

[BareKnuckleRoo]

MAME's ability of actually playing games is a consequence (more of a side effect, really) of its own goal, it's not the cause which brought forth the cause of coding MAME.

By that logic, any time I pop an NES cartridge into an NES console my ability to play the game is a "side effect" and not the goal of the console.

Being able to play a video game is not a "side effect" of a video game emulator.

Some emulators focus more on accuracy or being used for development purposes and require more powerful GPUs, and some make concessions in accuracy for the sake of being played on less than optimal hardware, but they've all got the same goal in mind: playing the games. If you can't play games on a game emulator, or if the game emulator views being able to play the games as a "side effect", that's one heck of a bizarre "emulator" you're describing.

[WelshMegalodon]

Congratulations, you own an arcade cabinet and PCBs now. So do I. What does any of that have to do with the fact that video game emulators inherently exist for the purposes of emulating software which was designed for the purpose of being be played? If you're not actively playing games on an emulator and encouraging people to play games on it, then there's no way to even confirm if the emulator is functioning properly!

The response I would expect from a MAME dev on that point is that, based on the goals they've set for themselves, MAME only wants to make concessions to playability to the extent that it aids documentation. Not for the sake of playability. Hence their recent interest in things like graphics card use for 3d games or the introduction of a separate HLE Q-Sound driver.

Going by that logic, it actually would make sense to include autofire since it would facilitate playtesting, but their answer to that is "that's what Lua is for".

Why is minor criticism of a videogame emulator or a feature request for the sake of playability treated like such a big deal?

Because we've made it that way. When a vocal minority of users push for a feature request over and over despite the creator having made his stance on the matter clear, and then continue to get upset when he refuses to change his opinion, a minor criticism becomes a big deal.

For what it's worth I'd also like to point out that basically all the people defending MAME's stance on this issue here have basically no posts in the Hi Scores section of the forum, including Haze's old forum account. That suggests there is significant disconnect between those of us who actually want to play the games seriously, and the people who apparently want to claim that we shouldn't argue that MAME could be even better than it already is with this key bit of functionality.

There are also regular contributors to the Hi Scores section that have never so much as let out a whimper about MAME's lack of autofire in this thread.

[BareKnuckleRoo]

Going by that logic, it actually would make sense to include autofire since it would facilitate playtesting, but their answer to that is "that's what Lua is for".

Yes, and that's one of the points of contention. Lua is great, but external scripting and plugin systems can break as the emulator's developed, and are inherently not as user-friendly as having them built into the core itself the way MAMEPlus/ShmupMAME/AutoMAME does it. There haven't been any cogent arguments as to why MAME should not simply implement what's in MAMEPlus/ShmupMAME/AutoMAME as default. Worse, some of the arguments coming from the dev as to why MAME shouldn't implement it or can't be bothered to have been frankly silly ("why don't you just buy a rapid fire controller", "autofire isn't accurate emulation" and so on for instance) and are probably worse than just saying "we can't be bothered to implement it, deal with it".

There are also regular contributors to the Hi Scores section that have never so much as let out a whimper about MAME's lack of autofire in this thread.

Those people are probably extremely wise for not participating in this mess of a thread. Seriously, shmupsforums has already had these arguments about autofire being a totally normal expectation in countless previous threads.

[WelshMegalodon]

There haven't been any cogent arguments as to why MAME should not simply implement what's in MAMEPlus/ShmupMAME/AutoMAME as default.

It's a cheat because people in communities just like this one asked for it to be a cheat so that it couldn't be used for setting high scores, or replay files without it being obvious it was turned on.

Can't please everyone I guess.

As I said elsewhere, you could probably write an autofire lua plugin that would work without modification in current MAME if you so wanted tho, that's actually the model we want to encourage people to use for such things. Once written it could be distributed, maybe even included with MAME, and the existing functionality removed.

(of course the current hiscore support doesn't actually even care if cheats are turned on anymore, since that too is now a lua plugin, so yes, MAME is moving away from the model where we even care about that. We've found it to be better to generally ignore opinions of the community when it comes to such things, rather than take the suggestions on board as we did when it was hidden behind a cheat option in the first place; creating ugly special cases for specific user groups was never a great idea and had it been done today, it would have probably never been put behind a cheat option in the first place)

MAME is a public project, anybody can contribute, there are plenty of people out there with the skills to do a lua plugin with more flexible autofire options, this stuff is barely interesting to those reverse engineering hardware etc. People are already doing all sorts of complex game self-playing AI scripts using the functionality, which is good to see, it clearly shows it isn't inaccessible.

Telling a dev there's no reason for not having something, or asking for a justification, is immediately somewhat adversarial. There's always a reason not to have something - one less thing to spend any time on, one less thing to go wrong, one less thing to accept responsibility for, hell maybe even it was something that was added and it just annoyed a key person when it was accidentally applied and from then on it basically purged.

Maybe not cogent enough for you, but this is certainly cogent enough for me.

[BareKnuckleRoo]

We both know it's not worth going through a re-hash of this entire thread again. The most compelling post in the thread for why autofire should a) not be universally seen as a cheat (it can be a cheat if it's game-breaking, but that depends on a game-by-game basis), and b) should be a standard feature in MAME, is Plasmo's. It's really the post that matters here, so please refer to it.

I sympathize with the people who believe that autofire is cheating and will taint the element of gaming. Being a purist isn't a virtue; I know, because I've been there and used to feel rapid fire controllers were dirty things. The reality though is they're not, and there are many mediocre games where they vastly improve and elevate the playability and experience of the game, and being able to play games with different tools to try and get the best possible experience is something to be embraced.

[WelshMegalodon]

I'm not opposed to autofire on principle (I prefer Super Darius to the original for autofire alone), I just don't think continuing to beg the devs for it like we've been doing is at all appropriate.

[BareKnuckleRoo]

Are we begging them though? It sucks they won't build autofire into it by default but we don't have any reason to beg for it as there's other perfectly functional MAME forks out there with autofire to choose from and use instead. It's more like, hey, here's why we shmuppers don't use the main MAME build, it's missing a key feature, we use these other better versions because they're not missing a key feature that makes some games vastly more playable.

We can tell them why they should have it included by default and why it'd make MAME better, but I mean the main MAME build has gone for years without it and there isn't exactly a lot of awareness of what's considered standard as far as modern arcades go. Arguments for autofire have been around for years; I don't think anyone here seriously expects them to turn around and suddenly change their minds, as much as we'd like them to. We're pretty used to having to rely on an alternate fork/build or plugin to get autofire by now.

[MameHaze]

It's more the aggressive arguing over semantics that is coming across as toxic (along with all the cheapshots)

To an end user, the difference between it being a plugin, or hardcoded is minimal, it's a single extra box to check, a different menu to look in. It makes such a TINY difference it's not worth arguing over. To a developer, it's a nice boost, we know as long as we don't break the plugin API (that many things now depend on) that functionality will keep working with no additional case specific burden.

The system was designed for users, specifically for use cases just like this, to be user friendly, while at the same time not being a burden on the devs, so also to be developer friendly. It's a nice middle-ground compromise, that in all honesty still favours users more than it does devs (because in the end there is still the plugin system itself to maintain)

So for somebody to be so aggressively dismissive of it, and unwilling to accept when an effort has been put in, unable to see the compromise that has been made, and still demand it is instead done exactly their way with no compromise, yes, that's toxic. It's not criticism at that point, because it's not even logical, it's just needless aggravation.

This community is maybe 0.001% of the userbase, none of the people demanding this are as special as you seem to think you are, outside of this community nobody even really cares about this.

and yes, this is my last post on the subject, I'm just glad to see some well reasoned arguments have been put forward, because it's incredibly draining coming here, only having good to offer the community, and having the community spit in your face all the same.

As an anecdote, it always seems to be this kind of situations that cause problems. Cases where the devs have made it literally as easy as we can, aside maybe one unavoidable extra button press, or one extra checkbox for the users; something that, for a user is basically the minimal effort we could reasonable ask, and they hit back and attack like we're asking the world of them, like we're putting up some impossible barrier. Things like the emulation status warnings are the same; it is *essential* that they stay, because otherwise it causes many, many problems for the devs and new users. We've reduced it to a single button press, we have compromised to the point where it's something so easy your cat could do it by walking across the keyboard, but even that, something we can't remove without making the project entirely developer-hostile (and new-user-hostile) ends up being too much to ask of some people to the point where we they want to aggressively abuse us for it. People act like no research has been done on the subjects, when in fact *extensive* research has been done to find the middle ground.

Just because something strikes a balance, a compromise between being developer friendly and user friendly, doesn't mean it's user hostile, or irrational, or illogical. These things are well thought out, and a sweet spot is picked that doesn't put too much burden on either group. For there to be entire threads filled with hate and 'criticism' over that is ridiculous.

Anyway, goodnight, and thank you to those who have been posting some sense in this thread.

[DietSoap]

With all due respect MameHaze, you're making this way harder on yourself than you have to.

[Square_Air]

There are also regular contributors to the Hi Scores section that have never so much as let out a whimper about MAME's lack of autofire in this thread.

Because it doesn't seem very productive to speak with developers who have a limited understanding of the community. Most of us just live with whatever ratchet autofire/custom button setup we can get our hands on. I'll always get by like this, but progress towards a better fork/implementation/plugin will only be of benefit to the community.

This community is maybe 0.001% of the userbase, none of the people demanding this are as special as you seem to think you are, outside of this community nobody even really cares about this.

Then why are you here? I understand that you can do whatever you please with your emulator, but this just comes off as petty.