Stupidly Smart Idea for a Visual Pinball Utility (need opinions)

[Howard_Casto]

Visual Pinball has annoyed me for years.... there's no standardization.  Even when they added mp3-like tags to the file format, authors refused to use it or use it properly.  The short of it is that it makes it quite difficult for front-ends to determine the proper name for artwork files and for users to make artwork packs.  I tired to deal with it and eventually left it alone because it was a hopeless cause. 

Some recent additions to mame have made me re-think this though.  You see mame now contains all the roms that pinmame does and I'm assuming it will from now on.  As we all know it is MUCH EASIER to manage artwork packs for mame due to name standardization.   So at least for tables with pinmame roms, I can now writie a utility to parse a vpt table and report it's pinmame rom!

You see every single pinmame vpt has a line with:

 .GameName= "rom"

This is where the rom is loaded.  Now it isn't as simple as that... some tables allow you to choose the rom.  That is still do-able though... in the first search through the file, you'll get:

.GameName= variable

Because it isn't in quotes we know that it isn't a rom name (strings must be in quotes).  So now we have the variable name and we can search again, only this time we search for:

variable = "rom"

And poof! One of the romname's are returned.  Of course we don't care which... once we get one of them we can retrieve the proper, parent rom via a call to mame.


Long story short I want to write a command line utility that you can feed in a vpt name (or a "*.*" for all tables) and it outputs a catver style ini file with the rom/vpt relationship.  It actually reads the code in the table on the fly, so unlike some of these dats out here, it would always work.  Then the front end can use this data to get the table info from MAME and NOT VP..... which means standardized artwork and game info. 


Is this a good idea?  Would it be used by fe authors? 

I know that progretto's mame artwork packs already contain the flyers, cabinets and backglasses for the tables, so I guess all that would remain would be some screenshots. 


I know this wouldn't solve the issues with regular pinmame tables... but non-pinmame tables seem to be ported over to the superior future pinball at an alarming rate, so I'm not sure how much of an issue it would be. 


Anyway, I want to release some other apps first, so it's just a thought, but let me know. 

[drventure]

Sounds like a good idea, but I'd be far more qualified to make comments once I've gotten back into getting VPin and Future Pin operational on my cabinet. This is one of those things that you don't really understand until you've tried to do it yourself.

The only comment I might make is to make the output XML such that it could (potentially) but a master pintable metadata collection point.

Maybe that's too ambitious though...

[headkaze]

PleasureExtractor is the closest I ever got to sorting out the pinball rom mess.

[Howard_Casto]

Sounds like a good idea, but I'd be far more qualified to make comments once I've gotten back into getting VPin and Future Pin operational on my cabinet. This is one of those things that you don't really understand until you've tried to do it yourself.

The only comment I might make is to make the output XML such that it could (potentially) but a master pintable metadata collection point.

Maybe that's too ambitious though...

I'm really not sure what the point of making it xml would be.  The info on these games is already stored in mame, all we need to do is link the table name to the rom name and vice versa.  An INI would be infinately quicker to parse and then you just go to the proper entry in the good old listxml generated by mame.

HK:  Yeah I had similar utilites back in the day.  I ran into the same problems as well, namely the archivers were insaine and didn't know what they were doing.    I never did manage to figure out a reliable way to figure out which table is the latest  (there isn't even standardization in version numbering), but luckily more recent torrent collections only include the latest versions, so it isn't as much of an issue anymore. 

I'm done with [romsite name redacted] myself.  The way the uploading works with my cable company I simply can't maintain the ridiculous seed ratio they require and even if I could, my favorite torrent programs seem to screw up the reporting anyway.

[Space Fractal]

I did similar utility too long time ago, it's was futurepinball in mind, but visual pinball seen do same thing:
http://forum.arcadecontrols.com/index.php?topic=86953.0

not a ripoff of headkaze, since I did that by my own.

It's also trying to guess the newest version of various format, but might fail on few tables.

[Kangum]

