Monopoly WIP

The flashers are installed as are the plastic ramps, although they still need some block-wall work. The plunger reel is in as well. I still need to do the regular sign lights, block off a few things and what not and tweak the gameplay a bit more.
 

Attachments

  • preview_0.8_196.jpg
    preview_0.8_196.jpg
    105.9 KB · Views: 743
Wow. This looks exactly like the real table. Since the other one at ajs is down, I'm definitely getting this version.
 
Not sure what more you could want - it already has the flipper speed, direction, and position. If it's slowing down or operating eratically then it's probably some other drain on the system that's causing it. Hopefully you can get it smooth enough somehow for your purposes. It looks fine in the two complete tables I have but then I didn't make the speed resolution very accurate (just used 4 flippers). I think it would be much much simpler if the flipper could be rotated by degree on the fly instead of needing different sets of flippers to accomplish the effect. Basically I'm saying there is nothing to fix on the emulation side - it pulls the correct values in pinmame that it should and the code doesn't have bugs.
 
Nevermind, Destruk. I think Sellenoff or someone else should look at it that knows what I'm talking about. It's not fixable from this end. KC's table doesn't have speed control at all so you don't see what I mean there. 4 flippers isn't enough to judge speed by, IMO. I use 72.

it pulls the correct values in pinmame that it should and the code doesn't have bugs.

The error is obviously in the speed control code inside VPM's internal mech handler. It should never slow to a point where it takes over 20 seconds for 1 revoluion yet that's the kind of slow speed it will use at times (which then causes a ball search) if you use the internal handler.
 
I need to know something about code syntax in VBScript.....

If you have something like this:

dim LED(15)
LED(0) = Array(Light7,Light6,Light5,Light4,Light3,Light2,Li
ght1)
LED(1) = Array(Light14,Light13,Light12,Light11,Light10,Ligh
t9,Light8)
...etc...

and you want to call specifically say light5 there from the nested array, how would you do it? You might think this would work:

Led(0,2).state = 1

but it will give a subscript out of range error. Apparently, an array nested within an array is not accessed the same way as a multi-dimensional array. I've tried without success to find a reference to something similar online.

Led[0,2] doesn't work
Led[0][2] doesn't work
Led(0)(2) doesn't work
...etc.

Destruk's code in High Roller Casino did a collection type thing:

for each obj in LED(num)
obj.state = 1
next

That works, but I need to access two sets of separate arrays at the same time (so I can have a separate off color that is gray instead of dark orange to match the photos of the game) and the way VP stacks lights, you have to change them in reverse order at the same time so I can't use a for each type loop. I need to put manual variables in there with a nested loop and then extract both sets at the same time to make it work. But I have no idea how you directly pick out a value within that led array that's an array nested within it in VBScript. Maybe someone here knows....
 
Nice looking table Pacdude

I look forward to the release. I played the other older version, but like with all the newer stern VPM tables, the sound volume is low and I have to turn the volume up to hear sounds better, thats the only thing I notice about these newer stern vpm tables, that I didnt like.

Is the sound volume supposted to be that low? It's not really a big deal to me though. I played a real Ripleys table and the sound volume seemed fine, I could hear it. keep up the great work. :)
 
Pacdude said:
Nevermind, Destruk. I think Sellenoff or someone else should look at it that knows what I'm talking about. It's not fixable from this end. KC's table doesn't have speed control at all so you don't see what I mean there. 4 flippers isn't enough to judge speed by, IMO. I use 72.

You're absolutely right PacDude - Gaston wrote the mech handler for monopoly, and that is basically verbatim what he told me to post to you. Merry Christmas to you too. -edited - Basically there is no problem, it gives the correct information at any time, and perhaps it's your pc or code that is slowing it down as it's impossible to replicate just using the mechanic on its own.
 
After thinking about the syntax will this work?

LED( index )( obj ).state = 1

As an alternative why not forget about the 2 dimensional collections and just use a single collection or array, assuming that each set of lights have the same number of elements and even if they don't you could always use some dummy lights that are black, off screen or someting like that.

