Is your update cycle in a separate function or (as it looks from your last post worth giving some toughts) separate update cycle in every player action ?
If its separate function , there is one problem with your solution It might not be a problem for you personaly , but in more general form...When you reset the counter , an update is sent , but than your next update will come after x number of frames (as after a regular update). And forced updating is used to fill in the gaps between 2 regular updates...so , if you're normaly updating on each 4-th frame , the forced will always come on the second frame after a regular update. In your case , after sending a forced update , the regular update wont arrive 2 frames after , it'll arrive 4 frames after unless you set the 'update' as a forced , in order to send the next update after 2 frames as 'regular'.
But your post realy got me thinking I should experiment with updating cycles in each entity. Easyer to manage , I think...also gives some opportunities , to keep track of each entity thru local vars (wich are limitless number of skills in theory ) , to store movements and update only if an ent moved. The only disadvantage I can think of is , you cant use ent_next(ent) to cycle thru the other ents , to update each one to the 'my' entity,unless you could do 10000 ent_next instructions between 2 frames

I have fast updates currently only for players which are controlled by clients.

All other entites are controlled by the server and those are updated with a task scheduler. If I need a fast update there, I'll ahve a problem. Thanks for reminding me on this

thsi separation makes only sense with my setup I guess, so it probably has quite some flaws. I'll find out once I tested around more.

Here is a typical client readout:

fps 55, bps 20, bpk 68, rel 900, unr = 900, drp 0.


Here is a typical server readout (in non-ded. mode):

fps 110, bps 688, bpk 10368, rel 0, unr = 0, drp 0.


This for several (over 20) bots running around in the world and two players in the world. The important numbers to consider is that the client's maximum send was 68 B and averages about half as much. He is receivig about 1800 B from the server which is actually high for we have not optimized the server send much and we expect to be able to drop that eventually to around 1000 B.

Quote:

---

You said in your first post that BPS is how much you send , for the server here its 688 bytes/sec. but the client says 1800(rel&unrel) , or is this at diffrent times ?

---

Quote:

---

Also , strangely in your example , the server isnt receiving anything...

---

An annoying quirk of the 3DGS network panel on the server is that it only displays the received data for the last client connected. So if you have 10 moving clients and the last one isn't moving, then unr/rel will read zero.

This is a main reason why I don't use the network panel and instead use third party network monitors (ETHEREAL is a good one for it can sniff the packets too). It's hard for me to understand what those number mean but when you have a sniffer on the network, you get a precise idea of what is coming in and out. I don't have it set up right now but (because we develop on one computer, it is harder to separate server from client traffic) but I should and will in the future.

Quote:

---

2 Players = 115 * (2 * 2),3 Players = 115 * (3 * 3) , for 100 clients its 1150000bps , and I should start thinking how to solve this problem because a client cant always receive 1MB/s,or I'm wrong again ?

---

That seems right. If each player has an NPC that needs updateing, then you would need over 1 MB to update every player of every other players information... which is why you don't do this!

Instead, you limit the updates to only the players that are nearest to you and exclude the others. This way if player 1 is 100 miles from player 2, either player need not know what the other is doing until they get closer.

Quote:

---

when moved. For the others , I'm not shure how I'll reduce the numbers,because I'm already sending only X,Y

---

If you are not sending velocities, then 3 coordinates would require 3 variables or 12 bytes (without header). With velocity, it jumps up to 24 bytes per update. Hence for 100 clients, it should be 200.4KB (without header) at full resolution "could" be doable on broadband. All the same, I would still optimize by restricting who gets updates adn throttling the update frequency to minimize bandwidth.

I'm already updating only in a certain area wich is btw in my futuristic concept very small,because you see only a small part of the level... So , I'm talking about 100 players or NPCs on the screen at the same time wich would pretty much fill your whole screen
Right now I'm sending one var to indicate that an update came , one for entity ID that needs to be updated (I'll have to include entity type also in the future) 2 for X and Y coords , one for pan angle , one for firing/not firing and one for health , and today I'll include animation states. 7 vars packed in an array total 4 times/sec. for each entity visible on screen.
I'll have other updates but 'one time only' type of. For creating weapons on the ground or removing them...
Btw , I'm also testing on one PC. I suppose I cant find out what app is sending what to another app ?

Quote:

---

one for pan angle , one for firing/not firing and one for health , and today I'll include animation states.

---

Here's a common bandwidth saving routine: Packing as much data into a data type as possible.
Observe:

Pan can go from 0-360... or three digits max.
Firing/Not Firing is one bit... but aince you are using A6, the least we can do is one digit.
And I don't know how much health you have, but let's assume you have a max health of 9999.... or 4 digits.

So all together you have pan (3 digits), firing (1 digit), and health (4 digits).

A var has a total of 9 digits.

Hence, you can store ALL this informaiton into one var...

...and if you only have 10 animations states, you an store that in there too!!

You've just reduced 3 vars (12 bytes) into 1 var (4 bytes)!!!!
Or if you put in 10 animations, you've reduced 4 vars (16 bytes) into one var (4bytes)!!!!

Hm why shouldn't it be possible to use single bits in A6?
Mixing up digits and bits might be dangerous, but apart from that it's nothing more than some bitwise AND/OR. One digit can take up to 3 bits.

I'm using this for all button presses.

However I need a lock state for PAN, so you just reminded me of a good way to implement this

Quote:

---

Hm why shouldn't it be possible to use single bits in A6? Mixing up digits and bits might be dangerous,

---

It can but I don't recommend it not because it's dangerous, but inefficient. If you use one bit for firing, you still lose that one digit resolution since the two remaing bits can only represent a number from 0-3. So unless you have two other bitwise variables or a command that takes a value from 0-3, you are going to be doing unnecessary transformations for nothing.

The main point of the post above is that you should use every bit in a variable when sending it. A7 BTW, with it's native bool and structs, makes it MUCH easier to design network traffic. Also, IMO, it's better to clump all the bitwise operations in one var (for example movement... that is a great candidate for bitwise network compression) and all the numbers into another.

I'm not much into bits and bitwise operations so I'll stick with vars and btw , what you posted is a great idea for packing numbers. I tought of that , but using strings...sending player name,pos & other stuff and than when a client receives a string he can 'strip' off (Is this the correct word? ) the player name , the pos , all the data he needs. But , I dont know how much bytes a char in a string is and I havent tought of the actual 'mechanical' part of that concept. It'll be easyer to manage all clients with a string because this way you could always link an ent to a 'player name' in your project. Right now , my player names are nothing more than local strings and plus I dont know yet how to limit an inkey instruction to only numbers and "_[]{}=." for example. I also cant prevent clients from setting already existing player names , because I need an ent created to send to that ent back a response and my ents arent created until the client has set his player name But thats a separate wdl code , I can modify it later,when I optimise the current code.
Btw , I tested with 4 times/sec. updating and I think the clients will be satisfied with 2 times/sec. It'll decrease the bps received and still look like a regular MMO , because right now its more kind of a online shooter
I added animation , but local only (when the player ent is moving,animate) but I guess I'll need anim states updated because I'm planning for bones anim.

PS.: I'm currently testing with the default (3DGS's) MP code for entity management , but I might start over again to make the ent creation/updating handled by the custom server updates. Not only because of the BPS Peaks and a lot of traffic at the same time for all clients , but also because I might have greater control over the entities.
And , a little off topic from MP , how can I resize terrains that have a shader applied to them ? I tryed scale in WED , I tryed scale in the function , I even tryed in the console , nothing works when a multi-tex is applied. I think in the end I'll make my own script for terrain management , possibly with an editor if I have the nerves to get involved in image and mesh manipulations