Jump to content

WIP: Visual Pinball in Unity (2021 Edition)


Recommended Posts

  • Content Provider
On 11/3/2021 at 6:00 PM, KRouge said:

 

My humble opinion: Ideally, you should not even have the need to do such things on your own, like touching audio files and having to maintain several sets (by manufacturer or by any other criteria) at all.

Imho, this topic can be generalized, because there are other areas where a user should not have the need to adjust settings for each and every table repeatedly. Examples:

- Lighting. Some tables offer a set of multiple lighting settings. For other tables, this is not prepared by the table author. How to toggle lighting (which keys / buttons) is done differently for the tables. Ideally, a cab user would want to tweak lighting which fits his cab / TV / preference and use this across all tables. Maybe also switch from a day to a night setting. Personally, i really don't want to adjust lighting table by table.

- View angle / Camera settings. Same story. I imagine that a user can have a set of a few personalized and preferred camera settings which are independent of any table. When switching between tables i expect that the 'view' stays stable. Again, personally I really don't want to touch each and every table to hand tune for exactly one view configuration for this table only.

- Audio: Volume / perceived loudness and all other aspects of audio settings. Also here, it would be great if there is no need for a tuning per table.

- Table / game options: Some table offer options like number of balls per play, adjustable rules, etc. Currently there is no common way for the user interaction. Some table offer a dialog for this, triggered by a custom keyboard / button press. Some tables expect the user to modify script constants. Ideally we should have one single menu concept and maybe on top a UI concept how to adjust settings for a table. So a table author could for example define declaratively a config UI (dialog / pop-up).

 

You raised the idea of a library of shared audio files. In my opinion, that raises the question if the general idea of a fully self contained table(~file) is still a good approach. For scripts, VPX already relies on central scripts being present. True is also - like you say - that many audio files are shared between table. Why copy them into each and every table?

 

 

The idea of using centralized Library files for things like sounds, models, music, textures,etc that can be used for multiple tables (instead of adding them to each table file) is something Future Pinball has always done.

 

Honestly, at first this seems like a good idea, but it eventually turns into a bad idea. Someone at some point will decide to change a specific library file which they decide will be required for one particular table... and this will affect all other tables using it, and this ends up doing the opposite of what you want. Trust me... it becomes a mess.

 

We don't live in the days of the early 2000's. Our PC's have plenty of hard drive space and plenty of ram. Table file sizes are not a big deal anymore. They are in fact the smallest files on most pincabs :).

 

We are better off keeping all assets within the table file as much as possible (except for maybe video / some music / media files), instead of relying on scattered files in different folders. We want to get away from that and keep things simpler for player / user. Let authors do whatever they want on the table itself.

 

 

 

Link to comment
Share on other sites

3 hours ago, TerryRed said:

We are better off keeping all assets within the table file as much as possible (except for maybe video files), instead of relying on scattered files in different folders. We want to get away from that and keep things simpler for player / user. Let authors do whatever they want on the table itself.

I totally get what you say. Simply moving all assets into a centralized place and assuming every table references exactly ONE version of an asset will fail over time. I did not want to propose that as the solution. In fact my last paragraph was a bit misleading. We can keep assets in the tables and rather separate between assets (which should not be touched) and settings (which are typically touched). At the moment, this is all part of one monolithic table file. People should not have the need to touch assets and table files directly in order to adjust things.

Summarizing the problems I see:

- When a new version of a table is released all adjustments have to be re-done or are lost. And - if you want to preserve your adjustments you have a hard time memorizing or documenting your adjustments and doing them again for the new table.

- The user experience is bad if some options are doable for a table (lighting) but for other tables not. It's also a bad user experience if you have to touch scripts in order to tune sound (as an example) and moreover have to do it differently for each table.

- It is simply very ineffective to do adjustments table by table.

 

One proposal for the view position / settings:

Maybe a 'normalized' view should be introduced which should look identical for every table (as good as possible). A table author can hand tune the underlying view settings in order  to compensate for differing table dimensions and other aspects.

Users maintain their preferred view positions - which ultimately are only the 'difference' to the normalized view position.

By doing so, the users can select a view position and switch tables while keeping the same 'view'.

Link to comment
Share on other sites

  • Content Provider

