Tutorial FP Wecoc's collection of script snippets

[JLou5641]

I don't think that's very relevant, since default flippers are very limited compared to what you can do with BAM and FizX. That being said, since you asked, StartAngle and AngleSwing are ReadOnly, but I believe Strength and RubberBounce can be changed via script. I can barely see the difference, though.

In fact, "StartAngle and AngleSwing are ReadOnly" wil be very usefull :D :D

 

[JLou5641]

@Wecoc , just a question, how do you find those "hidden" feature that aren't explain anywhere?

Did you find some other?

 

[Wecoc]

@Wecoc , just a question, how do you find those "hidden" feature that aren't explain anywhere?

Basically I check everything I can think of, in the files or whatever, specially on those "alternative executables" like 2.5R2. And also doing a lot of trial and error. It's just about doing some tests.

I've found some other things, but not useful… more like trivia stuff.
This would be an example. This is not needed at all since a variable does the trick, it's just something that exists and it's not on the manual.

For example, did you know sequence effects (Light Sequencer effects, Queue Texts in DMD & Display, etc.) have an extra option to apply the last one used?

Here are them, in case someone was curious.

seLastDynamic
sbeLastDynamic
SeqLastDynamic
deLastDynamic

Here's another one; apart from "Table" and "Translite" there's a third grid that was meant for a secondary screen, but I don't think was ever implemented. There are also some hidden options on the toolbar like "Security options" (not sure what's that), "Save for arcade" (which was rescued on 2.5R2) and probably a few more. Finally, there are a few things that were later used as a base for BAM, like Ball or Camera implemented as a custom table object, etc.

I may still find a few more things in the future (for example, I never got to open the dev-only Model Editor window integrated in the program) but I don't think there's much more in there. For some time, I thought you could theoretically implement enamel maps on objects other than surfaces, but it seems I was wrong. I don't rule it out, though.

Back to the script snippets, there are some things that are not explained in the manual because they are basic VBScript Functions, which probably many people don't know they are implemented in FP. For example, you could make the DMD say "Merry Christmas" based on the current system date, or make Halloween themed pinballs free to play on Halloween, or things like that. Suffice to say, I've never really used any of this.

 

[Gimli]

Basically I check everything I can think of, in the files or whatever, specially on those "alternative executables" like 2.5R2. And also doing a lot of trial and error. It's just about doing some tests.

I've found some other things, but not useful… more like trivia stuff.
This would be an example. This is not needed at all since a variable does the trick, it's just something that exists and it's not on the manual.


Here are them, in case someone was curious.

seLastDynamic
sbeLastDynamic
SeqLastDynamic
deLastDynamic

Here's another one; apart from "Table" and "Translite" there's a third grid that was meant for a secondary screen, but I don't think was ever implemented. There are also some hidden options on the toolbar like "Security options" (not sure what's that), "Save for arcade" (which was rescued on 2.5R2) and probably a few more. Finally, there are a few things that were later used as a base for BAM, like Ball or Camera implemented as a custom table object, etc.

I may still find a few more things in the future (for example, I never got to open the dev-only Model Editor window integrated in the program) but I don't think there's much more in there. For some time, I thought you could theoretically implement enamel maps on objects other than surfaces, but it seems I was wrong. I don't rule it out, though.

Back to the script snippets, there are some things that are not explained in the manual because they are basic VBScript Functions, which probably many people don't know they are implemented in FP. For example, you could make the DMD say "Merry Christmas" based on the current system date, or make Halloween themed pinballs free to play on Halloween, or things like that. Suffice to say, I've never really used any of this.

Good to have you around again Wecoc !!

 

[GeorgeH]

A group of us just figured out that instead of having to assign constants to all the music and sound in the script you can use this code to adjust all music or all sound in the script. This just sets the volumes initially and the end user can make further adjustments themselves using the PgUp and PgDn keys for music and Home and End keys for sound. By the way, the volume control keys save settings uniquely to each table.

Sub FuturePinball_BeginPlay()

if nvTotalGamesPlayed = 0 then
   nvSoundVolume = 30
   nvMusicVolume = 50
end if

This debug code helps to verify that the code works. One press of the PgUp, PgDn, Home, and End keys changes the volume by 5 percent.

If keycode = 48 then 'B on keyboard
AddDebugText "nvMusicVolume = " & nvMusicVolume
AddDebugText "nvSoundVolume = " & nvSoundVolume
End if

 

