Home Page Forums MAME QMC2 Questions, suggestions or requests topic

Also, there are plans to use a database for things like these and other stuff, meaning that the data could be queried on demand w/o uselessly filling up memory... but that's not yet on the road map .

Note that all the "missing" data from -listxml is basically already there, it's just usually not fully processed. It is, however, already "queried on demand" and displayed in a tree below each game/machine item (in the "full-detail" view only). This process is currently very expensive because the data is searched for in the "raw" -listxml output, and given the many new systems added to MAME within the last year or so, it's no longer "the best approach" to be honest. Anyway, that's the main reason why I can't provide this data as system-notes macros right now.

No.
I'm talking about CPU, Video, Sound and driver information (which I thought that are available for frontends since MESSUI use for create some filters).
Not EmuInfo nor MachineInfo (nor xml new info).
Just open MESS/MAME and [TAB] and choose System/Game Info
These kind of information, hehe

Not only to sho this information, but for example, wioth this information, I know that the source code for this system can be found in http://mamedev.org/source/src/mess/drivers/snes.c.html
Also, System that use Samples show "Sample" in sound information.
Also, system that don't use screen show Video: none.
Etc. etc. etc.

Also, these informations are very interesting too

People go to a lot of effort to make sure they never learn any of that information while playing MAME

Regardless, I think everything on that screen is in -listxml and should be available to QMC2.

Right, all of this is available, just right now not in a way suitable for what Shideravan wants it for...

Ok, if isn't possible to separate the informations in blocks for use that way, at less have this info to show at same way that´s in System Info could be very useful too!

Also, if it's possible the show the status of flags like "GAME_SUPPORTS_SAVE", "GAME_IMPERFECT_GRAPHICS", "GAME_IMPERFECT_SOUND", etc. could be very useful also, for all the users
That will mean, for example, that some messages like:

# "THIS GAME DOES NOT WORK PROPERLY"
# "THE SOUND EMULATION IS NOT 100% ACCURATE"
# "THE VIDEO EMULATION IS NOT 100% ACCURATE"
# "THIS GAME LACKS SOUND"

WILL appear on the screen, and can avoid the users get a ROM or CHD for a game that don't work properly...
ALSO means that project member already know that these problems exist!

I agree, but it will take a bit of time... once the database mentioned above works, you should be able to "SQL-query" any information you'd want directly from JavaScript .

Don't need to hurry, take your time
All time that you take reveals a great work in final

Sure .

The first step will be to "design" the data model and create/update the DB seamlessly in the background (whenever the XML cache changes)... then I'll use it internally in the areas where searching the data currently hurts... and when that's working it's time to allow DB access through JavaScript in system-notes templates.