Fancade has a hard script limit. After a certain number of scripts in the editor, adding anything else will cause a "Too many scripts" error. The game will refuse to run as long as the extra scripts are not removed. Games that do not optimise scripts affecting multiple objects into loops are most likely to run into this issue.

History

Advanced Inspect

  • Script limit has been a mystery for a long time. An elusive upper limit that creators randomly hit, and are forced to scrap their ambitious project. Fancade 1.2 significantly improved the scenario by introducing Advanced Inspect blocks. Those blocks, when enabled, showed how much of the script limit has the game consumed already.

Optimized Scripting

  • For the most ambitious of projects script limit has proven itself to be the greatest wall, leaving the very same projects abandoned, scrapped or just barely hanging on the limit unable to get new game features and mechanics. In Fancade 1.11.3 however, "Optimized Scripting" feature has been introduced, significantly reducing script limit usage and effectively giving more freedom in coding complex games. With this feature only the first instance of the custom block put into the level counts every script inside it towards the script limit, the additional instances of the block then contributes only 1 point each to the script limit.

  • As you can see in the first picture the script consumes about 5% script limit. The second picture then shows that 2 instances of the same script still consumes about 5% of the script limit rather than 10% of it.

Technical Details

The introduction of advanced inspect allowed for more robust testing, which helped in discovering some key insights regarding the elusive script limit. Among those, Andrew Clark's discoveries were crucial for our current understanding of it.

Current Understanding

The limit is 4096. The value doesn't matter as much as how you decide to use them. There are four things that consume the script limit:

Script blocks

Every script block counts as 1 script towards the total limit. It does not matter which script block it is, as long as it is an inbuilt script block, it adds 1 to the counter. The attached image has 4 script blocks, thus the script consumption is 4/4096 or roughly 0.1%.

Wire splits

A wire split counts as 1 script towards the limit. Thus the script in image A adds 4 scripts (3 script blocks + 1 wire split) to the counter.

But wire splits are defined as "n to 1" and "1 to n". This basically means, no matter how large the split is, it will add only 1 script to the counter. The script in image B adds 10 scripts (9 script blocks + 1 wire split) to the counter.

The same applies in case of joining. The script in image C counts as 4 scripts, whereas the script in image D counts as 10 scripts.

Pointer dereferencing

This section will be easier to understand if you are somewhat familiar with the concept of pointers. If you are not, you can think of them as an address. Specifically, a memory address, that points to a variable. When a pointer is dereferenced, i.e. converted to value, it counts as 1 script. In image E, the Get Variable block outputs a pointer, which is then dereferenced to a value for the Negate block. Thus the script adds 3 scripts (2 script blocks + 1 pointer dereference) to the counter.

This behaviour, when combined with wire splitting, results in a peculiar quirk where adding another script block can actually consume less script limit than without that block. In the following picture, case 1 adds 8 scripts (4 script blocks + 1 wire split + 3 pointer dereferences) to the counter. Almost half of them are just from dereferencing. To avoid that, in case 2 another script block is added to dereference the pointer before the split. Thus case 2 only adds 7 scripts (5 script blocks + 1 wire split + 1 pointer dereference) to the counter.

Known script blocks that output a pointer are all the Get Variable and List Element blocks.

Known script blocks that accept a pointer as input are the Variable inputs of the List Element blocks, the Variable input of the Menu Item block and, increment and decrement block.

Inside custom scripts

When a custom script block has built-in script blocks inside it, the first instance of that block counts the number of script blocks in it + 1. Further instances only consume 1 additional script limit. For example, this would count as 5 scripts (4 script blocks inside + 1 instance). Adding two more would count as 7 scripts (4 script blocks on the first instance + 3 instances).

For every input and output port given to the script block, the first instance counts it as 1 more script. Rules for wire splitting still apply to these. To give an example, take a look at this vector interpolation found in Fanscripts by Sounak9434. This consumes 9 script blocks in total (3 script blocks inside + 4 IO ports + 1 wire split at top input port + 1 instance of the custom block):

Tips

Here are some general tips to conserve the limit as much as possible:

  • Use wire splits whenever possible.
  • Do not use variables unless absolutely needed.
  • If a pointer is dereferenced at least three times, dereference it before the split.
  • You may find it useful to pack scripts that repeat throughout the script into a script.
  • Comments do not count towards any limits. Use them as much as possible.