PDA

View Full Version : A suggestion to improve online lag and plane stuttering...



XyZspineZyX
08-05-2003, 02:42 PM
I notice that now in online-play FB, the positions of all planes are updated at the same rate no matter how far they are from the player and even when the player can't see the them. The positions of planes closer to the player should be updated more frequently than the positions of planes further from the player. Why should a plane 10 miles away that I don't even know of be updated at the same rate and use up the same bandwidth of a plane right in front of me that's stuttering all the time? This would make dogfighting more fun because planes near you wont be stuttering all the time. Aces high, Warbirds, and all the other sims with smooth online play have this feature. Can you add it?

http://www.assonetart.com/ClashofArmor.jpg
"Cowards die many times before their deaths;
The valiant never taste of death but once."

XyZspineZyX
08-05-2003, 02:42 PM
I notice that now in online-play FB, the positions of all planes are updated at the same rate no matter how far they are from the player and even when the player can't see the them. The positions of planes closer to the player should be updated more frequently than the positions of planes further from the player. Why should a plane 10 miles away that I don't even know of be updated at the same rate and use up the same bandwidth of a plane right in front of me that's stuttering all the time? This would make dogfighting more fun because planes near you wont be stuttering all the time. Aces high, Warbirds, and all the other sims with smooth online play have this feature. Can you add it?

http://www.assonetart.com/ClashofArmor.jpg
"Cowards die many times before their deaths;
The valiant never taste of death but once."

XyZspineZyX
08-05-2003, 02:44 PM
What is that technology - LOD?

I know they use this in the FPS - wonder if FB uses it?

Basically doesn't draw the same level of detail at further distances to save on FPS.



S!
609IAP_Recon

Forgotten Wars Virtual War
Forum: http://fogwar.luftwaffe.net/forums/index.php
Website: http://forgottenwars.dyndns.org
Visit 609IAP at http://takeoff.to/609IAP

http://www.leeboats.com/609/sig/609_recon3.jpg

Agnus Dei, Qui Tollis peccata mundi, Miserere nobis. Dona nobis pacem

XyZspineZyX
08-05-2003, 02:59 PM
No, I'm not talking about level of detail at further distances but a similar concept. When online, the position of all planes is downloaded at a rate of, let's say, 2 times per second. It shouldn't be this way. Far away planes from the player should be updated maybe once every 2 seconds to save bandwidth because you can't even see them while planes right near the player should be updated maybe 5 times a second so they move more smoothly through the sky.

http://www.assonetart.com/ClashofArmor.jpg
"Cowards die many times before their deaths;
The valiant never taste of death but once."

Message Edited on 08/05/0311:06AM by EvilBen

XyZspineZyX
08-05-2003, 03:09 PM
I feel this maybe bad idea you need info on all planes to develope you tatics flying alone or with wing man

XyZspineZyX
08-05-2003, 04:18 PM
Just asking but.. How could you notice that non visible planes are updated at all / as much as the near planes?

However, I strongly agree that there should be a "bubble".. But probably that's what the patch will bring. /i/smilies/16x16_smiley-happy.gif

XyZspineZyX
08-05-2003, 07:50 PM
papagunns wrote:
- I feel this maybe bad idea you need info on all
- planes to develope you tatics flying alone or with
- wing man
-
-
how do you get info about planes you cant see?

your comp only needs the data from planes he has to draw. Also if the enemy is a point at the horizon, there is no need to update the position every 1/10 second as the position of the point will not change. If a plane is 100m in front of you, then you need a smoth display of its flight path.

this would even better for projectils.


quiet_man

second foundation member of the EURO_Snoopy fan club!

I'm quiet_man, but if I post I post quiet much /i/smilies/16x16_smiley-happy.gif

XyZspineZyX
08-05-2003, 09:47 PM
I know that all planes get updated at the same rate because when map icons are turned on, even planes at the other map are turning as smooth as planes do 10 feet from you. And planes close to you still jerk around as much as further planes. Bandwidth should not be wasted on planes across the map. Planes closer to you should be of a higher priority. If you ever played Aces High, you'll notice that planes way off in the distance jerk and warp a lot (Aces High has an exceptionally small "bubble" if that's what you want to call it) but once you get within shooting range, they move perfectly smoothly becaue they are prioritized over futher planes. This system is usually used in massive multiplayer online flight sims but it can be of great use to IL-2. Does anyone understand this?

http://www.assonetart.com/ClashofArmor.jpg
"Cowards die many times before their deaths;
The valiant never taste of death but once."

XyZspineZyX
08-05-2003, 10:28 PM
Yes I understand EvilBen. I didn't realize that they were not already doing this sort of optimization. It is definetly something they should try to add. It could help things quite a bit.

Snoop Baron

XyZspineZyX
08-05-2003, 10:55 PM
We built Iron Skies around the assumption that IL-2 used something as common sense and well known as this technique. I am not 100% certain you are correct about this, perhaps turning on map icons makes for a map wide bubble? Have you checked fps with no map icons vs with map icons? Just a thought though not very scientific test I suppose.

