Page 1 of 1
Shifting addTemporaryValue to Entity
Posted: Fri Jan 07, 2011 11:31 pm
by 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?
Re: Shifting addTemporaryValue to Entity
Posted: Sat Jan 08, 2011 8:55 am
by darkgod
I pondered it in the past but never needed it

It's done, along with :attr()
Re: Shifting addTemporaryValue to Entity
Posted: Sat Jan 08, 2011 6:02 pm
by 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.
Re: Shifting addTemporaryValue to Entity
Posted: Sat Jan 08, 2011 9:41 pm
by 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
Re: Shifting addTemporaryValue to Entity
Posted: Sun Mar 24, 2013 6:44 pm
by 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.)