Ender1618

Apoch, I believe I understand your point.

Its not so much a matter of time investment of building up my current framework (although emotionally i guess it irrationally factors in), its that the method (BT) is working for me in a myriad of ways that HFSMs failed me or over complicated things.

The goal is that the AI is almost completely data driven, and there is visual tool, that a semi-layman can use for authoring. I have worked with HFSMs (with a visual tool) this way and found it could be pretty awkward expressing things (that I care aboutfor my AI) that are easy to express in BT.

The many context event problem. may be one of those problems expressed in a BT would be just as cumbersome or even worse. Square peg, round hole.

Every method has its pros and cons. I need to consider other methodology maybe for this type of problem.  I just would like to try to continue using BT for most things and another method for this issue. Yet mixing things is often harder than it seems.

Thanks for the input.

Already have alot invested in my BT system, works well for many things the AI does.  I guess I need to try to see how I can adapt/extend/wrap it for encompassing my new need.

Anyone have an opinion on that?

What I meant by nodes executing with respect to the right context is if for example, I placed many monitor nodes (or an activeselector with condition controlled subtrees) higher up in the tree (would only have to that once) that would respond to all the events that I could be looking for. 

One of those monitors might fire, while I am lower in the tree somewhere, but that monitor at a higher level wouldn't know where i was in the tree previously (at least the way I implemented my monitor/activeselector), and just switch out to the tree under the monitor, loosing the context of what was going on.

If every node in the tree that would be considered a special context for an event, were to have the all the monitors duplicated there, that would be ALOT of monitors. 

I must be thinking about this in the wrong way.

Alex, Dave, thanx for the insight.

So typically a BT system would only deal (encode logic) for 1 target/threat at a time.

Where an external to BT system would be picking what that 1 threat/target is.

Something like a cover picking system can consider more than 1 threat, when picking a cover position, but only communicate its top choice to the blackboard where the BT would look it up. Or possibly more than 1 cover point can be chosen, where the other cover choices (valid but maybe not optimal) could be weighted lower, for a weighted random selector to pick between them.

This prioritizing choice could be done in a number of ways, one being using marginal utility (constructed by some multiple consideration formula adjusted by possibly some graph primitive, like a Logit function, etc.)

I guess this could be done in what I am calling the perception filter, that is feed by the perception system then generates derived perceptions and writes them into the agent blackboard.

So we would typically want to keep that logic out of the BT, and let the BT worry about other things.

Am I understanding that right?

Are there situations where some of that threat/etc prioritization might need to exist in the BT, in some fashion.  I am thinking about flanking sub behaviors that need to understand the geometry of the battle and therefore its participants and what they are doing?

So the glTexStorage2D internal format is just a high level representation of what is going to be in the texture and the depth per channel ? The actual order of R G B A bytes is up to OGL driver.