If this is true, then Oleg definately should do as you propose. It would immensely improve online play and have no adverse affects to anyone online or off.

For those not quite sure what EvilBen is talking about, beyond a certain range warping is not visible. At that range, we can update a planes position far less often and you will not notice it is warping.
This saves bandwidth which you can then use to update the position of the planes near you much more often, reducing their warp.

It would be nice to know for certain if Oleg already does this or not.

<img src=http://www.simops.com/graphics/wildcard.gif>

IRON SKIES
As real as you want it to be.

XyZspineZyX
08-05-2003, 11:52 PM
I also know this isn't implemented because when you record an online track and when you play back the track while watching the other planes that were far away from you at the time of recording, all the other planes on the server move in the same way, no matter how far you were from the plane you are watching. If this were implemented, closer planes would be moving smoother and further planes would be warping more.

BTW, This system would also increase the number of people who can fly on a server because there is less (or no) useless data transfer.

http://www.assonetart.com/ClashofArmor.jpg
"Cowards die many times before their deaths;
The valiant never taste of death but once."

Message Edited on 08/05/0307:01PM by EvilBen

XyZspineZyX
08-06-2003, 12:08 AM
I still don't know what to think about this. If this is true, then it definately won't be fixed for the patch. To fix this would require that the map-wide bubble be enabled to make online tracks and when map icons are on. Then disabled when you want better fps. Otherwise, neither of those features would work with limited bubbles, if you are correct.

And just to be clear, I would rather have bubbles within which my data is updated faster and outside of which, my data is updated slower and have less accurate map icons and online tracks that show warping when I look at planes that were far away from the action.

But others might want an option for online tracks vs better playability.


<img src=http://www.simops.com/graphics/wildcard.gif>

IRON SKIES
As real as you want it to be.

XyZspineZyX
08-06-2003, 12:12 AM
Good Point !!!!


Another tip is the fact that we do not have a dedicated server .exe

When the machien thats hosting has to also draw graphics this is a bad thing & causes lots of lag !! regaurdless of ram ammount & whatnot

Games such as FPS games that have dedicated server exe run much more smoothley because the server isint runnung any graphics thus freeing up the CPU to do server work not graphical work

Runing a non-dedicated server & minimizing the sim is not the same as a pure server exe the cpu is still working on graphics regaurdless of the fact that its minimized

Get dedicated server.exe for FB & half the lag will be gone

Impliment your other Idea & we are Lag free all the way on dedicated servers with Highspeed connections

also give servers admin tools & allow us to inable/disable things like screen shots, wingtip smoke, Making of Demos, Client Network connection speed also known as packet rate

These few things would cease the lag/pauses in this sim

<center><FONT COLOR="white">ӚFJ-M œ R D ˜ ӡ[/i]</font>

<center> http://www.onpoi.net/ah/pics/users/ah_109_1059752328.jpg </center>

<center><FONT COLOR="black">
I am He who lives, and was dead
and behold
I am alive forevermore.
I am the Alpha and the Omega
the Begining and the End.[/i]</font>

XyZspineZyX
08-06-2003, 12:26 AM
Online tracks would be fine if you like to stick to your own plane and planes close to you while watching but if you wanted to watch another player that was very far away from you at the time of recording, you will see warping. Map icons are not a problem because who needs far away map icons updated like ten times a second? Once every few seconds would be fine for distant planes/their map icons. The only downside to this "bubble" system is some warping when viewing online tracks of people who were far from you at the tIme of recording. It's a small price to pay for increased online performance and less warping.

http://www.assonetart.com/ClashofArmor.jpg
"Cowards die many times before their deaths;
The valiant never taste of death but once."

Message Edited on 08/05/0307:28PM by EvilBen

XyZspineZyX
08-06-2003, 03:22 AM
In my opinion tracks are good for one thing Making training films !!!

Never should anyone be making tracks while there in someone elses server thats just asking for lag....

if they wana host & film themsleves fighting one on one v a friend for trainign proposes thats another story

<center><FONT COLOR="white">ӚFJ-M œ R D ˜ ӡ[/i]</font>

<center> http://www.onpoi.net/ah/pics/users/ah_109_1059752328.jpg </center>

<center><FONT COLOR="black">
I am He who lives, and was dead
and behold
I am alive forevermore.
I am the Alpha and the Omega
the Begining and the End.[/i]</font>

XyZspineZyX
08-06-2003, 05:01 AM
It sounds like a good idea but it's based on the assumption that the "warping" problem is due to an "overload" on the client's machine. What you are suggesting might improve framerates for a low powered CPU but it doesn't address the real problem.

Lost data packets and high transit times cause the warp. The "target" aircraft sends its data to the host, the host then sends the updated position to you. Now, the next data packet from the target gets dropped or delayed on it's way to the host, the host says "forget you" and puts him at the end of the queue. In the meantime the target has changed position. The next time the host gets good data from the "target" it updates his position and sends it to you. Viola! The target "jumps" to its actual position. A faster sampling rate cannot make up for lost and delayed packets from the client to the host, or from the host to you for that matter. Note that warping can occur even when there are only two or three planes on the server (including the server's plane).

FB seems to be worse than most online sims in this aspect but I'm not so sure this is the reason.

Message Edited on 08/05/0306:11PM by Wind_Master

XyZspineZyX
08-06-2003, 05:17 AM
Wind_Master wrote:
- It sounds like a good idea but it's based on the
- assumption that the "warping" problem is due to an
- "overload" on the client's machine. What you are
- suggesting might improve framerates for a low
- powered CPU but it doesn't address the real problem.
-
- Lost data packets and high transit times cause the
- warp. The "target" aircraft sends its data to the
- host, the host then sends the updated position to
- you. Now, the next data packet from the target gets
- dropped or delayed on it's way to the host, the host
- says "forget you" and puts him at the end of the
- queue. In the meantime the target has changed
- position. The next time the host gets good data from
- the "target" it updates his position and sends it to
- you. Viola! The target "jumps" to its actual
- position. A faster sampling rate cannot make up for
- lost and delayed packets from the client to the
- host, or from the host to you for that matter. Note
- that warping can occur even when there are only two
- or three planes on the server (including the
- server's plane).


Sure, lag will still occur no matter what if the server/clients connection isn't clean but this feature is meant to improve the efficiency of the newtwork. Bandwidth is being used up in the wrong places.

http://www.assonetart.com/ClashofArmor.jpg
"Cowards die many times before their deaths;
The valiant never taste of death but once."

XyZspineZyX
08-06-2003, 06:40 AM
Similar to this concept, I had an idea that could improve OFFLINE play.

We all know that AI planes fly on simpler FM because the limitation of computing power. What if there's this "bubble", outside of which AI's fly on simpler FM; while inside, AI's fly on the more complex(player's) FM. This way we can have a huge air war on the map, while dogfighting non-ufo AI.

XyZspineZyX
08-06-2003, 07:03 AM
First, an assumption. It seems basis of the netcode is that the host polls all the client machines, compiles the position and other data about each client then sends all of that data back to all the client machines. I could be wrong about this but having all of the clients communicate independantly through the host just doesn't seem practical. How could it work? A exchanges data with B, then D, then E. Then it's B's turn to contact D then E and so on?

Assuming the above is correct (it could be something entirely different), to operate as you suggest, the host would "filter" the data it sends to each client? To do this the server would, in addition to compiling the data for all the clients, have to calculate which aircraft were within target range of each client, send it, and also determine the proper time to sent the lower priority data. It seems this would put a heavier load on the host. Since this not a dedicated server (ala Warbirds, etc.), remember that the host must also be dealing with the graphics for itself at the same time.

Again, what you suggest would undoubtedly ease the load on the client machine but at what expense? Please don't get me wrong, I'm not arguing that the netcode can't be improved. I'm just not sure that your assumption about what the primary problem is, is correct. It could be that you are but without really knowing how the netcode operates doing what you suggest could actually make matters worse. Very often when dealing with computer code, a seemingly small change to improve one thing can have unforseen consequences elsewhere.

XyZspineZyX
08-06-2003, 10:15 AM
Changing the update rate at a distance is probably a good thing. Trying to check visibilities is probably not. For sure, there would have to be a state check for cockpit-only and even then there would be a very large load on the server even if it's running stand-alone. View is something done at the client end down in the 3D render -- you expect to do that for 16 or 32 planes on a server? Remember that the videocards now carry a good bit of the render load.

WM, if the positions were transmitted in a daisy-chain fashion then everyone would be hosts and IMO, all H would break loose in waves! Dedicated servers are the best way although the host can opt for smoother play for all by just parking his or her plane or not even renewing on death while hosting DF. To add that one extra plane is no big deal in coop, is it?

How many million lines of code does Oleg say there is? Code size alone takes up resource space. Intel-based chips also transfer data (including code) in 64k chunks, swapping it in and out of the "golden" lower 640k. Even 10 or 20k extra makes a difference -- which is why dedicated servers do so much better regardless of the PC being used. If the PC world had gone Motorola back even as late as 1985, we would have been seeing much faster and better programs ever since as the 68000 series ran full 32-bit addressing though that is assuming that the mobo busses supported all 32 lines. Instead, we have the schizo-chips from Intel.


Neal

XyZspineZyX
08-06-2003, 03:40 PM
EvilBen wrote:
- Sure, lag will still occur no matter what if the
- server/clients connection isn't clean but this
- feature is meant to improve the efficiency of the
- newtwork. Bandwidth is being used up in the wrong
- places.

Lost packets aren't necessarily an issue with bandwidth
at the points at which your suggestion would affect it.
Many factors affect the likelihood of lost packets. Bandwidth
is one of them, but a high bandwidth load might be due
to factors other than FB, or any of the PCs involved in
that game. Only if the network bandwidth generated by
FB itself puts a strain on the 'last mile' for the PCs involved will your suggestion improve matters.

