Dear diary...P-ROC'king

[dave]

About a month ago (maybe more) I set out to get this P-ROC framework running with Visual Pinball after seeing Marks F-14 shop log, I didn't know it was possible at the time. After a good few hours & back 'n forth emails, winding people up on forums it's all good.

During that time I've rewritten Robocops original rules for use with an lcd/dmd/music/film, that's been kind of shelved now until I can pick one up. That tables cost would be a fair amount more because of the need to buy extra board...any data east or sys 11 needs extra $$$$. Going off the idea of that now but it was a decent table to learn with.

Decided to remake my FP Evil Dead that I made a couple of years ago now for p-roc and already well into coding game. Currently not possible to use the p-roc with Unit3d pinball, would love to just use Unit3D and really if could be bothered to figure it out I should make a bridge in the same way as the visual pinball. Time doing that or time making tables? choose the making tables/writing rules, someone else will do it at some point
Maybe one day I'll have this game flipping for real but until then I'll finish writing the game.

Future Pinball
Unit3D Pinball
Visual Pinball

Played so much with getting the dmd/lcd resolutions good. Obviously the higher the resolution the more memory you need. Started with 720p on Robocop but by the time you have a few animations running you're using 1gb of memory very quick. You'd pick up a machine cheap enough to run the game but still doesn't make sense for a pinball to me. Unless you're doing a back-glass like woz, just no point. Even for a game like that I'd have to use a different route for graphics and would have to do some 3D/2D animations myself.

The resolution you see on VP picture is Sega DMD size, 192x64 and then scaled up 4x. Tested on a few different screens I'm happy with that. Using a dot filter and even scaling up 10x still looks decent & clear to me. As it stands with the animations I have now, the memory usage is really low. Even when finished I think this would run off a raspberry pi or beaglebone.

Would like to write in a login system for hi-scores/achievements but not yet as important as getting game done.

Short Rules:
Complete 5 modes + 3 stackable multiballs = wizard = Not easy.

Pretty much downhill from now for the rest of it...finished the Cellar Multi-ball this afternoon. 2 more to go.

If you've got ideas for tables & you're good with everything other than the software maybe we can bang heads together to make some custom games.

I'll post some game play soon as it moves along but will have to censor some modes as she's graphic ;p

That....was..long...for....me
Thanks for reading to here

 

[dave]

Missing hundreds of pieces from this list but calculations so far

Must be cheaper to gut a T3...

 

[Sonny_Jim]

I've been looking at P-ROC for a project and I'm working on and TBH I haven't been very impressed with it at all.

Hardware wise, the main gripe I have is that he is pushing people towards using the P3-ROC/SW16 boards rather than a P-ROC with it's built in switch matrix. As you've found out, this winds up being very expensive. Gerrys retort to that was that it makes wiring simpler. Well, if you can't wrap your head around something as simple as wiring up a switch matrix then I think you'll have bigger problems. FWIW when I spec'd our project it came in to be about $200 cheaper to use the following hardware than the P3-ROC equivalents, plus you got more for your money (power conversion):

P-ROC to provide switch inputs and the interface to the main CPU
Rottendog WPC95 board for lamps, coils and power conversion

Software wise, compared to FreeWPC I don't see anything in particular that makes it a 'Pinball friendly' OS. Sure, it has things like a service menu but there isn't anything in the way of containers/device handling, which is a large part of a pinball OS. When I raised some of these issues with Gerry his response was that it needed to be like that to maintain 'flexibility'. I'm sorry, but I don't buy that at all. 90% of hardware on pinball tables is pretty much identical (slings/flippers/trough etc) and the way we do it in FreeWPC allows you to be able to add custom code if the device isn't completely standard. An example of this would be the autofire mechanism on TZ, as this has to open a gate, kick a ball, wait for the ball to settle in the autofire, kick the ball and close the gate again.

Using a methodology like the above means that ball tracking can be kept in the OS, rather than having to be written for each game implementation. Using common code rather than rolling your own means that bugtesting becomes a hell of a lot easier.

