Monopoly WIP

[PacDude]

The sad thing is if I had about 1-3 more full days I could probably get an initial vesion released before Christmas. Oh well....

 

[PacDude]

I just threw together a backglass based backdrop really fast. I think it came out OK.

 

[Shockman]

I think it's better than OK. You still have the P3 1 gh?

 

[destruk]

It looks good, but some parts look scrunched, or pushed down a little. For the spinner, this is an overhang-type spinner support - so there shouldn't be any side support posts for it. I've attached a picture. Having the support post to the playfield surface does impact gameplay as it could block a shot to the standup. Of course I know vp doesn't have what is required, but I do have a solution made up which works somewhat - I'm sure you could improve it if you'd like. Just let me know, ok?

 

[PacDude]

I've toyed a bit with the spinner, but so far I haven't found a way around that left side support, so I'd be interested to hear about a solution for it. Raising the spinner above the playfield didn't achieve satisfactory results, so I'm guessing it's something else.

 

[destruk]

The only two viable ways I've been able to come up with for it is to use a trigger on the playfield to get the ball speed where the spinner is, and then update the spinner graphic itself with an emreel, or with ball images raised above the playfield. Two ball objects are sufficient - one of the left side of the spinner, one for the right.

With the new ultracade vp you can turn off the 'supports' with a checkbox - real easy solution.

 

[PacDude]

Yeah, that reminds me of the gate elasticity thing in VP6 versus VP7. It's like why bother with creative workarounds when the new VP already has it fixed....

 

[yogiholzer]

I like that backglass based backdrop much more than many other backdrops. Not too importunately, but gives table most attention.

 

[marv75]

Yes I agree that backglass fits in quite well.:)

 

[tiltjlp]

The only two viable ways I've been able to come up with for it is to use a trigger on the playfield to get the ball speed where the spinner is, and then update the spinner graphic itself with an emreel, or with ball images raised above the playfield. Two ball objects are sufficient - one of the left side of the spinner, one for the right.

With the new ultracade vp you can turn off the 'supports' with a checkbox - real easy solution.

But if UltraCade has to turn their improvements over to Randy, we might not ever have them officially released. I'm sticking with 6.1 for now.
John

 

[PacDude]

Starting to fiddle with the plastic ramps. I'm not sure this method will work out in the end, but....

 

[kristian]

WOW!!!!

It feels like Christmas!!! But wait... it IS Christmas!!!!

PS: Monopoly has black, rugged side rails & lockbar. They look almost plastic in real life. Try filling the bar & rails with Filter -> artistic -> film grain and then darken them to almost black. That's how I created the black rails for Tommy (DE games use the same type of rails).

 

[yogiholzer]

I agree, wow!!!

That looks more real than a photo of the real table.
http://www.pinballzone.com/view.php...dex.php&title=Monopoly - Lower Playfield View

 

[davidsss]

Those plastic ramps look awesome, I don't know how you get the tables looking so real but it's quite amazing.

DS

 

[Joe]

WOW!!!!

It feels like Christmas!!! But wait... it IS Christmas!!!!

PS: Monopoly has black, rugged side rails & lockbar. They look almost plastic in real life. Try filling the bar & rails with Filter -> artistic -> film grain and then darken them to almost black. That's how I created the black rails for Tommy (DE games use the same type of rails).

WOW!!

 

[PacDude]

I don't want the rails darker than they already are. They're already almost black. They wouldn't even be visible at that point.

 

[kristian]

You don't have to darken them more. I meant that the surface of Stern rails look almost plastic. That's why I suggested the "film grain" option.

They're not metallic at all... they have crispy looking black plastic/vinyl surface.

Hmm... apparently not all Monopoly tables have rails like that... this one seems to have standard metal rails. Never mind what I said...

 

[destruk]

About the flipper mechanic - the home switch was removed from the simulation because 1) no owner bothered to time the flipper rotation for all three speeds, and 2) the home switch isn't pulsed at the 0 position. So it was decided before release to allow authors to handle the home switch - makes it easier as we don't need to keep adjusting it in the dll if it's wrong. The mech should work that way (with the switch closure/open in the update subroutine) or you can come up with your own handler - whichever you like best. The mech handler internal will handle the three speeds, but we still don't have an exact timing for a complete rotation.

monopoly.c

#ifndef VPINMAME // must be disabled, as the switch is set by script in VPM
core_setSw(30, locals.flipperPos < 33);
#endif

 

[PacDude]