Sounds like a good idea, but I'd be far more qualified to make comments once I've gotten back into getting VPin and Future Pin operational on my cabinet. This is one of those things that you don't really understand until you've tried to do it yourself.

The only comment I might make is to make the output XML such that it could (potentially) but a master pintable metadata collection point.

Maybe that's too ambitious though...

I'm really not sure what the point of making it xml would be.  The info on these games is already stored in mame, all we need to do is link the table name to the rom name and vice versa.  An INI would be infinately quicker to parse and then you just go to the proper entry in the good old listxml generated by mame.

HK:  Yeah I had similar utilites back in the day.  I ran into the same problems as well, namely the archivers were insaine and didn't know what they were doing.    I never did manage to figure out a reliable way to figure out which table is the latest  (there isn't even standardization in version numbering), but luckily more recent torrent collections only include the latest versions, so it isn't as much of an issue anymore. 

I'm done with [romsite name redacted] myself.  The way the uploading works with my cable company I simply can't maintain the ridiculous seed ratio they require and even if I could, my favorite torrent programs seem to screw up the reporting anyway.

*removed

[Howard_Casto]

It isn't a matter of limits, it's just a matter of bandwidth.  Typically your upload bandwidth is MUCH LOWER than your download BW.  This means you are already fighting an uphill battle. 

My download speed is 5-10Mbps, depending upon the time of day.  My upload speed is 1Mbps, BUT because of the way cable works, my internet access slows to a crawl if I allocate more than around 5-10 KILO-bps for uploading.  So if I want to upload at any real speed, I pretty much can't use the net. 

So [romsite name redacted]'s ratios just aren't realistic imho.  Let's say I spend an hour downloading some files.  Well now it will take a minimum of 5 hours for me to get the ratio back up, realistically it'll be more like a day or two if I want to actually use the internet while I'm doing it. 

[Howard_Casto]

Ok I wrote a quickie little app to test the concept... it works really well!  I don't have a lot of tables anymore, but I was able to pull the rom name out of every pinmame table I tried!  Also progretto has done an amazing job keeping mame's artwork up to date.  Even though none of these games work in mame yet, I managed to find flyers, backglasses (saved as marquees), and cabinets of each of my tables... which was the goal... no more annoying art packs!

But upon downloading tables I ran across something odd.  I downloaded the latest Freddy table and the game wouldn't insert credits.  I looked at the files that came with it and there was a nvram file BUT it was named after the table and not the pinmame rom.  That seems really really dumb to me... afterall how is pinmame supposed to know the table name?

Or is it something else entirely?  Do vpt files now support some form of nvram?

My little utility could easily fix this seeing as how it gets the rom name.  I was going to include a feature to rename the snaps anyway, so checking for and renaming nv would be trivial. 

[Gray_Area]

It isn't a matter of limits, it's just a matter of bandwidth.  Typically your upload bandwidth is MUCH LOWER than your download BW.  This means you are already fighting an uphill battle. 

My download speed is 5-10Mbps, depending upon the time of day.  My upload speed is 1Mbps, BUT because of the way cable works, my internet access slows to a crawl if I allocate more than around 5-10 KILO-bps for uploading.  So if I want to upload at any real speed, I pretty much can't use the net. 

So [romsite name redacted]'s ratios just aren't realistic imho.  Let's say I spend an hour downloading some files.  Well now it will take a minimum of 5 hours for me to get the ratio back up, realistically it'll be more like a day or two if I want to actually use the internet while I'm doing it. 

By which time they might shitlist you because you didn't seed quick enough. Maybe it was my torrent client's fault (it was my first foray into using one, but) I haven't bothered with PD for years.

VPLauncher, and I think VP-Man, had some way of identifying tables and art files that was awesome. Nobody's ported it or anything.

[Kangum]

I have noticed considerable slowdown when surfing and uploading. so I understand where howard is coming from. my upload is alot higher then his and i still experience the slowdown. so if it was that much lower it could really be a problem.

[Howard_Casto]

It isn't a matter of limits, it's just a matter of bandwidth.  Typically your upload bandwidth is MUCH LOWER than your download BW.  This means you are already fighting an uphill battle. 

My download speed is 5-10Mbps, depending upon the time of day.  My upload speed is 1Mbps, BUT because of the way cable works, my internet access slows to a crawl if I allocate more than around 5-10 KILO-bps for uploading.  So if I want to upload at any real speed, I pretty much can't use the net. 

So [romsite name redacted]'s ratios just aren't realistic imho.  Let's say I spend an hour downloading some files.  Well now it will take a minimum of 5 hours for me to get the ratio back up, realistically it'll be more like a day or two if I want to actually use the internet while I'm doing it. 

By which time they might shitlist you because you didn't seed quick enough. Maybe it was my torrent client's fault (it was my first foray into using one, but) I haven't bothered with PD for years.

VPLauncher, and I think VP-Man, had some way of identifying tables and art files that was awesome. Nobody's ported it or anything.

Wow a swear word slipped through! Awesome! 

Actually they didn't have a method of identifying tables and art.... it was a mess.  There was this ini you see, and they manually created it.  Basically it would list a vpt name, followed by all of the names they've ever encountered it being, as well as all of the names they've seen the artwork for said table being named as.  Now it worked, and worked well, but you had to do special coding to support the ini and it was outdated almost immediately upon it's release.  Eventually they stopped updating the dat because it was a buttload of work.  Regardless, I don't think it's the best way to go about things.

Aside from the method I suggested there are id3 tags in the tables, so I suppose they could be using those.  I've downloaded several tables though and the tags are almost always blank.   

I've been really busy with real-world stuff this week.  Hopefully I can work on this after tomorrow. 

For pinmame tables at least, mame's inclusion of the roms is pretty exciting.  It also means that you can stop downloading pinmame roms... they are in your mame set.  Basically it means less duplicates.  This seems to be a growing trend.  Even the emulators that run games mame can't use the roms in the mame set.  It means that aside from the odd pc game or console emulator, you can just maintain your mame roms and artwork and use it for everything else.

[Gray_Area]

Wow a swear word slipped through! Awesome! 

Actually they didn't have a method of identifying tables and art.... it was a mess.  There was this ini you see, and they manually created it. 

For pinmame tables at least, mame's inclusion of the roms is pretty exciting...It means that aside from the odd pc game or console emulator, you can just maintain your mame roms and artwork and use it for everything else.

What?...through the sensor, or from me?  That's what they call it, so I was just repeating.

I haven't done a serious upgrade of VP tables in a while. But I like your idea.

[Howard_Casto]

Just an update:

I went ahead and made a command line app that generates an ini file with the vpt=rom relationship.

Thus far it works perfectly! 

I'm going to make a really lame, "windowsy" front-end to show it's usefulness as a sort of proof of concept. 

Then I'll let you pinheads run it through it's paces.  You'll need a folder full of tables, mame .143 or higher and progretto's art packs for .143 or higher.


So if anybody meets those requirements let me know.  I should have a front-end ready this weekend and I'll go ahead and release it.

[dna disturber]

Hi howard,

I'm using the pretty name of pinmame to get the romname.
When you start a table, there is a window with the pretty romname.
In an inifile i have all the pretty romnames and what their romname counterpart is.
Disadvantage of course is that you have to start a game (once) to know what the romname is.

Also there is an option in scripts dmdhide, used in alphanumeric games to get the position right from the displays.
If the conversion above doesn't work i use filelastaccessed in the nvram directory to determine the romname...

Works great...

I use this in pinemhi leaderboard
Even if people change their rom in the tablescript it catches it.
http://www.vpforums.org/index.php?showtopic=16572

Not sure if this is useful to you but who knows....

[Howard_Casto]

Are you referring to the Game Name?  As in the caption on the pinmame dmd window
(if you were to turn on the title bar of course)?

I'm a little confused by your terminology.


If it's something other than that we should be able to pull it out of the table via parsing anyway....  99% of a vpt is just vbscripting and thus it's plain text. 

Let me know a little more what you are talking about and I'll see what I can do.

