So I’m thinking about how to construct the list of potential behaviors that goes on the right, and it’s actually a kind of interesting problem. I can think of several bad solutions, but it’s hard thinking of one that’s actually satisfactory.
The difficult part here is making it so that the behavior list knows which behaviors are available. I could create a static init function that goes in the base behavior class, but I believe if I did so it wouldn’t have visibility of any of the sub-classes, just get called once initially when the main base behavior class gets created. So that’s no good. I could add a register command to the base behavior constructor, which would be able to analyze its own type and register it appropriately, but that means that every behavior would have to be instantiated at least once before showing up in the behavior list, which kind of undermines the purpose of the list being there in the first place. I could also manually register each desired behavior, either through a loaded in xml file or through special-case code, but that means having to manually register each new behavior which, as well, somewhat undermines the point of having a general use behavior list in the first place.
Well, not sure how to approach this yet, but it’s an interesting problem for sure. Unfortunately I’m feeling rather out of sorts today, so I’m probably not going to make a lot of progress on it right away… I’ll sleep on it, and hopefully that will clarify the problem, if only slightly.