Then you could reference each elment with a little maths,

LED( index * sets + element ).state = 1
 
destruk said:
You're absolutely right PacDude - Gaston wrote the mech handler for monopoly, and that is basically verbatim what he told me to post to you. Merry Christmas to you too. -edited - Basically there is no problem, it gives the correct information at any time, and perhaps it's your pc or code that is slowing it down as it's impossible to replicate just using the mechanic on its own.

Well, if you've never actually tried to USE the mech handler (using more than 4 frames might help just for starters), how the heck can you possibly know it's "correct"?? I'm not controlling the mini-flipper, after all. I'm just telling to obey the internal mech handler's position code and sending the home switch at the positions Gaston said to use and I'm saying it's not operating correctly and it has NOTHING to do with with how fast my computer is (the one I'm using is an Athon 2800+). That handler has the flipper moving at about 1 revolution every 20 seconds at times (I've seen it go even slower) and after far fewer seconds, it just gives up and changes direction and speed because it's wondering why the heck it never hits the home switch and it doesn't hit it because the flipper is moving too slow. But this behavior is arbitrary as it will work correctly PART of the time. It's apparent that it's somehow switching into speed ranges it should never move at, yet I have NO control over that flipper's speed when I use the internal handler (beyond making sure the timer is fast enough to keep up with it and it's set to 1 so it can't go any faster). It's only matching 72 frames to the 1000 internal counter which Gaston said is 1 revolution of that flipper. That's it. It follows the internal numbers. All I do is send the home switch data, nothing else. So how can it be correct when it goes into search mode every other game and moves the flipper at ridiculously slow speeds sometimes, which the real game never does?

But I might as well just beat my head against the wall if people are going to just say it's correct when I know it's not as it doesn't do much good to tell someone their house is on fire if they're unconscious or have their fingers in their ears.
 
if you'd like, I have some time off over the next few days - I 'could' use that time to work out a system for it in VP and send a table to you to check over. AFAIK it's correct, it seems to be ok in the tables I've tested using it. Naturally it would work better if a flipper could be set to an angle during runtime that it needs to be to match the position exactly. The home switch won't cause a ball search - perhaps you mean when a ball is in the saucer and the flipper is moving? That instance would cause the ball search.
 
I think it would be easier for me to send you a stripped table to look at with the mech handler already in place.

When I say ball search, I don't mean an actual ball search. I should have said flipper search (i.e. if the mini-flipper is moving so slow that it never activates the home switch in a certain amount of time, the rom will reverse the direction (and change the speed) of the flipper to see if can find the home switch that way (i.e. maybe it's stuck on something or whatever). But the cause of it happening in my VP table is the flipper is simply moving too slow to reach the home switch before the rom decides to complain. Like I said, I don't control that. Gaston said 1000 positions internally = 1 revolution so I set my 72 frames to fit into that.

Heck, here's the code I'm using verbatim:

' WaterWorks FlipperController
dim WWPos, WWLastPos, WWSpeed : WWPos = int(0.072*(controller.getmech(0))) : WWLastPos = WWPos
Sub UpdateFlipper_Timer()
dim t
WWPos = controller.getmech(0)
WWPos = int(WWPos * 0.072) ' converts 1000 positions to 72 positions (number of flipper frames)
If WWPos >= 0 and WWPos <= 3 Then controller.switch(30) = 1 : else : controller.switch(30) = 0 : end if 'home position
WWFlip(WWLastPos).Visible = False : WWFlip(WWPos).Visible = True ' visual change
If WWPos >= 3 and WWPos <= 20 Then : sw29.enabled = False : else : sw29.enabled = true
If WWPos = 4 or WWPos = 5 Then : bsSaucerWW.SolOut 1 : End If
If WWPos = 18 or WWPos = 17 Then : bsSaucerWW.SolOutAlt 1 : End If
WWLastPos = WWPos
End Sub

the saucer stuff is to simulate the flipper hitting it out from either direction and the saucer is disabled when the flipper is close to or over top of the saucer (since the ball likes to move right through it sometimes). That is tied to a collection of 72 flippers placed in a circle with the collection name being WWFlip in VP. The timer is set to 1, although I've tried slower values as well (in case my CPU was missing cycles or something). No real difference until you use a really slow timer at which point it starts losing sync.
 