[Howard_Casto]

Ok I downloaded it.  I'm not sure what you are using that stuff at the top for...  looks scarily like the old vplaunch database. 

As for the stuff at the bottom, yeah it's helpful, but because can easily be outdated I'm not so sure that is the best way to go.  Let's say that I parse a table and determine that the rom used is "granny".... I can then call mame via "mame.exe granny -lx" and get not just the game name, but the release date, the manufacturer, ect....

If anything I think your project could be helped by mine.  Although pinmame rom collections are fairly stable, with my method you wouldn't have to worry about it anymore.  You also wouldn't have to launch a table first to get the romname.

Regardless, you have inspired me for a method of determining a table name if it is NOT a pinmame table, so thanks!  I'll keep you posted.

[dna disturber]

I think you're right about your project that it could help mine.
It sure would be great to just read roms out of the tablescripts...
I also have a commandline program that can read hiscores out of nearly all roms...
This program could be used by frontends using your retrieval method....
www.pinemhi.com

How do you go about the tables with a menu to select which rom you would want to use?
Don't you get multiple roms out of that table?

Good thing that you managed to figure out my mumbo jumbo....


The nvram with freddy by the way is the same as with more gottlieb tables.
Certain values must be in the nvram otherwise it won't work properly..adding credits
That's why there was an nvram in the zip i guess.....name should still be the same as the rom....
You can solve it by going into servicemode and perform certain tasks but an nvram that already works is of course easier.

I' ll certainly keep an eye on this thread...and thanks for all your hard work for the community 

[Howard_Casto]

How do you go about the tables with a menu to select which rom you would want to use?
Don't you get multiple roms out of that table?

Yes but I ignore them.  For my purposes I just need the parent rom.... that's easy enough, it's usually the first one defined.  It isn't an exact science, but thus far I've yet to see it fail to pull a valid rom name.  It's explained how I pull it earlier in this post.


It would be possible to grab them all as an option though but I'm not sure that would be particularly useful.  Afterall, much like getting the extended table info via  mame call you can also get a list of all clone roms via a mame call (mame.exe rom -lc)


Since you are more active in the vp community than I am maybe you can help me find some info.  You know the "Table Information" section within Visual Pinball?  It was my understanding that you could parse that data similar to how you read a idv3 tag on a mp3.  I've looked high and low though and I've found no data on how to parse it.  I could probably reverse engineer it, but that would take forver.   

The info inside a table is typically junk (unlabeled or labeled wrong) but many tables do include a snapshot, so I would like to be able to extract it and name it after the rom. 

[dna disturber]

How do you go about the tables with a menu to select which rom you would want to use?
Don't you get multiple roms out of that table?

Yes but I ignore them.  For my purposes I just need the parent rom.... that's easy enough, it's usually the first one defined.  It isn't an exact science, but thus far I've yet to see it fail to pull a valid rom name.  It's explained how I pull it earlier in this post.


It would be possible to grab them all as an option though but I'm not sure that would be particularly useful.  Afterall, much like getting the extended table info via  mame call you can also get a list of all clone roms via a mame call (mame.exe rom -lc)


Since you are more active in the vp community than I am maybe you can help me find some info.  You know the "Table Information" section within Visual Pinball?  It was my understanding that you could parse that data similar to how you read a idv3 tag on a mp3.  I've looked high and low though and I've found no data on how to parse it.  I could probably reverse engineer it, but that would take forver.   

The info inside a table is typically junk (unlabeled or labeled wrong) but many tables do include a snapshot, so I would like to be able to extract it and name it after the rom. 

I need the exact rom of course to read out the right hiscores but for the purpose of matching names to snapshots etc it really doesn't mather as one of the roms is enough to get the gamename...i understand....

I'm afraid i can't help you with the table info...i really don't know anything about that part....
Maybe someone else on vpforums.org would know...

[Howard_Casto]

Why would you need to know the exact rom?  Couldn't you simply read out all of the high scores from any potential rom nv?

[dna disturber]

Why would you need to know the exact rom?  Couldn't you simply read out all of the high scores from any potential rom nv?

But i would still have to link a hiscore to the game just played.
And with several different scores i don't know which one it is...unless i use lastaccess timestamp or another method.

Pinemhi leaderboard lets you play a game... catches your score and then submits it to a database.
Containing the player's name , table , rom used, timestamp and score of course.
Also the special scores as loop champion are in....

[Howard_Casto]

I guess I would have to see the internals of how the nv save the scores or something.  I wouldn't rule out usage yet though.

In regards to my project things are progressing nicely, but I've ran into one or two hiccups due to pinmame only being updated once a century.

Since the big agemame/pinmame/mame merge  a few pinmame roms had to be renamed due to conflicts.  There are very few.... the only one I've ran across thus far is startrek (renamed in pinmame to startrep).  The roms have been renamed, but the tables still call the original rom name and thus it pulls the artwork for the video game, not the pinball. 

Now my test FE allows you to edit the ini entry and likewise the command line app doesn't overwrite anything that you've edited so long as you don't force an overwrite so it isn't THAT big a deal, but until pinmame gets it's ducks in a row there might be one or two name conflicts.

[Howard_Casto]

Ok just an update. 

I never thought I would do it again, but I guess I'm writing a new pinmame wrapper. 

I kind of got disgusted with the vp scene, namely because they seem to intentionally make the programs as user un-friendly as possible.  A lot of this had to do with vp an pm being closed source for the longest time.  So when they finally opened them up I thought  "Great, all of this will get fixed!  I'll wait a while, come back and you'll just be able to launch a table."  Boy was I wrong!  It has bee more than a year and they still haven't gotten to the most basic things like getting a table to properly launch via command line.  (In other words, you don't see the editor table, the dmd properly layers itself and when you press the exit key the whole thing closes.) 

PinMAME is even worse.  It comes with an ini folder and yet it doesn't support ini files!  All of it's settings are STILL saved in the registry, even stupid settings that don't apply to pinmame like vector options.  They've also changed the renderer, so now I can't move/resize the dmd window programatically.


So my new rom name extractor will be getting some use.  In order to resize and center the dmd, I'll have to first parse the table to get the rom name and set the proper settings in the registry prior to launch.

Stay tuned.... this might result in me sending source code to the vp guys. 

[headkaze]

Why write a new "wrapper" if they've opened sourced the code? Surely downloading the latest source and modifying it to add command line and ini file processing support would be the better option. Once done send them off a diff.

I'm not sure what language it's in but I can help work with you on adding these features.

[Howard_Casto]

Well I'm definately going to submit stuff to get the tables to launch and exit via command line... that much is certain, but the real issue is that things are fundamentally wrong on two or three levels.

PinMAME: 

Why do we still have pinmame again?  There are only like two or three pinball specific things added to pinmame at this point.  All that would be needed to eliminate it completely would be to add an input system to mame (should be possible via a modification of the output system), a dmd "artwork" routine similar to the segmented displays already in mame and one or two window positioning options.

BUT assuming that doesn't go pinmame needs to at least be modified to quit reading and writing settings from the registry.  If it used it's ini files properly, for example, those could be easily manipulated and changed on the fly.

Visual Pinball:

Aside from launching issues  there are issues with the pinmame com interface.  Weather or not the dmd window gets proper focus, positioning, and layering all depends upon how the scripting was written for the table.  It shouldn't.... that part at least should be automatic.   This has a lot to do with the fact that the com interface doesn't expose enough options for the author and vp relies exclusively on the com interface for positioning.  You can set the x and y value of dmd, if it's compact, double or regular sized and if it's visible.  That's it.  No layering, no exact dimensions, nothing. 

The only way you can change those values without dragging the window with the mouse is to edit the registry.  But sizes aren't in percentages, they are in absolute pixels, meaning you need to know the resolution of the game before you change things.  This is a problem because there isn't any way to call visual pinmame and get the resolution, you have to run a game and let it write the values first.  What's worse is the fact that the "official resolution" is never written to the registry, so if you've used a double setting or manually distorted the window there is no way of knowing.

To make matters worse, table authors don't take advantage of the tools they do have.  Take Granny and the Gators and Baby Pacman as examples.  They have those video screens up top and the tables are designed to give a specific place to position the dmd window.  You would think that they would at least move the dmd into place right?  Wrong... they have a black bitmap in the middle of the table with a message "drag dmd here".  Wtf man?


So yeah, some stuff we can fix, but we would be opening a big can of worms if we fixed all the things that really need done to make vp/vpm cabinet friendly.  That's what I'm scared of.... I dont' want to spend the next year of my spare time working on pinmame. 

[Howard_Casto]

Ok grouchy old man rant aside.....

I got the command line app finished pretty much, along with the fe.  The only thing the cl utility can't parse are protected tables where the script is protected.  Other than that it works without a hitch.  I'm going to wait until tomorrow to release a test version because I want to add "alias" support to the app to help address that issue I mentioned before about a few roms having different names than the mame version.  Basically there will be an "alias.ini"  and you will be able to define things like "mamerom=pinmamerom". 

This is a temporary measure.  As pinmame gets updated  I've got to imagine that they are going to change over to mame's naming convention.  Heck if I end up having to work on pinmame's source then I might change the romnames personally. 

[Howard_Casto]

I haven't forgetten about this, I've merely been testing the rom name grabber extensively. 

Apparently the scripts in vp tables are case insensitive, so that throws a monkey wrench into the works.  I compensated for it, but it was just something unexpected.  Also I found that some of these "MEGAPIN" tables set the variable defined in .gamename to an array.  So I had to add a third pass to parse any arrays. 

So yeah, the parser is getting just a tad complex, but it still isn't super bad and I've been able to fix for any undetected tables thus far.  I want to download a few more tables to test and my dl limit is maxed for today, so I'll try for a release sometime this weekend.

[Howard_Casto]

Heh.... everytime I think I've got this thing working I run into another oddball thing I need to compensate for. 

I had to add in source code to remove comments from the data when parsing as a few authors commented in the full game name next to the rom.  I think I've finally got it licked though.... expect a release tomorrow...err.... later today.

[Howard_Casto]

I got some soruce code from the guys over at vpforums that shows how to read table info and extract screenshots.  So I'm going to implement that today and make this a one-stop command-line app for dealing with vp files.

[Howard_Casto]

Man I've spent more time on this than I ever intended!

Ok, I've gotten the command line utility to also parse table info data and extract screenshots. 

So to just to give a short overview of what the utility will do.... running vpInfo.exe "table.vpt"  will:


1.  Parse the scripts inside the table to see if it uses pinmame roms, and make a "filename=rom" entry in the "PinMAME" section of names.ini

2.  Parse the Table Info insde the table to get the table name and make a "filename=tablename" entry in the "VP" section of the names.ini

3.  Use the "rom" variable found in step 1 to generate a listxml for the game via calling mame or pinmame and make a
"rom=Name | Manufacturer | Year | Parent" entry in the "PinMAME" section of info.ini

4.  Use the "tablename" varaible found in step 2 to make an entry in the "VP" section of info.ini in the format
"tablename=Name | Author | Table Version | Release Date | email | website"

5.  Extract rules, blurbs and descriptions and save them as text files named after the tablename in the appropriate folders.

6.  Extract embedded snapshots and save them as jpg named after the tablename in the appropriate folder.



Why no xml output?  Why get the data from two places and store it in two inis? 

Well Visual Pinball is complex to say the least.  I'm not sure that an xml file would be helpful.  For example, crcs are useless due to the editable nature of the tables.... you have potentially three table names (the file name, the name found in table info and the name found in mame's listxml) and no way of knowing which one is best. 

If anyone wants to propose a xml format I'm all ears, but keep in mind it would be totally useless for rom managers due to vp's unique nature and instead would be used for front-ends.


I'm also thinking of renaming the vpts, to match the rom if available, the tablename if it isn't and finally leave as-is if neither is available. 


