is HTC capable of the level of detail of IL2FB?

[vorticon]

26 bits, a single 32 bit word seems enough to transmit our actual visible damage for any plane. Adding much more visible damage will imply the transmission of much more data with the corresponding impact on communications.

no it wont...what gets transmitted is data on whats hit...the actual graphical display of the damage is done by the users computer...there will be more data...but not so much as to crap out the connection

why do you think a half hour .ahf file is less than 1 mb...all the data it contains is just locations of planes type of planes when someone fired what that firing did and what the map it was recorded on looked like...all the graphics and stuff are stored on the computer and are called at the right time...and im assuming that this is the same sort of data thats transmitted while flying online (with the exception of the map)

but then again i know damn near nothing and this is all speculation...

[GODO]

vorticon, think on the following scenario:

You aproach to a friendly stuka, and, as result of close observation, you notice it is lacking left gear, right flap and aileron. The server is sending not only the position, bearing, angle and speed of the friendly stuka, but also info about its current damage so your client can represent it.

Now imagine the same situation, but, as well as the mentioned damage, you notice five 20mm holes in the stuka's left wing, several small cal holes in the forward canopy glass, rear machine guns destroyed and a section of the tail teared off. Surely that stuka is sending much more data about its damage to the server so that your FE can represent all of them accurately.

[Ecliptik]

With a very complex damage model, bandwith would be affected noticeabily. When you see a plane, you see the visible damage, so, that information is being sent and distributed by the server. Our actual visible damages are:
2 wing roots.
2 wing tips.
2 ailerons.
2 flaps.
2 elevators.
up tp 2 rudders.
oil x n engines (up to 4).
fuel.
radiator x n engines (up to 4).
fire.
up to 3 gears.
tail section.

26 bits, a single 32 bit word seems enough to transmit our actual visible damage for any plane. Adding much more visible damage will imply the transmission of much more data with the corresponding impact on communications.

Using one bit exclusively to store the status of a single component is rather primitive.  

Using a complex damage model need not increase bandwidth at all.  

A 32 bit word could theoretically hold 2^32 (~ 4 billion) different damage "states".

Obviously using a massive lookup table with 4 billion entries is unfeasible (it would consume all addressable physical memory), but you get the idea.  There are many tricks you could use to keep the required bandwidth down without placing too much additional stress on the client computer.

You might break the aircraft damage up into three "blocks" of 8 bits, each storing 256 states, and reserve the remaining 8 bits as simple 0-1 flags, like what you did above, for important pieces of information that may reduce computations if known quickly.  For example, if an entire wing is gone, none of the components in the wing need to be checked.

No need for much more bandwidth.

[AKS\/\/ulfe]

Originally posted by mold
I simply do not think that is true.  I have done some multiplayer programming before, and the CPU is not spending the majority of its time in these tasks.  Communication is filtered by the server, so that each client is being updated only with the closeby planes with any great frequency.  Furthermore, even full 400-player updates would not be so bad on the CPU--it is the network that would suffer from this.

I'm not sure what type (different types place different requirements on a computer system) of multiplaying interface you programmed for - but in the case of a flight sim there is a lot more that goes into the networking side than simply communicating, packaging (encoding/compressing and decoding/decompressing) packets, theres also quite a lot of client side computations to place the aircraft in a certain course relative to its last heading/speed/attitude (with more information no doubt being in the packet). Which is one reason why "stick stirring" leads to jumpy aircraft on connection speeds ranging from 28.8K (pretty much the minimum for MP gaming now a days) up to cable. It is due to both lack a steady communication of an object's state (.1 difference in all categories of movement) and because the program figures the plane will be doing something so much but the next packet is a vast difference so a smooth movement turns into a snap movement in the blink of an eye. 400 player updates still make a vast difference over a 32 player game, because updates (no matter how rare - once every 10 seconds with only updating what sector and what countries the numbers are in) still make a difference in what is going on "behind the scenes".

Anyway, the point I am getting at is that: Yes, HTC COULD do that - but its just not sensible unless we want one plane every month or two. As far as the program's size I may be the exception, but I refuse to download anything that takes longer than 6-8 hours of sleep(56K modem).
-SW

[mold]

Originally posted by AKS\/\/ulfe
I'm not sure what type (different types place different requirements on a computer system) of multiplaying interface you programmed for

Actually, it was a flight sim.  Not industrial grade, but I do have some idea of what's required...

