BAM Difference Between BAM_Init and FP_BeginPlay

[GeorgeH]

You guys may already know this but for those that don't, I asked Rav what the difference is between the following 2 subroutines. It seems like they should both start at about the same time.

Sub BAM_Init()

Sub FuturePinball_BeginPlay()

Rav answered by saying:

They are almost same thing.
Only difference is that BAM_Init is executed after 3 rendered frames, after BAM is fully initated.
FuturePinball_BeginPlay() is executed before BAM is full ready to work.
Some BAM functions will not work if you execute it from FuturePinball_BeginPlay but will work from BAM_Init.

 

[TerryRed]

A good practice I've been doing on my latest releases..... is to use a Timer called BAM_Startup_Settings_Delay_Timer set to 1000, and have it run at startup.

' Delay applying BAM Settings on startup (to ensure they get applied each time)

Sub BAM_Startup_Settings_Delay_Timer_Expired
    SetLightsParamsInBAM
    Set_RayCast_Shadows
    BAM_Startup_Settings_Delay_Timer.enabled = false
End Sub

BAM_Startup_Settings_Delay_Timer.set True, 1000

Some things like SetLightsParamsInBAM may not get set correctly depending on the table's startup routine. So by delaying them for 1 sec, this ensures that on the table's first startup, the correct settings are applied. If not, sometimes they may defer to BAM's Default settings instead, and lead to a confused player as to why the table may look too birght, or wrong, etc.

 

[Gimli]

A good practice I've been doing on my latest releases..... is to use a Timer called BAM_Startup_Settings_Delay_Timer set to 1000, and have it run at startup.

' Delay applying BAM Settings on startup (to ensure they get applied each time)

Sub BAM_Startup_Settings_Delay_Timer_Expired
    SetLightsParamsInBAM
    Set_RayCast_Shadows
    BAM_Startup_Settings_Delay_Timer.enabled = false
End Sub

BAM_Startup_Settings_Delay_Timer.set True, 1000

Some things like SetLightsParamsInBAM may not get set correctly depending on the table's startup routine. So by delaying them for 1 sec, this ensures that on the table's first startup, the correct settings are applied. If not, sometimes they may defer to BAM's Default settings instead, and lead to a confused player as to why the table may look too birght, or wrong, etc.

I doesn't really matter and I don't know if it is possible , but I was wondering about not having the DMD's load at all when pup stream is enabled ?

Sometimes it take several seconds for the pup stream to kick in and during that time you see the old DMD stuff.

if pupstream.enabled = True then DMDstuff.FadeOut

 

[TerryRed]

I doesn't really matter and I don't know if it is possible , but I was wondering about not having the DMD's load at all when pup stream is enabled ?

Sometimes it take several seconds for the pup stream to kick in and during that time you see the old DMD stuff.

if pupstream.enabled = True then DMDstuff.FadeOut

Completely separate thing.

That's by design. PinEvent does a check to see if PUP is installed and accessable.... it checks if the actual PUP Display windows even exist / are accessible, etc. Sometimes it can take a few seconds for a pup-pack to completely startup (depending on the table and PC speed).

Even if you have PUP Stream enabled... if PUP can't be detected / accessed... and if the PUP Displays being used for PUP Stream can't be found... then PUP Stream will be disabled on startup. You don't want the FP HUD DMD / HUD Overlays etc fading out immediately if there is a problem with PUP or PUP Stream. It's designed to wait until after all those checks are done before possibly fading out any HUD elements.

In PinEvent_V2_Settings.txt, the PUP_Stream_Delay_Start is what controls how long the table will wait before activating PUP Stream. 3 seconds is usually enough time for a pup-pack to startup, and to allow the table to do all the checks. Shortening this, may cause problems or not allow PUP Stream to work correctly. For some people.... they may need to actually increase it.

 

[Gimli]

Completely separate thing.

That's by design. PinEvent does a check to see if PUP is installed and accessable.... it checks if the actual PUP Display windows even exist / are accessible, etc. Sometimes it can take a few seconds for a pup-pack to completely startup (depending on the table and PC speed).

Even if you have PUP Stream enabled... if PUP can't be detected / accessed... and if the PUP Displays being used for PUP Stream can't be found... then PUP Stream will be disabled on startup. You don't want the FP HUD DMD / HUD Overlays etc fading out immediately if there is a problem with PUP or PUP Stream. It's designed to wait until after all those checks are done before possibly fading out any HUD elements.

In PinEvent_V2_Settings.txt, the PUP_Stream_Delay_Start is what controls how long the table will wait before activating PUP Stream. 3 seconds is usually enough time for a pup-pack to startup, and to allow the table to do all the checks. Shortening this, may cause problems or not allow PUP Stream to work correctly. For some people.... they may need to actually increase it.

Ya, I thought something like that might be the case just thought I'd ask.

 

[madmrmax]

Pulling up an older thread to discuss something -- I'm trying to define a custom Pinball Framework (PF) for me to create tables with. In this, I'm trying to consider different scenarios on what events are needed. For folks that understand "view-model" programming, I'm kinda viewing PF as the "model" while keeping the "View" part in FP.