[HZR]

Future Pinball's Manual is great for scripters, since it gives detailed info on which functions you have available for your table objects. That being said, it doesn't showcase all the options, and that means there are some things you can do on your tables that probably many scripters don't know about, and in some cases those can be a life changer.

Of course, no wonder some of these things are not included on the guide, since I can't find a single use case for them. For example, did you know sequence effects (Light Sequencer effects, Queue Texts in DMD & Display, etc.) have an extra option to apply the last one used?

I'll be posting on this topic a collection of the (non-BAM) code snippets I find more useful, and probably I'll also include a few more advanced stuff later, this way even the expert coders may find something new to play with.

1. Object properties: Introduction​

Let's talk nomenclature just a little, to make sure we're on the same page.
Table objects have basically three types of callers, and the manual refers to them with these names:
- Script properties
Example: Bulb.State = BulbOn
- Script methods
Example: Kicker.CreateBall()
- Script events
Example: Sub Timer_Expired()

What some people might not know, is Editor properties are also "script properties", so they can be called via script. Most of them are ReadOnly, which means they can't be modified, but it may still be useful to know you can obtain them.

For example, you can use Light.X and Light.Y to obtain the coordinates of a Light, which could be useful to implement some kind of light simple pattern. Coordinates could also be used to calculate the distance between two triggers, and with the help of a timer, you could even get an approximation of the speed of the ball through a lane. Of course where we run BAM flies, but this approach could be enough in some cases.

Another example: You can use DropTarget.BankCount to check how many Event IDs a DropTarget includes, so with this you could make a function that checks every single one independent of how many targets that specific bank has. As you can see, the script properties usually have the same name as in the Editor, without any space or special character.

The default script has only one example usage of this. The variable LastSwitchHit defines the last trigger object that was hit. To check which one it was, it uses its name string, therefore using the editor property Trigger.Name:

If (LastSwitchHit.Name = "PlungerLaneTrigger") Then
    bBallSaverActive = True
End If

You may not be convinced of its potential yet, but I needed to explain this in order to move on to those properties that can be modified via script.

2. Advanced Kickers​

One of the most important properties you can modify via script is Rotation. Sadly, that's not particularly usable in those objects with a collision box, since it doesn't change its rotation. Hope's not entirely lost though, because some object types can use models with "Per polygon collision" instead. Kickers use that option.

You can modify many Kicker properties in real time.

- Rotation
You can easily make a "Two directional kicker" that launches the ball up or down depending on where it came from (you would check this with two invisible triggers). If the kicker model is symmetrical, the rotation won't be visible, only its effect.

Dim LastTriggerPressed ' 0: Up, 1: Down

' Update the variable LastTriggerPressed
Sub UpTrigger_Hit()
    LastTriggerPressed = 0
End Sub
Sub DownTrigger_Hit()
    LastTriggerPressed = 1
End Sub

' The Kicker is Hit
Sub DoubleKicker_Hit()
    If (LastTriggerPressed = 0) Then
        ' Look up
        DoubleKicker.Rotation = 0
    Else
        ' Look down
        DoubleKicker.Rotation = 180
    End If
    ' Launch the ball to the current position
    DoubleKicker.SolenoidPulse()
End Sub

You could also make a PinBelt that launches the ball to a random direction, like a very basic magnet release. You will need a MakeRandom function for that:

' Function to get a random number between two numbers (both included)
Function MakeRandom(ByVal min, ByVal max)
    MakeRandom = CInt(Int((max - min + 1) * Rnd())) + min
End Function

Sub PinBelt_Hit()
    PinBelt.Rotation = MakeRandom(0, 359)
    PinBelt.SolenoidPulse()
End Sub

- Kicker Type
You can set your Kicker's type (Directional or VerticalUpKicker) via script.

Kicker.KickerType = 0 ' Directional
Kicker.KickerType = 2 ' Vertical

On this example, a vertical kicker launches the ball to a wire ramp, but on TILT it simply releases it back to the playfield. In order to release it properly, you will have to define its angle on the Editor, even if the model Kicker-Hole-T3 doesn't look rotational. I would recommend making a custom model that makes it clear the kicker is "double".

Sub VerticalKicker_Hit()
    If (fpTilted = True) Then
        ' On Tilt mode, release the ball back to the playfield
        VerticalKicker.KickerType = 0
        VerticalKicker.Strength = 1
        VerticalKicker.SolenoidPulse()
    Else
        ' By default, launch the ball to the wire
        VerticalKicker.KickerType = 2
        VerticalKicker.Strength = 7
        VerticalKicker.SolenoidPulse()
    End If
End Sub

- Strength
You can set the Kicker's strength via script, from 1 to 9. With this, you could make a Kicker that launches the ball harder the longer you've pressed the Plunger key, for example. Usually you will use this for more basic cases, for example on the previous examples you may want to change the strength when you change directions as well.

- Ball Weight
When you create a ball, you can define its "weight". Without BAM this is a cheap trick, but it kind of works…
The idea behind this has nothing to do with the kicker, nor the ball; what you have to change is the table slope. That change doesn't apply on current balls, but it does apply on new ones. This way, to make a very "light" ball first you would set the Table Slope to 1, create the ball with a Kicker, and set the Table Slope back to its default value again. Note the Table has a Name property as well, just like any other object in the Editor, that's why this is possible.

' Create a "plastic" ball
Sub CreatePlasticBall()
    ' Store the default table slope
    Dim DefaultSlope : DefaultSlope = NewTable.TableSlope
    ' Set the slope to 3 to create a light ball
    NewTable.TableSlope = 3
    ' (You may want to make the ball a different colour)
    CaptiveKicker.CreateBall
    ' Set the slope to the default value again
    NewTable.TableSlope = DefaultSlope
End Sub

Since this is a bit weird, I would only recommend using it for captive balls, to control their resilience to the player ball. For more complex cases, you could theoretically assign a special BallID to "plastic" balls and modify other object's strength (or effect) based on that, when the ball hits them. Remember, you can set a custom color to the ball as well, to make that more clear… I haven't even tried any of that, though

Well, I talk way too much. This is all for now, but there's still more to come!
I hope you find this useful!

is there a way to call default camera views and adjust them?
like future pinball camera views. scrolling and switch to full table and then back to scrolling?
Sub CreateView()
Dim DefaultCamera : DefaultCamera=NewCamera.CameraView
' cameraview 1-scrolling 2-scrolling2 4-fullTable 5 -etc (name of views)
' 8 future pinball views
NewCamera.CameraView=1
' functions like switch to full table for multiball then back to scrolling
NewCamera.CameraView=DefaultCamera
End Sub

or something like that?

 

[AnonTet]

Go to bam menu a assign a key to change the cameras (default fp cameras)

 

[TerryRed]

@hellrzr2k1

In script you can call to a BAM "static" camera view only, and then you can call to release to the last camera view chosen by the player (BAM static camera view or FP camera view. Whatever the player last used with C key or Function keys, etc). I don't think you can call to one of the specific predefined FP camera views

You create a Static Camera view by using the BAM menu, going to Camera, adjust your camera view to what you want (F11, then mouse and WSAD to move), then go to either a Global setting or Table setting and use SHIFT+ENTER to save it. Then while highlighting that setting, you CRTL+C to copy the settings to the clipboard. Then when in table script you paste the BAM Static Camera view.

Look at the latest Sonic Pinball Mania for examples of switching to a BAM static camera view (for the MagnaSpinner or MB), and then resuming back to whatever the player is using for the normal Camera view (release).

 

[HZR]

Figured i would ask. I have the docs from this site and others about scripting but they are vague son I look at code. With limited time and working g 140hours every 2 weeks i never sleep..its 230am and I work at 8.. cant sleep..

 

[GeorgeH]

@Wecoc

I discovered by accident that ramps have assigned names although they are not displayed anywhere. The first wire ramp added to a table is named WireRamp1 and the first plastic ramp is named Ramp1.

I discovered this by trying to name an object "WireRamp1" on a table that had a wire ramp and noticed it would not accept the name. So I performed a "Find" for "WireRamp1" and found it highlighted the wire ramp. Then I guessed that a plastic ramp on the same table might be named Ramp1 and verified it using the same method.

Since ramps are named, I suspect that other unnamed objects on tables have hidden names also. It might be useful if these names can be used in code but I haven't tried it yet. I figure that if anyone could find a use for this info, it would be you.

 

[AnonTet]

You can use xbam.dumpallobjectsname
Launch a table, exit and use ctrl-v on any notepad if you want to know more.

