Re: Behaviour Tree Update, Questions and Choices

> Using csReport()?

That's it.

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

Maybe the node that is at the source of the error may report it using
csReport() (along with the name of the node), then also the root node
would report a message if the error is propagated to it. Maybe the first
report may have the 'notify' report status, while the second would be an
'error'.

The user would then be able to inspect the state of the BT and of the
stack when an error is met. Maybe some helper class may help for that, eg
for the display of the stack and the BT.

In some future, it may become worth to provide some functionalities for
developing & debugging, like a step-by-step execution, breakpoints, and a
GUI displaying the BT along its state.

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

Yes, the severity can be used for that, ie 'notify', 'warning' and 'error'.

You shouldn't probably care about what is made of the reported error, this
is mainly application dependant. Your main task would just be to report
appropriate events, and they will be catched here by the default report
listener.

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

Propclasses are attached to an entity in order to define its abilities.
They can be added an removed dynamically, although the entities have
usually a set of propclasses that is fixed throughout the application.

Here the BT propclass would provide the ability to execute automatically a
BT, that can for example be used to define the behavior of this entity
(but is not limited to that entity and may control some other process
too).

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

I actually now realized that it would probably be cleaner to do that
save/load stuff in an external dedicated tool, such as was done for eg the
'dynworldload' in plugins/addons, on which you can probably base your code
(there is an example file at data/elcmtest.xml). The Parse() method of
your loader plugin would return a reference to the root iBTNode of the
tree.

Hence, your XML file would start with a tag 'library', then a tag 'addon'
with the name of the new iLoaderPlugin plugin that you will write for
that, then the BT and its nodes.

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

That method in the propclass can probaly be kept, although the Save/Load
methods in iBTNode can now probably be removed.

And that LoadFile() method would now pass the XML file to the iLoader,
then upcast the parsed result from the iBase to the iBTNode, and set it as
the root of the BT of the proclass.



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