End of Day Commit.
Getting ready to decide where to put the plan-sensing code, and finding all sorts of fun speghetti.
Initially I was going to take received messages the same way as dispatched messages. Then I realized this was a bad idea. Dispatched messages I can make sure leave us at a rate of only 1 per frame (should I wish it) which allows me to make sure I don't accidentlaly mask any sent data by, say, sending two messages once per frame. I give every class an opportunity to poll each new message once and not miss out on any data. This is largely because sending messages is handled by coroutine. Incoming messages can arrive at any pace or frequency however, which means they can get covered up. They are also handled in external threads. They are fewer in number. I am not sure if the received messages construction is still such a good idea. However, it will get the job done. To be honest, I would like to think of the Connection/Network singleton as a form of input/output device which needs to be polled once per update cycle. I will, however, put in this commit and perhaps in an issue, that it would be more stable if we had OldMessageHandler storing messages in an array and popping them to parse at no greater than one per frame. I would like to think of classes as also responsible for maintaining some visible data about whether its coroutines are in progress and what time they completed themselves.
Thought I needed to add something to the action planner to detect when the plan finished, but it turns out I can still use the Connector Singleton.
Learned a bit about the action controller and how the battery is actually destroyed at runtime today
The coding is all present to check for the plan's completion, but nothing is tested.
Really really random bug. I can't figure out what it is at all; near as I can tell Unity isn't rebuilding something. It basically is saying an enum value is undefined.
MUAHAHAHAH. The unit tests all work. Everything connects. Joy is known to the multitude. MUAHAHAHAHAH.