One other thing, I don't see why we even deal with buildings here, I removed that code, and didn't notice anything different in my small tests.

Have you looked into this before?

I'm not sure why you're using sizeof(DROID *) there (that's the size of the pointer there).

Also would this change the code to only send changed orders with a limit of the unit cap ? Since sending the same order for every droid in every frame would definitly cause a significant increase in bandwidth usage. Only sending updated orders OTOH might very well be next to unnoticeable.

Step 1) rewrite code to handle orders for all units, not limit it to 6(!) per call.

Step 2) fix the broken update calls.

Units now do as what they should be doing, and will NOT go off on their own anymore.

We were only sending 6(!) droids per frame in the old code. I know the original had it based on bandwidth, and they had either 4 or 6.
We must send orders to all units that we have per frame.
If we do not, they will do their own thing on different machines, and we don't want that.

We currently have a cap set at 300 units. (it CAN be higher than that though)
As you might be able to guess, max case scenario is we send all 300 at once.

300 * sizeof(DROID *) = 1200 bytes.
That is for 1 player. If Host has a game with 6 AI and one other human, then we get:
1200 * 7 = 8400 bytes (max).
That is just for droid orders updates.

Unsure how we want to handle the bandwidth requirements.

Right now, for each player the Host machine is in charge of, I update all the orders per player. Not sure if I should leave it at 300, or if we should break it up more to 150 units per call or what?
What should be the max length of a packet that we can send before we crash & burn?

For the updating function, that function never worked, it did nothing really. It was left over basically 'as is' from the original, and that was another issue.