Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Full-physics pinball machine?

Scalar Tardis
SL Scientist/Engineer
Join date: 5 Nov 2005
Posts: 249
09-11-2006 04:47
Well, I'm embarking on a huge project, to see if it's possible to build a fully physical and working pinball machine. I'm looking for any experienced scripting help to make this work.

I've played with lots of gears and done many physical motion experiments so I know that in general this should be workable. I just need to make everything huge to deal with the lack of precision in the physics engine. And so I'm using a 1m x 1m x 1m sphere as the reference size.

Even without any scripting, these flippers move on the hinge axis correctly. The size may be a problem since the Havok engine doesn't like things with lots of mass, so I've made it 98% hollow:




But many script-driven games involve a linked set containing all objects. At this scale, the table can easily reach across the 40-meter linking limit so it's not going to work to put everything inside a single linked set. The objects are probably going to have to talk to each other over a sim channel since they can't be linked.

Another problem is going to be scripting speed. Can the engine keep up with a fast-moving ball, to detect it hitting a bumper and kick it before the ball bounces away?




And to make it harder yet, I'd like things to be as physically real as possible. Most of the kicking could be done with llPushObject but if possible I'd like an actual physical kicker to hit the ball. I don't know if it's possible to fire a plunger and have it travel a certain distance and hit with a certain impact power.




I am aware that full physical motion of this rubber-band kicker is not going to work.



But a close approximation can be done by breaking the band in half and rotating the two pieces at each end slightly. Here's an end-rotation example that already moves correctly using rotation in the object editor:



But I have no idea if a rotation movement like this can be forceful enough to kick the ball hard like real band-kickers do.


There is one place where llPushObject will be at home, and that's with this simulation of The Power in The Addam's Family pinball machine ("Feeeeel the Pooower....")



Two magnet coils under the table push and pull the ball around in odd ways. Though for a pinball machine that might have multiple balls in play, llPushObject may have a problem since it needs to know the key of the object to push. and I'm not sure how it can be able to know what ball is nearby it to be pushed/pulled. I don't want it pushing on all balls such as the ones in the ball hopper, and I'd lika high force-rolloff factor just like with a real magnet.


And speaking of the ball hopper...



Ideally there'd by absolutely no rezzing/derezzing of the balls if at all possible. Everything is as physical as can be, including the ball return and ball ejector. This will need little kickers to lightly pop the ball up the the ramp and into the launcher chute, as well as some sort of ball detection mechanism.

Probably this is best done with phantom versions of the wire triggers used in real pinball machines. When the ball rolls through the phantom trigger, the ball's key can be read and sent to the kicker, as well as monitoring for scoring and lost-ball error conditions.


I'm open to any scripting ideas on how to make this work, whether here or in SL. Note, I don't own any land and so I just rez this from my inventory in a sandbox to work on it. If there's someplace it needs to call home so people can work on it, I'll see about purchasing some tier..
Yumi Murakami
DoIt!AttachTheEarOfACat!
Join date: 27 Sep 2005
Posts: 6,860
09-11-2006 07:15
Aindreas McGee has already made such a machine, although a simple one: /invalid_link.html . So it is definately possible! :)
NeoBokrug Elytis
Master Blaster
Join date: 1 Nov 2005
Posts: 35
09-11-2006 07:41
I saw you buildin' this yesterday, Was gunna give you tips but then descided against it. But, trying making the ball and playfield out of the material type: Glass. Much better results on movement.
Scalar Tardis
SL Scientist/Engineer
Join date: 5 Nov 2005
Posts: 249
10-04-2006 01:03
One of the big problems with trying to do this, is that so many actions need to be synchronized across so many separate prims. Since they cannot be linked together, message passing is going to have to be used.

The most secure communications route seems to be listens that only respond to messages from a certain key, but since I have no land and this thing is so huge, the only reasonable place to work on it is in a sandbox. As far as I know, every time I pull it out of the inventory, everything gets a new key, so I cannot use that for secure object-to-object communication.

Am I going to be forced to use one of those complicated message encryption schemes to handle communication? Maybe it'd work to just use the encryption to pass the initial object keys when rezzed, and then set the listeners to establish their communications after that via the keys only...


I'm sure it's far too lofty a goal just starting out, but I'm planning to try and build a relatively accurate simulation of the Addams Family pinball machine, complete with sound effects, score-keeping, and a functional dot matrix display. Hell, I still don't understand how to make the flippers even hit the ball, but nevermind that. I'm moving on to the easier stuff first... :)


I already see that I can store dot-matrix display animations by making a single texture with multiple animation frames and sliding the texture around on the prim face to simulate the blinking, flashing, and dancing animations.

Using a series of stacked transparent prims, it'd be possible to store all the dot matrix animations as a series of very low-resolution frames. Transparent prim stacking would allow me to cheat where the score is onscreen with countdowns and other animation. Use one prim for the animation, one to hold the counter, and ten prims to hold each digit of the score.

There's no need to try and actually simulate EACH dot of the dot matrix display, though I suppose that too is possible... just would need about 128x48 listener scripts, one in each dot, to accept matrix animation commands. (What was that I've heard about minimizing listeners on a sim??? Oh well..) ;)


But if this can be made to work even partially, it'll be a miracle. I am not a coder by trade, so it's very hard to get much of anything accomplished.

I am SO happy just to have the balls circulating in my auto-firing ball-return, ball-kickout, auto-plungers, and pop-bumpers, as it is now.
Scalar Tardis
SL Scientist/Engineer
Join date: 5 Nov 2005
Posts: 249
I am getting unhinged here...
10-04-2006 02:54
Okay, I've sort of figured out a way to make the flippers work, except this method really is no solution. :(

I can do it using the evil Linden-unapproved hinge joints, which we cannot make anymore. But I was able to res a hinged wheel from my inventory and modify it into a flipper test.

My idea is to:
1. Use a hing or hinge-like swingarm
2. Make the flipper-hinge physical
3. Use hard end-stop prims to limit flipper travel
4. Use llPushObject to kick the flipper-hinge from one end-stop to the other, and whack the ball in the process

And a simple mockup using my old wheel object works! (The yellow wedge is the hinged physical part, and the red and green blocks are the end-stops.)

http://img176.imageshack.us/my.php?image=hingedflippergw0.png

I cut the original hinged-wheel cylinder down to a wedge and it seems to work fine. Except for some reason I cannot resize the wedge or it disappears and breaks on me, so this object cannot actually be used as a flipper-hinge to get around the no-make-joints limits of the client.

Any suggestions as to how I can do this WITHOUT a hinge?? :(



Advanced hinged-flipper control option (not tested yet):

- Make the flipper physical, and move the using llPushObject to kick it from one end-stop to the other
- After allowing a second or so for the flipper to move. make it non-physical again to hold it in either the up or down position. This reduces physics processing and deals with ball ricochet and bounceback issues.