Today we drove 7 hours to get to our chrismas vacation, at my grandparents house. Along the way we stopped at a rest area, and they had a monoply game. Put my quarters in, but there werent any balls in the machine! And the right flipper was broken! I was pretty pissed, as I've been wanting to play this tble for awhile, but no one takes care of their pins anymore. I should preserve machines, buy them for 500 bucks and fix them.
Your machine looks lik it is coming along well. The ramps could be lighter, not very much though. Guess the one that I saw was possibly so screwed up that it was too light...anyway.
 
zerhino said:
Today we drove 7 hours to get to our chrismas vacation, at my grandparents house. Along the way we stopped at a rest area, and they had a monoply game. Put my quarters in, but there werent any balls in the machine! And the right flipper was broken! I was pretty pissed, as I've been wanting to play this tble for awhile, but no one takes care of their pins anymore. I should preserve machines, buy them for 500 bucks and fix them.
Your machine looks lik it is coming along well. The ramps could be lighter, not very much though. Guess the one that I saw was possibly so screwed up that it was too light...anyway.
In all of the rest stops that I have been to had games that are broken in some way. They must be one of places where games are the very rarely fixed.
 
I think the point is, that you want it to work for your needs, and I have accomodated those. I went ahead and made the code a bit more straightforward and will check it into cvs tonight and send you a dll you can look at. I tested it with 72 flippers as you have it and it's fairly smooth with at least 3 speed variances in both directions without doing a ball or flipper search. The changes I made to the dll are just tiny tweaks to the existing code - namely rather than counting the bit values for the operation of the flipper in groups of 4, it now counts them singly - meaning as soon as a 1 comes across the line it adds it to the position, instead of counting 4 bits at a time and adding them all at once. This results in slightly higher accuracy. As for the length of a revolution, it appears to not make any difference provided the home switch is pulsed/closed at relatively correct timing - so I changed it to 360 (for 360 degrees) for easier conversion to the flipper angle. The 360 vs 1000 shouldn't make much of an impact when it comes down to it - I mean it's just easier to access than by multiplying by .36 for the same result.

I doubt this will ever be truly perfect due to the speed at which the bits come in from the rom, along with the delay that had to be done to move the flipper solenoids to free up access to the string data - so it might never match the real machine to exact perfection - it is a highly complex device, and as such you can probably see why nobody is too thrilled as we run up against all the imposed limitations. However, it does work plausibly well. About the only issue really seen during gameplay is the skill shot flipper rotates at different speeds rather than a set constant rate 100% of the time, and ball kickout spinner sequence suffers the same variation on speed.


As for changing the rotation length or timing of the mechanic without changing the dll, I managed to do that just fine from the script. But I think that's beside the point.
 
It's those variances in speed that I'm talking about being incorrect. It sometimes slows way down when it should just keep rotating at a reasonable rate. When it does slow way down, it's THEN that it gets confused and the result of that confusion is that it changes direction (and somtimes speed) hoping to find that home switch (as it apparently isn't aware that it has slowed way down probably because the real thing never slows way down like that). I don't think the 360 tweak you mentioned is needed (reducing 1000 to 360 probably just lowers overall resolution; the 0.072 multiplier operation converts it to 72 steps just fine in my code above). The 1 at a time thing might be a little better, but I doubt it accounts for those weird slowdowns and variances that shouldn't be there. It is those variances that I'm referring to as being incorrect behavior. The question is WHY those variances exist.

I'm thinking the problem is most likely to be in whatever code determines which speed to use in the internal mech handler. I think it's simply coming up with an erroneous speed choice or setting. From the VP script side, all you see is the motor solenoid being turned on constantly. I do not think you can see any pulses to the motor there or anything. So however it determines a speed to use must have something slightly off there that it's sometimes selecting a speed that's far slower than it should ever use. I really need to take the time to download the code and look at it (assuming I can make sense out of C code; I haven't programmed in C in 7 years and even then it was just a beginner course.) I actually had more class time in assembly language, come to think of it.

...

I'm also curious if another rom set has the multiball animation I'm used to at the arcade. The usa default set is something I've never seen there.
 
I found the problem with the mini-dmd thing I was trying to do. It seems I was trying to assign a variable to the 2-dimensional array value, which is an object, not a value so it was crapping out. Pointing it directly to the spot instead worked.

For example:

Led(x)(y).state = 1

works whereas

LNum = Led(x)(y)
LNum.state = 1

does not work.

In any case, the DMD is working now and looks more like the real thing now IMO with the grey off shade:
 

Attachments

  • preview_0.77.jpg
    preview_0.77.jpg
    106.8 KB · Views: 1,019
StevOz said:
After thinking about the syntax will this work?

LED( index )( obj ).state = 1

;)
 
PD, the flipper upside down under the right top fliipper has yellow rubber.
 
There are two versions of that flipper from what I've read.
 
Well, the good news is I've managed to create a working 2-speed mini-flipper mech with VPM V1.52 getmech(1) speed data. I basically ignore the position data altogether and only use the speed data instead to create a custom 2-speed mini-flipper mech. It essentially just uses that data to tell it to speed up or slowdown on the extremes. This has the flipper speed up to kick the ball out of the saucer and go crazy during multiball, but keeps a nice steady medium speed the rest of the time the motor is running. I'll try and see if a 3-speed version is stable next.
 
I've got a 4 speed waterworks flipper mech running now that doesn't act up (using only speed data from VPM 1.52, no position data). I'd probably need to watch a real Monpoly to be sure which one actually behaves more accurately. The 4 speed version seems to float through the different speeds too much, IMO whereas the 2 speed allows a lot more cut off leeway so that slow is slow and fast is fast and your eye sees it quite plainly. 4 speed doesn't look like it speeds up much when it does so to kick out the ball whereas you can't miss it on the 2 speed version. The VPM internal mech (when you use position data) looks more like the 2 speed version, but of course it's fracked up in terms of stability (it goes haywire for unknown reasons... going incredibly slow at times and then suddenly reversing directions and speeds because it was moving so slow the home switch wouldn't get hit within a reasonable amount of time). Looking at the actual VPM code, I'm not sure why/how it slows down so much, but apparently the speed data is ok if used alone).

That mech won't work with the DLL Destruk sent me as that seems to get rid of the 4 speeds (has only 1 speed from what I can see from the code and getmech(1) output) and runs way too fast position data wise (due to dropping it from 5000 points to only 360 with no timer change). I recommend VPM stick with the previous code, which apparently is stable for speed, at least even if the position seems to cause problems (a VP mech really only needs one or the other and since the speed data is just a relative number, using speed allows you to alter the individual speeds for each speed change whereas position pretty much stuck you with the internal VPM speed timings, which is why it had so many problems when it was telling it to move so slow for some reason)

I mostly need to mask off the remaining decals with walls behind them, make the sign light reels and tidy up a few bits and then do the final gameplay tweaks.
 
I think I've straigtned out the mini flipper for the most part. It'd help to see the real one in action again, though to compare the speeds, etc.
 
No apology is necessary PD - it's back to 1.52, we're just trying to get it correct so you're happy. Both are just different ways of accomplishing the same thing, and real timing would help, but vp is flexible enough to allow for many possibilities. Perhaps now you understand a bit more of what it's doing.
 
Sign lights are done; pop bumper animations added, etc. It's down to mostly gameplay tweaks now....
 

Attachments

  • preview_0.85.jpg
    preview_0.85.jpg
    107.5 KB · Views: 876
Forum activity
Help Users
You can interact with the ChatGPT Bot in any Chat Room and there is a dedicated room. The command is /ai followed by a space and then your ? or inquiry.
ie: /ai What is a EM Pinball Machine?
  • No one is chatting at the moment.
      Mibs Mibs: GeorgeH has posted a new reply in the thread "How to Install Addressable LEDs".
      Back
      Top