813 replies to this topic

[freezy]

There is not really an API yet, but in that case that would be:

_table.Flippers["LeftFlipper"].RotateToEnd();

However you'll probably be able to setup flipper controls in the editor directly.

[chepas]

if unity3d or ue .... was so easy why there are so many tables created with vpx, fp and not with unity3d or ue .....?

 

 

Make a thread to ask your question, freeyzy get cob on if keep derailing.

[freezy]

if unity3d or ue .... was so easy why there are so many tables created with vpx, fp and not with unity3d or ue .....?

 

I think you've misunderstood what Unity and UE are. They are generic-purpose game engines. There is nothing pinball-specific whatsoever in them. You would have to program everything from scratch if you wanted to produce a pinball game with UE or Unity. Some people like shaderbytes did exactly that, but he's a professional game developer. If you want to easily (re)create a game, you need a pinball editor and simulator. And that boils it down to VP and FP.

 

VPE is a work in progress of yet another pinball editor and simulator. We're at the very beginning, and we haven't even decided how we're going to deal with scripting. We might even add VBS support if it's easy enough to do. However in the future I'm sure there will be a simpler way to deal with scripting. For starters, we should provide a scripting library that should take care of most stuff you would do in a script. If we ship that, we can also ship editor support. That means setting up VPM would be as easy as (visually) linking solenoids, lights and switches to playfield items. No scripting at all. We're probably able to do that for many patterns that nowadays people just copy paste from other tables. The goal is to keep the actual script unique to the table.

 

I honestly don't understand why you're panicking. UE's "visual scripting" has a learning curve as well. What you'll be getting is better, and easier. And if you're not willing to transform your VBS coding skills into C# coding skills (or whatever language it will be), then I can't help you.

[ClarkKent]

I still hope that there will be a more realistic physics engine than in VPX. More realistic in the sense of that there will be no need for script additions or other ticks the deal with physics problems as we see lately in VPX tables.

[freezy]

@ClarkKent Yes well the "hacks" we can somewhat easily integrate, i.e. apply them at core level instead of user scripts. The question is whether we would like to spend more time on making the actual physics engine better, which is, unless Mukuste comes back, kind of out of reach (for me, anyway).

 

Personally, my goal is to make it in a way that apart from custom mechanics, no or very few actual scripting should be necessary.

[Ben Logan]

I wrote Mukuste a thank-you letter via PM in late April 2020. Still hasn't been read. ;(

[freezy]

Inserts and bulbs are imported, flashers however don't have a position in space in VPX (not where the actual light source is anyway), so they need to be properly positioned (they are actually ignored at the moment).

 

Adding an FP importer is a reasonable request. It will probably happen at some point, but as I said, we're at the beginning of this, and we have to start somewhere.

Edited by freezy, 29 May 2020 - 07:46 PM.

[xantari]

C# is worlds better then VB anyways. Also, there are so many VB to C# converters online to get you started with a script conversion I don't see the point in supporting VB, which these days is less popular than C#

[Ben Logan]

freezy, can you say anything about the rendering engine? toxie and fuzzel have done amazing work with smoothing out jaggies over the years, but I'm wondering if things might potentially look a little clearer in Unity. Hope we're not killing you with questions, here!

[toxie]

Unity has all the modern bells and whistles like TAA and i also guess DLSS soon. So anti-aliasing should be fine there.

But beating the clarity vs smoothness of all the static objects in VPX is close to impossible i'd say, as i used all the techniques usually used in production rendering (as we have the luxury for these to do whatever we want, i.e. can be costly).

Unity can do proper AA on ALL objects though, so thats the clear win there.

[freezy]

Well, the top features out of the box in terms of rendering are dynamic lighting and camera (and thus VR support). Unity provides multiple rendering pipelines, so we'll have to see how we'll be dealing with that. Another advantage is that table authors would have somewhat more freedom when working on materials and shaders. Unity provides a shader graph where you can go pretty deep (if you want), without having to actually program shaders. And for me, having a team of world class engineers working a renderer is clearly an advantage, although for toxie it's not, because he's himself one and enjoys doing that stuff

Edited by freezy, 29 May 2020 - 08:22 PM.

[toxie]

Indeed. 

 

But Unity definetly has some of the brightest minds in their rendering team, so the quality of lighting and the materials is hard to beat by a 2man team when it comes to realtime usage.

[chepas]

 

if unity3d or ue .... was so easy why there are so many tables created with vpx, fp and not with unity3d or ue .....?

 

I think you've misunderstood what Unity and UE are. They are generic-purpose game engines. There is nothing pinball-specific whatsoever in them. You would have to program everything from scratch if you wanted to produce a pinball game with UE or Unity. Some people like shaderbytes did exactly that, but he's a professional game developer. If you want to easily (re)create a game, you need a pinball editor and simulator. And that boils it down to VP and FP.

 

