This section of the document contains a variety of technical notes about the FlexBot that were left out of the rest of the documentation, generally in the interest of brevity. It is by no means a complete discussion of all technical issues relating to the system.
Because changes may be necessary as FlexBot develops, it is possible that behavior DLL's developed for new versions of the system will be incompatible with older versions of the FlexBot release DLL. The provided BotBehavior template checks for this by loading function pointers to all of the sensors upon initialization. If any of the sensors are not present, initialization will fail. This should lead to a graceful failure of FlexBot's behavior loading (console error message such as "could not load behavior DLL").
Similarly, if an actuator accessor function that the FlexBot requires of a behavior DLL is unavailable, then the load should fail gracefully. One of the reasons that actuator commands are returned to the FlexBot via accessor functions rather than as a C-struct is to allow for such elegant failure (whereas passing a mismatched C-struct could have unpredictable and potentially dangerous results). This approach means that outdated behaviors should work with new versions of FlexBot as long as no new actuators have been added.
The proper operation of the FlexBot requires that certain files be in specific locations. Since it is currently implemented as an independent MOD, the mod directory name must be hard-coded into the release FlexBot MOD in several places and is hard-coded into the BotBehavior workspace in one place. In the current release, the FlexBot MOD directory is "FlexBot". Searching the FlexBot code for this mod directory name in the source should show all instances of the hard-coded path. The behavior DLL's must reside in the "Half-Life/FlexBot/dlls/behavior_dlls/" directory.
Initializing and Updating Actuator Values
Because the FlexBot will retrieve actuator commands on every think cycle, it is important to either initialize the return values or update them on every think. Passing uninitialized values to the FlexBot may cause mysterious or fatal errors. If actuator values are not set on every think cycle, it is behavior-implementation specific as to what the bot will do (e.g. go limp, keep doing the same thing, etc.) There is no FlexBot specification for what should happen in this case.
Why Define Left-Distance, Rigth-Distance, and Center-Distance Explicitly?
Convenience is one motivation for doing so. There is something to be said for the user not having to implement code to calculate these distances themselves. Additionally, this allows the FlexBot to show the debugging beams for the look-angle and outer ranges of the field of vision because specialized code is required to do so. Perhaps a more general implementation for the future would be to allow the user to actually poll a custom vision sweep and draw debug beams for any such sweep.
Use Of Circuit-Like Behaviors Can Use Excessive System Resources
With a circuit-like architecture, every signal is polled on each think cycle. While this has advantages, it can also have disadvantages. For example, suppose that a user has three different "situations" that the bot might be in. Each of these situations requires a different analysis of the world around the bot. Each analysis requires a significant number of different traces. Because every signal is computed on every cycle, all three sets of traces are run, requiring a large chunk of compute time. A simple C program set up to only run the required set of traces could achieve the same task with 2/3 less compute time required.
The Chase-Camera is jerky when used on the client-side of a FlexBot game. The Chase-Camera will perform very smoothly when used in "listen server mode" (a user running a non-dedicated server). This is a result of the way in which the Half-Life client extrapolates positions. While player positions are extrapolated, the client does not extrapolate the camera position and therefore has its location updated far less frequently than is desired. There does not appear to be an easy solution to this short of making a custom client, which is not desirable because it would reduce the potential user-base. This effect is far less noticeable when using the Free-Camera.