The idea you mention for POV settings is similar to what ravarcade did with BAM for FP. The idea is you can set a default POV (or anything) that is written to a default.cfg file. Each table has their own CFG file that is saved in a separate CFG file in a CFG folder. When any table loads for the first time, if there is no table specific CFG created yet, and there is no specific POV settings made for the table, then the table will use the default.cfg settings (and create a new table CFG file based on that). At anytime, while playing in realtime, the player can bring up the BAM menu to change the pov (or lighting, ball, physics, etc) to their liking, and this will get saved to the table's CFG file. No change is made to the table file at all. If the user messed up something, they can always reset to default CFG or use the table file's settings (if there are any). It works really nicely, and I include my own table specific CFG file with all my releases. It's also nice, because if you update the table, you can keep your custom user settings without needing to touch the table at all.

 

Something like that on VPE could be used, and expanded to real pins layouts and settings for Bally, System 11, etc.

 

I can tell you, being able to author and also change table settings for the player,etc in real-time is nice, and it's hard to go back to doing everything from a script or a 2D table editor after that. VPE could certainly allow for so much more now that things can be done in a full 3D environment, and I'm sure many things could be done in real-time as well.

Link to comment
Share on other sites

VPX supports global POV.

 

Save your preferred *.pov as autopov.pov and it will be used as long as it doesn't exists a file named exactly like <tablename>.pov

If that one exists, it will override the autopov.pov. The same can be done for physics. I don't recommend trying to change every table you've got by putting such a file into your tables folder, but, well, if you really hate one authors physics - it can be a quick fix until you improve it yourself.

 

I use the autopov.pov for Loserman's tables. They look good by default, but, I still prefer as slight change on my end. So vptables\LMN is where I put those great EM's.

 

Not sure how VPE will support such a scheme. For me at least, it saves me a lot of work; and, it supports table(s) updates like a dream.

Link to comment
Share on other sites

39 minutes ago, Thalamus said:

VPX supports global POV.

 

Save your preferred *.pov as autopov.pov and it will be used as long as it doesn't exists a file named exactly like <tablename>.pov

If that one exists, it will override the autopov.pov. The same can be done for physics. I don't recommend trying to change every table you've got by putting such a file into your tables folder, but, well, if you really hate one authors physics - it can be a quick fix until you improve it yourself.

 

I use the autopov.pov for Loserman's tables. They look good by default, but, I still prefer as slight change on my end. So vptables\LMN is where I put those great EM's.

 

Not sure how VPE will support such a scheme. For me at least, it saves me a lot of work; and, it supports table(s) updates like a dream.

What the what??? OMG.... why didnt I know this information.. lol

Link to comment
Share on other sites

8 hours ago, Thalamus said:

Save your preferred *.pov as autopov.pov and it will be used as long as it doesn't exists a file named exactly like <tablename>.pov

...

Not sure how VPE will support such a scheme. For me at least, it saves me a lot of work; and, it supports table(s) updates like a dream.

I have also never heard of that. It's great that it exists, but I hope with VPE we can go at least one step further by making this not an optional thing (which many people not seem to be aware of) but to make it the standard.

I would also like to propose that users can manage more than one preferred POV setting (and easily switch in-between them) and that these are not absolute replacements for the POV setting of a table, but the delta to the 'normalized' POV setting that i mentioned above.

 

I hope we can achieve the same for other settings (lighting, sound, physics, etc...)

Link to comment
Share on other sites

Throwing the idea of anaglyph 3D modes into the ring for VPE (as well as perhaps other 3D modes such as interlaced, side by side, top bottom etc).

VPX has several inbuilt 3D modes for use with 3D screens which are harder to come by now, however it is missing support for anaglyph glasses on regular 2D screens.

I've done a little digging and found that a shader called SuperDepth3D can be used in conjunction with Reshade to achieve anaglyph 3D modes in VPX but it is a little inefficient it seems and also currently requires setting windows desktop to portrait mode if you want to run in a cabinet situation.

Keep in mind that not all anaglyph 3D methods are created equal, it seems that green/magenta glasses beat out red/blue for colour reproduction for instance. There are also other lens colours such as blue/amber. These modes are all supported by SuperDepth3D and the glasses can be obtained very cheaply (usually only around $10-$15 delivered for proper plastic glasses, not cardboard).

Worth considering?? Could likely just be done using reshade in VPE, however might be more efficient if it is part of native features of VPE?

There is a thread discussing Reshade/SuperDepth3D further on VPF.  https://www.vpforums.org/index.php?showtopic=48019

Edited by Gravy
Link to comment
Share on other sites

dans l'ensemble t2 fonctionne bien , j'ai eu ce message :

