Re: Behaviour Tree Update, Questions and Choices

Sam Devlin <[email protected]>
Newsgroups gmane.comp.graphics.crystalspace.devel
Message-ID <CAL0_xOqJP66Kw6XUAXFUHa1eF0EkymOQL0JUNRSDrb2UTQ-dpw@mail.gmail.com>
On Wed, Jun 20, 2012 at 7:57 PM, Christian Van Brussel <
[email protected]> wrote:

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


Ok, so this is mostly done now (see revision 4908). My one remaining
problem before this part is IMO complete is regarding checking if the
parameters for the decorators execution_limit and loop have been set.

At the moment if a parameter is not set the code crashes due to an access
violation when calling the parameter managers resolve parameter method.
What I want is for the node to recognise this instead and report it as an
unexpected error in the same way all other unexpected errors are reported
by BT nodes. Is there a way using the parameter manager to check for a
parameter before resolving it?

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.