BAM BAM - Request for support to remove need of Execute and Eval

[madmrmax]

Looks good @ravarcade! Dictionary object works great. I validated that the errors which the Dictionary object can fire are properly processed in script.

The xBAM.Item("objectName") is awesome as well! Works great. I was expecting an error to be raised if the table object referenced by "objectName" doesn't exist, but no matter. Simple checking for nothing is good.


For the new xBAM.Call "callback_subroutine_name" -- This is such a game changer! I assume the reason for using frame count vs. milliseconds for delay_in_physics_frame is to keep you from having to time math in every call inside frameTick/Newton Tick? I wonder if the function could be easier for people to use if it just was milliseconds. Can you share any insights @ravarcade on why physics frame vs. milliseconds?

 

[ravarcade]

@madmrmax: I selected physics frames, because it is less confusing.
With 256 FPS for physics engine. There is fake impression, that you can add 1 or 2 ms... but it is not true. 1 frame is 3.90ms. So, less than that is 0 frames.

2nd reason: In many case i wanted to set very small value, like 1-3 frames, just enough time to break ball contact with object.

If you prefer passing float value in seconds or ms, just let me know and i will change it.

 

[madmrmax]

If you prefer passing float value in seconds or ms, just let me know and i will change it.

I'd love to get other people's opinions. @TerryRed, @GeorgeH, @JLou5641, @shiva, @Popotte, and @AnonTet thoughts?

I personally prefer milliseconds with the note that "This method does not support time smaller than 4ms. Anything requesting below 4 seconds will fire as soon as possible"

So, option would be to special case <4 ms to fire immediately, or just treat it to fire at 1st frame/first opportunity.

 

[GeorgeH]

I don't know enough about it to know which would be best. The other guys would know more than me.

 

[TerryRed]

Anything involving math... I'm the wrong guy to ask :)

@ravarcade

Since we've got you here, I wanted to mention one thing I've noticed (this is not a new issue, its been a bug for a long while). I have noticed it more while working on MOTU CE. BAM's flipper shadows work great, but I find that sometimes the right flipper shadow will flicker a bit when there are multiple balls on screen. I'm not sure if there are any other factors that cause it, but when there are multiple balls on screen it tends to happen easier. When you get down to fewer or one ball then the flickering goes away. This only happens on the right flipper.

Beyond that, though, the new BAM update has been running stellar with MOTU CE which is getting closer to being done.

 

[madmrmax]

@madmrmax: I selected physics frames, because it is less confusing.
With 256 FPS for physics engine. There is fake impression, that you can add 1 or 2 ms... but it is not true. 1 frame is 3.90ms. So, less than that is 0 frames.

2nd reason: In many case i wanted to set very small value, like 1-3 frames, just enough time to break ball contact with object.

If you prefer passing float value in seconds or ms, just let me know and i will change it.

After some thoughts here, yes I think changing to milliseconds would be the best experience for table builders without requiring them to understand frames and time. Let me know if you are able to make that change and release another beta build. I'll test it out!

-mark

 

[ravarcade]

Updated version with ms units: https://ravarcade.pl/beta/BAM_v377.zip
Post: https://pinballnirvana.com/forums/t...e-need-of-execute-and-eval.23189/#post-155771
is also updated.

 

[Popotte]

For me, frame is better than ms (in the case of low ms).

 

[madmrmax]

For me, frame is better than ms (in the case of low ms).

Can you share more details? What does frame mean to you? Lastly, would you be using it with frame #s in the low <5 value? Just looking to understand usage more.

 

[TerryRed]

Frame time means it will only be updated for each frame drawn in FP. This is synched to whatever FP runs at.

So if FP was locked to 60 Hz (most people), then Frame Time only updates 60 times / second. If it was 120Hz, then 120 times per second.

Frame Time can be handy if you only want to update something visually such as lighting, or toy animation, etc. Something that needs very precise math such as physics needs much more than that.

 

[Popotte]

But Rav speak about physic frame not screen frame (I think): With 256 FPS for physics engine. There is fake impression, that you can add 1 or 2 ms... but it is not true. 1 frame is 3.90ms. So, less than that is 0 frames.
But if we can have both (physic frame and ms), why not.

 

[TerryRed]

For FizX tables, the physics frame is now running at 512 fps :)

 

[Popotte]

So, 1,9 ms... Do we need a shorter time?

 

[madmrmax]

Perhaps someone does need shorter time (shorter than 4ms), but do we need a generic BAM function of "call this method after X milliseconds" to support it? Sounds like a job for a high-resolution timer or use something like NewtonPhysicsTick?

I'm not opposed to it, just trying to understand what all the different scenarios are for what we want out of the new BAM function.

FWIW, FP's Timer's bottom interval is 10ms. In "general" anything less than 30ms is not human-perceivable in real time.

For FizX tables, the physics frame is now running at 512 fps :)

So using Frame time would be more frustrating for a table author if perhaps a frame length can vary. That is why I had thought that milliseconds is the best way to go -- 1) MS is used for other timing related things in FP, and 2) easier to deal with if frame length can vary.

 

[ravarcade]

Here is small update: https://ravarcade.pl/beta/BAM_v378.zip
added:
- xBAM.CallAtFrame - it works exactly same way as xBAM.Call but delay units is number of physics frames.
- xBAM.Physics.FPS - current "FPS" value. Read only. In case someone want to do manual calculations.

 

[madmrmax]

Here is small update: https://ravarcade.pl/beta/BAM_v378.zip
added:
- xBAM.CallAtFrame - it works exactly same way as xBAM.Call but delay units is number of physics frames.
- xBAM.Physics.FPS - current "FPS" value. Read only. In case someone want to do manual calculations.

