[crossfire] Metaserver2 / schmorp

[Nicolas Weeger]

This nicely sums up my issues with Schmorp : our common sense, perception of 
the world and handling of diplomacy are too different to lead to anything 
positive.


Nicolas


Le samedi 15 septembre 2007, Marc Lehmann a écrit :
> 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.



-- 
http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de 
l'aléatoire !]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070916/da726770/attachment-0001.pgp