If lost packets are due to some other reason (network
bandwidth loss elsewhere, misconfigured router somewhere
deep in a network) then reducing the number of packets being
sent to update positions of distant planes brings the risk
of making them more warpy as there is an increased chance
with lower number of packets sent that ALL of them in a
given time period will be lost. Warpy planes at distance
might not be a concern, though. It would make it harder,
though, to track a plane when it has just become a dot,
and assess its path and plan a climb accordingly. You'd
really need to push the distance out to beyond the visible.

XyZspineZyX
08-06-2003, 03:48 PM
WWMaxGunz wrote:
- How many million lines of code does Oleg say there
- is? Code size alone takes up resource space.
- Intel-based chips also transfer data (including
- code) in 64k chunks, swapping it in and out of the
- "golden" lower 640k. Even 10 or 20k extra makes a
- difference -- which is why dedicated servers do so
- much better regardless of the PC being used. If the
- PC world had gone Motorola back even as late as
- 1985, we would have been seeing much faster and
- better programs ever since as the 68000 series ran
- full 32-bit addressing though that is assuming that
- the mobo busses supported all 32 lines. Instead, we
- have the schizo-chips from Intel.

This is why sometimes optimising code too heavily
(unrolling too many loops) can be counterproductive if
it increases code size too much.

It's one reason why you have to take chip GHz with a pinch
of salt - memory architecture, numbers of pipelines,
cache sizes, numbers of levels of cache, branch prediction,
pre fetch, etc, all make quite a difference. x86 chips
actually do relatively poorly in terms of Flops/GHz.

XyZspineZyX
08-06-2003, 04:29 PM
I think some modifications could improve the online game:

1. Using of TCP insteady of UDP: This would make it easy to conect behind a firewall. Only the server should have a valid IP. Clients shouldn't. Also, as it's oriented to conection and not datagram, the server and the client can detect any broken conex instantly insteady of waiting for timeout;

2. Using of dedicated server just for exchanging messages between the host and the clients. Even the host could be behind a firewall. I'm using this kind of aproach to distribute real time quotes for more than 200 users, with more then 10 updates a second. It was the best solution I've found;

3. Using of dedicated host without the graphics render;

4. Stablishing the concept of bubble. As the dot is visible up to 14km, why do I have to receive information about planes and other objects that are far away from this? The client should receive updates only from the objects inside this 14km bubble and nothing more. Its easy for the host to calculate this. Just check the delta between my horizontal position and the horizontal position of other objects. It's 2 calcs for each object. I think only the criptograph of each update packet do a lot of more calculations than that. Falcon4 SP3 use this concept, as well as WB.

I think that way it would be possible to develop a massive multiplayer for FB.

Rgds,
Jagua.

michapma
08-06-2003, 05:07 PM
Do you think that maybe Oleg is aware of such programming techniques and has a reason for implementing it the way it is?

Just a thought. /i/smilies/16x16_robot-happy.gif

Mike

