Hey Brian, just curious, are you still planning on moving off of Pygame for OS X? Looks like it's broken with El Capitan, and considering the last version of the OS they mention on their site is Lion is doesn't give me much hope that it's being actively developed. 
Spending a Sunday morning checking out this death metal band vid turned me onto (Skeletonwitch, what a great name) and reading through the MPF docs. Really great documentation!
Edit: 
Answered my own question reading your really useful docs! I see you're going to move to SDL2. That's cake to install since you just need to drop it in the Library/Frameworks folder. When you get that transition finished I'll get it working in OS X.
Quoted from pinlink:I am having problems downloading and installing MPF. Looking for some guidance here. Once I start the install I get several error messages, here are the first 2 that pop up. Any ideas? Thanks!
Capture.PNGCapture2.PNG
For best support with MPF you should post to the forums at missionpinball.com
Aaron
FAST Pinball
Thanks Aaron, I will do that! Having problems registering for the site right now though. Asking me to enter the captcha, but there is nothing there.. weird. I will try again later.
Sorry for the registration troubles. Our current spam blocker is overly-aggressive I think, so I just updated that now and we'll see how that goes.
I see you register now and get your question posted there. (I'm just responding here for completeness for future people who read this thread.) I think this issue is related to running the installer out of the zip package versus unzipping it first and then running it out of the newly-unzipped folder. Looks like we need a doc update!
Seeing how the Minion guys had some trouble when the latest MPF came out, I have a question. What is currently missing from MPF that is required to have a fully functional machine?
I imagine that these things will be added in the future. If .30 makes everything prior require rework, but then no future update is expected to cause rework, then all is right, but it every major milestone requires significant rework, that would make things very challenging for somebody who isn't very good with the programming side in the first place.
Quoted from desertT1:What is currently missing from MPF that is required to have a fully functional machine?
Good question. There have been 3 complete machines done with MPF so far, so by some counts you could say that it's all there now. (Here's the current feature list.) That said, I literally have a 50 page document of bullets of things I want to add, so you also can't wait until it's "done" because it will never be.
Probably the biggest thing missing today is there's no service mode. So if you want to change settings you have to edit the config files directly with a computer. Second is that there is no bonus mode which you can setup via configs. I wrote a How To guide on how to do the bonus mode in Python, but I definitely want to get it to the point where you can just do it without Python.
The bigger question is about the pain of moving between releases. To us it's important that we don't cause too much pain by making changes between versions, while at the same time we don't want to box ourselves into a corner limiting some functionality due to some decision we made 10 versions ago.
That said, the minions guys have 2000 lines of config, but it's not like going to 0.21 broke all 2000 lines. Really it's lots of little things. We have a new setting for ball device (things that hold balls) timeouts, so you have to change one line in each of your ball devices, or we combined "shots" and "targets", so you have to combine those two sections of your config files. If someone spent 100 hours making those configs, I don't expect it would be more than a few hours to update them for the latest version. (Kind of like how you need to update all your apps and stuff when you move to a new OS on a computer, except that MPF comes out every 3 months instead of every 3 years.)
We also have a config file migration tool that will update your config files automatically to the current version. So even all the little find & replace type stuff and easier changes are done automatically.
Broadly-speaking, most new releases of MPF (there have been 21 so far) have added functionality rather than broken existing functionality. So a lot of the changes people need to make are where they manually coded something in Python before and then in a later release there's an automatic way to do it with MPF config files, so they have to make the decision as to whether they throw out their hand-coded versions or not.
Also one thing we just put in place in 0.21 (which hopefully the minions guys will take advantage of moving forward) is for game projects that are public (on GitHub), we can actually download the latest configs for all the MPF projects out there and then run unit tests on them against the next version of MPF (along with the migrated config files). So the idea is that as we're adding and changing stuff, we can keep testing against all the known MPF games out there to make sure we don't break anything. That functionality is in place now, but I haven't written a How To guide on it yet. But I expect to have all that up and rolling in the next few months.
So.. sorry that was a bit long-winded. Basically MPF is still alpha/beta/work-in-progress, so things will keep changing, but we're doing everything we can to make sure our changes have as minimal impact as possible. Even though MPF is new, there are almost 50 projects on it (that I know about), so we are definitely interested in not pissing a lot of people off!
Added over 7 years ago: Updated link for MPF features.
Quoted from desertT1:Thanks for the great explanation and not a defensive quip. This is a great tool and I have read so much on it but there is a ton to digest. If it weren't for your write ups, I'd be lost.
Brian does an awesome job with the documentation for sure!
Quoted from Aurich:Brian does an awesome job with the documentation for sure!
Months ago when I was trying to decide what I wanted to use for software I spent some time looking through their blog updates and the thing that absolutely sold me was how they managed the doc updates. Hugely appreciated.
Hi Brian,
I just listened to your interview on the Boom Go Pinball Podcast which was very interesting. I am wondering if the MPF will be compatible with the P3 in the future? Will you be able to use it to make games for the P3? I know that Multimophic are making their own development kit for the system but was wondering if all the great features you described in your interview are able to be used on their platform as well?
Thanks.
Quoted from solarvalue:Hi Brian,
I just listened to your interview on the Boom Go Pinball Podcast which was very interesting. I am wondering of the MPF will be compatible with the P3 in the future? Will you be able to use it to make games for the P3? I know that Multimophic are making their own development kit for the system but was wondering if all the great features you described in your interview are able to be used on their platform as well?
Thanks.
Considering that P3 is Unity and MPF is Python I'd assume no, but who knows what they might be able to work out.
From what I've read Unity can use interpreters, so it's quite possible that they can make something happen. I wouldn't expect anytime soon though.
Interview part 3, 47:20, Brian talks about how there is a movement to use Unity as the media controller. Also slightly before that point he mentions that the media controller for video and sound is separate from the process and the application that controls game logic. So you could use Unity for your graphics and then the stock mpf for your game logic. Not sure how far along that project is but it is a distinct possibility.
He does say 'advanced' user but....if you're determined I'm sure there is a way. Pretty cool how mpf is set up that way.
Quoted from epotech:I believe someone already used Unity with MPF (maybe Archer?)
Archer is not running MPF
Quoted from rosh:Archer is not running MPF
Nor Unity.
Quoted from WaddleJrJr:Considering that P3 is Unity and MPF is Python I'd assume no, but who knows what they might be able to work out.
Just to clarify this: the P3 is a hardware platform. We have a bunch of libraries (in our dev kit) that help you develop apps without requiring low level knowledge of the platform. Unity is the GUI we've chosen for our in-house development projects, and it's what we're basing our dev kit on currently. So using Unity is going to be the easiest path for 3rd parties to develop P3 apps for the foreseeable future. P3 apps can be built without Unity, but you won't get the benefit of reusing a lot of the unity work we've already done.
Similarly, I understand MPF to be GUI agnostic, allowing you to interface the core of MPF to any graphical subsystem via events/sockets.
On topic:
Quoted from solarvalue:but was wondering if all the great features you described in your interview are able to be used on their platform as well?
I'm curious - can you list some of the features in question? We can discuss in a separate thread how those features are handled in the P3 development framework.
- Gerry
http://www.multimorphic.com
Quoted from agodfrey:They talk of UNITY!!!
https://missionpinball.com/forum/f/unity-bcp-server/
Unity is pretty cool. I am going through tutorials with my oldest son. It is pretty impressive how much he has been able to do. He is less interested in working on pinball than my other kids, but is excited about the idea of bringing some slick interactivity onto screens in the pinball games his brother wants to make.
Whatever it takes to get them learning cool stuff, I am all about it!
Aaron
FAST Pinball
Quoted from gstellenberg:I'm curious - can you list some of the features in question? We can discuss in a separate thread how those features are handled in the P3 development framework.
It wasn't anything in particular, it was just that Brian was outlining the amount of work that has already gone into the MPF and their plans for the future and I was thinking that it would be great if that work could also be utilized when developing games for the P3.
Well, we're not outlining the amount and specifics of our dev kit work yet because we're keeping it confidential until release, but I'm quite confident you and other 3rd party developers will be satisfied with our efforts. It's been a mammoth effort by a team of experienced developers, and we've been building our own games on top of it. The P3 has a lot of features traditional games don't have; so our dev kit will have a lot of features traditional frameworks don't have too.
Sorry for the off-topic post. Feel free to contact me directly or create a P3-related thread for questions.
MPF is certainly a huge accomplishment, and I continue to enjoy watching the progress they make every release, just as I continue to support them as they develop new P-ROC hardware support. In fact, I owe Jan some specifics on setting up the P-ROCs burst switch functionality.
- Gerry
http://www.multimorphic.com
I think we'll treat the P3 hardware platform like any other. Once the specifics of the dev kit are released then we can take a look and see if it makes sense and/or how it would work. The architecture of MPF which separates the core engine from the media/display engine does allow for events to be sent in both directions. So conceivably there could be a Unity-driven component based on the P3 dev kit that acts as the media engine for MPF and also handles the ball tracking and stuff and sends that data to the core engine.
I suspect the challenge will be around which component "owns" the USB connection to the hardware. In MPF, the MPF core engine is what's connected to the hardware, and in the P3 platform that hardware connection also includes all the communication to the IR transmitters and receivers that do the ball tracking. So we'd just to see if that logic can be handled by the MPF core engine or whether there's code in the P3's Unity project for that or what.
Bottom line I guess is I have no idea, but we'll definitely take a look when the dev kit is released.
Hi Everyone,
It's been 2.5 years since the original post, and MPF is going strong. We've recently changed the website to ".org" since we're just a group of hobbyists and not a commercial company. New URLs are:
http://missionpinball.org (For general info on MPF)
http://docs.missionpinball.org (For documentation)
https://groups.google.com/forum/#!forum/mpf-users (User forum, since the one we ran on our own was too hard to manage)
Happy pinballing!
Brian
Today is the 3rd birthday of MPF!
We're still going strong with almost 8,000 commits across the various MPF repos on GitHub and almost 1200 pages of documentation and tutorials. The hardware support list is getting pretty long: P-ROC, P3-ROC, FAST Pinball, Open Pinball Project (OPP), Stern SPIKE, LISY (for Gottlieb System 1 & 80), plus lots of different stepper, servo, LED, I2C, and DMD boards.
And we're seeing that it really is possible build complex game logic with MPF's config files. (And of course for those who want to do more "real" programming, you can do that too. We recently created a developer documentation site: http://developer.missionpinball.org/en/dev/
We're now working on MPF v0.50 in time for Expo this coming October. (The current version of MPF is 0.33.)
All still completely free & open source!
Thanks for the support and use and helping create more pinball in the world!
mpf -b worked for me for the first time last night, so I got to bat a ball around. That's a very exciting feeling. The MPF docs have literally held my hand until this point and I expect I will need that the whole way through. Thanks to the MPF folks who help and the homebrew guys who also lend advice.
Man I need to blow the dust off Alien Poker and finish it..... MPF has made programing it a lot easier than I thought.
I'm finally getting to the stage of actually using MPF for Spaceballs and it's making my life amazing. I actually get to focus on the fun parts of designing the code versus having to worry about the nitty gritty technical stuff.
One of my goals is to do a config only machine, with no coding other than YAML config files. I'm working on some sound effects tonight, so fun!
Quoted from Wolfmarsh:I'm finally getting to the stage of actually using MPF for Spaceballs and it's making my life amazing. I actually get to focus on the fun parts of designing the code versus having to worry about the nitty gritty technical stuff.
One of my goals is to do a config only machine, with no coding other than YAML config files. I'm working on some sound effects tonight, so fun!
You and I are basically yin and yang on the technical side.
Just a small follow-up: In the meantime MPF 0.50 was released (and two maintenance releases 0.51 and 0.52). Soon there will be 0.53. A lot of features were added and even more bugs fixed.
A few things which came up earlier in the thread are also becoming reality:
- You can use MPF with Virtual Pinball (VPX) tables (currently only dev; soon 0.53)
- There is a proof of concept to use Unreal engine as backbox (in addition to the built-in media controller and Unity)
- A lot more hardware platforms are supported (Arduino Pinball Controller, Stern Spike Stepper, TIC Stepper Controller, StepStick and PD-LED Steppers and much more)
Documentation has been extended (http://docs.missionpinball.org/en/dev/) and we added a lot more example for common cases. Let us know if you are missing anything and keep on building!
Quoted from jabdoa:Let us know if you are missing anything and keep on building!
Nice work!
About the only thing I would ask for is at least an outline here: http://developer.missionpinball.org/en/dev/dev/hardware.html
It would have been easier for me to get my platform working if there had been an outline and explanation of a minimal platform.
Quoted from ThatOneDude:About the only thing I would ask for is at least an outline here: http://developer.missionpinball.org/en/dev/dev/hardware.html
It would have been easier for me to get my platform working if there had been an outline and explanation of a minimal platform
No problem. I can write something up (since I did like 15 platforms in MPF). There are multiple ways to do that and also support external platforms which are in another python module.
How is your platform working? Which hardware/controllers are you using?
Quoted from jabdoa:How is your platform working? Which hardware/controllers are you using?
Oh, I just realized that I never answered this. I'm working on a OPP inspired platform based on a Teensy 3.5 arduino compatible board that controls a series of MCP23017 based I/O cards.
oppa (resized).jpgHi Everyone!
I'm not sure if anyone is still following this thread, but I figured I'd post this here just in case.
The MPF team is looking for the next generation of volunteer project maintainers, coders, and documentation writers. If you're interested in helping keep MPF alive, or you want to give back to the community that created the pinball software you use, please reach out!
It's wild to see how far MPF has grown since I started the project over 8 years ago. And it's cool to see how MPF flourished to meet most of the objectives I originally outlined back in Post #1 of this thread. That success is based on thousands and thousands of hours of volunteer time, primarily from Jan, Quinn, Anthony, and me, but dozens of others have contributed in meaningful ways too, especially as MPF grew to support additional hardware platforms. (27 at this point!!!)
Ideally we'd find someone who knows Python, though I didn't know Python before I got into the homebrew pinball space so you can definitely learn as you go. There's a lot of growth ahead for MPF, though frankly there's also a lot of "maintenance" type things which need to be done too. (For example, in August I spent about 100 hours re-writing all the installers and cloud build environments from scratch.)
So if you, or anyone you know, is interested in helping maintain this massive (and massively important) project, please reach out!
Thanks!!
Brian
Quoted from BrianMadden:...Mission Pinball Framework (MPF) project, an open source (MIT License) python-based pinball machine framework...
Hey Brian,
Thanks for MPF. It is a great project which I've been following for years now, and it will make possible for me to make a custom pinball machine with a theme of my choosing – a bucket list item of things I want to do in life.
But, and I'm sorry if this is necroposting, but as a tech oriented guy, I need to ask:
Why wasn't MPF written in C or something similar? I would never have thought Python response times would be adequate for pinball but apparently they are. However, wouldn't it, being in C, be much less demanding in terms of hardware?
What was the reason behind the language choosing?
Thanks!
Quoted from r0nin:Hey Brian,
Thanks for MPF. It is a great project which I've been following for years now, and it will make possible for me to make a custom pinball machine with a theme of my choosing – a bucket list item of things I want to do in life.
But, and I'm sorry if this is necroposting, but as a tech oriented guy, I need to ask:
Why wasn't MPF written in C or something similar? I would never have thought Python response times would be adequate for pinball but apparently they are. However, wouldn't it, being in C, be much less demanding in terms of hardware?
What was the reason behind the language choosing?
Thanks!
Here’s a decent writeup on the ‘why’ behind using config files in python. I think the team went back and forth, weighing pros and cons, and decided on python.
Quoted from r0nin:Hey Brian,
Thanks for MPF. It is a great project which I've been following for years now, and it will make possible for me to make a custom pinball machine with a theme of my choosing – a bucket list item of things I want to do in life.
But, and I'm sorry if this is necroposting, but as a tech oriented guy, I need to ask:
Why wasn't MPF written in C or something similar? I would never have thought Python response times would be adequate for pinball but apparently they are. However, wouldn't it, being in C, be much less demanding in terms of hardware?
What was the reason behind the language choosing?
Thanks!
Python doesn't have to be fast, in terms of raw response time. The real time controller(P3,cobrapin,fast,whatever) is handling that part. A few millisecond lag in a video or sound isn't that noticeable. C/C++ is certainly used in the real-time controller firmware. But requiring that the average pinball builder also be a proficient low level programmer is probably a recipe for disaster. And it's simply not necessary now.
That being said, there are platforms that let you program bare metal, so to speak. You can program the Arduino Pinball Controller in C++, for example. And you can always connect to OPP based systems, like the Cobrapin, using whatever you like.
Quoted from ThatOneDude:Python doesn't have to be fast, in terms of raw response time. The real time controller(P3,cobrapin,fast,whatever) is handling that part. A few millisecond lag in a video or sound isn't that noticeable. C/C++ is certainly used in the real-time controller firmware. But requiring that the average pinball builder also be a proficient low level programmer is probably a recipe for disaster. And it's simply not necessary now.
That being said, there are platforms that let you program bare metal, so to speak. You can program the Arduino Pinball Controller in C++, for example. And you can always connect to OPP based systems, like the Cobrapin, using whatever you like.
All true. With our FAST platform all you need is a processor/device capable of connecting to high-speed serial at 921600 and you are off to the races with our FAST Serial Protocol.
https://fastpinball.com/fast-serial-protocol/
Our FAST Neuron Controller has a Raspberry Pi 4 40pin header so you can directly seat an RPI4 into the controller or use the header to interface with something like a Teensy or other device.
https://fastpinball.com/modern/
Aaron
FAST Pinball
Quoted from r0nin:However, wouldn't it, being in C, be much less demanding in terms of hardware?
I mean, maybe a little, but the actual compute usage is pretty low from MPF and the rules. The majority of the hardware demand comes around video and audio.
Quoted from Wolfmarsh:I mean, maybe a little, but the actual compute usage is pretty low from MPF and the rules. The majority of the hardware demand comes around video and audio.
Exactly. When people ask me what kind of computer they need, I'll ask "what are your on-screen/audio/online connectivity ambitions?"
They are the important factors when selecting your controlling CPU/PC.
Aaron
FAST Pinball
As time has gone on I've had increasing trouble. P3_roc not supported by Gerry means I can't update the os. So any improvements I miss out on.
Its great for the av side but I've ended up writing quite a lot in python anyway.
Quoted from epotech:As time has gone on I've had increasing trouble. P3_roc not supported by Gerry means I can't update the os.
I'm not sure why I'm being called out in an MPF thread. I'm not involved with MPF dev, nor have I ever used it. I can tell you that the P3-ROC is still the primary pinball controller we (Multimorphic) use and sell, and it will continue to be for a long time.
P3-ROC (and P-ROC) projects generally make use of a C/C++ driver (libpinproc) for interfacing to the hardware, and many python pinball frameworks link to libpinproc through a python interface layer called pypinproc. Both of those projects are (and always have been) open source. Feel free to fork and modify, or modify and issue Pull Requests if you have changes that you believe will benefit everybody.
If you're saying that MPF devs have made implementation choices that make it incompatible with older libpinproc/pypinproc builds, that's a different story, and it's likely one that's easily resolved by somebody familiar with the changes that made it incompatible. I know MPF at least used to distribute a custom build of libpinproc/pypinproc. Is that now obsolete? It should be easily resolved by anybody motivated to dig in.
To the question about C/C++ vs Python frameworks... we originally developed pyprocgame with Python because of its accessibility, and that paid off in spades in the early days of custom pinball development. I think MPF prides itself on even more accessibility for non-programmers with config file-based rules. Most people programming commercial machines are long-time professional programmers with an eye towards efficiencies and performance (and minimizing compute-engine costs), so they tend towards lower level languages, but there are some that still use Python.
- Gerry
https://www.multimorphic.com
Quoted from gstellenberg:If you're saying that MPF devs have made implementation choices that make it incompatible with older libpinproc/pypinproc builds, that's a different story, and it's likely one that's easily resolved by somebody familiar with the changes that made it incompatible. I know MPF at least u
I believe its something like this. All I know it is not longer possible to use newer versions of mpf.
Quoted from epotech:I believe its something like this. All I know it is not longer possible to use newer versions of mpf.
Are you sure about that? I thought someone rebuild the p3/proc piece to work last year?
Wanna join the discussion? Please sign in to reply to this topic.
Great to see you're enjoying Pinside! Did you know Pinside is able to run without any 3rd-party banners or ads, thanks to the support from our visitors? Please consider a donation to Pinside and get anext to your username to show for it! Or better yet, subscribe to Pinside+!
This page was printed from https://pinside.com/pinball/forum/topic/announcing-the-mission-pinball-framework-hw-independent-python-based-game-sw/page/3?hl=jabdoa and we tried optimising it for printing. Some page elements may have been deliberately hidden.
Scan the QR code on the left to jump to the URL this document was printed from.
Torrance, CA
Leicester
São Paulo