Hello @ravarcade - what needs to happen to convert the beta release into a new release number? I'm working on using these new functions and I'm wondering if betas get turned into retail release after some point or if they just remain Beta until someone asks.

Ideally when the time comes the Beta would be fully released. Let me know if there is anything you need from me!

thanks!
-mark

 

[TerryRed]

Hello @ravarcade - what needs to happen to convert the beta release into a new release number? I'm working on using these new functions and I'm wondering if betas get turned into retail release after some point or if they just remain Beta until someone asks.

Ideally when the time comes the Beta would be fully released. Let me know if there is anything you need from me!

thanks!
-mark

Just a heads up... I'll be including a BAM beta update of 1.5-380 with a new FP and BAM Essentials AIO update I'm releasing very soon (it's needed for MOTU CE).

 

[madmrmax]

Just a heads up... I'll be including a BAM beta update of 1.5-380 with a new FP and BAM Essentials AIO update I'm releasing very soon (it's needed for MOTU CE).

Cool to know! I assume the Betas versions include previous beta features (e.g. -378)? I think the AIO update will be a great way to get 380 out there as many folks will try your MOTU CE table. Still, it I hope Rav could help me understand if he is looking to publish a new release version on his web site (currently at -373)

 

[GeorgeH]

Hello @ravarcade - what needs to happen to convert the beta release into a new release number? I'm working on using these new functions and I'm wondering if betas get turned into retail release after some point or if they just remain Beta until someone asks.

Ideally when the time comes the Beta would be fully released. Let me know if there is anything you need from me!

thanks!
-mark

Rav always releases all betas in the next version. I would think beta 378 would be included in beta 380. The released version is always numbered higher than the beta. Rav would normally release a new version sooner than this. I don't know what the hold up has been. There have been a few times I released a table and included a copy of the beta with, telling those that download it that a version would be forthcoming. It looks like Terry will be doing that also.

 

[madmrmax]

@ravarcade I'm getting a crash when attempting to use xBam.Call inside a Hit event. It produces an access violation which also DOES NOT produce a bam_crash log doesn't produce. I've attached the table that repros the issue. Just hit the ball into the scoop hole.

'------------------------------------------------------------------
'    Hole under Trunk (front and back)
'------------------------------------------------------------------
sub TrunkFrontHole_hit()

    TrunkFrontHole.SolenoidOff
    xBAM.Call "TrunkFrontHole_DestroyBall", 300
end sub

sub TrunkFrontHole_DestroyBall(arg)

    TrunkFrontHole.DestroyBall

    xBAM.Call "BasementKickOutBall", 600
end sub

Sub BasementKickOutBall(arg)
    BasementCover.Collidable = false
    BasementKickerOut.CreateBall()
    BasementKickerOut.SolenoidOn()
    BasementCover.Collidable = true
end Sub

Faulting application name: Future Pinball.exe, version: 1.9.2008.1225, time stamp: 0x4d1d68d3
Faulting module name: Future Pinball.exe, version: 1.9.2008.1225, time stamp: 0x4d1d68d3
Exception code: 0x40000015
Fault offset: 0x00126640
Faulting process id: 0x3EAC
Faulting application start time: 0x1DB6786B8EB75AD
Faulting application path: D:\Program Files\Future Pinball\Future Pinball.exe
Faulting module path: D:\Program Files\Future Pinball\Future Pinball.exe
Report Id: f40e1adc-b9b9-452e-ae29-41fccf403e84
Faulting package full name:
Faulting package-relative application ID:

 

[madmrmax]

@ravarcade In addition, I noticed that xBam.Call crashes if I pass in a script defined Const value.

Const cTrunkHole = 3
xBAM.Call "RotateTrunkTo", 300, cTrunkHole

Sub RotateTrunkTo(pRequestedFace)
 '...
End Sub

 

[Popotte]

I think you can't have a xBam.Call in a xBam.Call.
The followed script is OK.

'------------------------------------------------------------------
'    Hole under Trunk (front and back)
'------------------------------------------------------------------
sub TrunkFrontHole_hit()

    TrunkFrontHole.SolenoidOff
    xBAM.Call "TrunkFrontHole_DestroyBall", 300
    xBAM.Call "BasementKickOutBall", 900
end sub

sub TrunkFrontHole_DestroyBall(arg)

    TrunkFrontHole.DestroyBall
Exit Sub
    xBAM.Call "BasementKickOutBall", 600
end sub

Sub BasementKickOutBall(arg)
    BasementCover.Collidable = false
    BasementKickerOut.CreateBall()
    BasementKickerOut.SolenoidOn()
    BasementCover.Collidable = true
end Sub

 

[Popotte]

@ravarcade In addition, I noticed that xBam.Call crashes if I pass in a script defined Const value.

Const cTrunkHole = 3
xBAM.Call "RotateTrunkTo", 300, cTrunkHole

Sub RotateTrunkTo(pRequestedFace)
 '...
End Sub

For me, it's work.
Press left flipper key in order to rotate the toy.

 

[madmrmax]

For me, it's work.
Press left flipper key in order to rotate the toy.

Thanks for looking into this Popotte! I think in my case it was an aspect of a "xBam.Call" within another "xBam.Call". If I used a Const it would crash, but if I used a variable (Dim) it wouldn't crash. I think I'll work first on the Call within a Call thing.

 

[madmrmax]

I think you can't have a xBam.Call in a xBam.Call.

@ravarcade - can you comment if there is a possibility of removing this restriction? It really hampers the usability of the method. Every time I want to use it in a function/sub, I'll have to look at what functions might call that other function and ensure there isn't a chance of nesting.