The problem I'm seeing is that the internal mech handler will start the simulation at a very slow "pulsed" speed and change directions searching quite often before it finally starts behaving normally. This starts before any switch is hit, etc. If it starts wrong, it's going to start acting weird as the game starts changing the solenoid settings when the home switch isn't hit after so many seconds. The problem is the motor isn't moving fast enough to hit the switch when it starts that slow and yet the internal handler completely controls that.

If I make my own mech handler, I have no speed control at all so you get a 1 speed version of the mini-flipper. It works, but it doesn't do that cool speedup effect when you land the saucer like it does when it uses the internal handler (assuming its functioning ok by that point). It's hard for me to say WHY it doesn't work right with the internal handler without seeing the code (I guess I could donwload the source code), but if VPM output the power setting to the solenoid somehow, I could just work on a fully custom handler with speed control and I'm sure I could find the right timings at that point to get it working 100%.

BTW, the rom is happy even if I only run the switch on 2 frames out of 72 total that I use. The slowest speed works ok at around 4 seconds a turn, but gets unruly much after that. The full speed rotation is somewhere between 1-2 seconds a turn, I think, so I'd imagine it's like 1 second, 2.5 seconds and 4 seconds for the three speeds. It might be a little off, but that's a rough estimate.

 

[destruk]

The very slow pulsed speed would be when it's looking for the home switch to be closed. The vpm output to the solenoid is running quite fast. Koz sent a PM about it er...3 years ago? Anyway he said something about feeding 24 pulses to the solenoid to determine the speed - it's highly complex. As for source code, go to sourceforge.net and download monopoly.c - it's all right there and notepad would show you the 16KB file. Speed ranges 0,8,16,24 - meaning that many pulses to the solenoid per some timeframe to get the speed, then the home switch is maybe done over 8 of those depending on speed. The internal mech handler should work for you since you just need to set the home switch at any value between 0 and 33 for the mech position. None of the vpm solenoids have a power variable except for on/off - otherwise capcom would work better too.

 

[PacDude]

