Suggestion: Make xBam.BallCloseTo(x,y,z) return nothing when there are no balls close to position

[madmrmax]

I was hoping there was a concept of BallCloseTo returning Nothing/Null if there really isn't a ball close to those coordinates. Unfortunately, it appears that BallCloseTo always returns something, even an "empty" ball.

set testBall= xBam.BallCloseTo(TrunkMagnetBallReleaseFront.X, TrunkMagnetBallReleaseFront.Y, 0)
if IsNotNothing(testball) then
AddDebugText "test ball X=" & testBall.Position.X & ", Y=" & testball.Position.Y
else
AddDebugText "test ball is nothing!"
end if

When I do this code even before I create a ball on the table, it returns something. Then if there is at least one ball on the table, regardless of where it's at, the ball is returned. Ideally "close to" actually means something more when a ball "is not close to" position.

thoughts?

 

[Popotte]

As you have the coordonates of the ball, just tests them (for example 250 < x < 350, ...).

 

[Wecoc]

You're not defining a radius, so "close to" is ambiguous. And what if there's more than one ball near those coordinates? Would you be interested in "Ball Closest To" or it should apply to all? I guess it can depend on the context...

Even though you could make a formula that calculates the current distance, calculating that for every ball constantly would cause lag. It would probably be better to use a trigger; some kind of detector that simply activates when a ball crosses the region's limits.

I think the intents of the function "BallCloseTo" are not about what you're trying to accomplish; it's basically a shortcut to get a ball directly involved in something, for example the ball involved in a hit or trigger of something that doesn't have that property defined.

 

[madmrmax]

You're not defining a radius, so "close to" is ambiguous. And what if there's more than one ball near those coordinates? Would you be interested in "Ball Closest To" or it should apply to all? I guess it can depend on the context...

Even though you could make a formula that calculates the current distance, calculating that for every ball constantly would cause lag. It would probably be better to use a trigger; some kind of detector that simply activates when a ball crosses the region's limits.

I think the intents of the function "BallCloseTo" are not about what you're trying to accomplish; it's basically a shortcut to get a ball directly involved in something, for example the ball involved in a hit or trigger of something that doesn't have that property defined.

I believe you're spot-on with the true meaning of BallCloseTo. Great point!

As you have the coordonates of the ball, just tests them (for example 250 < x < 350, ...).

Good point! I'm trying to get a reference to the ball that is connected to the magnet on the magic Trunk. Right now, I find the ball that is connected to the magnet via a special kicker (red below) that gets me the reference to the ball (as the ball intersects with this kicker when it is on the magnet). The purple kickers are used to simulate the ball "dropping" from the magnet because unfortunately turning off the BAM magnet on the trunk causes the ball to fly in weird directions and not just drop. (as an FYI - The trunk is where a majority of my challenges with kicker "Z" height comes into play.)

Ok that is all good, but in some weird instances, in weird cases, the ball might become stuck on the red kicker and not ever "drop". I'm trying to determine if this happens and see if I can perform some logic to fix it. I was hoping BallCloseTo would almost have a max range that could be specified.

 

[Paolo]

MP=miniplayfiled function

@madmrmax
Ok....maybe I'm saying something wrong, I'm not a mathematician, so I hope to help by giving some information...Honestly not knowing what you are trying to create or solve regarding the trunk, i can say something about it, since i have worked on it.If I remember correctly I also explained it to you via PM.

The magnet has limitations, its physics don't work inside a MP, and as far as I know the ball physics don't work inside a MP either, so to simulate what the trunk does, I came up with some tricks with those kickers.