But as the model it creates new "events" or tells you when to do things. I've been hearing/reading/and looking in the code of many of the awesome table creations and I notice a lot of different places that different things are initialized, etc. Anyway, I'm trying to look at this Pinball Framework a bit "generic" as well as figuring out what I want to do with this for coding up Theatre of Magic.

So, this discussion about FP_BeginPlay, and Bam_Init is interesting because I'm trying to combine them logically into a new "event".

Step 2 and 3 below is what I'm trying to determine what could be best:

Right now, there is a place for the table developer to:

1. "Register" -- this happens before BeginPlay/Bam_Init. Goal is to _specify_ things that affect the startup of FuturePinball with your table (custom loading screen, custom camera, DMD stuff, etc). Including other BAM settings like lights, MiniPlayfields, and things. (Pinball Framework will initialize FizX stuff behind the scenes)
2. "Booting" -- (name TBD, this is the "event" I'm currently working on). Currently I'm thinking about having this after BAM_Init AND FP_BeginPlay.
3. "Booted" -- (name TBD). Currently I'm thinking of having this fire 100-200ms after Starting. This is where the things that table authors have said "need to do X after some 100 or 200 ms timer fires to ensure everything is setup correctly"

There are many other "events" after 3 that are important, but I haven't gotten to this yet.

I'm just looking for feedback -- would having event 2 and event 3 (by default) be enough for the complexities of setting up all the things?

Note: I'm not suggesting that anyone but me will ever use this framework, but due to my engineering background, I like to organize and establish code in a framework-like structure, so this my cross to bear.

thanks for any feedback.
-mark

 

[GeorgeH]

I don't see how you are going to combine FP_BeginPlay and Bam_Init. They are almost the same thing except Bam_Init starts slightly later than FP_BeginPlay.

It seems like you are making this more complex than it really is. I haven't experienced anything that needs to be run after FP_BeginPlay runs until Gimli and I created the tweaker code. We kept getting a string error and we finally figured out that a call to run a sub was stated before the sub had loaded. The tweaker code is pretty long and complex so it is a unique exception. It is the only time I have ever seen anything like that happen. The other guys might have encountered something like this but I sort of doubt it. I am not sure but I do seem to remember that TerryRed said he staggers the start of some things but don't recall why.

 

[madmrmax]

Thanks @GeorgeH! Good to know about the Tweaker code having to deal with a bit more "unique" challenge.

Assuming a combined event for Bam_Init and FP_BeginPlay existed, will it introduce any challenges in building complex tables? Just trying to learn about this, not saying again anyone would use this custom PinballFramework.

@TerryRed I'd love to hear more about your cases (if there are more than the case with PUP_Stream_Delay_Start) where you had to do some things in Bam_init and not in FP_BeginPlay OR even had to create a timer to do additional after those two events.

 

[TerryRed]

I don't add anything to BAM_Init itself, as I've had some things just not work correctly unless they've been delayed for a bit on startup.

I find for anything extra I add during startup that is BAM related... its simply easier to add them to a BAM Startup Delay Timer to ensure all previous startup processes are completed without worrying about some things happening too quickly. Newer PCs can process some things quickly, and I've had odd things happen when not adding a delay for some things. I also have extra things like pupstream, or VR room related stuff that are time sensitive, so its just a good idea to allow all FP stuff and BAM defining stuff to have the time they need to sort everything out first. MOTU CE has a bunch of delayed stuff on startup.


My memory about specifics is not good right now... as I sadly had a HDD failure and lost 2 weeks of detailed work on Silent Hill, and my project files from the last 6 months.... so I'm sorting through that misery right now.

 

[madmrmax]

My memory about specifics is not good right now... as I sadly had a HDD failure and lost 2 weeks of detailed work on Silent Hill, and my project files from the last 6 months.... so I'm sorting through that misery right now.

So sorry to hear about that Terry. I appreciate your response, and I'll take those insights under advisement!

 

[GeorgeH]

My memory about specifics is not good right now... as I sadly had a HDD failure and lost 2 weeks of detailed work on Silent Hill, and my project files from the last 6 months.... so I'm sorting through that misery right now.

I'm sorry to hear about that.

I run a backup of most things once a week to a portable 4 tb SSD. It is handy when I travel so I can access my files on another PC.

I have read that Microsoft One Drive offers 5 gigabytes of storage space free of charge. I just had the thought that it might not be a bad idea to save your FP files to it so you can automatically back it up more frequently than once a week, perhaps like once a day in the overnight hours. If that is not enough space for all your tables, you might do an auto backup of your most current table and leave the rest for the weekly run.

 

[TerryRed]

I normally backup my stuff regularly to my online G Drive and my projects to my external portable HDD drive as those are too big to upload to a cloud. I just didn't upload my latest updated table file to my gdrive, as I've been a wee bit distracted going back to work (military) and the stress of all the political turmoil going on right now.

The main stuff I can't recover were the latest project files for MOTU CE... but luckily, my last backup from 6 months ago had "most" of the latest project files for table art / textures... but none of the pup media project files.

The Silent Hill stuff I can recreate in a couple days since I know what I'm doing... but its lots of other downloads and stuff that got lost that I can't recover. Forced pruning of my digital junk drawers I guess.


I got a new 4 TB M.2 drive that goes up to almost 8000 MB/s, so that will be nice for my newer PC games... and my newest PC won't be using mechanical drives anymore (except for backup mostly).