[crossfire] Metaserver2 / schmorp

[Marc Lehmann]

Yann, you are a liar, and you know it. There is no excuse for the amount of
FUD you spread, as what you say can easily be verified. The fact that you
didn't even try to verify your claims and sitll do them has no excuse.

I originally didn't want to react to your postings, but your ongoing fuding
really left me little choice, personally.

> Subject: Re: [crossfire] Metaserver2 / schmorp
> From: Yann Chachkoff <yann.chachkoff at myrealbox.com>
> > entries from servers that are not compatible with the client.  Thus, the
> > player would never see a 2.x-trt server if in fact the client they have
> > won't be able to play on it.
> >
> Indeed. The problem is when the server itself is not "honest", and does not 
> report accurate information. 

We report absolutely accurate information.

I was told personally on IRC that the metaserver2 will make it possible to
distinguish between the projects, and that I should NOT use the project name
in the version.

This has apperently not happened, as there is no project column or
whatever.  Still, I followed the rules originally agreed upon. You changed
them, and are now using this against us, without giving us even the
slightest chance to react (we still haven't been notified on why we have
been removed form both metaservers).

> - Should I remind you that TRT is reporting "Standard" for the arch, map, and 
> code base ?

Which is completely honest and true, we do use the standard arch map and code
bases for both of our servers.

> - Should I remind you that TRT is reporting "2.2" as its version string, 
> increasing the confusion furthermore ?

Thats what was agreed upon.

> - Should I also underline that TRT reports "1026/1023" as the protocol 
> version, despite the fact it uses elements that were never included in the 
> original Crossfire 1026/1023 protocol ?

It was agreed upon that the next version of the metaserver will allow
clients to filter out servers according to the protocol version. We
honestly use this mechanism, and its an outright lie that we use elements
never included in the original 1026/1023 protocol (when talking to clients
supporting that protocol).

(something Mark Wedel seems to agree to, so I am not the only one who was
tricked into thinking this. I say tricked because it was obviously done
just to change the rules later and use it against us).

What you say is that extensions to the protocol are not allowed even when not
used. Sorry, but how stupid is thta a reason?

The reason we report such a low protocol version to the client is to work
around bugs in gcfclient that happen when we use a newer version of the
protocol and sometimes cause hangs in the client on startup.

We are 100% compatible with gcfclient. I even invested days of work to
make that happen by working around the many security problems, buffer
overflows, crash bugs, map bugs etc. in gcfclient.

Construing this quality work as a reason to exclude us is deeply dishonest :(

> versions of servers reporting accurate information. But I do think it isn't 
> an option for servers who don't "play nice" with the metaserver2,

I fully agree. But it has nothing to do with us, as we completely play nice
and honest with the metaserver and metaserver2.

In either case, this would only apply to the metaserver2, not the
currently metaserver.

> false informations just to increase their visibility - for those, 

Which hasn't been done, and there is no indication for that. Thus
blacklisting was done for other reasons.

> From: Yann Chachkoff <yann.chachkoff at myrealbox.com>
> guess) read the latest news entry on Schmorp's Crossfire TRT website, where 
> 
> notice or explanation. But thats the ways of the Crossfire developers: if you 
> can't convince with quality, try to shut them down with other means..."
> 
> You are speaking about the absence of technical problems between the "stock" 
> CF client and the TRT servers. I'd like to mitigate this by underlining two 
> important points:
> 
> - First, the "old" network protocol commands used to transmit map data, still 
> used in the 1.10 client, has been removed from the "trunk" code (that is, the 
> code for the 2.x version of Crossfire). This means that, for all those people 
> using the trunk code for the client, they are unable to connect to a TRT 
> server.

When the original design goals for the metaserver2 were layed down, this
problem was meant to be solved by the version field. Again, refer to Mark
Wedels posts who clearly thinks the same.

These rules have obviously been changed unilaterally, and used as a reason to
exclude us from both old and new metaservers.

Won't do.

> - Second, there are obviously some annoying compatibility irks noted on 
> Schmorp's side - else, why are they bothering to print all those 

We don't note any compatibility irks at all. If you mean the bug
workarounds we have to enable for gcfclient users, those are just that -
bug workarounds.

As an example (as you obviously didn't care to investigate or verify but
just made up lies), we have a workaround in place that avoids larged
mapscrolls, as most if not all gcfclients overflow their internal buffer.