<table width="100%" border="0" cellspacing="0" cellpadding="10"><tr valign="middle" bgcolor="#3e463b"><td height="40" colspan="3" align="center">The ongoing IL-2 User's Guide project (http://people.ee.ethz.ch/~chapman/il2guide/)</a></td></tr><tr bgcolor="#515e2f"><td width="40%">FB engine management:
Manifold Pressure sucks (http://www.avweb.com/news/columns/182081-1.html)
Those Marvelous Props (http://www.avweb.com/news/columns/182082-1.html)
Mixture Magic (http://www.avweb.com/news/columns/182084-1.html)
Putting It All Together (http://www.avweb.com/news/columns/182085-1.html)
Those Fire-Breathing Turbos (Part 1 of 6) (http://www.avweb.com/news/columns/182102-1.html)</td><td align="center"><p/i/smilies/16x16_robot-mad.gif 69.GIAP=Chap

69.GIAP (http://www.baseclass.modulweb.dk/giap/)</p></td><td width="40%" align="right" valign="top">Hardware:
Flight Simulation Performance Analyzed (http://www.simhq.com/_air/air_062a.html)
Building a home-made throttle quadrant step by step (http://forums.ubi.com/messages/message_view-topic.asp?name=us_il2sturmovik_gd&id=zkavv)
Sound Can Be Hazardous for Games (http://www6.tomshardware.com/game/20030405/index.html)</td></tr></table>

XyZspineZyX
08-06-2003, 05:08 PM
The problem for a bubble is that there are a lot of
objects in the game - mostly game objects, that have
damage states.

If you have a non-bubble system then you get information
on the world state at loading, and then more or less
constant dribs and drabs updating the state of those
objects. This information is common to all clients.

If you have a bubble system then you have to tell
the host where your bubble is. The host then needs
to send you update information on the state of everything
that has come into your bubble area, as well as everything
within it. In some areas (cities, airfields, armoured
columns) the object density is quite high, so you'd have
to be given a whole load of information about damage
of those areas. (Luckily if something is blown up it
at least stays that way). Potentially you suddenly get
hit with a lot of data being transferred.

More than this, if you are flying in formation you
will have 4, 8, 12, or more clients informing the
host of their position, and due to variations in their
location requesting a number of slightly different
updates of the state of those ground objects, all of which
the host needs to fulfill.

I think you are looking at stuttering in these situations.

What would be better is rather than a bubble in the sense
previously talked about would be a way to prioritise the
order in which data is sent to clients - i.e. things
close to a client get sent out first, things further away
get sent when there is less bandwidth load to that client.
You'd have to be careful to design the queue such that
all information got sent in a relatively timely manner,
of course!

However this still puts quite a CPU load on the host, and
this might result in the host not being able to send out
any packets in a timely manner, and hence stuttering!

XyZspineZyX
08-06-2003, 05:34 PM
AaronGT wrote:
- The problem for a bubble is that there are a lot of
- objects in the game - mostly game objects, that have
- damage states.
-
- If you have a non-bubble system then you get
- information
- on the world state at loading, and then more or less
- constant dribs and drabs updating the state of those
- objects. This information is common to all clients.

So maybe the ground objects info gets updated independant of the range limit? Problem solved.


Neal

XyZspineZyX
08-06-2003, 05:36 PM
Yes, that was my suggestion. I shouldn't have used the word bubble. It's more like many bubbles. Like within 100 meters, all objects are updated 10 times a second, within 300 meters, all objects are updated 5 times a second, within 1000 meters, all object are updated 3 times a second and so on. Every unit on the server will always be updated, it's just that farther units won't be updated as much and closer units will be updated more. This won't cause lag because all the distance calculations can be done on the client-side. The client will assign each unit its own update rate and the server will update each unit for the client based upon that update rate.

http://www.assonetart.com/ClashofArmor.jpg
"Cowards die many times before their deaths;
The valiant never taste of death but once."

Message Edited on 08/06/0312:38PM by EvilBen

XyZspineZyX
08-06-2003, 05:44 PM
WWMaxGunz wrote:
- So maybe the ground objects info gets updated
- independant of the range limit? Problem solved.

True, although maybe my drive for ultimate consistency
in all things means I don't like that. But it's certainly
a good pragmatic solution. Also ground objects don't
tend to move so quickly, so warp is less of an issue for
them, so it is reasonable to hold them to different
update requirements.

XyZspineZyX
08-06-2003, 05:49 PM
Making the client do that work makes sense, and I
hadn't spotted that idea. So well spotted that man!

I still think you need to analyse what causes the
lag/stutter first, though. It only makes sense to
implement the system suggested if bandwidth limitations
are the cause of the lag.



EvilBen wrote:
- Yes, that was my suggestion. I shouldn't have used
- the word bubble. It's more like many bubbles. Like
- within 100 meters, all objects are updated 10 times
- a second, within 300 meters, all objects are updated
- 5 times a second, within 1000 meters, all object are
- updated 3 times a second and so on. Every unit on
- the server will always be updated, it's just that
- farther units won't be updated as much and closer
- units will be updated more. This won't cause lag
- because all the distance calculations can be done on
- the client-side. The client will assign each unit
- its own update rate and the server will update each
- unit for the client based upon that update rate.
-
- http://www.assonetart.com/ClashofArmor.jpg - "Cowards die many times before their deaths;
- The valiant never taste of death but once."
-
- Message Edited on 08/06/03 12:38PM by EvilBen

XyZspineZyX
08-06-2003, 07:06 PM
Sorry to burst anyones bubble (pun intended /i/smilies/16x16_robot-wink.gif ) but this is always the first question you ask yourself when starting the design for the net-code. Oleg's team certainly went over this a couple of times and they took the option with less lag and most features... I've designed multiplayer games and the first question is always "distributed server" or "host server" the second question is always what information to send to whom. I'm quite sure Oleg's team spent a long time designing and thinking the net-code to make it as less laggy as possible and as most secure as possible (secure in both the sense of resillient to hacking and to limit packet loss).

I'm sorry if I offended anyone. But now I work for clients designing and producing edutainment software and clients act just like you did. "Hey did you think about this or that?" Which is irritating since it's my job to think about those things, just asking me this is doubting my abilities. I have plenty more of informations and knowledge about the subject at hand, I'll, whitout a trace of doubt, make the best decision.

Ouf sorry some steam from my job got out... Anyway the comments brought the steam. And since I cannot rebuke the client with and evil grin I somehow jump on this occasion to do it. ;-)

Esc101_ElPape

XyZspineZyX
08-06-2003, 08:24 PM
AaronGT wrote:
-
- Making the client do that work makes sense, and I
- hadn't spotted that idea. So well spotted that man!
-
- I still think you need to analyse what causes the
- lag/stutter first, though. It only makes sense to
- implement the system suggested if bandwidth
- limitations
- are the cause of the lag.
-

More than that:

My idea is:

1. The ground demage and objects positions would be send to anyone. It´s not so fast and not so often, so I think it would not impact in the performance;

2. The server (or the host) would store a list of horizontal position of each plane. As one client sends one update, it compares it´s horizontal position with each other clients plane position in order to decide if it should or not send this update to this especific client. Its easy. And It should not calculate the bubble for each plane.

3. Other decisions could be done in the client side;

4. Its not only a question of lag, but it could expand the number of players online in a game.

S!
Jagua.

XyZspineZyX
08-06-2003, 09:00 PM
ElPape wrote:
- Sorry to burst anyones bubble (pun intended /i/smilies/16x16_robot-wink.gif ) but this is always the first
- question you ask yourself when starting the design
- for the net-code. Oleg's team certainly went over
- this a couple of times and they took the option with
- less lag and most features... I've designed
- multiplayer games and the first question is always
- "distributed server" or "host server" the second
- question is always what information to send to whom.
- I'm quite sure Oleg's team spent a long time
- designing and thinking the net-code to make it as
- less laggy as possible and as most secure as
- possible (secure in both the sense of resillient to
- hacking and to limit packet loss).
-
- I'm sorry if I offended anyone. But now I work for
- clients designing and producing edutainment software
- and clients act just like you did. "Hey did you
- think about this or that?" Which is irritating since
- it's my job to think about those things, just asking
- me this is doubting my abilities. I have plenty more
- of informations and knowledge about the subject at
- hand, I'll, whitout a trace of doubt, make the best
- decision.
-
- Ouf sorry some steam from my job got out... Anyway
- the comments brought the steam. And since I cannot
- rebuke the client with and evil grin I somehow jump
- on this occasion to do it. ;-)
-
- Esc101_ElPape
-
-

ElPape,

Related to Bubble, NP. But if other sims use it with relative success, why FB couldn´t use it. I like to see all the players in online tracks, but if the bubble could help to implement a massive multiplayer (not alone, of course), why don´t use it?

Im not a game developer, but Im a telecomunications software developer for 20 years now and my opinion, as yurs, is based in experience, some experience that many game developers dont have.

BTW in my work, I always listen to my clients opinion. Some times they have good ideas. http://ubbxforums.ubi.com/infopop/emoticons/icon_smile.gif

I think we can use the best of both worlds, and thats the reason of my suggestions.

Rgds,
Jagua.

XyZspineZyX
08-06-2003, 09:33 PM
ElPape wrote:
- Sorry to burst anyones bubble (pun intended /i/smilies/16x16_robot-wink.gif ) but this is always the first
- question you ask yourself when starting the design
- for the net-code. Oleg's team certainly went over
- this a couple of times and they took the option with
- less lag and most features... I've designed
- multiplayer games and the first question is always
- "distributed server" or "host server" the second
- question is always what information to send to whom.
- I'm quite sure Oleg's team spent a long time
- designing and thinking the net-code to make it as
- less laggy as possible and as most secure as
- possible (secure in both the sense of resillient to
- hacking and to limit packet loss).
-
- I'm sorry if I offended anyone. But now I work for
- clients designing and producing edutainment software
- and clients act just like you did. "Hey did you
- think about this or that?" Which is irritating since
- it's my job to think about those things, just asking
- me this is doubting my abilities. I have plenty more
- of informations and knowledge about the subject at
- hand, I'll, whitout a trace of doubt, make the best
- decision.
-
- Ouf sorry some steam from my job got out... Anyway
- the comments brought the steam. And since I cannot
- rebuke the client with and evil grin I somehow jump
- on this occasion to do it. ;-)
-
- Esc101_ElPape

Then I would like to hear from one of the developers what's the benefit of updating all planes/ground units at the same rate no matter how far it is from the player. I think it would be better if units closer to the player (or his camera if he chooses to view other planes from external view) are prioritized and given more bandwidth than a planes across the map that can't even be seen. This isn't ground breaking, new, theoretical technology. Simulations from years ago have this feature. It can do wonders for FB. I'm sure Oleg new about this technolgy and I'm just wondering why he chose not to use it.

http://www.assonetart.com/ClashofArmor.jpg
"Cowards die many times before their deaths;
The valiant never taste of death but once."

XyZspineZyX
08-06-2003, 11:05 PM
EvilBen wrote:
- Then I would like to hear from one of the developers
- what's the benefit of updating all planes/ground
- units at the same rate no matter how far it is from
- the player.

There may be no benefit, but there might also not
be any detriment, or rather the stutter/lag might
not be related to bandwidth issues. So introducing
the additional complexity (and thus propensity for
bugs) when bandwidth might not be the issue would
be counter productive. (To paraphrase Einstein the net
code should be as complex as required, but no more so).
If the lag _is_ due to bandwidth issues, then that's
another matter.

There does seem to be a stutter issue in relation
to skin download, but I am not sure if that is due
to pure bandwidth issues, or if the host has to devote
too much CPU time to mediating the transfer and so on?

You could do third-party transfers but then you'd need
to have the client transfer data to each other client
in the game, which wouldn't be much fun for the new
client, but would free up load on the host. I suspect the
way it is currently done is the client uploads to the
server, and then back down to clients. This can load
the host. However it's a format that is very compatible
with potential commercial hosting of IL2, as in Aces High,
Warbirds, etc. where you have a (series) of powerful,
well connected machines. You could have net code for
self-hosting that uses third party copy, and other net
code for server-centric type hosting, but then you
multiply the total code base, and that makes the project
less managable.

As PCs and network bandwidth improves, the bottlenecks
move to different parts of the system.

- I think it would be better if units
- closer to the player (or his camera if he chooses to
- view other planes from external view) are
- prioritized and given more bandwidth than a planes
- across the map that can't even be seen. This isn't
- ground breaking, new, theoretical technology.
- Simulations from years ago have this feature. It can
- do wonders for FB.


But is it the source of the problem?

XyZspineZyX
08-07-2003, 02:41 AM
EvilBen wrote:
- Yes, that was my suggestion. I shouldn't have used
- the word bubble. It's more like many bubbles. Like
- within 100 meters, all objects are updated 10 times
- a second, within 300 meters, all objects are updated
- 5 times a second, within 1000 meters, all object are
- updated 3 times a second and so on. Every unit on
- the server will always be updated, it's just that
- farther units won't be updated as much and closer
- units will be updated more. This won't cause lag
- because all the distance calculations can be done on
- the client-side. The client will assign each unit
- its own update rate and the server will update each
- unit for the client based upon that update rate.
-

If the client does the calcs then it has to communicate all that to the server. Better to have the server which knows all the positions first and most often do the range calcs an set the update timing. Compare the savings of client side calcs to the time the server would spend collecting, translating and acting on packets from every client machine about every other plane timed according to where they were in the update scheme.
The bandwidth savings would be much less than if the server did the calcs with client to server. As it is there's data on position, heading, rate of turn data and when you fired each shot... would each client tell the server when every shot passed boundaries for update timing?
At 540kph a plane is moving at 150m/sec, only 30m every 5th/sec right? Two approaching head to head may still not seem like much. Both of those firing shots at each other and what happens to the upload traffic?
Or you could let the server tell the clients where the planes are, heading, deltas and fire times then let the clients just work out the picture themselves. Let the server decide how often to send the updates and avoid the lag in that along with the load. And at 300m, how does gunnery work out when the client only knows about shots originating every 2/10ths of a second? What lag does to gunnery is bad enough now although I have no way to know what the update rate ~is~ in FB. The server can keep a much cleaner picture including when a plane has taken hits, it does that in SP already.


Hey Aaron! Long time ago, about 23 years ago I made the application of a basis on Occams Razor as part of my coding philosophy. Cut away the slow parts because they'll be slow and put them on the end of the list. It worked really well running 3mz 8085's, 4-5mz Z80's and 1mz 6502's and stood by me for 20 years since while CPU speed and power increased then so did the loads we dumped onto them. Clean doesn't necessarily mean code-orthagonally consistent although yes that makes for less exceptions and much more general not to mention fewer modules, less granular code. I applaud that but reality does require solutions that run with or within (I preferred the first there, worked better in the long run.) the flow of constraints. LOL, your mileage may vary.


Neal

XyZspineZyX
08-07-2003, 05:05 AM
I found this article about another sim that shows the transition in a sim from the old netcode (the one FB currently has) to the new netcode. It also explains why the new system is better than the old one. I now hope you all believe me now that this will improve FB. I can't think of any more proof to support my opinion.

http://eteam.frugalsworld.com/articles/10799/netcode.html

http://www.assonetart.com/ClashofArmor.jpg
"Cowards die many times before their deaths;
The valiant never taste of death but once."

Message Edited on 08/07/0312:10AM by EvilBen

XyZspineZyX
08-07-2003, 07:13 AM
EvilBen wrote:

- I found this article about another sim that shows the
- transition in a sim from the old netcode (the one FB
- currently has) to the new netcode.


Again, we don't know how the netcode of FB works (unless you have some inside information). What reason is there to believe that the netcode of FB is the same as the "old" netcode of F4? The original code for F4 is what? Four, Five years old (six)?

The way that article describes the "new" code sounds pretty much the same way I guessed it works in FB. Note that the article also points out that while the "new" may help in some areas, it may also cause problems elsewhere (as I pointed out).

You've taken one part of the code (the "bubble" concept) and ignored the other crucial parts. This is not a matter of a patch, you're asking for a total rewrite of the netcode....for a product that is "finished". Don't hold your breath.

You've taken this idea in your mouth like a pitbull and won't let go even though you don't have enough information to base your assumptions on.

Message Edited on 08/06/0309:22PM by Wind_Master

XyZspineZyX
08-08-2003, 01:44 AM
You seem a bit hypercritical there WindMaster. EB's observation is a valid one. It may be true and it is definately worth looking into. The more I read up on it, the more it seems he may be correct. MAY Be correct. And if it is, then yes, it would mean rewriting the netcode. Well, if the netcode is so outdated that it doesn't use ideas that have been standard for over five years then maybe Oleg should rewrite it for his next sim so he doesn't keep having the same problems he's having now.
Or maybe this isn't true and Oleg has other issues causing these same problems.
Either way, this won't be resolved unless Oleg chimes in on this thread so it probably isn't going to go anywhere.

<img src=http://www.simops.com/graphics/wildcard.gif>

IRON SKIES
As real as you want it to be.

XyZspineZyX
08-11-2003, 08:10 AM
Wind_Master wrote:
- It sounds like a good idea but it's based on the
- assumption that the "warping" problem is due to an
- "overload" on the client's machine. What you are
- suggesting might improve framerates for a low
- powered CPU but it doesn't address the real problem.
-
- Lost data packets and high transit times cause the
- warp. The "target" aircraft sends its data to the
- host, the host then sends the updated position to
- you. Now, the next data packet from the target gets
- dropped or delayed on it's way to the host, the host
- says "forget you" and puts him at the end of the
- queue. In the meantime the target has changed
- position. The next time the host gets good data from
- the "target" it updates his position and sends it to
- you. Viola! The target "jumps" to its actual
- position. A faster sampling rate cannot make up for
- lost and delayed packets from the client to the
- host, or from the host to you for that matter. Note
- that warping can occur even when there are only two
- or three planes on the server (including the
- server's plane).
-
- FB seems to be worse than most online sims in this
- aspect but I'm not so sure this is the reason.
-
- Message Edited on 08/05/03 06:11PM by
- Wind_Master


EXACTLY!

XyZspineZyX
08-11-2003, 01:05 PM
I've played games with 16 players with no stutter, and
with half a dozen players which have been too laggy to play.
It suggests that other factors may be involved. If it can
handle 16 players without stutter, that's doing reasonably
well.

Anyway, I've done some back-of-the-envelope calculations.

Looking at the Falcon article, if it needed such
bandwidth, it was very badly written netcode! Based on
that, and 16 bits for X, Y, Z positions, angles, etc.
FB would only be able to handle about 20 objects at a
time at 40Hz, which is clearly not the case. Even with
cunning schemes such as bifurcating the spaces and
only sending deltas (low bit rate) each 1/40th second
and a full postion (in case of packet loss you don't
want to rely on deltas) each second, you can't handle
much more than 32 objects on a 56k modem. I've hosted
a mission on a 56k modem with about that many planes
in total, plus ground objects. So basically whatever
way FB does it, it doesn't use the same parameters
as Falcon.

Given this, I am not convinced that FB sends information
out in a dumb way. Maybe it sends information out in
chunks in which the information is free form, dependent
on status bits at the beginning of the message. This means
you can send out information regarding ground objects
in a more asychronous way, i.e. just updates on their
status. But then you'd need to ensure that the client
has received them, so you'd need to send them TCP to
give more routing relability. If you are using TCP then
packets can arrive late, in which case you can see sudden
jumps as the client finally updates its information from
a late-arriving packet.

Also it might prioritise update rates too. Who knows.

I am sure it is more complex than that.

XyZspineZyX
08-11-2003, 01:32 PM
Someone recommended using TCP instead of UDP...

Can't do it. First off, TCP requires ACK packets for each one sent. Guaranteed delivery but almost doubles the amount of needed packets and if no ACK on one packet the stream needs to be resent.

Would allow for about 4 players steady on a LAN and that's about it.TCP is very reliable but not very efficient. UDP is efficient and made for speed but not reliable--hence why most games use it and enable some sort of client side predictor code...

XyZspineZyX
08-11-2003, 04:39 PM
WWSensei wrote:
- Someone recommended using TCP instead of UDP...
-
- Can't do it. First off, TCP requires ACK packets
- for each one sent. Guaranteed delivery but almost
- doubles the amount of needed packets and if no ACK
- on one packet the stream needs to be resent.
-
- Would allow for about 4 players steady on a LAN and
- that's about it.TCP is very reliable but not very
- efficient. UDP is efficient and made for speed but
- not reliable--hence why most games use it and enable
- some sort of client side predictor code...
-
-

I made an survey about network protokolls and TCP is in fact faster than UDP on most of todays hardware

nearly all low level network protokolls today are optimized for reliable communication, the network cards themself implement resending and error correction, packet loss only occurs on routers or server (send/receive buffers full)

so if you use UDP there is only minimal change on the network protokoll stack, but usually at last a detection for old packages is added in the application (you don't want to see where the planes where 5 minutes ago /i/smilies/16x16_smiley-wink.gif ) that increases overhead

one advantages has UDP, for an realtime application like FB there is no use to resend old packets if the client already received actuall ones. But if packet losse only occurs when router/server are close to breakdown its a question how good the connection is at all.

It would be interesting to see how IL2 would behave with TCP. I think that people with connection better than X would see better performance, while people with worse than X would lose connection. The question is where X is.



quiet_man

second foundation member of the EURO_Snoopy fan club!

I'm quiet_man, but if I post I post quiet much /i/smilies/16x16_smiley-happy.gif