Using BAM's generic Hit to get Hit event for object? (need for fx sounds)

[madmrmax]

For Theater of Magic I have custom sounds when the ball hits the magic trunk. The problem is that very few FP objects support a Hit method. I'm using a Peg model type for the magic trunk model which of course doesn't support Hit.

Is there a way to use BAM's Generic_Hit or SetSharedHitCallbacks for Peg and ALSO know in the code that the object being hit is the Trunk?
FP and BAM knows the ball hit the Trunk object, but I just need to be told about the hit. Perhaps there is an opportunity for a new BAM Hit specific event request (e.g. register for a specific Hit event for a specific object)

I would hate to switch to not using per-polygon hit on the Trunk model and instead use hidden walls to duplicate the experience, just to get a Hit event from the walls.

I've thought about placing multiple hidden triggers (opto or star type) around the trunk but that doesn't guarantee that a trigger hit matches a ball hit to the trunk.

Thoughts?

 

[TerryRed]

Yah, that's the problem with any model type that doesn't have a "Name" in the editor... they don't register a unique hit that can be called in script.

FizX code uses Generic_Hit to define special item types that are identified by name so we can have different rubber settings per rubber item, drop targets have different physics settings, etc. "How" to do that is beyond me. :)


Myself... I would place the Trunk toy outside of the playfield, and setup 4 invisible walls with different names for each side of the Trunk. This would allow each wall to have simple / efficient collisions and register a hit (then you can use a _Hit sub for sounds, or anything you want), and you can disable collisions as you want on the fly.

Then use a BAM mini-playfield (set to enable Physics Move) to capture the Trunk / walls area outside the cabinet and position it where you need. Then using the miniplayfield tool you can rotate the trunk and all walls, and lights etc as one item with all collisions and lights working like normal. the only thing you can't use within a miniplayfield tool would be something like a kicker (that would need to still be on the main playfield).


This would give you max flexibility with both animation, and physics collisions.


Most of what you see for this stuff in vpin land is smoke and mirrors. Fake it until you make. How you do it doesn't matter as long as it works well in the end.

 

[madmrmax]

Agreed on that approach! I currently have the Trunk in a MP (mini-playfield) already, I just didn't want to have to deal with drastic changes to the physics of things to get a Hit event. I already have to adjust the Collidable values of the MP as well as the MP's PhysicsMove value to ensure the magnetic field correctly adjusts (this is all logic that @Paolo was able to figure out along with help from Rav).

Thanks for the response Terry! I'm also going to mess around with changing the Trunk's model type to be a Target just to see if things could easily change.

 

[GeorgeH]

Is there a reason you can't change the model to one that has a name? Perhaps one of the following:

toy
Gate
Spinner
Trigger
TriggerOpto
SpinningDisk
AutoPlunger
Bumper
Diverter
EmKicker
Popup
Flipper
Target
DropTarget
SwingTarget
TargetVari

 

[madmrmax]

Yup. Changing the object type to Target worked fairly easily to get the hit event! I wonder if there are certain "Named" object types (FP objects with a Hit event and a Name) which would be as light weight as possible (if there is any issue).

 

[TerryRed]

Yup. Changing the object type to Target worked fairly easily to get the hit event! I wonder if there are certain "Named" object types (FP objects with a Hit event and a Name) which would be as light weight as possible (if there is any issue).

They all would use whatever colliders you define in FPM Editor, which is usually fairly simple (cube, sphere, etc). That can be almost any combination you want. Not all colliders need to have a hit event, as you can use some for control to prevent unwanted _hits.

The details of the model if using "per polygon collision" would be more demanding than anything... but you normally don't need that unless you are talking about a ramp-like model.

 

[madmrmax]

Oh good point. I was generally always using per polygon collision on the models, but something simple like the trunk I might get away with just using a box collision shape. I'll try that out!

 

[TerryRed]

Oh good point. I was generally always using per polygon collision on the models, but something simple like the trunk I might get away with just using a box collision shape. I'll try that out!

You could try one flat box for each side, and possibly have a separate _hit for each side associated with the same object. You may need to read the FP manual for more explanation of how that may work.

 

[TerryRed]

One thing to note... more advance targets like Roto Targets or Vari-Targets won't work in a mini-playfield for full physics collisions. Same goes for some things like flippers, slings, diverters (for collisions) and kickers. Basically the more advanced physics based items.

 

[TerryRed]

Honestly though... I would just use your model as it is, with no collision for the basic box... and use the surface / walls for each side, and a mini playfield. This would still allow you the most flexibility and total control of collisions should you need to disable them. A "target" model won't offer you those options.

 

[GeorgeH]

