Re: Behaviour Tree Update, Questions and Choices

Hi Christian,

I'm not sure, that the following is still valid with your new changes in
> the BT, but when an error occurs somewhere in the tree, shouldn't the
> implied node simply exit with the 'error' status?
>
> Then if the parent is able to handle that 'error' status, it will cleanly
> continue through another node.
>
> If the parent is not able to handle the error, it exits too with the
> 'error' status, repeating the process until either some parent handles it,
> or it reaches the root of the tree.
>
> If the root of the tree is reached, then the execution is stopped, the
> error is reported, and the tree is no more updated (is this last really
> needed?).
>

This is how it currently works. By stop updatings, I was referring to
stopping the callbacks to the behaviour trees. I use a callback every frame
to update one node (at the moment - this willl be a settable parameter once
I move to a propclass). Once the tree has completed or an unexpected error
has been propogated back to the root the callbacks are stopped to prevent
wasted computation.


> Letting the user define specific code to be executed for error management
> seems a good idea. But the user is currently still able to implement its
> own additional nodes, so this mechanism can already be used for that and
> this seems therefore not a huge need right now.
>

Ok, I agree the functionality is there now for someone that may have an
unexpected error and a method to deal with it can implement their own node
using interface iBTNode that would not simply propogate the
unexpected-error terminationation status upwards.

Note also that the error shouldn't be directly reported to the console,
> but to the CS report system instead.
>
>
Using csReport()?



> That's probably a good idea since there might be a lot of different nodes
> in a BT, having names for them would be helpful.
>
>
Ok, I will add this to my to do list.

With regard to reporting the error and using the name of a BT node, if the
error is propogated upwards should each node the unexpected error is
propogated through report the error and it's name? or should the name of
the first failing node be noted by the behaviour tree and if the error then
reaches the root one error is reported with the name of the start of the
problem?

The first would give a trace of the path back to either the root or to the
node handling the error which may be useful but also could be too much
detail especially when deployed in a game. Or does the csReport method's
severity argument perhaps allow for me to implement both and print all
errors in the case of the console being set to verbose or just an error if
the unexpected error reaches the root in cases where the console is not set
to verbose?


> That's it. You can take example on the other propclasses that are
> implemented. Most of them use the celPcCommon.
>
>
Ok, I'm struggling slightly still with the concept behind property classes
though. Is it simply so that (in this case) a behaviour tree will be linked
with an entity (such as a non-player character) amd will be
constructed/destructed as and when that character is?


> You can probably base your code on the sequences/triggers/etc that are
> also parsed from XML. This parsing would therefore be implemented directly
> in the node classes, ie through eg an additional method
> iBTNode::Load(iDocumentNode*). A Save() method would be needed too at some
> point.
>
> For the root of the tree, I don't think there is really some mechanism for
> the loading of propclasses from a custom iDocumentNode, therefore you
> might have to add a dedicated method for that in your BT propclass, eg
> "LoadFile(const char* filename)".
>
>
So each implemented BT node (sequences,decorators etc) will implement a
Load(iDocumentNode*) which is able to initialise a node of it's type as
specified in the XML passed to it as an argument.

And the BT propclass will implement LoadFile(const char* filename) that
will open an XML file, construct the relevvant BTNodes and in turn call
their Load methods passing on DocumentNode*s containing the XML relevant to
that particular node?

Kind regards,
Sam.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
Crystal-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-develop