[crossfire] Release proposal

[Mark Wedel]

On 06/25/2017 08:18 AM, Matthew Giassa wrote:
> My guess is with meteor, let's assume 10 projectiles in rapid
> succession, each generating a 15 tile radius (approx) effect, that's
> about 10 * 700 = 7000 objects. How does the bandwidth shoot up to
> 10MB/s though?  What is the minimal unit/"tick" of time the server uses?

120 ms is the tick time.

  However, spells (unfortunately), do not move that simply.  If one takes a cone 
(simpler) that is cast to the right, it becomes

  / (a)
-- (b)
  \ (c)

  So on the next tick, when a moves more, it adds an object in the same 
direction (upper right) as a, as well as an object directly right.  Object b 
creates 3 new objects (in directions/spaces a,b,c), and c creates another one in 
c direction as well as b.

  A nice side effect of this is that something in the middle of the cone takes 
more damage at the edges, becaus there are more damage causing objects in the 
middle.  But it means that for an even modest sized cone, it can be a lot of 
objects (there is some merging logic, but a lot of these can not be merged.

  A better approach, would be that when that cone is cast, an invisible object 
is put on the map at the origin point that records various import details 
(direction, how long, etc). Then, each ticket, it just extends the cone to the 
next space as needed, inserting only the objects as needed on those new spaces. 
Then, the number of objects used would match exactly the number of spaces the 
object is on.

  Merging may not be possible, because of different durations (the first fire 
effects would burn out before the second.  Though this could perhaps even be 
handled by recording that information in each effect, eg, a fire object may 
contain data saying it does 20 damage and burns out in 8 ticks, but within that, 
says 6 damage burns out in 5 ticks, so that for the last 3 ticks,the spell does 
14 instead of 20, etc.

  But none of that is a trivial change.

  I'm not quite sure why the bandwidth would go that high - the map information 
is tried to be done efficiently (only send changed data, and each map space 
isn't a huge number of bytes).  However, I suppose if the fireball is killing a 
bunch of creatures and burning up a bunch of objects, the map is actually 
changing considerably.

>
> Finally, does the server employ any sort of compression when sending out
> this data, or is that impractical in such a case?

  I think this was investigated, but never done.  One has to make sure that 
adding the compression does not add more latency, which may mean that there are 
many small chunks of data compressed.

  Note also that bandwidth used is going to be pretty directly related to the 
size of the map - a 25x25 is going to use up about 4x the bandwidth of a 13x13 
in highly dynamic content, simply because it has that many spaces.