I'm not seeing any pulses to the motor solenoid here. It appears to be constantly on during testing. As I said, the internal mech has some issues like starting up slow and acting weird until it tries some more speeds and then finally starts rotating normally. I have tried a number of frame ranges for activating the home switch (odd how the operator menu says it's switch 40 when it's really switch 30) and that doesn't seem to matter since the startup glitches happen before it ever even touches the home switch (e.g. it will start somewhere on the opposite side by the switch and just barely be moving and then reverse directions and then reverse them again at a higher speed and finally after hitting the home switch once or twice it will start moving normally (sometimes longer).

I wonder if I had the startup script pulse the switch a few times if that would get it moving sooner. I'll play with a few more things, but ultimately using the internal mech puts the system out of my control. The speed is predetermined. I could modify the length by modifying the number of steps to hit the home switch, but that's about it. Using a custom mech, it's quite easy to control those things, but then I see no way to get the motor speed other than to check getmech(1) which only returns +/- 0-4 values. I tried using that to guide the speed, but then it gets all choppy movement and sooner or later it freaks out.

 

[destruk]

The current waterworks flipper position is controller.getmech ( 0 )
The current waterworks flipper speed is controller.getmech ( 1 )

Clockwise is positive speed, counter-clockwise is negative speed. The speed will fluctuate quite quickly - really for smooth animation you'd just need to use the internal handler and look at the direction (positive/negative speed) to decide which way to move the flipper, and then at set intervals, or when the direction changes, compare the current and the previous position of the flipper. If the flipper is somewhere between 0 and 33 set the home switch, and clear it if it's outside the range.

 

[destruk]

As for the motor always being on - it will run in the diagnostics test constantly when you tell it to run, until pulsed or until the menu exits. That must be the way the real machine works in diagnostics (not much chance to get that incorrect). The OFF/ON display is for the directional relay solenoid.

 

[destruk]

sample code would be something like

Sub Timer1_Timer
Textbox1.Text = Controller.Getmech ( 0 ) 'Position
Textbox2.Text= Controller.Getmech ( 1 ) 'Speed and Direction
If Controller.Getmech ( 0 ) < 50 and Controller.Getmech ( 0 ) >0 Then
Controller.Switch ( 30 ) =1
Else
Controller.Switch ( 30 ) =0
End If
AnimateFlipper
End Sub

With timer 1 set to 1ms, or set it as a solmotorcallback

 

[PacDude]

I'm not sure you're understanding what I'm saying as your post isn't telling me anything I don't already know. I've tried all these methods of making the mini-flipper work already:

Method 1> Direct control by internal mech using the getmech(0) (i.e. position) data. This method works the most lke the real thing, but it slows to a crawl at times for no apparent reason (you can see this if you just run the DMD in full debug mode and put a simple timer in place to activate switch 30. It will not run consistently each time you start the table. The flipper should move at a slow to medium speed when the game starts and sometimes it will, but other times is CRAWLS (watch how slow the numbers move) and then the game wonders internally why the home switch hasn't been activated (because it's going too slow to get to that position which tells me it SHOULD NOT be going that slow PERIOD or the game wouldn't go into "search" mode where it starts reversing the motor and altering speeds. The problem is when it switches back to the same direction it's usually moving the same CRAWLING speed (we're talking maybe 20 seconds to make 1 revolution SLOW type speed here) and so it then switches back yet again. The really funny thing is that if I land the ball in the saucer while it's acting all crazy slow, the game will suddenly kick the flipper into high gear and move much faster and then it starts acting normal again... for awhile until you land another saucer shot and then it might start acting up again.

I can ONLY conclude there's something fracked up in the internal mech handler as the flipper should NEVER move that slow and yet ONLY VPM is controlling that position code using this method. The ONLY thing I do is set the switch 30 to activate across a small range around position 0 (the same range Gaston recommended).

Method 2> VBS mech handler. This uses the onedirsol method with both solenoids. This has two odd behaviors and one major limitation. The major limitation is there is no speed control. The two odd behaviors are that the flipper motion is slightly jerky (not smooth despite having 72 frames so it SHOULD be smooth) and I think that's due to the odd timing behaviors associated with the VBS mech handler under some circumstances and the other issue is that you have to order the frames backwards because the VBS handler has no way to tell it the direction to go with the 2nd relay solenoid. It defaults to the wrong direction (i.e. it's going counter clockwise whereas I numbered the frames clockwise so I have to reverse them since I can't reverse the default direction in the VBS mech handler as there is no switch for that.

3> Custom Mech Handler. This method uses a simple timer control for the animation and switch data and uses solenoid 27 with a flag to determine which direction to count. I can easily set the correct direction just by changing the flag value. Solenoid 25 controls whether the timer is running or not. This results in ultra smooth visual operation and correct directional behavior as long as the timer is set within a valid range (8ms-52ms or so per frame with 72 frames works OK; if you go much slower, the flipper will start acting up in that "search" mode again (which tells me that the game was never designed to have that flipper move slower than a certain rate or it thinks its broken). The only problem with this method is that there is no speed control. The flipper will always move at the rate the timer is set to. That is functional, but not accurate to the real behavior, whic has the ability to move at different speeds.

4> Custom mech code but using getmech(1) (i.e. speed/direction) data to alter the timer interval so that method 3 might work yet have speed control. I've tried just using 3-4 set possible speeds and using a 2nd timer to "smooth" (acclerate and deaccelerate) while "switching gears" so-to-speak so it doesn't just suddenly start moving much faster/slower. Neither method works right. The speed data is too limited coming off that getmech call with only 4 possible values for each direction (1-4 either positive or negative to indicate direction). You might think well that means there's only 4 distinct possible speeds for that flipper and it would be OK. Nope. It fluctuates between those numbers very quickly, resulting in odd/choppy/jerky looking motion (not totally dissimilar to the jerky movements in method #2, but a lot worse since it's speed related to the internal mech handler data being shoved out, not just a timer issue. I thought maybe using a smoothing timer would help, but it just seemed to make things worse overall. Worse yet, the speed data seemed to get the position all out of sync somehow (probably because the speed data coming off that get mech is wrong or too limited) and that then causes more weird "search" behavior soone or later and VERY choppy behavior at that since the speed data seems to go wild in that mode.

Basically, I know of no other possible methods to do a mech handler for that mini-flipper. Method #3 is the only "reliable" method in the sense that the flipper motion is constant at least and doesn't do weird things like slow to a crawl or move jerky or get out of sync. But it can't speed the flipper up. Method #1 behaves exactly right at times, but it seems to suffer from kicking into majorly SLOW speeds that the game just doesn't expect to see (I'm guessing there's an error in the handling code as it should never move that slow and the motor solenoid just comes on; it doesn't pulse so it's the internal speed calculations that causes that internal position and speed data to go to a crawl, etc., not the solenoid callback signals.

I mean the fact is if you try these methods yourself on a little mock setup (you don't exactly need to make the whole table to test the flipper out since it's just 2 solenoids and a switch and a few dozen flippers flipped through using the ".visible" attribute, you'll quickly see that what I'm saying is true.

They best fix would be to correct VPM's mech handler so those "too slow" speeds never occur as those are what screw things up. Again, I'm not sure offhand what exactly is causing it to go that slow at times internally. It has nothing to do with the switch position, but the internal speed calculations where apparently something is a bit off.

Otherwise, the only other option is to just use a single speed handler as described in method #2.