This happens on Crossfire servers too, e.g. when doing dimension door. It is
less often then on TRT servers, but still happens.

Again, the fatc that TRT has a higher quality codebase which enables more
people to play crash-free is used as a reason against us.

Won't do.

It would be less ugly if you gave the pretense of actually having tried to
verify your claims, but you don't even do that.

> Given that they themselves have to use workarounds to make both 
> interoperable, 
   
Thats a lie. We do not need any workarounds to make the server
interoperable with gcfclient any more than Crossfire servers do. The only
difference is that we implement some workarounds for bugs, keeping clients
from crashing or worse (silent memory corruption), and Crossfire servers
don't.

> Then, you are underlining the fact that it is correct and fair to include 
> their server in our metaserver lists, because it is "how opensource spirit 
> works". Sure - I just wonder why they forgot that spirit and forgot to 
> display all the other CF servers in their own client's server list

Thats a loaded question, because you claim we forgot that. This is another
outright lie that could easily have been verified by you, but finding
truth is painfully obviously not your goal.

The truth is easy to explain:

- I didn't have time to create our own metaserver that would be compatible
  with gcfclient, so this was a temporary stop-gap measure (as can be seen
  as we do not even include all of our servers in the list).
- our server was removed from the Crossfire metaservers FIRST. why we should
  include the servers from the metaserver when our servers have been excluded
  in the most rude way (i.e. without even telling us why) escapes me.
- my server was blocked from accessing the metaserver information. This made
  it *impossible* to provide the list of servers to cfplus clients, for purely
  technical reasons, as those servers do not report to us.

Again, see the pattern: we are blocked from *accessing* the Crossfire
metaserver information and providing that to our clients, which is *then*
construed as unfair behaviour from our side.

And again, the metaserver operator has removed the other crossfire servers
from our list. We didn't "forget" anything.

You are so full of shit. This really tops it all.

> Exchanges of ideas and freedom of choice can only properly work when all
> involved sides agree to "play the game".

If you would only heed your own advise. Or is telling lies about us and
fabricating obviously false information "playing the game" for you? I
don't want to play any such games, sorry.

> server. Definitely - and that's all what the metaserver2 was about: providing 
> more accurate informations about what a server offers. This is why 
> metaserver2 includes a field about the map set used, for example.

Indeed. And we did and still do provide honest and correct information
there, as was agreed upon earlier.

> proper informations about its content. TRT clearly isn't using a standard 
> content (this is one of its major differences with the original Crossfire), 

Of course, we use the standard TRT map set, codebase and archetypes. If
you want to redefine the meaning of standard, do it without me. If the
columsn would contain sthe project name (Crossfire vs. Crossfire TRT)
there would be merit, but it doesn't, it only contains wether the standard
set was used or some variant thereof, and in our case, all of our servers
use the standard set.

Also rmeember that we didn't want to become our own project in the first
place. The Crossfire developers forced this on us, together with two
name changes to which we complied, upon threat of removing us from the
metaserver.

Yet again this is used against us.

Won't do.

> yet was saying otherwise to the metaserver2. Same with the version number. Or 
> for the "code base" used. Or for the archetypes set.

See earlier discussion in that the version number must not include the
project name.

I understand changing the rules makes it easy to fabricate reasons for
exclusion.

> Why didn't they "play nice" and provide accurate information is a question 

Again, you are lieing because you are claiming we didn't "play nice". Or your
definition of "play nice" is seveerly distorted, as we did follow all the
rules laid upon us, wether we greed to them or not.

The one person who repeatedly doesn't play nice is you, by making up
easily refuted lies...

> you'd want to ask them, not us. The fact is that I believe our own gamers 
> have the right to get infos as accurate as possible. If a server fakes those, 
> then it is better for the players themselves to remove it from the list.

Then why do you use the fatc we provide accurate information against us?

> of servers running the trunk code. CF-TRT, on the other hand, is a fork of 
> the original project, and cannot be compared to it in terms of "newer" 
> or "older".

Yes, but in "better" or "worse". In fact, whenever I presented features
that would doubtlessly be very useful (such as asynchronous I/O so the
server doesn'T stutter like mad when many players are logged in, certainly
not a problem for existing Crossfire servers but for TRT servers), I was
told (e.g. by Nicholas) "I doubt this".