Regarding the magnet, I'm also having problems, it doesn't allow me to not attract other balls into play, I spoke with Rav about this too, suggesting me to use BallCloseTo together with .SingleBall, to be clear.... this codeMagneticField_Light.SingleBall = xBam.BallCloseTo(MF_light.X, MF_light.Y).......I also asked @Wecoc HERE. and I think he gave you the same advice( but that's not the point for me) but of this"xBam.BallCloseTo" I'll talk about it later...

I understand that the trunk is involved many times during gameplay, and those kickers that simulate the ball (catching and falling) may not work sometimes.....and I'm very sorry about that

For those who don't know what you see in the videos, both mine and Mark's, the ball that turns 180° (either to the right or to the left) attached to the magnet is the image of the ball.....the real ball, better ball physics, remains in the position where it is captured,(point A) perhaps this image can help to understand better



So those kickers are there to get the real ball from point A to point B.because the magnet inside a MP does not spin/turn/rotate the real ball, but only the image of ball,the magnet does not rotate together with the MP, it remains in that position of point A,so those kickers take the ball off the magnet.
Now I talked a lot about this with Rav, maybe a solution that could work to eliminate the kickers, but Rav was clear, there is a lot of work and calculations to do, I don't know if it's easy for you Mark, maybe Popotte could help... but you have to calculate every single "frame" including the position of the magnet y,x,z during the rotation from point A to point B......If I still have Rav's answer, I'll send it to you in PM......in practice how many "frames" does the magnet draw from point A to point B? if you are capable of that, you can rotate the magnet inside the MP, together with the MP, but the question is will the real ball rotate together with the magnet while it is active? i.e. the captured ball, obviously the captured ball must be outside the MP

At the time while I was working on it I discarded this probable solution, because it was too mathematical for me, and since the way I had conceived it worked for me.

Returning to the"xBam.BallCloseTo" I don't understand what you want to use it for, on kickers or something else, but for the magnet it doesn't work.... if you think it can solve the trunk problem, as I said above, I thought to solve my magnet problem in Space Cadet, using this property, but it didn't work for me, this property if suitable for the pendulum ball like in JunkYard... @Gimli would be the right man who could explain better

Ok that is all good, but in some weird instances, in weird cases, the ball might become stuck on the red kicker and not ever "drop". I'm trying to determine if this happens and see if I can perform some logic to fix it. I was hoping BallCloseTo would almost have a max range that could be specified.

I don't remember having inserted two kickers, there in front, I don't understand why the ball has to fall from that red kicker in that position? if it is to simulate the catch or the release of the ball, in that position the magnet has to do it, which in the original position works, I don't know what happens but this kicker is also taken from the MP?

Note: As I highlighted in black above, I hope I'm not saying the wrong things

 

[madmrmax]

Thanks @Paolo ! Great explanation!

the magnet inside a MP does not spin/turn/rotate the real ball, but only the image of ball,the magnet does not rotate together with the MP

I didn't fully understand all the details about where the magnet actually goes. I had thought that the ball stayed attached to the magnet during turning but something when turning off the magnet causing physics to do something.

I don't remember having inserted two kickers, there in front, I don't understand why the ball has to fall from that red kicker in that position? if it is to simulate the catch or the release of the ball, in that position the magnet has to do it, which in the original position works, I don't know what happens but this kicker is also taken from the MP

Correct. I had to add an additional kicker to the front to mirror the kicker in the back. There is one modes in TOM (Clock / Midnight Madness) where the magnet side is shown and the user hits it with the ball, the ball attaches to the magnet, and then the ball is drop from the magnet back to the playfield. The user tries to hit the magnet like this as many times in ~20 seconds. I needed a good effect of the ball dropping from the magnet back to the playfield, so the additional kicker in the front does that.

Returning to the"xBam.BallCloseTo" I don't understand what you want to use it for, on kickers or something elseT

In truth, my question isn't related to the trunk or anything. At a high level, as I work to create a pinball framework model for logic controlling, I wanted to simulate a physical pinball's switch states. Kickers in Future Pinball only have a Hit method. There is no method/property that can say "the ball is in the kicker". This causes problems when attempting to simulate that in real pinball machines there is a Switch and a Solenoid. Since FP only tells you when the ball is Hit the kicker there is no way to know when the ball has left the kicker.

I was hoping I could verify some things using GetBallNear(x,y,z) to know when the ball has left the kicker.

I even tried creating an invisible Switch with the hit test the same size as a Kicker, because a Switch has an Unhit event. But as soon as the ball goes into a Kicker, the ball kinda is removed from the playfield as this Switch actually fires an Unhit.

 

[Paolo]

I didn't fully understand all the details about where the magnet actually goes.

@madmrmax
The magnet doesn't go anywhere, it stays there, in this position


PS:now i noticed that red kicker

I had thought that the ball stayed attached to the magnet during turning

Not Unfortunately......as I said above the magnet does not rotate the real ball, but only the image of the ball, this is what Rav told me.

but something when turning off the magnet causing physics to do something.

Obviously...... with "Fizx" physics everything changes in a table, absolutely everything!!!
So also the magnet, unfortunately in my video it works well, because I have standard physics, this was my mistake, but if you pass me the updated table with that "Clock / Midnight Madness" mode, I can try to set the parameters for an optimal ball release....I am "quite familiar" with magnet.
If you want....

I needed a good effect of the ball dropping from the magnet back to the playfield

I wonder what kind of effect? Did you see the effect I created in SC?

Since FP only tells you when the ball is Hit the kicker there is no way to know when the ball has left the kicker.

Ok for event hit....a question....maybe I'll say something stupid......but when using the "destroy/create" property, with a timer(between two kickers), the Fp engine doesn't know when (via that timer) where "we", are sending the ball to another kicker? if so.... maybe there is a way to know where the ball is going.....you could put some invisible kicker here and there, to know where the ball goes, obviously this costs too much code ....
.I belive,and if it works.

Now in Dragon Keep, Rav, has created a system for me where the ball (via kicker, and not "destroy/create" property, but mathematical code to direct the ball into the dragon's mouth, with its nice effect.

I even tried creating an invisible Switch with the hit test the same size as a Kicker, because a Switch has an Unhit event. But as soon as the ball goes into a Kicker, the ball kinda is removed from the playfield as this Switch actually fires an Unhit.

Ahhhh...mmmm....ok sorry for the question, not knowing what the kicker in question does, have you tried putting a surface over the kicker?
what do you mean by Switch? a trigger,dro-target......what??? why there is the property of Unhit?
"actually fires an Unhit" I do not understand

Rav, maybe a solution that could work to eliminate the kickers, but Rav was clear, there is a lot of work and calculations to do, I don't know if it's easy for you Mark, maybe Popotte could help... but you have to calculate every single "frame" including the position of the magnet y,x,z during the rotation from point A to point B......If I still have Rav's answer, I'll send it to you in PM......in practice how many "frames" does the magnet draw from point A to point B? if you are capable of that, you can rotate the magnet inside the MP, together with the MP, but the question is will the real ball rotate together with the magnet while it is active? i.e. the captured ball, obviously the captured ball must be outside the MP

Have you considered this solution?

 

[Popotte]

@madmrmax said Since FP only tells you when the ball is Hit the kicker there is no way to know when the ball has left the kicker.
Yes, you can: create an invisible switch just side of the kicker and a flag KickerHit (set 0 at initialisation). When the ball hit this switch (before entering the kicker), nothing to do as KickerHit = 0. Then the ball enter the kicker, so set KickerHit to 1. Then the ball hit the switch and as KickerHit = 1 so do what you have to do (and reset KickerHit to 0). Just my opinion.

 

[Wecoc]

I think there are many ways to approach this.

Without BAM, the solution would be destroying the ball and creating another one as a Toy, moving it around, and creating a new ball back in the other position. I've used this trick a few times in my tables. With BAM you can control the ball's position by frame so the Toy's not required; you could force its velocity to 0 and keep changing its coordinates accordingly in the NewtonPhysicsTick getting basically the same result (I don't know if BAM has a function for balls similar to the Toy's "MoveTo" but if it doesn't, it could be defined like this with some math). Another solution, and here's how I'd probably do it, is with a Miniplayfield. The invisible kicker traps the ball, and then the Miniplayfield rotates everything in the zone (including that kicker), and finally releases the ball back, getting that "grab-rotate-release" effect. None of these solutions use a Magnet.

I also want to point that there's a magnet entry in the XML used for custom physics, and the Magnet used by BAM is a handle of those same magnets, so that line still applies. If the only problem here is Fizx changes the magnet's physics in an undesired way, I'd try tweaking that.

 

[Popotte]

If the trunk is a toy, an other solution could be have 2 toys. one only the trunk and the other the trunk with an attached ball.

 

[Popotte]

Otherwise (as @Wecoc said), with NewtonPhysicTick, you can know the angle of the trunk, so you can calculate where the ball should be.

 

[madmrmax]

Ok so I think I've kinda caused the discussion to go a bit sideways.

I'm fine with the Trunk experience as I have coded it up now (all based upon what @Paolo did!). It supports everything I need. You can see the video at this post with everything working and the effect looking great! https://pinballnirvana.com/forums/threads/theatre-of-magic-help-build-the-theatre.22973/)

The BallCloseTo discussion I started is really about finding if a ball was in a kicker or stuck someplace.

Regarding the "trigger" I created and placed on top of the kicker, but that didn't work correctly. The trigger is just a square hit area. as defined below.



In FP I place the trigger over the kicker and then output the kicker_Hit event, triggerKicker_Hit event, and triggerKicker_Unhit event you'll see that as soon as the ball is in the kicker the trigger's unhit event is fired.

Since FP only tells you when the ball is Hit the kicker there is no way to know when the ball has left the kicker.
Yes, you can: create an invisible switch just side of the kicker and a flag KickerHit (set 0 at initialisation). When the ball hit this switch (before entering the kicker), nothing to do as KickerHit = 0. Then the ball enter the kicker, so set KickerHit to 1. Then the ball hit the switch and as KickerHit = 1 so do what you have to do (and reset KickerHit to 0). Just my opinion.

I like the idea @Popotte, use a trigger around the kicker and look for that to get hit.