Shifting addTemporaryValue to Entity

[yufra]

Working on the Moon/Star knife pairing has highlighted how it would be useful to add temporary values to objects as well as actors. The addTemporaryValue, removeTemporaryValue functions and the compute_vals table could be moved from engine.Actor to engine.Entity quite easily, allowing for more flexible options. Thoughts?

[darkgod]

I pondered it in the past but never needed it
It's done, along with :attr()

[yufra]

I have two further extension proposals for the temporary value adding/removing. Currently you can only set a first-level property (something in the self table) with either a number or a single-level table. I have a use case where I would like to update a third-level property (so self.combat.melee_project[DamageType.BLINDPHYSICAL]) and these extensions would allow that.

The first and easiest on the code-eyes is to allow prop to be either a string or a table. If it is a table iterate over it to find the table you want to update the properties of and then execute the code as is (replacing self[prop] with the newly found table).

The second option is to allow the value to be updated be a nested table and write a closure that can be recursively called. We can also combine both and have a truly flexible/general function.

[yufra]

Here is my current refactor: http://pastebin.com/FjEx09sw

I think the stdout could be improved a bit to help with debugging, but I tested this with Moon/Star pairing and both extensions work.

EDIT: A slightly updated refactor: http://pastebin.com/hYbjxKYz

[nate]

I think a general addTemporaryValue is a nice idea. I recently tried using it with a talent, something like talentId:addTemporaryValue("cooldown", n), and of course it didn't work.

Still, not hard to work around; any function that can remember a temporary value id can remember a field and a value and can handle stuff manually. (In fact, I'm still not sure why addTemporaryValue is necessary, but I try to use it for consistency's sake.)