VPE is a work in progress of yet another pinball editor and simulator. We're at the very beginning, and we haven't even decided how we're going to deal with scripting. We might even add VBS support if it's easy enough to do. However in the future I'm sure there will be a simpler way to deal with scripting. For starters, we should provide a scripting library that should take care of most stuff you would do in a script. If we ship that, we can also ship editor support. That means setting up VPM would be as easy as (visually) linking solenoids, lights and switches to playfield items. No scripting at all. We're probably able to do that for many patterns that nowadays people just copy paste from other tables. The goal is to keep the actual script unique to the table.

 

I honestly don't understand why you're panicking. UE's "visual scripting" has a learning curve as well. What you'll be getting is better, and easier. And if you're not willing to transform your VBS coding skills into C# coding skills (or whatever language it will be), then I can't help you.

 

That did not answer the question. I don't see how any of that speil is to do with "Why so many games created instead of x" .

Edited by chepas, 30 May 2020 - 04:16 AM.

[chepas]

trad google :

my coding knowledge is basic, but sufficient for pinball.

they are to declare a variable, increment it (or not) until it reaches a certain value to trigger an event.

more obviously the various commands for the dt, kickers ....

 

but I have no knowledge regarding the syntax in C #, to realize the above.

 

unless I have small concrete examples of the end of script.

 

more import table FP seems more respectful than that of vpx with the elements that compose it. (including lights that are not considered objects).

when you import a vpx tables in the unit the lights are there too?

 

 

Listen. If you started to learn some basic C# now, by the time this is actually finished, you should be fine.

 

Investing your time in learning some C# will not be a waste and that goes for everyone as .net standard and core can be used cross platform nowadays.

 

In the future if you needed to make some program, script or UI one day to complete a task you have the skills to do so.

 

If this falls flat on it's arse like Unit3D did then you still have the C# skills. So don't invest C# just for this, do it for the long run.

 

 

[freezy]

@chepas He asked why most games are created in VPX and FP and not UE/Unity and I answered exactly that. If you think I didn't, let me know why, or even better, answer directly!

Edited by freezy, 30 May 2020 - 08:34 AM.

[chepas]

It deserves it's own thread, as I suggested.

[fuzzel]

Indeed. 
 
But Unity definetly has some of the brightest minds in their rendering team, so the quality of lighting and the materials is hard to beat by a 2man team when it comes to realtime usage.

And don't forget about all the legacy stuff a lot of people are still using. 100% dynamic rendering without a static rendering pass is no magic. VPX has one advantage it's also very good playable on low end systems without suffering too much quality loss. That's something you won't really get with Unity or UE

[ClarkKent]

@ClarkKent Yes well the "hacks" we can somewhat easily integrate, i.e. apply them at core level instead of user scripts. The question is whether we would like to spend more time on making the actual physics engine better, which is, unless Mukuste comes back, kind of out of reach (for me, anyway).

 

Personally, my goal is to make it in a way that apart from custom mechanics, no or very few actual scripting should be necessary.

Mukuste had more plans for more realistic physics but never realized his improvements because of some disagreements. A friend of mine knows him as he lived nearby but the latest info is that he has a new job and no time for other things. Sadly.

 

I think we need totally new physics and not the ones from VPX and/or scripting additions as even the improved physics are showing much differences to the real world physics of a pinball table. The latest VPX physics improvements are really good but there are still so many problems existing, especially backhands and the special behavior of the flipper coils.

[Ben Logan]

Would be great to invite Mukuste back into the mix. But, if he’s busy Clark, between you and RothBW, I believe we’re covered physics-wise. You guys are “top men” in my book. 

[rothbauerw]

 

@ClarkKent Yes well the "hacks" we can somewhat easily integrate, i.e. apply them at core level instead of user scripts. The question is whether we would like to spend more time on making the actual physics engine better, which is, unless Mukuste comes back, kind of out of reach (for me, anyway).

 

Personally, my goal is to make it in a way that apart from custom mechanics, no or very few actual scripting should be necessary.

Mukuste had more plans for more realistic physics but never realized his improvements because of some disagreements. A friend of mine knows him as he lived nearby but the latest info is that he has a new job and no time for other things. Sadly.

 

I think we need totally new physics and not the ones from VPX and/or scripting additions as even the improved physics are showing much differences to the real world physics of a pinball table. The latest VPX physics improvements are really good but there are still so many problems existing, especially backhands and the special behavior of the flipper coils.

 

If Mukuste would be willing to do some consulting, I'd love to just chat with him through PM and get his thoughts on VP physics.  While I don't have the advanced programming skills I think this requires, I do think I know enough to help move the physics forward.

 

I've been following the development on discord.  While I think starting with VP physics is a good place to start just to get things working, I do think there's an opportunity to leverage the work ravarcade is doing to move to a more robust physics solution to will start to close some of the gaps we currently have.