I need to modifying the logger to implement this:
Use STL streams for easy C++ thread-safe logging
This hadn’t occurred to me. It’ll be less efficient, but properly thread safe. It’s rare that messages actually get mixed up by the logging system, but it does happen.
BEHAVEngine and FI3RST are now talking, and movement/speech requests are tested. Action requests are not yet tested, but should be smooth. I’ve set up an action framework in FI3RST; to add an action, create a new FI3RSTAction class and make sure it gets instantiated in the FI3RSTAction::initializeActions() method. The following must be written for a complete action:
- name : this is the name of the animation to use for this action. it may be a fake animation, but it must be defined in the character description file (walking-guy-jump-idle.xml)
- interruptible : true if this action may be interrupted before it is complete, false otherwise. This is independent of whether the animation is interruptible (though it would probably be sensible if they match).
- duration : how long after the action animation is started that the action should take effect. for example, for the “pick-up” action, the object should not disappear until the animation has put the character within reach of the object. Value is in milliseconds.
- loop : set to true if the action should repeat, false if it should just run once. usually should be false. This is independent of whether the animation will loop.
- checkRequirements(ActionInformation &, std::string &) : This takes the request for the action, checks that it is possible (the character and objects exist and are capable of the action), and returns true or false. If it returns false, the “reason” string must be filled in with information about why it failed– this string is printed directly to the console.
- reserve(ActionInformation &, std::string &): This takes the request for the action and marks all objects that will be used for it. We do this to make sure that the objects are still available when the action itself executes. If any objects cannot be reserved, it must fill in the reason string with information about why it failed.
- executeAction(ActionInformation &, std::string &): This executes the action, and will be called no sooner than gTime->getTickTime() + duration, but may occur slightly after. It should call checkRequirements again to be safe. If the action fails at this point, reason must be filled in with information. If the action succeeds, reason should be filled in with a feedback message.
- cleanUp(ActionInformation &): This method must clear any flags set in the reserve method.
Note that only one instance is created of a FI3RSTAction, so it must not be used to store state. If any state beyond what is present in ActionInformation is needed, and there is absolutely no way to work around it, then we’ll deal with that later. No additional state should be necessary, though.