Re: Behaviour Tree Update, Questions and Choices

Hi Sam,

> My first question is how would people like unexpected errors to be
> handled?

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?).

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.

> Also if reporting the error to the console, should I add a method to
> iBTNode to set an ID which could then be returned with the report and thus
> simplify identifying errors in the tree?

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.

Note also that the error shouldn't be directly reported to the console,
but to the CS report system instead.

> Can someone please confirm that by
> making my current celBehaviourTree class implement celPcCommon, I will be
> making it a property class?

That's it. You can take example on the other propclasses that are
implemented. Most of them use the celPcCommon.

> If so, to maintain consistency should
> plgBehaviourTree become plgpfBehaviourTree?

Those files are generated automatically, hence you shouldn't have to care
about them.

> Finally, with regard to loading from XML, are there any guidelines on how
> the XML should be designed or should I just try to maintain the same style
> as existing propclasses loadable by XML?

No real guidelines probably since you will need to define your own
semantic for the BT nodes.

You can however clearly have a look at the other XML files used in CEL, eg
to try to keep some consistencies in the tag names and structures.

> and to implement the load, do I
> just need to create a plgaddon_behaviourtree with a class
> implementing iLoaderPlugin and add load and save methods taking a single
> argument iDocumentNode*  to celBehaviourTree or have I missed something
> out?

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)".



------------------------------------------------------------------------------
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/