Also as an aside, there is no inbuilt support for LCD displays in pyprocgame, only DMDs. This means you'll be having to write all of your own LCD code (ie priority manager so the animations run together properly). There is an extension to pyprocgame that aims to address this, but it's not part of the master code.

The documentation is pretty poor also, every time I've asked a question I've been told to read the source, which isn't ideal. There should be at least a document that outlines each of the different modules available to coders. For example, I had no idea that the service menu was implemented, as it's nowhere in the docs.

Unfortunately, Gerry is more of an electronic engineer rather than a software engineer, so whilst I think that some of the hardware decisions he has made are the correct ones, his approach to software leaves a *lot* to be desired. The same goes for the guy who wrote pyprocgame, by trade he is a mobile apps engineer and I don't think he has enough experience with pinball hardware to be making the right choices.

FWIW, Gerry was very receptive towards my critism but I think he expected me to be fixing all the flaws in pyprocgame, which I just don't have the time or the energy to do. As it stands right now, I'm looking towards porting FreeWPC to the P-ROC hardware and binning pyprocgame altogether, as believe this will be less work than having to add all the features I'd expect from a Pinball OS to pyprocgame.


EDIT: One other thing to note would be the need to split your code between game rules and shot detection, ie Any code that keeps track of the ball should be in the same place, with game rules/scoring separate. This helps as the code gets more complex as you add features and makes debugging easier.

 

[dave]

Yeah indeed, the route for having to purchase 4 separate switch boards just for 64 switches is a bit much. If you were just going for a standard dmd I would hold out for ben hecks board which has all the switches/lamps/dmd controller all in one for $300-$400.

The LCD isn't a problem at all really for me, moceans branch of pyprocgame is very good for that, you also don't need to mess about with making fonts because you can use what's installed on the machine. I've been running a few different branches on one machine, it's not too much trouble. You can use a lot of other gfx libaries too, but above my head for time being and not particularly needed for my use at the moment.

Trust me had a lot of frustration with the documentation, there is a lot missing. It's just one of them things you have to keep plugging away on so it sinks in. The biggest thing was lacking a lot of code snippets and explanations. Found myself going through thousands of lines of (spaghetti) code + manual for hours.

Once you got the hang of it you write anything you like as far as any ball tracking/service modes/hi scores/log ins/achievements (if that floats your boat) and they can be passed on from table to table.

Mmmmm, almost like I'm defending it here but really my biggest annoyance is the cost too for an original build. I've said before that maybe with the competition he's got coming there could be some shift in prices.


I've looked at FreeWPC a while back but if I remember rightly I had a bit of a brain fart on that. Cheers for your thoughts!

 

[Sonny_Jim]

I've looked at Ben Hecks code and from what I've seen so far, it's not great. The other option is to use the FAST WPC board but that looks like it's going to be encumbered with license issues.

I've also noticed a lot of people defending pyprocgames 'emptiness' and pointing towards the various projects that have already been built with it, but really I think Gerry needs to appoint someone to take over control of the pyprocgame and start adding the various things that a Pinball OS should have.

From what I see at the moment it's a bit of a free-for-all, with people replicating code that achieves the same thing in their projects. That to me is just stupid and a waste of time. We should be 'standing on the shoulders of giants' and not reinventing the wheel with each project.

 

[dave]

I've really no clue what he's using for framework on his board, not looked into enough apart from the cost of it His "Americas Most Haunted" was built with it I think.

I did think about documenting pieces of it as I was learning but came to the conclusion everybody must of felt the same way if they were just starting out with Python, which would've been "why the f should I", I will let others suffer the same way as everybody else in the process of learning. Or it was a case of "You never going to learn anything about the system if it's all laid out for you ready to use".

Which again is a terrible way of looking at it, considering he would sell a boat load more boards if anyone could just pick up & use instantly.

If it was set out like any of the virtual pinball engines where "this does that" and "you do this to do that" with all bread & butter modules, it would've been 100x easier & faster for anyone and less frustration. It's missing all of that big time and since they've been going like this way since 2011 they should pull finger out, I hear ya.

