Jump to content


  • Posts

  • Joined

  • Last visited


0 Neutral
  1. You're right. I did not pay attention to that since i'm not familiar enough with the preferences of the community and the will to change. Now how do we solve this? Do we need to solve this right from the start anyway? Vpdb.io support as i sketched it out seems to be such a great addition, i would just risk to try it out and see if it grows over time. (But that's just my opinion)
  2. The more I look into vpdb.io the more excited i get. It looks perfect to me - not only in the context which we're talking about - but perfect by itself! The 3D preview is GREAT!! I just changed my mind: Forget about the idea of browsing tables with your pinball frontend upfront and deciding which ones to sync/pull from there. Instead we could use the web part of vpdb.io like it's intended - check out tables, look for ratings, etc. But add a functionality to 'mark' tables (or whole sections/tags like 'beta' or author 'xyz') on a personalized basis. ~add another button besides 'download' named 'sync'. A pinball frontend with vpdb.io support (or a simple, yet to be written client app) would sync all marked tables next time it's started (using the users credentials). This way, the amount of code needed to be added to the pinball frontend remains low (compared to full browsing capabilties). The amount of code needed in the VPE editor to allow an automated upload to vpdb.io seems to be not much to me as well (imho).
  3. Never heard of vpdb.io - but it makes a great first impression! Looks like a viable solution and it's completely in your hand!! What do we want more!?! You have to make it very easy for the authors to follow this path. I.e. make it a natural part of the build process / workflow (At least for VPE). Add vpdb.io support into the VPE Unity editor and let the table creators choose how to use it with a few simple clicks. [o] Publish to vpdb.io Please choose vpdb.io section [o] Alpha (restricted) U: [____________] P: [____________] [ ] Beta (public) [ ] Release (public) Also, either the frontend authors have to support vpdb.io as well or there needs to be support in the VPE Player in order to pull (or sync) the local tables in an installation with vpdb.io. Both would be possible. Ultimately, you could even be able to navigate through all tables with your frontend before even pulling them locally. This would only be necessary when deciding to 'play' a table the first time. (This might be a strech goal) Simpler approach would be that your frontend has an administrative section where you can decide which tables (alpha/beta/release/...) to sync locally and then afterwars browse you local tables in a classic way.
  4. @freezy I totally got that you were talking about the authoring side in your original post. With my response, I just wanted to create a complementing vision how beneficial it would be to have a central repository for the finished tables as well. I'm not asking anyone to create that respository right now for my personal convenience. I tried to spark an idea here. The term binary artifactory (Nexus and alike) would have been more appropriate, but it's not so well known generally. Why shouldn't a central respository for tables + additional assets be possible? After all, vpforums.org / vpuniverse.com are 'repositories' as well (with additional commenting, which is nice), except that we don't use an API to pull but do by hand. And since these are only two - they are pretty 'central', don't you think? It's all just based on the agreement what to use by the community & the creators. Imho we intend to be state-of-the-art on the authoring side (which is a fantastic thing), but fall back into Internet history 15 years ago when it comes to distributing & accessing the binary results. You could - if you will - say it also with a sharper tongue: We are totally misusing the forums to host large files releases because there is nothing better available (easily) as of now. But again: i was about a vision, right?
  5. Hey freezy, this is exactly how I imagine the hopefully near future will be! While you sketch a picture of how the creative process of the authors & modders can greatly benefit from the collaborative model used since decades in software development, I'm thinking more about how we as pinball players can benefit from it. For example: When i fire up the cab after a week or two, i would love to see my frontend (say PinballY) telling me that n of the installed tables are outdated (~have received an update in the central VPE/VPX repository) and m tables have been added to the repository in the meantime. Do i want to sync to the latest versions before playing? Hell, YES! Because that means that i don't have to watch each and every forum thread repeatedly whether a table has received an update or not or if a table has been added. And then having to manually download & 'setup' these tables and searching for additional assets, etc. pp.. Please don't get me wrong - i don't expect to be fed automatically with the results of painstaking work of the authors without any appreciation. I just think it would make our life so much easier! (I don't want to miss a "sudo apt-get update" on Linux and do all steps by hand, taking the whole evening...) It would ultimately mean that everyone could focus on playing the tables instead of spending large portions of the spare time to just staying up-to-date and maintaining the rig. Or alternatively - spend more time for creative work, where also others can benefit. I mentioned assets: Yes, why not pull backglasses, wheel logos, etc. automatically (or interactively by browsing the repository with your frontend) as well? One important aspect (imho) is to reduce the manual work everyone has to do before playing a table to his liking and avoiding to touch the table(file) itself to do so. Example: the camera setting / viewpoint. Why should i be forced to adjust that for each table separately? What if i wanted to switch viewpoint while playing? Having typically 2-3 favorite viewing presets? Think of Pinball FX2/3. As a player, I just want to toggle through my viewpoint presets with a function key or my cab buttons. And they have to be separate from the tables and work across all tables (at least for the majority of tables). Next could be the lighting settings. In VPX, some tables bring a handful of lighting presets & options. Other tables don't. This could be handled centrally in VPE. (Maybe the principles of Unity dictate that change anyway...) And lastly - while i'm at it - the options (config dialogs) and hotkeys which currently every table offers in a different way. I would like - when i'm allowed to ask for it - to see that unified too. We should have one known way how to access & show options a table might offer. Everyone involved in the project: You're doing great work. VPE will rock! I'm confident and can hardly wait!
  • Create New...