minor json file format issues

[stojy]

These are pretty minor, but figured you might want to know/investigate/fix..

• spyhunter rom year is wrong.. showing as 0213 instead of 2013. I noticed because it was (but since fixed) caused some grief with the unix time conversion.
• Game.Theme and TableFile.Theme - perhaps should be renamed Thems (plural) for consistency with your other arrays
• WheelArtFiles - there's no way to distinguish between the 'transparent' and 'circle' items? Perhaps the Name property could be used?

Plus a general observation.. the multiple AC/DC entries in the VPS are now merged into a single entry in the json which makes it impossible(?) to identify the different AC/DC tables are identifiable now? e.g. Luci vs Helen vs Pro Fault. Perhaps this was deliberate though as part of a cleanup.

[Fraesh]

Hey!

Thx for the rom year. Will fix that. For the theme/s, sure I can add the "s" :D.

On a general note: Ive taken the export from Dux original sheet and kind of converted it into this json structure to begin with. BTW theres also typescript interfaces if you need them :). Since Dux sheet wasn't typed in any way though, it definitely has some edges to it that need rounding out. Like the date typo f.ex :P For the AC/DC, yes I have merged them in the cleanup process, maybe it was a bit naiv :D

I havent had time to test them all so I actually dont really know how they differ. The differentiation itself is still for debate by the way. From a "clean up your DB!!" perspective I want similar tables under one entry, especially if its just like a skin or lighting mod. If the gameplay is redically different though, they should be split at some point while still referring to one another. Im planning to introduce a reference to another game for these kind of situations in the future. Still thinking about it though.

Thx alot for the feedback! If you want to cintribute to the project, I'll happily invite you to the party :)

[stojy]

HI

ROM year - looks a lot happier.

Theme/s label - I'll check out the theme/s rename when you're ready. No rush :)

Table consolidation/groupoing - it's a tricky one. It's something I've been thinking about for my ClrVpin project and how to join the PinballX and VPS DBs. Perhaps you consider it along these lines of whether the change is a fork?

• Not a fork: the tables can be merged since the newer table supercedes the older version, e.g. same author, lighting changes, better models, etc.
• Forked: don't merge the tables as both tables are valid and may be played independently, e.g. black and white mod, different development streams/authors working on the same table (I think a few JP tables fall under this category), etc.

At any rate, I suspect AC/DC tables should be probably unmerged as they are actually referring to unique physical tables, i.e. different IPDB ids. https://www.ipdb.org/search.pl?name=acdc&sortby=name&searchtype=advanced

Most of my "free time" is being soaked up with the ClrVpin work, but for sure happy to help to contribute. Especially when it comes to the data modelling :)

[Fraesh]

Ye if they have a seperate IPDB they should definitely be split. Ill take IPDB as my source of truth ^^ For the B&W for example... Well i guess Ill leave that decision to Dux :D I'd put them under the original but if you guys use the DB differently it has to be good for the user.

One example would be Christmas mods. Ive added a seprate theme to the tableFile itself to make those usable. So we can put South Park Xmas under the Sourth park game as it is exaclty the same table, full-text search will spit it out though if you search for "christmas". Same pattern i would've applied to B&W mods for example, makes everybody happy :P But then again, im too far into the code, UX decisions should be made by someone closer to the people (aka Dux in this case)

[stojy]

I understand. Putting the mods (e.g. B&W, christmas, etc) under the same entry sounds very reasonable. So long as the mods table/directb2s/etc are individually retrievable (via the same parent entry) with it's own 'updatedAt' timestamp then that should be fine.

If it's ok with you, to make it easier to track i'll keep this issue open pending the changes..

• append "s" to theme entry
• split those ac/dc tables into separate entries which have unique IPDB
• WheelArtFiles - add something (e.g. fill Name property) so they can be identified as eithr 'transparent' or 'circle'

No rush of course.. I'm just super happy to have a nice json object to work with :)

[Fraesh]

Hey again :D thx for the feedback, really appreciated. Glad you find the data usable :) Sry for the lack of updates in that regard. busy week, end-of-year wrap up at work. Next week starts PTO though 💯

For the wheelart, im not actually sure how wed wanna proceed with that. So from my perspective, I dont care much. The code is added quickly. Now that i have image hosting in place, best would be to add the image itself I guess :D On the other hand, someone has to moderate the content which is again a lot of work.

Then again, most are hosted on nailbusters server anyways, arent they? I always use the popper media loader so never used the downloads personally... It would be on dux or "the community" to decide on further support for wheel art or just leave it to Popper for the time beeing. Need more contributers!!

[stojy]

No worries at all. Bring on the xmas break!

Personaly, I've shy'd away from pinup popper preferring to rely the open source community for everything when it comes to vpin (e.g. PinballY front end). So for myself at any rate, knowing the wheel type is transparent (vs the circle format favoured in popper) would be a nice feature to have.. but not a big deal though given how infrequently they're updated anyway.

[Fraesh]

That actually makes sense, havent thought about that at all :) I guess with the thumbnail, you'd easily see the transparancy aswell as what youre getting so that would be best? Or do you need the datapoint specifically for the way you handle it like filtering and such? Maybe its not a bad idea to keep them, given the black box nature of popper.... good call. Lets see if well find a maintainer :D

[stojy]

Open source for the win :)

The wheel thumbnail is definitely good for a manual check. But with ClrVpin, the intention is to automatically detect ouf of date content (based on the UpdatedAt timestamp) with a filter on wheel type 'transpraent' vs 'circle'.

Hopefully once it's defined in the json (perhaps using the existing Name property which is currently null i believe).. there won't be a lot of maintenance required as they rarely(?) change.

[Fraesh]

Thats a cool feature! So with transparent/circle, i guess you mean the ones that are in the well known format and ones that are just transparent graphics? They are technically all png if Im not wrong :D So basically a boolean "Circle" would be enough to identify them as the standard circle. I could use the name but its not right and you'll end up with spelling errors. Beauty of the json is that i can modify the shape as needed :P

For the maintainance, i mean we have >1300 tables so far and the wheelart is not even close to beeing indexed completely. So even if its just a checkbox, that means like 2000 checkboxes to be set aswell as upkeep whenever new wheels come out, additionally to all the other files. Hopefully i can automate some of this stuff at some point but given the nature of uploads, I fear it will always be manual labor... If data was uploaded with correct relations we wouldnt need vps in the first place >.<