I wouldn't have gotten as far as I have without the intellisense of Visual Studio. I have looked into other projects but would never blindly copy from one to the other. I need to know how it works to fully understand it.

Sometimes I wonder how I've understood any of it because programming/scripting is not my job, it's just something I happened to picked up for fun. Got too much time on hands. If you do take it on don't worry to give me a shout if you need anything.

Cheers

 

[Sonny_Jim]

Or it was a case of "You never going to learn anything about the system if it's all laid out for you ready to use".

In my discussions with Gerry he was basically trying to tell me "Well, that's the way you want to do it, not everyone will want to do it that way", which is a fair point, but as you've noticed, a lot of people who aren't coders are looking at using P-ROC and he would almost certainly sell more hardware if it wasn't so daunting to newcomers. Hell, I'm an experienced pinball programmer and even I felt nervous at the job that was ahead of me. I didn't feel like that when I was working with FreeWPC because we have excellent documentation and an active dev who would answer questions rather than saying "read the source".

I need to know how it works to fully understand it.

Oh for sure, but again this is where common code and decent documentation helps, so all I need to know is that device_unlock (BallLock1) will drop a ball from ball lock 1, rather than having to read and understand the entire sourcecode for device_unlock ().

I didn't look too closely at Ben Hecks code, but a cursory glance I saw there were a lot of 'magic numbers', ie things that should of been defined rather than hardcoded, which made me think that he doesn't have enough experience working with projects that have a large amount of code that needs to be maintained.

 

[dave]

EDIT: One other thing to note would be the need to split your code between game rules and shot detection, ie Any code that keeps track of the ball should be in the same place, with game rules/scoring separate. This helps as the code gets more complex as you add features and makes debugging easier.

Sorry, I missed this part.

In a way this is all covered anyway really. I'll try and give a quick look to how it's sort of laid out. Sorry if you know all of this anyway. Just feel I need to show you it's actually all here anyway.

Evil Dead.py = This is your main file on load. All of your main "game" object, variables go here for use in all of the modules. "fonts" "paths to your assets"

Pretty much all modes. More or less everything is a mode.

When game is started it would load a BASE.py with low priority. To start with , every coil & switch is added in here, so you control all of your table from get go. Any other mode you need to use a switch/coil differently can override this and be told to stop so it doesn't call the BASE.py.

I used a similar strategy with that of the earthshaker code. Where he uses a Utilities.py. Everything in here is stuff you use all the time, like ball tracking, player_stats. So you just call to this through any mode. So in essence it is separated from rules. Then every player uses all of these variables on their own.

balls_in_play = self.game.utils_mode.balls_in_play

It took me like 3-4 weeks to realize that I could add in a main() call at the bottom of every single mode so I can launch that mode just on its own to test. So now anytime I write a mode I don't have to launch the whole thing and make my way through the game to test it. Just pop open the command line and run that file. ie: Python badhand.py, then just use keys set to switches to test. So much of this gubbins isn't glaringly obvious.

Pretty much the following is bread & butter I think for every game:
"Evil Dead.py" "Base.py" "Trough.py" "Attract.py" "Utils_Mode.py" "Assets.py"

The assets is handy, just pre load everything here (sound/dmd) so it can be called from any mode.

