This nicely sums all the issues I have with schmorp - our common sense, perception of the world and 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 <[EMAIL PROTECTED]> > > > > > 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 <[EMAIL PROTECTED]> > > 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 !]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
