Pass input parameters to Cycle::generate

[unlessgames]

Passing the parameters would allow for real-time structural changes. This would be constrained to each batche of events but might still be fairly useful.

Dynamic data could be supplied via a HashMap<String, Variant>, where keys would be the name of the input parameter and values would be wrapped in a variant type of floats, ints and strings (to mirror parameters), then inside the notation you could say something like

[a b c d]*$div

This would substitute the value of the parameter named div when generating, allowing you to change the speed of the subdivision step at runtime without changing the code. Similarly it could be used for setting chance, setting event properties etc.

[emuell]

Nice one! Could even take this further and allow bash-like parameter expansions here:

[a b c d]*${div / 2}

If we evaluate the content of ${} as Lua code with no context other than the parameter identifiers, it could be quite powerful as inlined map functions.

[unlessgames]

That sounds really powerful!

---

Looking into it (just basic parameter replacement), the current cycle implementation would need to be changed to get rid of all the static application at parse-time (used for ! and @ operators and ranges) for this to work consistently.

[emuell]

As appealing as such a bash like extension to the variables may seem, I think we no longer need it after #107 .

Such var expressions would be very difficult to parse. Actually would need to add a whole Lua interpreter to the cycle to do so, while the suggested 'vars' function should also do the job nicely; adding dynamic expressions based on parameters and other external variables from the context, with a lot less overhead and without introducing a new syntax.

[unlessgames]

I guess that inverting the responsibility here would make sense. So the cycle couldn't execute the arbitrary code expression but it could parse it as just a single string delimited by ${...} which would then get treated as any other variable identifier.

Then it would be up to the outside scripting context (if it exists) to deal with executing and assigning the result to such an identifier.

I think there is some merit to having this feature as it would make injecting math one step easier and more direct than having to define a variable and assign it separately in a vars function. But as the latter allows the same functionality and more, I'd keep expression syntax as a possible enhancement with low priority for now.