[crossfire] Bug 2789515: output-count broken since 1.11 server

[Kevin Bulgrien]

> > After looking over the server code, it seems quite clear to me that
> > mwedel's suggestion to move it to the client is a good idea.
> 
> Do you have any idea how this affects the latency on longer network links and 
> when there are huge numbers of messages flowing? The output-count helped me a 
> lot sometimes.

I cannot say, but the SF tracker contains mwedel's comments to the effect that
the network bandwidth used by the messages is pitifully small compared to
other components of the traffic content.  While I am not sure that the comments
really take everything into consideration, I didn't really stop to think that
much about it either after I saw the number of conditions that were designed to
avoid use of the output buffers.  Still, there is that side that must admit that
when I did not have a DSL connection, though I was able to play crossfire, it
seems to me that I used to experience lag more often than I do now.  Some of it
was definitely not caused by output-count/sync issues, but I cannot say I could
be so definite about some of it actually being related to it.

Also, the output-sync/count facility appeared to only be expected to work under
some conditions.  I cannot say I fully followed the logic while looking at the
code because it was very convoluted and appeared to have been so quite some time
- notwithstanding it was broken the first time I looked at it.
 
A part of me would like to fix it... but probably mostly along the lines that it
is annoying when working code is broken because someone rewrites something, and,
because crossfire always given the impression of being network link intensive.
I may have given it a go if I felt more adept with svn.  Also, now that I have
DSL and it lets me be less concerned about speed, and as so few people seem to
play via internet (by the metaserver status), it did not occur to me to argue
long and loud against the suggestion to remove the code from the server.

It is a feature that loads a server, whereas with a client operation, memory and
processing is able to be off-loaded to clients very naturally - leaving the
system more time and resources to support game play vs. network traffic
management.  What's more, I don't know if I ever knew what it did to know to turn
it on until just recently.  I suspect not many people use it either.  Not knowing
the server code vs. having done a lot of client work, I feel more likely to be able
to effectively re-instantiate a working feature in the client than in the server
without taking a risk of breaking other clients.  Since there seem to be only
a few people even interesting in working on CF these days... I'm also feeling
that I have more freedom than if the case were different.  It used to bug me in
the past when people would argue something to the point where no code ever got
done.  Since its not a cut-and-dried thing, and since there are no actual
metrics, and because I would like to have the feature working due to the horrible
spew that happens because of melee changes (i want less spew during gameplay),
it seems that the balance is tipped on the side of making the feature work in the
client vs. the server.

> > Comments welcome.  The changes are sitting in my SVN checkout, but I'll
> > hold back a bit in case there is any life out there that cares.
> 
> Contrary to you expectations, someone answered? =)

Amazing!  Perhaps you'd like to start work today... ;-)  Hmm... let see... to
answer the question... one might start by collecting actual data about its
impact on gameplay... ;-)  That'd be a whole lot more helpful than all this
conjecture and theory - most of which is probably worth less than a kobold's
treasure drop.

> -Juha
>