> Composites:
> Would be nice to have the parallel composite too... :)
Yes it would, however without implmenting a sheduler I do not see how to do so
as all children will be fired sequentially and not be rechecked during the
execution of other children. In effect they are therefore not parallel and
provide no additional functionality. With a scheduler implementation the tree
is progressively parsed and such parallel children can be rechecked whilst the
parallel subtree passes. The scheduler also then eases the method of bailing
out of the subtree. This could however be an oversight on my behalf, I simply
do not see how to execute the children in parallel.
> ParameterCheckCondition:
> Note we have propertychange trigger, which basically does what you
> describe already. (well, it cant check property class properties, while
> yours could do it).
I did overlook this, I have already implemented a very basic parameter check
but it is possibly redundant in light of this point.
> BTAction:
> Would this allow to use any reward? Or is it intended just for the
> action reward, by the terminology i'm not sure.
This can fire any reward, my choice of the term BTAction was to keep in line
with BT literature, however, I can see the confusion and perhaps this should be
changed. Perhaps BTReward would be more appropriate for cel, symbolising that
it is a wrapper for rewards so that they may be used in a BT.
> Triggers:
> You say triggers do not directly fit because they fire but the behaviour
> tree checks if they fired already, well.. triggers support Check()
> function for checking if they fired, in addition to notifying when they
> fire. Did you overlook this, or maybe there is some catch i dont see?
Again, yes I overlooked this. However, there still needs to be a BT wrapper for
triggers so that they can use the BTNode interface and be connected as a child.
I think it is more efficient to maintain the current method implemented (not
yet committed) that registers as the callback to a trigger. This way the node
stores the trigger has fired instead of calling Check() each time the node is
executed. If anyone disagrees I will happily change this wrapper class to use
check each time instead.
Any follow up queries or further comments greatly appreciated,
Sam
_________________________________________________________________
Celebrate a decade of Messenger with free winks, emoticons, display pics, and
more.
http://clk.atdmt.com/UKM/go/157562755/direct/01/
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Cel-main mailing list
Cel-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cel-main