In case I spelled this wrong, just look at the first lines of cosmic princess. I'm pretty sure it is there.

 

[Wecoc]

I discovered by accident that ramps have assigned names although they are not displayed anywhere.

@GeorgeH Every object in the table has a name! Try going to Edit -> Find and search "Peg1", for example. The table doesn't let you rewrite their name, but they still have it stored, and to define it they simply use the default way to name objects, which is the class name plus the first available index. The name of each class is always pretty obvious as well. That may help locate small things easier in the editor, although I've rarely used that ever.

That being said, one thing is having a name property defined, and another is having an accessor for the object in the script. If you try to read "Peg1" directly in the script (as you do with, for example, "Light1"), it won't find it and an error occurs. I believe BAM has some options to access those types of objects using a handler, and that can be used to change their texture or more complex things like that... but by default, those objects are inaccessible via script.

 

[AnonTet]

xBAMFindObject
Also seen in FizX code

 

[HZR]

@GeorgeH Every object in the table has a name! Try going to Edit -> Find and search "Peg1", for example. The table doesn't let you rewrite their name, but they still have it stored, and to define it they simply use the default way to name objects, which is the class name plus the first available index. The name of each class is always pretty obvious as well. That may help locate small things easier in the editor, although I've rarely used that ever.

That being said, one thing is having a name property defined, and another is having an accessor for the object in the script. If you try to read "Peg1" directly in the script (as you do with, for example, "Light1"), it won't find it and an error occurs. I believe BAM has some options to access those types of objects using a handler, and that can be used to change their texture or more complex things like that... but by default, those objects are inaccessible via script.

to find those tough tiny objects, unlock everything for one.
then search the name and narrow it down to 1 layer, then when you search for the name notate the items position, then on the bottom left go to those coordinates.

 

[GeorgeH]

to find those tough tiny objects, unlock everything for one.
then search the name and narrow it down to 1 layer, then when you search for the name notate the items position, then on the bottom left go to those coordinates.

It really doesn't help to know the name of an object because it can't be used in the script. I guess that is why Rav created the "GetObject" script.

 

[HZR]

It does, if you can't find a tiny surface etc unlocking helps for one, and the mouse cursor has x and y, just match them and you will find your hidden item.
I haven't tried the get obj, I dont understand some of the bam commands as the definitions are vague , for me anyways.
This pertains to finding an item on the table.
Edit/find/ type item name.
When it finds it set your mouse to the x and y of the item.

 

[GeorgeH]

It does, ...

How does it help you?

 

[HZR]

turn overlays on or off, fadeout isnt working.
Can you Actually make a overlay go Away enable / disable?
I havent tried commands. I looked at the bam.dll for class methods and didnt notice anything
I have 3 overlays ontop of each other, 3 different texture lists/ movies.
they play different times, fadeout seems to be the right way but I cant get it working correctly.
Im about to just do a a pup lite version, but thats a lot more work than anticipated.

 

[TerryRed]

NameofOverlay.fadeout

NameofOverlay.fadein

is all you need.

The Future Pinball manual is the first place to check for that stuff.

 

[HZR]

it doesnt work, i usually go to the manual

do I set a timer to turn off the overlay once its finished, it fades in ok,
but when I stack them they dont fade out

 

[TerryRed]

Works fine here. You can't have it fade out right away I think (if its fading in). you may need to wait until its completely faded in, etc.

 

[TerryRed]

If you mean, you want the overlay to fade out when a video is done playing... it won't do that for you.

You do need to use a Timer (or other table event) to have it do that for you when you want... or not have it fade out and have it change to a transparent texture.

 

[Popotte]

Works fine here. You can't have it fade out right away I think (if its fading in). you may need to wait until its completely faded in, etc.

Not really

 

[Popotte]

it doesnt work, i usually go to the manual

do I set a timer to turn off the overlay once its finished, it fades in ok,
but when I stack them they dont fade out

I think you have a problem with your code.
3 overlays with their image list exactly at the same place and you get that

 

[GeorgeH]

it doesnt work, i usually go to the manual

do I set a timer to turn off the overlay once its finished, it fades in ok,
but when I stack them they dont fade out

The fade out only works on Hud overlays and DMD. You can't fade out overlays saved to the backbox but you can display an invisible frame; in fact, it is best to list an invisible frame first in the image list so you don't see it when the game starts up.