The FunctionCommandLimit rule has a maximum value of 10,000. While this is suitable for using commands for a mini-game or other map functions, there is a use case that needs a higher limit.

I can convert a schematic to a set of commands, the easiest way to share this with other users is to convert the schematic into a function file and package this up as a behavior add-on. While this approach works for a small and medium sized structures, this does not work for larger structures. I would like to see the maximum rule value be increased so that we can support running a function or chaining a set of functions together so that we could run 200k or 300k commands to execute an import of a large structure. This will allow for supporting importing schematics in a way that is better supported by the product, since it is just utilizing fill and setblock commands.

Here are some associated bugs, that were created while testing functions hoping to increase the limit.

https://bugs.mojang.com/browse/MCPE-39390

https://bugs.mojang.com/browse/MCPE-38845

I would really hate a true upper limit of 10,000. With porting my softfp library to CBA C (which is an Assembler and Very Minimal C Compiler), some of the things that need to be done to simply add 2 floating point numbers will quickly exceed 10k with just a few commands (esp with the fact that a memory lookup needs to take place, which is absolutely disgusting without some sort of proper variable system). This is a huge barrier (and I can't even sync, which tells it to wait until the next game tick, or I risk breaking the in-operation atomacy that the library guarantees). I don't even want to think about how many commands are in a simple USRH operation. I think removing the upper limit entirely is a good idea, so that server operators can set an arbitrary amount of commands to run. Esp when you have really stupid functions like exp(x). (e^x = 1 + x + (x^2)/2 + (x^3)/6 + (x^4)/24 + (x^5)/120 + ... + (x^n)/n! for lim[n->∞]). Even going up to n=7 (where the function converges close enough to e^x to be valid for IEEE754), that is 9 additions, and 7 pow/fact operations (my way of optimizing taylor series to not compute an O(n) recursive function twice).

I highly doubt I could run more than 1 exp(x) calls in the same tick without crashing right through the 10k upper limit.