Then you just make your modes one by one. It really is very easy once it clicks. So much "Ah-Ha" (partridge moments") when you get going on it.

I wouldn't write a LOTR in a day but I will say you can get a whole game done very quickly. I need to push on and do more but right now it doesn't feel challenging anymore just more of a chore, especially as I'm writing the games with Visual Pinball and I doubt very much , it's no way near as fun as real table. If I had table right now I would make more than one game for it easily.

Wow sorry if that's patronizing, quite surprised on how well I know the framework now.

 

[Sonny_Jim]

Here's a simple example of how we'd implement shot based code in FreeWPC, lots of timers basically. Notice there's no scoring/lamp effects, it just detects where the ball is and calls different bits of code:
https://github.com/bcd/freewpc/blob/master/machine/wcs/shot.c

I'm a bit curious as to why you'd store the value of self.game.utils_mode.balls_in_play in balls_in_play, seems a bit redundant when you can just use self.game.utils_mode.balls_in_play to find out how many balls you have in play.

Thanks for the explanation though, I've yet to actually sit down and start coding anything solid, I spend most of my time trying to find documentation.

 

[dave]

Should of been in an If statement to try & explain that one where you'd globally use that.

After all this time why am I led to believe I HAD to buy a p3-roc for an original build? I'm not sure this is correct.

Not sure if you've noticed but a couple of people from over there are making up a new framework to run with a FAST or P-ROC. Pretty much exactly what you wanted and should allow anyone to give this a go without having to know much Python.

If you haven't purchased one already I can give you a blank table setup with the standard stuff you need to start to use this with Visual Pinball. It will help you to get feet wet.

Here's a simple example of how we'd implement shot based code in FreeWPC, lots of timers basically. Notice there's no scoring/lamp effects, it just detects where the ball is and calls different bits of code:
https://github.com/bcd/freewpc/blob/master/machine/wcs/shot.c

To reverse engineer a rom it's written from scratch? Or some way to get the original code?
I suppose you have to be careful for the size of it all to be flashed to a rom?

 

[Sonny_Jim]

After all this time why am I led to believe I HAD to buy a p3-roc for an original build? I'm not sure this is correct.

It's not, this was one of the issues I had with Gerry. The only difference is that you need to buy a master controller board (iirc), so the P-ROC can talk to the add on boards. After looking at the various differences, it became clear to me that a P-ROC + WPC95 driver was a far better option than what he was offering. FWIW I believe it'll be easier to get hold of WPC-95 driver boards in the future and in bulk, compared to Gerrys boards.

I've already got a 'blank' table setup working, I'm just putting off sitting down and getting on with it, due in part to not having the full rulesheet and also due to me hoping that some more modules are written for me to use by the time I get around to it.

To reverse engineer a rom it's written from scratch

This is a very common misconception when it comes to FreeWPC, it's not reverse engineered nor is it a ROM hack. It's a ground up implementation of a pinball OS written in C currently targeting the 6809 CPU board. As such you will have to write the entire gamecode rather than just modifying an existing ROM. The biggest downside is that you are stuck with the original sounds, as we haven't currently got an OS for the soundboard completed, otherwise it's as feature complete as you'd expect a pinball OS to be ;-)

Heighway Pinball are using a port of it for their tables coming out, Brian Dominy wrote FreeWPC and is currently HPs head coder.

I suppose you have to be careful for the size of it all to be flashed to a rom?

Not at all, you forget how small C code is once it's been compiled. Looking at the 512KB ROM I did for Twilight Zone, about 20% of it was game code with the rest being given over to the animations. For an example of how complex a rulesheet you can do, check out the following links:

https://raw.githubusercontent.com/SonnyJim/freewpc/master/machine/tz/rules.txt

 

[dave]

By having to reverse engineer, this was worded wrong I suppose, your explanation is exactly what I meant. You have to build from scratch, even if you wanted to go and fix something small , ala Draculas tilt warning removing bonus, this is ground up job.

I led myself to believe I had to use a P3-Roc to get my own switches if I wasn't jumping off an existing machine, but this isn't the case. So that £140 really can be wiped off the slate and just use the original board that comes with the built in switch matrix.

Heighway Pinball are using a port of it for their tables coming out, Brian Dominy wrote FreeWPC and is currently HPs head coder.

Interesting, how are they hooking this up for extra lcd/sound? As it is now like you say with the sound it seems very limited apart from rules.

Nice one for videos, will watch the second one properly later, haven't seen that.

 

[Sonny_Jim]

this is ground up job

Yup, and it's the way is has to be done now that people are being whacked with C&D's from the WMS/Bally rights holders on their projects (see what happened to the LED ghosting patch and CCC).

Interesting, how are they hooking this up for extra lcd/sound?

The core OS is extremely portable, so it'll run on a variety of hardware. Note that I am just guessing that Brian just ported the code and extended it to run on their new platform. At the very least he'll be using some of the same design methodologies, which imo are excellent.

it seems very limited apart from rules.

To be honest I never felt limited when using it and it was an extremely cheap way of being able to write code for a table. All you need is a £5 EPROM, you can test in VP very easily. I miss FreeWPC :-(

 

[dave]

Video's funny, button mashing is good but can't agree with the anti-cradle.

You got rid of TZ?

https://pinside.com/pinball/forum/t...framework-hw-independent-python-based-game-sw

This will get interesting...

 

[Sonny_Jim]

No, my TZ is sat in a lock up somewhere (with batteries removed of course) waiting for me to find a house big enough to fit it in. I just wish I could use FreeWPC on this project as I'd probably already have half of it done by now. But then if we always stuck with what we were familiar with then life would be very boring.

Yeah I've looked at some of the Mission pinball stuff, yet another *yawn* from me. Don't really see anything yet that's going to make me want to use it. Not a fan of python as a language so that's not helping much with my enthusiasm for it.

It's nice to see others agree that pyprocgame is weak though, the pinball coders I've spoken to about it have all said it's not professional enough to use in their commerical products. Who knows, maybe Gerry will actually take notice and start to work on it's flaws.

 

[dave]

yet another *yawn* from me

Lol, you making me laugh man. Nothing wrong with your views on it at all. You did want some kind of ready 2 go modules to be used like your ball tracking etc before, they're trying to set out for that. Who knows..

I think it is more than pro enough, it really does do anything you need it to plus wherever your skills & imagination can take you, end of the day it's up to you to build on that. I agree if there was a proper library to use like the FreeWPC you would indeed save a tonne of time and headache.

I only see non-pro problems with the pyprocgame being easily accessible too all in a way for a commercial business. Who's going to rip Predator code? TBL. Bop. All too easy to edit. Someone could buy Bop, copy and not buy a kit other than a p-roc & their own display/ sound.

When it comes to building dmd stuff for the freewpc that sounds like an awful lot more work than this is. Really is limiting for any graphics/sound. Unless you have a team of people , gonna take you forever.

I know your views on any video or dmd is that you don't stand & watch it anyway when you're playing a game but this was 2011, has that changed? All for the attraction anyway in my point of view, for the waiting player etc. WOZ is horrible , that is OTT. I'm not into stop/start pinball where I'm made to watch a sequence either, another reason to love Dracula to skip all the gubbins.

 

[Sonny_Jim]

When it comes to building dmd stuff for the freewpc that sounds like an awful lot more work than this is

Interesting, what makes you think that? I managed to do all my animations by myself (with a few from highrise). I would mock it up in dmdPaint, maybe touch it up in the GIMP and send it over. It has priorities/queuing/transition effects etc. I don't see any of that in pyprocgame so far. I'm not sure what bits of code you are looking at, but for standard stuff like score display, high score entry, special etc it's all done for you.

The big issue I see atm with MissionPinball is that their main coder doesn't know C. This might be a major hurdle as afaik libpinproc is all C, plus you can bet your sweet bippy that FAST pinball are going to use a compiled language, for the reasons you state about Pred/BOP.

 

[dave]

Well after seeing video really, just had this picture in head of dot by dot, getting shades right. I wasn't aware of being able to send a series on frames over.

        self.Grouped_layer = procgame.dmd.GroupedLayer(192, 64, [animLayer, self.test_layer])
        self.Grouped_layer.transition = dmd.ExpandTransition('vertical')
        self.Grouped_credits = procgame.dmd.GroupedLayer(192, 64, [animLayer2, self.credits_layer])
        self.Grouped_credits.transition = dmd.transitions.ExpandTransition('vertical')
        self.Grouped_layer2 = procgame.dmd.GroupedLayer(192, 64, [animLayer5, self.info_layer2])
        self.Grouped_layer2.transition = dmd.transitions.SlideOverTransition('south')
        self.Grouped_layer3 = procgame.dmd.GroupedLayer(192, 64, [animLayer, self.test_layer])

Transitions are here but there's not enough of them. Scripted layers, queues, handlers, listeners, everything all prioritized by the current mode layer.

Try looking for transitions in docs ....you won't find it lol. Terrible , had to spend a couple of hours searching for that too on forum & intellisense.

Do you not know enough of C to communicate with pinproc from FreeWPC? Honestly no clue if possible...

 

[Sonny_Jim]

Well after seeing video really, just had this picture in head of dot by dot, getting shades right

Ah ok. I probably didn't explain it too well in the video, but it's more to do with the problems of creating DMD art in general rather than anything FreeWPC specific. With FreeWPC it accepts 128x32 PNG frames so it's a doddle to export something from a graphics program. Whether it looks good in 4 colours and with the dot spacing on a DMD is a different matter, hence why dmdpaint is so useful.

Do you not know enough of C to communicate with pinproc from FreeWPC?

It's certainly possible, like I said before FreeWPC is very portable due to the way it's written. It's something I may look into doing if pyprocgame doesn't sort it's act out.

 

[Snux]

Interesting conversation guys. I'm kind of firmly in the P-ROC / pyprocgame camp at the moment with my F14 project plus having designed the Sys11 P-ROC driver board, but these kind of discussions are cool. As you've both mentioned (and Gerry backed up in the MPF thread) the documentation for pyprocgame isn't the best for sure so diving in the deep end works best, eventually. I did do some initial tinkering around with FreeWPC a couple of years back. I liked it a lot, especially the portable nature of the end result (pop in a ROM and you're away) but got a bit frustrated when trying to debug things. If I'd stuck at it longer that would have been less of an issue for sure, it's like all these things they have a fairly steep initial learning curve.

I'd missed the MPF post somehow on pinside, it'll be interesting to see how that goes. I just hope that doesn't turn into another nearly-finished project; like most of these things the first 80% is quite easy, the last 20% is the hardest but most critical. I also hope it isn't dumbed down too much as the comment that

"Be easy enough for non-programmers so that anyone without programming skills can get a machine up and running."

is kinda scary. As you've both mentioned, python isn't maybe the best choice if you're planning to commercialise something and don't want to give your source code away, although there are various code obfuscation tools and also projects which take python and compiles it (properly, via C or C++ instead of just zipping up the python bytecode like py2exe does). I've not tried any of those options as my code is open source, so don't know how well they work.

At the end of the day producing code for a pinball machine (be it for an existing or custom game) is always going to be a very very niche activity. I can't see any toolset or environment ever being easy enough to use so that the non-programmer masses can really do very much. That leaves programmers (or at least people with a reasonable understanding of it) and as we know the debate between programmers on which language/OS/programming technique/concept/paradigm (I hate that word) has been going on since computers were invented. Horses for courses at the end of the day and having some choice is a good thing. Folks will have their preferred framework and coding approach and if they can work with that and produce good results then I reckon that's a good thing!

We know this is only going to stop being a niche thing when we can tell our friends what we do as a hobby and they don't say "you do WHAT?" Never gonna happen

 

[Sonny_Jim]

got a bit frustrated when trying to debug things

Nature of the beast when dealing with a 6809, it's not like we've all got access to Motorola Executor debugging stations ;-)

