> > 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 > _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire