Strategic dots for projectiles

"Should be moddable" or "is actually working as intended"?

E.g.:

• Server not culling projectiles
• Strat icon system being efficient enough in terms of vertex updates
• Did I mention server not culling projectiles?
• For immersions sake: Restoring particle system state when zooming in on projectiles

You should be able to give it strategic icons just like units is what he's saying I believe?

That it is possible was already known. They did it with the nuke.

But when you look at the nuke, you will also see that they gave it highest network priority to prevent culling. With the bandwidth limit in place (and the still lacking compression), most of the projectiles get culled quite soon when zooming out.

And there is also cosmetic bugs, like artillery etc. missing their tracers after zooming back in. Actually, even nukes have visible and disturbing gaps in their smoke trail where the particle system was paused (and the state not reconstructed properly). Fabber beams have a massive LOD on low zoom levels, probably for this specific reason.

That was no issue in SupCom and TA due to the synchronous network model where every client had these projectiles "for free", but in PA everything has to be transmitted over the network. And smart interpolation / priority aging on the server side is still not implemented as far as I'm aware.

Well then that's impossible to fix... right? Because the system for the game they want is server hosted so there is no lowest common denominator.

It ... is possible to fix, at least partly, by using using some clever predictions about what the user will see and what he won't see. Or to be precise: When will it become obvious that a bullet or unit movement was only fixed by two points in time, rather than having the full path transmitted.

E.g. for artillery. You WILL notice if the projectile is culled. However you won't notice when you are zoomed out and the projectile actually flys in a straight line rather than in the high arc as it was supposed to (since you only got 2-4 intermediate point instead of regular 5-10).

You won't notice if a unit is 1-2 meters of course, but you will notice if the unit isn't blowing up after being hit. You won't notice if a formation is slightly messed up and projectiles don't exactly align with the models when zoomed out, but you will when zoomed in.

You won't notice the lack of a trail when zoomed out, but you do notice even the tiniest gap when zoomed in.


These are observations which must be made for every single type of event if you wish to maintain the immersion and keep the effects of culling and/or reduced update rates and/or reduced accuracy(!!!you can save quite a lot by using data types with less resolution if full resolution isn't required!!!) hidden.

On top of that, there is also always the option of developing your own compression scheme instead of relying on standard algorithms.

I would say:
Yes, it can be fixed. It's not trivial and requires a lot of analytic work to determine which components have to be weighted how when bandwidth becomes scarce (and also to figure out how to make this decision efficiently), but either way: 2Mbit/s is quite a lot of data. That should be certainly enough to transfer estimated 10-20.000 position updates and events per second when done right. That's not enough to transfer every projectile's position from every server frame, but more than enough for an unbroken immersion.

Just some rough ideas HOW to squeeze that amount of events into the bandwidth:
Adaptive Huffman encoding for entity ids (just be careful with package loss. The adaptive portion doesn't like this. Can be fixed though). Whenever possible, delta updates with reduced bit depth (you really don't need 16 or even 32 bit per attribute!), eventually only transferring second derivation can save even more.