I can't see any toolset or environment ever being easy enough to use so that the non-programmer masses can really do very much

Yeah a lot of people seem to think "Well, can't you make it point & click, I only wanna change a few things" without comprehending the amount of work it takes. To be fair though, I had zero programming experience before I embarked on my TZ project and I think it turned out alright

 

[dave]

Cheers Mark, I had wondered if you would come & chime in!

Sorry if I came across as too much of an a-hole earlier, was just trying to make a point of what a mission it can be. I had singled you out lol, sorry.

It's the same for anyone who wants to start with it , where they have to come looking hours on end for answers etc, same old thing time & time again. It probably wouldn't be as bad if you knew some python to begin with.

Indentation & whitespace is a killer and can cause errors all over the shop without being glaring obvious, especially testing with VP. Until you try and run the py file in question through cmd, then you have a better time to debug. I have to use a mixture of visual studio & sublime text open all the time to do anything. A lot of the time going into sublime > view > convert indentation to tabs. Same with the yaml files too.

I'm fairly adept with some C# gubbins, so wasn't as new to OOP.

 

[Sonny_Jim]

Coming from a C background, I've learned a special level of hate for the way python handles whitespace. Why should a intepreter give a toss about the visual formatting of a load of instructions? *grumble grumble* ;-)

 

