There is none. I was investigating the idea about a year ago. To execute code in this way is unfortunately not easy. Basically you would need to parse a string into c# code. Either you need to do it the old playmaker way, or create a c# script with a function (and then you can run that function in playmaker if you want).

While it is technically possible to do, the action to do it, needs to be a dll file, and not just source c#.

Hi,

 making a custom action for a particular math equation is actually by far the preferred way, both in terms of performances and reliability.

Can you show an example of the equation you want to perform, and I'll do an action that does this, then you can use this as a base to do more.

 Bye,

 Jean

Hi,

Yes, this would be a good addition indeed

have you tried this: https://assetstore.unity.com/packages/tools/visual-scripting/c-eval-56706

 if that works for you in code, I can can make an action for this where you plug your variables and then use this, or even better, we could team up with the author so that he can add PlayMaker support right out of the box.

 Bye,

 Jean

 

Id be interested in investigating some integration with that asset and making some samples for playmaker. I just purchased a copy to play with.

Hi,

 excellent! Thanks Eric

Bye,

Jean

I've been playing around with a Math Expression action that uses the Mathos Parser: https://github.com/MathosProject/Mathos-Parser

The parser was pretty easy to setup as a Playmaker action (attached), but I haven't done a lot of testing yet - consider it alpha software!! Please post bugs/feedback and we'll see if it might be a viable solution to release...

Also, the parser is very extensible - we can easily add custom functions and variables e.g., to access things like Time.deltaTime in the expression.

I think it's worth exploring other options as well to compare performance, usability etc.

I've had little more time to test the action. (Thank you again, Guys).
In normal uses, it's fantastic so far.  It's processing anything I throw at it.  And it shines more when the calculation is longer or more complex.


I also tried to do some stress test. 
Set Up:
Two identical FSM to process the same math operations 999 times, but one with the MathExpression, and the other with typical math and conversion stacks.  I extracted out how long it took for the operation to complete in real time.

 
Assumption:
- The operation loop will happen in the single frame, so I just need to compare the time it took to complete the loop.
- Parsing strings will cause some GC spikes in the profiler.


The followings are the results.
1. For whatever reasons, I couldn't get the MathExpression loop to process all in the same frame.  Action does process, but it seems like the state that include the MathExpression action process it again in the next frame, rather.  (The identical FSM with the simple math and conversion operation stacks loop through the operation in a single frame).  I’m not sure if it’s because of parsing, or something else.  That’s beyond my ability.
2. The GC size is pretty big.  For simple math equation loop, the GC allocation was about 250kb every frame.



To sum up my finding so far,
1.  It's a beautiful action to process complex math action with many mix of floats and ints.  The more complex the equation is, the more it will save you from needing to make conversion variables, and stacks of math actions.  It helps keeping the FSM clean and organized.
2.  Not meant to be running too frequently due to some overhead such as GC.
3. Obviously, I could've made some mistakes with the set up somewhere, that's why I made the identical FSM for the two (except the state where it does the calculation).  What I was after was the comparison purpose only.  Nevertheless, I wouldn't call my testing a deep dive thorough test, so hope someone more technical than me can also test it out.