Well, bandwidth is one of my favorite subjects(latency being the other), so I'll share what I know about it. Here is a quote from the The A6 Client/Server Protocol manual page:

Quote:

---

The protocol is optimized for using as less bandwidth as possible. Only parameters that have changed are sent over the network. Sending a player's changed XYZ coordinate from the server to the client, for instance, needs only 12 bytes (including header). A dead reckoning mechanism is used for extrapolating positions and angles between cycles.

---

If you look through the entire Protocol page, you'll see that it is pretty efficient. Unfortunately I can't give you the exact number per entity, because a lot of it will depend on what you are doing. For example, an entity at rest will send 0 bytes of data for xyz coordinates. An entity in motion will by default send 12 bytes of data 16 times per second, just to update the xyz coordinates. Other things that get updated whenever they change are pan/tilt/roll, animation frames, lighting and color adjustments. But keep in mind these things only get transmitted when they change, and even then only 16 times per second.

There are also things you can do to control the auto-updates. Of course everything is a tradeoff. For example, you can control the time between update cycles with the dplay_entrate, but in doing so, you can introduce excessive lag into the gameplay (or flood the network if you go the wrong way). You can also shut off individual updates, or even all of the updates, but then you'll have to manage the data transmission yourself.

I can tell you from my experience that most likely it will be problems with your script and not the A6 auto updates that will be flooding the network. Usually the bulk of the bandwidth will be used up by your script sending vars, skills, and strings between the server and the clients.

There are lot's of things that you can do to minimize these script issues. Take a look at locoweeds tutorial on Multiplayer. He did an excellent job of keeping the BPS low in his code. The biggest key is to do exactly the same things that the A6 protocol does. Namely, use as few bytes as possible to send your data, only send updates for things that have changed, and if possible try to use things like prediction algorythms and update cycles to minimize the frequency of sending updates.

So... best of luck. I'm sure Locoweed and Fastlane can add some useful info to this thread.