FP LoadExternalScript vs. 'Copy Paste' for Script Libraries

[SpacePirateScott]

What is the best practice for including a .vbs library into your table script. As far as I know there are two ways:

One is to include the script via the LoadExternalScript command
e.g.

ExecuteGlobal LoadExternalScript("SPSColorSequencer_v0_1.vbs")

The other is take the contents of .vbs and directly paste it into your table.

LoadExternalScript

• Pros
  
  • Updating the library is easy, just copy the new .vbs into the scripts directory. All tables using it are automatically updated
  • Easy to add to table. Add one line of code.
  • Doesn't add 1000's of lines to your table script that you have to navigate when editing the script
• Cons
  
  • Copying a new version of the library may break existing tables
  • Table installation is more difficult because you have to provide the library file and it has to be copied into the scripts directory
  • May cause issues with anti virus software.

Copy / Paste into table script

• Pros
  
  • All table code is contained within the .fpt file.
    • Easier installation, only one file to copy
    • Won't be affected by when installing other tables that overwrite the library with a newer/older version
• Cons
  
  • Clusters up table script code
  • Copy past is hard? :)
  • Each table will have to updated independently if there are bug fixes in the library

Personally think I will include instructions for both, but recommend the Copy/Paste approach

Thoughts?

 

[GeorgeH]

I think it is better to avoid using it and just save the code in the script. An example is DOFLinx.vbs. It was problematic for awhile until I submitted a copy of it to Microsoft for them to review and remove a false positive from Windows Defender antivirus. It did however help to implement DOFLinx to the cab guys. Unless you are going to create something that is used by a lot of users, I would say it is best to avoid using it. You can just provide code that an end user can insert into the script on their own.

 

[Popotte]

For me, LoadExternalScript is better (if you just change some bugs).
A looooooong time ago, James (Greywolf) made his tables with his core machine. He made a lot of changes without breaking nothing.
Obviously, if you make deeper changes with the logic and/or parameters, ... it's an other story.

 

[TerryRed]

I've done both for PinEvent and for FizX. I definitely prefer keeping code in script for many reasons.

The problem with loading external script files is, it only takes one person to include an older / incorrect version of that file (or a file with the same name) with their own release / modded table etc. Then when anyone installs their files, it will mess up potentially many tables from a different creator.

On my older version of PinEvent and PinEvent tables, I used multiple vbs files for the different features thinking it would be easier to update in the future if needed for all tables. Problem was, a table modder (who has been banned from all sites for other reasons) kept including out of date PinEvent vbs files with their releases, even though they weren't used with their mods (PinEvent = my releases only). This resulted in many people having out of date files that caused many headaches for me. I asked this person to remove the files, and they never did. Using external files never ended up being a benefit. It just caused more problems. The tables wouldn't run without the correct files, etc.

So, for PinEvent V2 (and Lite), I completely redid everything and made it all self-contained on the tables themselves. No external files are required to allow the table to run. I do use a single txt file for global PinEvent settings (PinEvent_V2_Settings.txt), but if that file is not found or detected, then the table will bypass it and use the Custom PinEvent settings in the table script as a fall-back.

With FizX, JLou initially thought keeping Fizx code would be better in vbs files.. I fought tooth and nail to try to help him understand why it was a bad idea for something like that. After MANY FizX updates that completely changed the functionality many times, (making older tables with older FizX related code / settings not compatible with the new FizX core code)... it was very clear keeping the physics code contained within each table was the right decision.

 

[SpacePirateScott]

it was very clear keeping the physics code contained within each table was the right decision.

I was going to give both options, but I agree with you on this.

 

[TerryRed]

I also don't like using Library files for the same reason. It only takes one person to use a modded version of a library file (or use the same name) to mess up many tables. This isn't 2005 anymore. Storage space is not a concern anymore for table files.

I prefer to try to make sure my tables / mods won't be vulnerable to someone else's files messing them up.

 

[GeorgeH]

I am not in total agreement on library files although I do agree somewhat. I have posted a few tables where I have 2 versions of audio files that have different audio themes that the end user can exchange. It is much easier to do it that way than to have to code every sound with 2 options. If you do the coding option, you have to load both versions of the audio into memory that can bog down the response time.

 

[madmrmax]

I think it also depends upon if you have multiple people contributing to a table. Having that separation at development time can be quite helpful.

Also, one tip -- don't use the .vbs extension. It will help reduce some anti-virus checks. It's just a plain text file, so use .txt.

 

[Wecoc]

Some Future Pinball scripts are generic classes with functions that may be used in different ways, pretty much like an external library. For example, imagine you make a custom DMD class with a lot of drawing options that extend or even replace the default. That works very well as an external script, because it's pretty much like an extension of the object functions you get on FP/BAM, and the user is not supposed to modify those codes, but implement them on their table's code instead. I've released a few scripts like that (it also helps to separate the functionality core to the demo itself). Some old codes by Propst come to mind that were pretty much the same deal, but they are pretty rare cases.

Most pinball codes aren't like that, and in that case I strongly suggest NOT to use external scripts, for the reasons others exposed. If you post a code here for others to use, for the most part you should assume they may need to modify it in some way for their pinball, so in that case external script is a no-go, it makes things way too messy. Also, most codes aren't that long, so it doesn't make sense to use an external file either.

All that being said, even in the first case where external scripts "make sense", offering both options is better practice, and would recommend the user to paste the full code on the table as a preferred option, even for the sole purpose of searching on the code or having more info on how everything works.