[dave]

Tried to capture some gameplay but the game is so hard when capturing, framerate comes over pretty good in end but bit choppy when playing. I've not added the ballsave in yet, don't know why keep putting that off I really need it , but can deathsave/bangback for time being.

Most of scoring & lamps will leave till the end, I know where to shoot and not relying on lamps to be lit anyway like you would normally in virtual pins.

3 of the 5 modes done.
Cellar Multiball is done (couldn't even make it with cheating the steps to open cellar)
Top rollovers need doing, but they're easy, keep putting the easy stuff off.
Cards on right orbit.
Actually still loads to do, having to do twice as much work with VP.

 

[Snux]

Looking good. I've got the advantage that the VP side of the equation is already done for me, I "just" get to do the code. I just posted an update on my pinside thread with a new video in case anyone is interested. Still loads to do, but the mission framework is nicely in place now and will extend as needed. Like you though Dave, some of the simple things I still need to get at - the kickback for example.

https://pinside.com/pinball/forum/t...-and-on-going-development/page/2#post-1798752

 

[dave]

Nice you're making some progress now. Yagov actually made it into my table but never fired off in the video . You can't just grab an auto-plung and spin it around 180, so I'd imagine yours was the same with a fake kicker. That part when fired out is dragging you through the woods.

There is one thing from the F-14 that stays with me after 100s of plays, whether it's a break off it or in the morning after, is the music is going around & around in head. Nothing wrong with the F-14 tune, it needs remixing and I've said I will do it at some point. You need the "giou, gii gii gii giiou giiou" but souped up to 2014. Either some jungle(standard) or some breaks like you have there. I have a spare machine just for making tunes on, but lately having a job to be inspired just to turn it on and do anything. I've worked with audio for a long time and wouldn't take me long to knock that up.

 

[Rus121]

****ing rockstars of the pinball world. Man I wish I had the patience to learn this stuff.

Great progress on Evil Dead. Cant wait to see the final product.

 

[dave]

It's not so bad, if you ever wanted to build one give me a shout and I could help. Swings & roundabouts, I will have trouble when it comes to building the machine that's for sure, where you'd probably know a boat load more than I do.

I added this bit into the Linda mode last night. A couple of shots before this, you then make it into the shed and fight off the body she brings in. Not sure whether I want it to kill you or give you less points for however long you can do Left/Right alternate on flippers. Killing you would **** you off a bit and make it harder than it is already.

I'm like Linford on the keyboard to do 8 seconds.

Bit like Lethal Weapon I suppose.

 

[dave]

Had a go at trying to finish the core of the Linda mode this evening, pretty much done. Had to cheat (deathsave) couple of times to try to complete for video. Made lot's of improvements on the physics of table, not that it matters to much for the game but more enjoyable to play.

I wouldn't attempt live catches on video, just too laggy to mess about when capturing but anything is possible. With the new Physmod5, VP is the nuts, probably best physics simulation out there right now when tweaked right.

It's not as difficult as before because the slingshots are not firing off unrealistically.

@Snux - Slingshot Hit threshold=1.2 , Force = 6, Threshold=5, elasticity = 0.6 , Friction = 0.015, scatter angle=5
Looks like you're using an old version of VP anyway , you may not have some of them options. I'm guessing friction maybe.

Always had this model in mind to use. Only £13.99



You can't see the hatch for it because it's not drawn in yet but in front of the cellar hatch it will pop up, like the trolls. Henriettas head can be removed and can attach the longer one. I'm hoping to have room for both.

In cellar multiball you have to bash the longer one a few times but in the wizard mode I want that whole body with her head in it to pop up too.

 

[dave]

I can black out the boob if it's against site rules? @)