Yup. Changing the object type to Target worked fairly easily to get the hit event! I wonder if there are certain "Named" object types (FP objects with a Hit event and a Name) which would be as light weight as possible (if there is any issue).

Perhaps my lack of intelligence worked in my favor in this case.

 

[Paolo]

I would hate to switch to not using per-polygon hit on the Trunk model and instead use hidden walls to duplicate the experience, just to get a Hit event from the walls.

Yes I understand what you mean, when I worked on the trunk my goal was to have polygons to avoid possible walls and at the same time have free passage (side with window) which fp does not allow if you create an entire model with polygons, regardless of which extensions you create it in (bulb, target, trigger, etc etc)
So I didn't have in mind that each side of the trunk had its own sound, now with bam(Generic_Hit, bla bla) there is the possibility to create "hit events", to be able to add a sound,....ok, but....

I'll start by saying that; I've always used invisible walls, for everything, there's a bit of code to do but it allows me to have all the control, now in trunk there are 4 sides right? and if I understood correctly there are 4 sounds, right?......

It could to try (I can) create 4 separate sides with "hit event" collisions (the pink mask)... obviously position them in the correct position so that with MP they turn as if they were a single model, obviously the most complicated part, if everything works as I'm imagining with my mind now while I write.... it's the side with the open window.
I have an idea if it works.....but I wonder if a simpler solution wouldn't be 4 invisible walls? because I think the side that works the most is the front side, the remaining 3 sides if I'm not mistaken are not hit with the ball in play, right?

 

[Popotte]

Do not confuse object and collision model.
You can have an object and his collision model (for example) is 10 cm in front it.
So, you can create a little cube (or just a single vertex as model, but a little bit difficult to select it...) and after create 1 box collision shapes (just a little less smaller in order to avoid _hit for the front face). For the open part, you just to have 2 collision shapes.
If your trunk is a toy, you know the exact coordinates, so it will be easy. Create collision shapes seems to be difficult but not (and I'm not a specialist, but I have created a lot of new models for my recreations).

 

[Paolo]

None confusion, we discuss to achieve the unthinkable.....every idea could become something, after all I'm not a programmer or a code mathematician, but I have animated(model) a bit of everything in my creations, with or without collisions,regarding certain "fpm" objects now with MP, you can basically animate or move anything you want.
By the way about JP codes, do you know how to use, or would you know how to use the codes xbam.Ball....or xbam.BallCloseTo? for a specific event?

 

[Popotte]

By the way about JP codes, do you know how to use, or would you know how to use the codes xbam.Ball....or xbam.BallCloseTo? for a specific event?

I can't answer without some more explanations

 

[Paolo]

I can't answer without some more explanations

Ok.... we are talking about the magnet.....I explained also Here ......waiting for Rav, who perhaps creates another property of the magnet that is easier to encode in these cases..., I'll explain better to you.

I would like to be able to tell my magnet to only attract one the ball in play(current ball) and not other balls like in multiball.
Now with this property .SingleBall=ball I can tell the magnet not to attract other balls... =ball is the key.....ok, I hope that's clear so far.

Here is the part that is practically impossible for me to understand, Rav tells me that; I can find "ball" on the table, in 2 ways:
xBAM.ball assigned to something from code handling _hit event. Like: "when ball hits objects, pull this ball with magnet".
xBAM.BallCloseTo called when you know, that there is one or more balls on table and you want to select one close to something.

The problem is......; how and where to insert them?
I tried to insert "xBAM.ball" which seemed easier to manage in a hit event (in a kicker) before activating the magnet, but I got an error,so I gave up.

 

[GeorgeH]

I don't know if it will help or not but I found the following code on one of Gimli's tables:

MagneticField_0.SingleBall = xBam.BallCloseTo(233.25, 230.25)

I don't know much about the code but it appears that "BallCloseTo" uses the X and Y coordinates on the table. Evidently, you can use the coordinates of a table object also as Gimli did here:

MiniPlayField_0.TrackedBall = xBam.BallCloseTo(Kicker7.X, Kicker7.Y)

I don't know anything about the "xBAM.ball" code.

 

[Paolo]

Yes....I looked at the tables where Bob had some dealings with the magnet,and I noticed those codes, but they are assigned to the magnet with the pendulum, and a locked ball CaptiveKicker ....and so I didn't try them since they were for other contexts and not for what I would like to do
I focused on "xBAM.ball" based on Rav's suggestion, and I didn't try xBam.BallCloseTo.....but I'll try MagneticField_0.SingleBall = xBam.BallCloseTo with the coordinates of the magnet itself and see if it works.....

Thanks for the tip G