Yeah sure, you doubt all the features (see
http://cvs.schmorp.de/cf.schmorp.de/server/Changes) we created, many of
which already achieve the goals set for your own 2.0 release, but why do
you even open your mouth while freely admitting you have no clue (because
you didn't even try to look at the facts, such as code, or simply cared to
ask for clarification).

> Both are developed in parallel. That's why it was asked several 
> times to the TRT team to clearly report that on the version string sent to 
> the metaserver.

I don't really remember that, but fine, we did it in any case after we
were asked to do so. It was also agreed thta this is only a temporary
measure ebcasue the old metaserver doesn't support a project column, and
this would be fixed with the new metaserver.

> That they chose to number their project as 2.x added much to 
> confusion, because people mistook their project for an advanced version of 

We chose so because a) we added a ton of features b) we rewrote most of
the server (which includes many times faster loading, fixing game exploits
and most of all basically fixing all crashes) and c) if thats not warranting
a new version number, we also implemented most if not all features planned
for the Crossfire 2.x release, too.

In any case, being a separate project, we are in need of using version
numbers to indicate progress.

And yes, you keepr epeating that this is confusing, but there ahs yet
to come up *any single player* who supports that he/she was confused by
that. As such, its an empty claim.

> the CF 1.x, while it was nothing else than a different development path.

Of course, and that obviously needs its own version numbers, wether we are
feature-compatible with the original crossfire or not.

> Finally, you are saying it is a shame for the players on Schmorp.

I agree. Your behaviour of blocking us from both metaservers without any
notice and not even caring to explain why to us to this date is ratehr
shameful behaviour.

I might have not have had the best opinion of some Crossfire developers, but
I never in my worst bad dreams imagined that all of them would let this
happen in such a shameful way.

And you, especially, put on a lot of extremely "shameful" behaviour on you by
fabricating lies about us and using them against us.

> At the risk of sounding repetitive, I'll say again: if the TRT servers
> played nice and provided accurate, non-confusing informations, this
> would never have happened.

Again, a lie, we did play nice and by all rules forced on us (our
informaton is completely accurate and in line with earlier agreements, and
is apperently completely non-confusing by all available evidence), wether
we found them sensible or not. The fatc that you a) keep hanging the rules
beneath our feet and b) spread FUD and outright lies to reach decision
cannot be called "play nice", in fact, it can be called criminal behaviour
:(

As such, your statement again is untrue, we did play nice, and still were
removed from both metaservers in the most ugly way.

> Notice that the issue is not a new one - it has already been 
> discussed in a not so distant past.

Yes indeed, and we always complied, as can *easily* be verified.

> I find pretty disappointing - and somewhat childish - that they
> preferred pointing fingers on their website than come and discuss on the
> issue.

All evidence available supports that, as the *only* possibly available
reasons for removal were fabricated by you and Nicholas. The fact that you
could easy have come by with truths instead of untruths makes them simply
lies.

The only ones acting childish are indeed the cf developers, as they let
that happen on the grounds of fabrications.

> Well, I think that's all. Again, note that this is only my opinion, not 
> representative of the whole CF developers community (even if I tend to 
> believe most of what I wrote is a shared opinion).

I believe so, too, as most people either agreed or didn't speak up against
it.

> I hope that my answer put a different light on your view of the events;

No, you are still a liar.

> I also hope that your call to respect, freedom, and fair play will be
> heard on both sides

*puke*

> of what appears to be a thickening wall between Crossfire and TRT.

And certainly not caused by the TRT developers.

In any case, after this dreadful episode, I think everybody can understand
why I certainly will not have anything to do with you or your project
anymore. If you can get along with continued lieing in your community, I
do not want to have anything to do with them anymore.

*Quite* understandably I hope everybody who has brain enough to verify your
lies sees :(

*plonk*

PS: to the few honest (or willing) people left: sorry for using such strong
language, but I think you should not punish me for that, as my outrage at
yanns behaviour is quite justified. He may sound cool, but the fact he
continously lied to you should weigh strong with you.

-- 
                The choice of a
      -----==-     _GNU_
      ----==-- _       generation     Marc Lehmann
      ---==---(_)__  __ ____  __      pcg at goof.com
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE