vpinball
Easier to upgrade: Rename VPMAlias.txt
Many new and old users stuggle with the only file which should not just be overwritten when upgrading pinmame. If VPMAlias.txt is renamed to VPMAlias_template.txt in the installation zip files, one can safely unzip the whole content without overwriting content built up over months if not years.
Second advantage is that there will always be a VPMAlias_template.txt available as well which can be compared by the enduser, to amend new entries.
Maybe the only drawback is that new installations has to rename or copy VPMAlias_template.txt to VPMAlias.txt
But why should anybody enter its own aliases? Alias.cpp was thought to create a backwards compatibility for tables using ROM names before there were different versions of a set, so a game referenced as "lwar" in the table script would map to "lwar_a83". VPMAlias.txt extended this idea to support custom games on known sets.
@toxieainc should be notified of new games popping up so he can keep the list updated, which he regularly does. So I seem to miss the point why the file should not be overwritten by a new release?!
I think there is more to it. Some users use the VPMAlias to be able to have multiple DOF configs and altsounds (i don't use it personally this way, but i think this is not uncommon), so it can contain more than what we provide.
But why should anybody enter its own aliases? VPMAlias.txt extended this idea to support custom games on known sets.
I wasn't aware that this is also a builtin feature of VPinMame, though that should maybe be built-in and not as loose file hanging around. Many including me, use VPMAlias.txt to be able to use the same table ROM with or without pup's. Or make sure a mod uses a different name. So there many ways to use this.
Yes, vpmalias.txt is an ESSENTIAL part of many installations, mine included. It is used for all reasons JockeJarre said. It happened only once to me (in a weak moment) that I overwritten it with the "default" I was so glad I found a relatively actual backup in my (monthly) backup folder.
100% agree with JockeJarre !
But why should anybody enter its own aliases? Alias.cpp was thought to create a backwards compatibility for tables using ROM names before there were different versions of a set, so a game referenced as "lwar" in the table script would map to "lwar_a83". VPMAlias.txt extended this idea to support custom games on known sets.
Yes, as you say here, people use this as a place to put custom aliases, which is not part of the executable. Maybe it would be best to add those delivered in VPMAlias currently, into the executable instead and leave the VPMAlias.txt for pure custom usage?
Originally VPMAlias, was a feature added in order to ensure the VPinmame team didn't need to add new entries for every new rom reskin table to Vpinmame, itself.
https://github.com/vpinball/pinmame/commit/0a47705311bbff77a91284d619c759a305d2fa68
Prior to its introduction, table authors kept needing to submit requests to add yet another alternate name for something like Hollywood Heat, but vpinmame wasn't really the right place for it. But it looks like vpinmame team itself has also found use for the feature, to preserve backward compatibility. :)
Maybe a solution could be to allow vpinmame to read a second file, VPMAliasUser.txt that VPinMame can read and treat the same way. Then Toxie can maintain the official VPMAlias list while users additional customizations are kept safe in a different file that won't be overridden by updates.
Coming back to this issue... There is a built-in table Alias.cpp which is used when there is no entry found in VPMAlias.txt:
{ "eshak_f1", "esha_pr4" }, { "eshak_l1", "esha_la1" }, { "eshak_l3", "esha_la3" }, { "lwar", "lwar_a83" }, { "ssvc", "ssvc_a26" }, { "torpe", "torp_e21" }, { "tmach", "tmac_a24" }, ... cut ... { "swtril", "swtril43" }, { "jplstwld", "jplstw22" }, { "bnzai_p1", "bnzai_pa" }, { "gs_l4", "gs_lu4" }, { "gs_l3", "gs_la3" }, { "kpv106", "kpb105" }, { "mousn_lx", "mousn_l4" },
So I guess the VPMAlias.txt could be used for custom usage and use the built-in for core changes? Then my initial request to just rename the file to VPMAlias_template.txt in the zip file, could be supported?
This means VPMAlias.txt wouldn't be overwritten each time you unzip the package.
@toxieainc as there is a built-in Alias.cpp, wouldn't it be possible to update alias.cpp for "core" aliases and rename VPMAlias.txt to VPMAlias_template.txt? Then pinmame should use the internal Alias.cpp + a personal VPMAlias.txt (which is maintained by the enduser) -> This is how it works now, first checking VPMAlias.txt and then the internal table. It would mean that VPMAlias.txt, which is maintained by the enduser, would override entries in the internal table.
If you are ok with this, I can update the internal table with the entries from VPMAlias.txt and then rename it to VPMAlias_template.txt? It would still be of interest to keep the internal table up to date with VPMAlias_template.txt though.