Originally posted by AKS\/\/ulfe
but in the case of a flight sim there is a lot more that goes into the networking side than simply communicating, packaging (encoding/compressing and decoding/decompressing) packets, theres also quite a lot of client side computations to place the aircraft in a certain course relative to its last heading/speed/attitude (with more information no doubt being in the packet). Which is one reason why "stick stirring" leads to jumpy aircraft on connection speeds ranging from 28.8K (pretty much the minimum for MP gaming now a days) up to cable.

No way.  This is not caused by CPU limitations.  If that were the case, then boxed sims would also display jumpiness.  The CPU is extremely fast and can handle all of these things with ease.

Stick-stir jumpiness is caused by latency, which is not necessarily related to bandwidth (which is why both the 28.8 and the cable are subject to it).  Latency is largely a product of per-hop delays in the transit to the server, i.e. the public internet...not the "local loop".

Originally posted by AKS\/\/ulfe
400 player updates still make a vast difference over a 32 player game, because updates (no matter how rare - once every 10 seconds with only updating what sector and what countries the numbers are in) still make a difference in what is going on "behind the scenes".

Not for the CPU.  If you had full state updates for all 400 players, yeah there would be some serious lag, but not because the CPU couldn't handle it--rather because the network couldn't handle it.  But any con that is not a dot does not have to have it's state transmitted at all, and any con at long dot ranges can be once every 5 secs or something.  The server has enough information to do this type of culling.  How many planes are within icon range at any given time?

Originally posted by AKS\/\/ulfe
Anyway, the point I am getting at is that: Yes, HTC COULD do that - but its just not sensible unless we want one plane every month or two.

Well, that's another issue... Yes, it is true that there would have to be more modeling and programming to make this happen.

[AKS\/\/ulfe]

Originally posted by mold
No way.  This is not caused by CPU limitations.  If that were the case, then boxed sims would also display jumpiness.  The CPU is extremely fast and can handle all of these things with ease.

I didn't say CPU limitations, but its due to how the program interprets the set of packets to place the object smoothly because it is not getting updates that would allow the object to flow smoothly through the virtual world. This comes down to having to allocate some of the CPU to do the calculations for this which would mean that the CPU is in fact doing work to place the aircraft along a predicted flight path by estimating its next point by the previously recieved data. It isn't recieving a constant flow, so there is a lot of work on the user's PC to give the illusion that there is in fact a steady flow of constant position updates which are real time when in reality there aren't but it appears that way because the CPU is using an algorithm to give this end effect.

Originally posted by mold
Not for the CPU.  If you had full state updates for all 400 players, yeah there would be some serious lag, but not because the CPU couldn't handle it--rather because the network couldn't handle it.  But any con that is not a dot does not have to have it's state transmitted at all, and any con at long dot ranges can be once every 5 secs or something.  The server has enough information to do this type of culling.  How many planes are within icon range at any given time?

All contacts are being updated all the time, how often and what kind of updates the client PC is recieving depends on where the contact is located. If this weren't true, you wouldn't have any dar bar, dot dar, or knowledge there were anything outside of what you see. Thats where the 400 players come into play, because you are still recieving some form of update on their status whether you see them or not.
-SW

[mold]

Originally posted by AKS\/\/ulfe
I didn't say CPU limitations, but its due to how the program interprets the set of packets to place the object smoothly because it is not getting updates that would allow the object to flow smoothly through the virtual world. This comes down to having to allocate some of the CPU to do the calculations for this which would mean that the CPU is in fact doing work to place the aircraft along a predicted flight path by estimating its next point by the previously recieved data. It isn't recieving a constant flow, so there is a lot of work on the user's PC to give the illusion that there is in fact a steady flow of constant position updates which are real time when in reality there aren't but it appears that way because the CPU is using an algorithm to give this end effect.

Yes, I do understand that...I have programmed this kind of thing myself.  What I am saying is this is a fairly small burden for the CPU.  It's not "a lot of work".

Originally posted by AKS\/\/ulfe
All contacts are being updated all the time, how often and what kind of updates the client PC is recieving depends on where the contact is located. If this weren't true, you wouldn't have any dar bar, dot dar, or knowledge there were anything outside of what you see. Thats where the 400 players come into play, because you are still recieving some form of update on their status whether you see them or not.

An extremely low update frequency suffices for dot dar, and darbar has even lower requirements than that.  In fact darbar could be communicated on a per square basis which would also save BW.