I would like some feedback please.

[spoot]

Just curious at the moment....what language you write your utility in?  Working on a db myself that lists all roms supported by mame/mess (in theory) with corresponding info........it's at 560,000+ records so far.   

[Howard_Casto]

Good old vb6. 

Visual basic is quite good at string manipulation and considering I basically have to parse the vb scripts inside the table to get the rom name, it works pretty well for this purpose. 


I didn't realize that mess actually outputted rom info... I thought it only outputted system info (like info on the nes, ect...)  or at least the last time I messed with it (which as admittedly years ago) the roms it did recognize were far from a complete list.

[spoot]

I didn't realize that mess actually outputted rom info... I thought it only outputted system info (like info on the nes, ect...)  or at least the last time I messed with it (which as admittedly years ago) the roms it did recognize were far from a complete list.

It doesn't.....parsed the xml's from the mess wiki.

[Gray_Area]

Howard, maybe you want to give the VP folks a call, and start a real revolution. Bring in everybody under one tent.

[Howard_Casto]

Howard, maybe you want to give the VP folks a call, and start a real revolution. Bring in everybody under one tent.

Well I've tried that  a couple of times and it didn't go so well.  Maybe it's me... I'm not exactly the best negociator in the world, but generally what happens is we talk about all of these changes that need to be made and most people are on board with it... until I get to the part where all the table authors that are still active need to go back and modify their tables to conform with the new standard..... then you can hear crickets. 

Then there are the authors themselves... obviously you have to have 100% on board or it won't work.  The only way around that would be to modify vp make the table info section mandatory... even then that doesn't guarantee that the info inside is accurate. 


This utility is a stop-gap really. 

Asuming they'll let me (apparently the open source vp still isn't completely open source.... ugh) I intend to modify visual pinballs code a little to help with loading and information storage.  Even then it still won't stop the most basic issue of authors naming their vpt files wrong.  It's been around 10 years and people still give vpts nonsensical abbreviations for names knowing that most front ends use the file name as the game name if a dat file isn't available.

[Howard_Casto]

Ok guys.... try this:

http://dragonking.arcadecontrols.com/files/vpinfo1.0.zip

I made a little front-end so people could understand how this type of thing would be useful.  Click on vpfe.exe and read the prompts carefully to set it up.


Also since sometimes it's hard to understand something without pictures, here are a few to understand just how this type of info is useful:

Here is the typical info you can get from a non-pinmame table:

http://img688.imageshack.us/img688/1337/4mbc1.jpg

4 million b.c. has a really nice internal shapshot as shown here.... note that my command line utility is doing all the work, the fe doesn't have to parse the tables.

http://img822.imageshack.us/img822/5715/4mbc2.jpg



And here comes the real purpose of the utility:  Note how much more info you can get if it's a pinMAME table and you know the rom name:

http://img580.imageshack.us/img580/5438/elvira1.jpg


And just to push home why this is useful....  I simply pointed the fe to my mame artwork path and was able to get the following art for this table... no custom pinmame art pack or anything:

http://img100.imageshack.us/img100/5156/elvira2.jpg

http://img713.imageshack.us/img713/1214/elvira3o.jpg

http://img577.imageshack.us/img577/1760/elvira4.jpg

So we got that much just by knowing the rom name!



Also on the pinmame front, I re-activated some old functions on my wrapper.  Check out the DMD:

http://img838.imageshack.us/img838/8584/cueball.jpg


Nothing fancy was used to get this effect... I just color-keyed black using set window layered attributes.  I can instead/also make the whole dmd translucent as well.  The reason I disabled it is because back in the day, it caused issues with some operating systems.  Considering people will be running a minimum of xp- sp2 at this point, it is no longer an issue.

These are effects that pinmame could do internally though.  I really need to see if they'll let me play with the source.  PinMAME desperately needs ini support, support of layered effects like shown above... artwork support, and output support so the backglass can simply be a artwork file instead of resorting to madder methods when running pinmame on a dedicated monitor.