Generic behaviors using eval()

Unity Engine
1

I’m trying to make some of my behaviors more generic so I can use them for multiple purposes.
In order to do that I’ve add a string variable called cmd that is called on Start() ex.

var onStartCmd : String;

function Start()
{
if(onStartCmd!=“”) eval(onStartCmd);
}
Now in the Inspector I add this cmd
obj.SendMessage(“resetOrigPos”,emitPos);

it works great. except the first time an object is eval() this cmd I get a hugh hit on perfomance and then everything is good after that.
Any idea why it’s happening only the first time? is there a better way to make behaviors generic?

2

You get the performance hit because the code has to be compiled on the fly. There might be better ways, though you haven’t explained what you’re trying to do exactly.

–Eric

3

Got ya, so the eval() has to be compiled the first time around and then it runs smoothly. that make sense.
What I’m trying to do is a bit more complex so I’ll try to explain.
I’ve made a simple pooling behavior to reuse objects like projectiles(bullets,missiles,etc) instead of recreating and deleting them all the time. so my first question is , should I even bother with this pooling behavior. I’m new to Unity (previous Torque user) so I’m not sure if it’s needed.

Lets assume that pooling is a good idea, since I’m using the same pooling behavior on multiple objects I’d like to have the ability in the inspector to add a generic cmd every time you get an obj from a pool
onGetObjCmd for bullets will be obj.rigidbody.velocity = Vector3(100,0,0); and for lets say boomerang it will be able to set angular velocity or some other attribute.
So instead of writing out all the different options for each object in the pooling behavior, it would be exposed in the inspector and I can write commands to execute on each object while I request in from the pool.

Now that you explained to me how eval() works I don’t think it’s a good idea :slight_smile: maybe I should add a SendMessage(“onGetObj”) for each object I get from the pool, and the other components (bullets, boomerang, missiles,etc…) will have a function onGetObj() to respond to it?

4

Nice theory, but it will be compiled every time you use Eval as it does on the fly on each call actually.
Its after all called eval not “CompileOnTheFly”

Pooling: Depends on the platform / hardware target. its always a good optimization and rather trivial to achieve with a simple List<> :slight_smile:

Also I don’t see why you need eval for your purpose, you can use SendMessage or you just extend all MonoBehaviours from a base MonoBehaviour that defines a the function you want to use for later reuse on all these extends for example.

5

Depends…if you’re talking about desktop, no, I probably wouldn’t bother.

That’s not true. I guess you haven’t actually used eval?

var evalThis = "transform.Translate(Vector3.right * Time.deltaTime);";

function Update () {
    eval (evalThis);
}

Compare that to running the code directly in the profiler, and you see the compile hit only occurs once. It’s still slower than running the code directly, but only a little.

–Eric

6

I think delegates are supposed to be good for generic behavior such as Example1: Delegates Tutorial

7

So it looks like I should use a pool since I do want to target mobile. I guess the eval() idea could work if I initiate 1 eval() call before each level start since after that I didn’t notice any performance hit.
However, it seems like there are better options suggested here so I’ll try them.
The delegates seems to be a C# which I’m not familiar with and writing all my code in JS.
I didn’t even think about the possibility of extending the base monoBehavior but it’s good to know it’s possible. it sounds hard to do anyways :slight_smile:
I’ll try SendMessage first.

8

Delegates work in JS:

function Start () {
	var myFunction = Foo;
	myFunction();
	myFunction = Bar;
	myFunction();
}

function Foo () {
	Debug.Log ("FOO!");
}

function Bar () {
	Debug.Log ("BAR!");
}

The only problem is that you can’t explicitly define the type of delegates. Or at least “Debug.Log (typeof(myFunction));” doesn’t show anything useful to me.

–Eric