VisualPinball: VisualPinball.Engine.PinMAME.PinMameGamelogicEngine|[PinMAME] <= coil UNMAPPED 47: False
UnityEngine.Logger:LogWarning (string,object)
VisualPinball.Unity.UnityTarget:Write (NLog.LogEventInfo) (at Library/PackageCache/[email protected]/VisualPinball.Unity/VisualPinball.Unity/Common/UnityTarget.cs:43)
NLog.Targets.Target:Write (NLog.Common.AsyncLogEventInfo)
NLog.Targets.Target:WriteAsyncThreadSafe (NLog.Common.AsyncLogEventInfo)
NLog.Targets.Target:WriteAsyncLogEvent (NLog.Common.AsyncLogEventInfo)
NLog.LoggerImpl:WriteToTargetWithFilterChain (NLog.Targets.Target,NLog.Filters.FilterResult,NLog.LogEventInfo,NLog.Common.AsyncContinuation)
NLog.LoggerImpl:Write (System.Type,NLog.Internal.TargetWithFilterChain,NLog.LogEventInfo,NLog.LogFactory)
NLog.Logger:WriteToTargets (NLog.LogEventInfo,NLog.Internal.TargetWithFilterChain)
NLog.Logger:WriteToTargets (NLog.LogLevel,System.IFormatProvider,string)
NLog.Logger:Warn (string)
VisualPinball.Engine.PinMAME.PinMameGamelogicEngine:OnSolenoidUpdated (int,bool) (at Library/PackageCache/[email protected]/Runtime/PinMameGamelogicEngine.cs:459)
PinMame.PinMame:OnSolenoidUpdatedCallback (int,int)

 

Edited by fastdraw
Link to comment
Share on other sites

On 11/12/2021 at 11:48 PM, freezy said:

@Gravy Probably this could do it, but I'd rather spend my time on VR than on that.

Yeah, I can imagine you would have limited time to fit everything in and I completely understand.

As I mentioned in previous post, anaglyph 3D for VPE could probably also be achieved relatively simply by the end user just by installing Reshade and Superdepth 3D shader (although likely somewhat more taxing on framerate compared to inbuilt 3D effect of VPX's SBS and interlaced 3D), particularly if the developer of Superdepth sees it as a good idea to add vertical 3D separation support rather than just horizontal.

VR is certainly the way of the future and I've recently got myself a quest 2 (my PC is still not up to the task of VR stuff though), but I was just thinking that since there are a lot of people with cabinet setups and decent anaglyph 3D glasses are under $10 then it could be something that is easily accessible to all even without 3D screens.

Edited by Gravy
Link to comment
Share on other sites

mpf ne s'implémente pas dans game logic

Quote

Library\PackageCache\[email protected]\Runtime\MpfGamelogicEngine.cs(28,51): error CS0535: 'MpfGamelogicEngine' does not implement interface member 'IGamelogicEngine.AvailableWires'
 

puis plus tard dans la console safe :

Quote

GetLoadedImportedAssetsAndArtifactIDs called with invalid artifactID

C:\Users\birdi>mpf --version
MPF v0.56.0-dev.18

Edited by fastdraw
Link to comment
Share on other sites

  • 2 weeks later...
On 11/12/2021 at 11:48 PM, freezy said:

@Gravy Probably this could do it, but I'd rather spend my time on VR than on that.

Just a heads up that Toxie has just implemented several Anaglyph 3D modes into the latest build of VPX 10.7 if you are interested in giving it a try, I don't have any glasses to test as yet but seems to work and much faster than reshade superdepth3d plugin. https://github.com/vpinball/vpinball/actions/runs/1502927498

Link to comment
Share on other sites

12 hours ago, Gravy said:

Just a heads up that Toxie has just implemented several Anaglyph 3D modes into the latest build of VPX 10.7 if you are interested in giving it a try, I don't have any glasses to test as yet but seems to work and much faster than reshade superdepth3d plugin. https://github.com/vpinball/vpinball/actions/runs/1502927498

 

I am keen to try this, but I can't figure out how to download the executable on GitHub. I'm logged in with my approved account, but so far all I see is a YML file that I assume is a script.  I thought I needed a new version of VPX 10.7 in EXE format, but I'm probably wrong about how it works.

 

Never mind -- got it.

Edited by DanLShane
Off-topic
Link to comment
Share on other sites

Hii, really sorry to disturb, the project is insane !!! CONGRATS

 

Unfortunely I have a issue about MPF after unpack the package (via package MNG as mentioned in the DOC)

 

the console said in RED :

 

Library\PackageCache\[email protected]\Runtime\MpfGamelogicEngine.cs(28,51): error CS0535: 'MpfGamelogicEngine' does not implement interface member 'IGamelogicEngine.AvailableWires'

 

Sorry again about this

 

LOVE YOU ALL PINBALL FANS

 

Sev Poolay

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
  • Create New...