Mame gurus: Is there a way to filter off consoles?

[Howard_Casto]

Ok so hell has frozen over and I'm working on Dragon King a little to get it working with newer builds of mame.  The problem is mame has all this junk in it now. 

Filtering off E.M. games is easy enough.... look for the "ismechanical" flag, but I haven't found an equivalent for the consoles. 

Is a "software_list" device type a universal indicator of a console/pc type?

Might I suggest to any mame dev's listing that a "isplatform" device flag would be nice. 

[Howard_Casto]

Ok so I ran some tests.....

Using "software_list" as an indicator gets rid of most consoles and PCs but not all.  As I feared it isn't a universal indicator.  I'm going to have to look for media flags as well like "cart" and "cassette".  The only problem with that is there are various arcade systems that use these peripherals as well.  A lot of later fmv games and cps3 games use cd's for example. 

This is something that needs sorted imho, preferably on the mame end.

[Haze]

We have no intention of making that distinction available, it currently exists at source level, but even that is likely to go away soon, as will the ability to build stuff without any of the non-arcade drivers included (we're more likely to make the sub-builds per-manufacturer groupings instead as it keeps closely related hardware grouped together, many manufacturers used the same hardware for their arcades and consoles)

Machines are machines, we emulate them, MAME isn't a toy so adding things to allow filtering of 'arcade games' doesn't make sense at this stage in the project's life.  By not categorizing at source level it also avoids the whole is / isn't an arcade machine debate that kept cropping up as of late by not trying to put things in boxes at all.  (things like are gamblers arcade games?, are things like the popcorn machine we just emulated arcade games? etc. - now we just don't have to worry, somebody else can make their own filters based on real criteria such as input/output devices, if a screen is present or not etc.)

As part of the drive to a more serious project you got some benefits, like the copyright nag screen going away (there are so many more 100% legal uses of MAME in it's current form that it seemed entirely pointless) but also it means you get things like this.

A bug report was opened for this, it was promptly closed
http://mametesters.org/view.php?id=6030

As you've discovered 'Software Lists' are just lists of user removable media that can be used with a system, which often means the known cartridges for home consoles (so that we can document them properly, including rom labels and ICs inside the cartridge as we've done for arcade games over the years)  You'll note however that to use things like the NeoGeo multi-slot emulation you need to use the Software Lists, as it's also the only way you get the flexibility required to put different cartridges in different slots and run it like a real unit.

It's possible that things like bios selection may end up deriving from the software list type system too at some point in the future as it's currently very limited.  Things like the ability to plug in upgrade roms on the Gauntlet Legends sets are currently kludged into the bios system, but in reality could benefit from softlist style handling so the main bios ROM and upgrade ROMs can be specified individually.  (yes, it is a little pointless because there are sets with the upgrade already applied, but it allows people to use MAME as you would use the hardware if you owned it)

That's the other reason we're being very clear on this, if a frontend is going to claim MAME compatibility it has to be prepared, a lot of the features you're not seeing used extensively now probably will be in the future, even for the arcade drivers (you're already seeing it in cases like Virtua Racing, where the game could be linked via a serial port, and MAME now exposes this allowing 2 instances of MAME running on the same PC to connect to each other - that's based on tech / code straight from the PC drivers etc.)

[Howard_Casto]

Explain to me how trying to print a list of supported hardware is helpful when half of the hardware listed can't be ran and you instead have to add an additional variable (the game, software ect) and the only way to find out is to first try and run it. 

Go ahead and explain away how a documentation project finds it counter-productive to document things.

Hardware is NOT Hardware.  Some hardware you switch on and you are good to go while other hardware requires the insertion of media.  And among hardware that requires media, some of it  is designed to be swapped out a lot, like a game console, while others use the media as a glorified upgrade system, like cps3 or mvs.  And those aren't the only distinctions.... there are pc class hardware devices, where you can boot the thing up, but you really can't do anything without installing additional software  Surely you aren't suggesting that this distinction should be ignored. 

I've been doing front-ends for over 15 years, and for many years supported emulators that were intentionally made so that you can't use a front-end with them so please don't act like I'm trying to be lazy....  the emulator has to meet halfway on this and it's unrealistic to expect a front-end to update itself with every mame release because the mame devs find it "impure" to add a singular flag that states the type of hardware device it is, which, again would just better document things. 

In reality it's you guys who are trying to pass on the work.  It's quite easy to classify things.  Anything that takes money and has a video screen is a video arcade. Anything that takes money and gives you something back (or allows you to win something back) is redemption.  Anything that allows you to win money or currency that is meant to be exchanged for money is gambling. (Of course there is video gambling, e.m. gambling, ect.)  Things that fall in between?  They are hybrids with the various components tacked on like building blocks as sub categories. 

So to answer your question the popcorn machine would be:

Coin-op Hybrid:  video+redemption. 

There is no gray area when you are a programmer, you just need to categorize better or drill down more.  You of all people should know that. 

You are too hung up on that "arcade" distinction.  All I was trying to do was filter off systems that I can't run without additional software.  If I can't do that with the given reports then the given reports are inadequate and need to be changed.  I mean bios has a flag and rightly so because if you try to "play" a bios you usually can't even get mame to accept it.  It would be silly to print it out in a report without noting this. 

You should really learn a lesson in regards to the nag screens.  For over a decade users said they were dumb and don't serve any purpose.  Finally you remove them and act like all those cries of foul somehow didn't count but now that the mame team has come to that conclusion it somehow matters more.  Long story short the masses are usually right, just listen to them and save yourself years of complaints.

For the record I found a solution, it's a stupid round-about way but it will do for now.  I only responded because your mentality is hurting mame's documentation effort and that is counter-productive to the project.  Chips and processors and pcb's are not hardware devices, they are just a component.  Cases, controls, artwork, and the software, they are just as important.  So yes, categorizing the various hardware is vital to the project if you aren't willing to document the non-hardware side so that these supplemental components of the project can be easily linked.   

[Haze]

You should really learn a lesson in regards to the nag screens.  For over a decade users said they were dumb and don't serve any purpose.  Finally you remove them and act like all those cries of foul somehow didn't count but now that the mame team has come to that conclusion it somehow matters more.  Long story short the masses are usually right, just listen to them and save yourself years of complaints.

not really, they served a purpose, as I said they were removed because we now feel the project is on better legal footing; with the non-arcade stuff there are thousands more legal use cases we can easily point at.  This is not 'admitting we were wrong' or that the 'masses were right' it's moving with the times as the project has evolved.  The very same reasons are the reasons I'm now happy to relicense any code I've contributed as plain old BSD without the non-commercial restriction, there are more legitimate reasons why somebody would want to sell the software rather than it looking like we were in bed with those selling illegal MAME cabinets.

also, on the same subject, despite giving users some rope and taking the copyright nag away idiots here are STILL removing the warning screens telling you about imperfect emulation / non-working drivers.  Those screens are absolutely essential to the user experience, they're NOT nags, they exist so that people know when they're running a broken driver, those screens help us (avoid false bug reports), and help improve the user experience by letting them know to expect problems, so please excuse us if we don't especially care for your 'needs' either after years of complete disregard for ours.

yes, we're passing on the work, it makes more sense that way, people can categorize things however they want then, let somebody create an .ini file, import it into your frontend.

What we've basically seen over the years is that what most 'game players' want is simply a 'good game worth playing!' flag, so no, we're not going to listen to them, because that's the opposite of what the project is about; if it wasn't then we would have called it quits after emulating Pacman, NeoGeo, CPS, and Mortal Kombat.

I'm telling you what is happening, we don't categorize games into genres, we don't really need to categorize machine types either, some stuff is more difficult to use than others, that was always the case (some of the gamblers have really contrived setup sequences)  As I said, you're likely to see different ways of operating things like CPS3 in the future, where you do select the cartridges and CDs from the software lists etc. maybe the existing shortcuts to run the games will remain, maybe they won't, if they don't, how does it differ from a non-arcade system? we're making MAME into a more powerful piece of software, as a result there will be more of a learning curve, we're not going to be restrained by the third party software or make it easy for such software to ignore the progress.

With things like the lua scripting capabilities and other such enhancements like the web interface we've actually given more power than ever to people driving MAME from external programs with a view to maybe making the modern MAME experience a bit easier by allowing them to provide things like 'auto boot' scripts to the program which can be used with some of the non-arcade systems etc.

FWIW I don't think this is 'hurting' MAME, allowing ourselves to go too far down the 'games machine' path (just select a game and play) is exactly what projects like RetroArch seem to be trying to do, tie everything down to simple but incredibly limited concepts that can be operated using just a joypad on a console.  The strength of MAME is moving in the opposite direction to that, which is why we're never going to consider integrating a RA target officially, it just constrains what we can do; if somebody is doing a frontend for MAME they have to understand that MAME is an ambitious project and any frontend will require maintenance.  Simply looking for ways to try and filter out that need by only showing simple stuff isn't really the correct solution.

Since making these changes we've seen more contributors getting involved than ever, it hasn't hurt the project, it's revitalized it.

I get that you're not too keen on where things are going, but it won't be long before there really are as many different 'types' of things emulated as there are genres of game, if it has a CPU it is a valid target, and even beyond that some things without CPUs are valid targets too if a full schematic can be drawn up and a netlist created.  Trying to categorize things is not a job for the dev team, providing the emulator for them is.  Trying to categorize things in the past actually caused immense damage to the project and preservation efforts when we were actively excluding things we felt didn't fit in a certain category and people started scrapping them rather than dumping them.