From mwedel at sonic.net  Sat Sep  1 00:15:49 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Fri, 31 Aug 2007 22:15:49 -0700
Subject: [crossfire] additional metaserver2 flag: test server
Message-ID: <46D8F585.2070501@sonic.net>


  We now have more official support for metaserver2 now, thanks to Leaf & 
real-time (http://crossfire.real-time.com/metaserver2/meta_html.php) - shortly 
I'll be putting metaserver2 support back into the 1.x branches.

  While the two servers listed there right now of this writing are test servers, 
I'm sure as time passes, there will be more servers in the mix, including 1.x 
servers.

  With the rework of 2.0 upcoming, and lots of those being major, I see it will 
be desirable for as many people as possible to play on those experimental (test) 
servers to find bugs, report balance issues, etc.  To facilitate that, it would 
be good for those servers to be listed in the metaserver.

  However, at the same time, it would not be desirable for the casual player to 
go onto one of those servers.

  So my thought is to add something like a test/expirimental server flag (T or E 
perhaps).  The client should not show those unless player clicks on button with 
something like 'show test servers'.

  I realize this could perhaps be done with looking at the version numbers or 
the cs/sc versions - problem is at some point 2.0 will stabilize, but there will 
still be need for test servers - someone making big changes to maps may not want 
to have to worry about fixing up guilds and apartments while making the changes. 
    It just seems having a flag would be the most sure proof way, and also 
removes any hard coded version checking in the client.

  Not to say that there shouldn't be - the client probably should filter out 
servers that don't have a compatible sc/cs version, but that shouldn't be hard 
coded - that is more like 'if cs_version from server does not match my 
cs_version, don't show' type of thing.




From kbulgrien at worldnet.att.net  Sat Sep  1 02:14:19 2007
From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien)
Date: Sat, 1 Sep 2007 02:14:19 -0500
Subject: [crossfire] libglade2.0 client (Rev 7094) supports in-client
	selection of UI layout
Message-ID: <200709010214.19480.kbulgrien@worldnet.att.net>

FYI to any interested parties, the libglade2.0 client branch in SVN
now supports in-client selection of the Glade XML layout file to
use for the main window.

There are already various Glade XML layout files in SVN, so there
are actually layouts to pick from.

make install on the gtk-v2 client will install the layout files in
a glade-gtk2 subdirectory of the client data directory (alongside
where the theme files are stored).  The configuration popup dialog
is automatically populated to list the appropriate .glade files it
finds in this directory.

One can always use the -window_xml command-line option to override
saved settings.

An "improvement" is probably in order with respect to how saved
window positions are handled when a user switches from one layout
to another.  Some contributed ideas on how to do that are still
pending implementation, but the client is probably now worthy of
merging back into main development.  Comments welcome.

Kevin Bulgrien


From kbulgrien at worldnet.att.net  Mon Sep  3 16:34:16 2007
From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien)
Date: Mon, 3 Sep 2007 16:34:16 -0500
Subject: [crossfire] Documentation / handbook / playbook / spoilers
In-Reply-To: <200707102320.24671.kbulgrien@worldnet.att.net>
References: <200706100016.32359.nicolas.weeger@laposte.net>
	<46931D9D.9070405@sonic.net>
	<200707102320.24671.kbulgrien@worldnet.att.net>
Message-ID: <200709031634.17390.kbulgrien@worldnet.att.net>

On Tuesday 10 July 2007 23:20, Kevin R. Bulgrien wrote:

> > > My opinion is doxygen including html, since doxygen will handle other 
> > > conversions for us (chm, pdf, ...)
> > 
> >   See note above.  We really should stick with only 1 other formatting language 
> > beyond plain text to keep things simple and easy to update.  I vote HTML since 
> > it is incredibly standardized, plus there are a large number of WYSIWIG html 
> > editors.  Are there any WYSIWIG doxygen tools out there?
> 
> For whatever it is worth, HTML is ubiquitous, and so would get my vote.
> 
> As Mark, I can almost do HTML in my sleep and have no clue about doxygen.  Also,
> FWIW, the htmldoc tool is an excellent tool for generating pdfs from html even so
> far as to create a collapsible tree section index.

I know this is an old thread, but I spent a lot of time today reviewing
doxygen and trying to wrap my mind around it.  I am changing position on
this - at least for code documentation, Doxygen is not hard to work with.
The conventions it has are good procedure anyway, and code documentation
is poor in a lot of areas.

As I have done a lot of work on the gtk2 client, I tried out using
doxygen on it, and was impressed.  It gives me a phenomenal overview
of the code base, and I don't even have to use a GUI. Navigation
with the likes of lynx/links is excellent.

The coding style guide can easily show how it works without adding a lot
of text to wade through.  See some of the recent changes in
   http://wiki.metalforge.net/doku.php/coding_style_guide
to see what I'm talking about.  Comments welcome on those changes.  If
there is not a volume of dissent, I'll filter them back down into the
document in SVN.

On generating documentation that is not based on code, I cannot say for
sure as I am torn about having to learn yet another formatting tool, but
since it looks like man pages can be output too, so I'd probably take a
another look for the reason given above with respect to using a unified
format.  FWIW, though, looking at the .dox files in server/doc/Developer,
they look reasonable, and easier to maintain than HTML, and beyond easier
than maintaining a man page source file, but, I do recommend developing
a condensed style guide on the wiki that takes the sting out of making
people learn one more formatting tool.  Documentation is already hard,
and a new tool doesn't need to be the excuse to keep not doing it well.

Kevin


From kbulgrien at worldnet.att.net  Mon Sep  3 18:27:11 2007
From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien)
Date: Mon, 3 Sep 2007 18:27:11 -0500
Subject: [crossfire] Gtk2/Libglade client < 1280x1024 and embedding data in
	the XML file?
Message-ID: <200709031827.11803.kbulgrien@worldnet.att.net>

An interesting consequence of qemu testing of the Gtk2/Libglade client is
that the default desktop is 1024x768.  It becomes dreadfully obvious that
the default layouts at 1200x1000 are difficult to downsize when you can't
get the grab handles on your workspace.

It got me thinking.  I haven't though this out entirely, but it strikes
me that it would be interesting to have a "hidden" widget in the design
that is used simply to store data in the layout.

1) Right now, the layout does not contain any information about its
   identity - not even it's name.  It might be nice if it did.

2) With such a construct, perhaps a designer could have plausible screen
   defaults for 1024x768 embedded as data, but the default size might be
   for a different screen size, and then the GUI could have an option to
   set a minimum-size layout.  Perhaps this would be better than having
   to have layouts designed specifically for 1024x768.

3) The glade layout file does not have any information about the author,
   license, etc.  With a hidden data widget, perhaps this could be
   changed.

If anyone happens to have any add-on thoughts about this, feel free to
comment.

Kevin


From kbulgrien at worldnet.att.net  Mon Sep  3 21:11:27 2007
From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien)
Date: Mon, 3 Sep 2007 21:11:27 -0500
Subject: [crossfire] Announce: oroboros.glade for 1024x768 clients, et. al.
Message-ID: <200709032111.27340.kbulgrien@worldnet.att.net>

The latest of the new UI layouts for the GTK2/Libglade client has arrived.  It
is a layout designed for 1024x768 desktops, and is named oroboros.glade.  A
short description may be found below.  The other layouts in SVN, aside
from the original layout, are described as well.

- caelestis.glade       A tri-column layout with a tall inventory/floor panels
                        to the right. At the top middle, a two tab notebook
                        for character and skill/experience data sits above map
                        views beneath. To the top left is a three tab notebook
                        for core stats, critical messages, and protections. At
                        the lower left is the messages pane with entry box.

- chthonic.glade        A tri-column layout with a tall inventory/floor panels
                        to the right. At the top middle, a two tab notebook
                        holds the map views above a notebook for character and
                        skill/experience data.  To the top left is the critical
                        message box with the standard message box and command
                        input below.  The bottom left corner two tab notebook
                        houses protections and core statistics.

- gtk-v1.glade          An approximation of the original GTK client layout.

- meflin.glade          A player-suggested modification of an experimental 
                        layout, and as such, is probably subject to change.
                        Presently a map view notebook is at the top right with
                        messages and inventory/ground views sharing a tabbed
                        notebook to the left.  At the bottom rest the stat
                        bars and a three tab notebook for character information.

- oroboros.glade        A layout designed for 1024x768 desktops.  On the left
                        are a tabbed message window, inventory, and floor view.
                        To the right, at the top is a four tab notebook that
                        contains all of the character statistics, and below it
                        is the map view.  At 1024x768, the map view is 20x13.

Oroboros makes heavy use of tabbed notebooks to maximize the map area on a
small desktop, and so might even appeal to players that desire a layout
with less information visible all the time.

As a general note, presently it is very difficult, if not impossible to resize
the other layouts below 1280x1024.  Some thought is going into contriving a
way to make them more flexible, but no solution has materialized at the moment.

Kevin Bulgrien


From nicolas.weeger at laposte.net  Fri Sep  7 01:56:34 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Fri, 7 Sep 2007 08:56:34 +0200
Subject: [crossfire] additional metaserver2 flag: test server
In-Reply-To: <46D8F585.2070501@sonic.net>
References: <46D8F585.2070501@sonic.net>
Message-ID: <200709070856.38699.nicolas.weeger@laposte.net>

>   However, at the same time, it would not be desirable for the casual
> player to go onto one of those servers.
>
>   So my thought is to add something like a test/expirimental server flag (T
> or E perhaps).  The client should not show those unless player clicks on
> button with something like 'show test servers'.

IMO the news file stating that fact is enough.
I'm not sure people will know what 'experimental' means, also. What is the 
meaning? Experimental maps? features? monsters? code being tested?

Nicolas
-- 
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/20070907/959c1ccc/attachment.pgp 

From nicolas.weeger at laposte.net  Fri Sep  7 01:57:12 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Fri, 7 Sep 2007 08:57:12 +0200
Subject: [crossfire] Announce: oroboros.glade for 1024x768 clients,
	et. al.
In-Reply-To: <200709032111.27340.kbulgrien@worldnet.att.net>
References: <200709032111.27340.kbulgrien@worldnet.att.net>
Message-ID: <200709070857.12597.nicolas.weeger@laposte.net>

> The latest of the new UI layouts for the GTK2/Libglade client has arrived. 
> It is a layout designed for 1024x768 desktops, and is named oroboros.glade.
>  A short description may be found below.  The other layouts in SVN, aside
> from the original layout, are described as well.

Thanks for the work on the layout! :)


Nicolas
-- 
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/20070907/ba4f320e/attachment.pgp 

From mwedel at sonic.net  Mon Sep 10 02:30:08 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Mon, 10 Sep 2007 00:30:08 -0700
Subject: [crossfire] additional metaserver2 flag: test server
In-Reply-To: <200709070856.38699.nicolas.weeger@laposte.net>
References: <46D8F585.2070501@sonic.net>
	<200709070856.38699.nicolas.weeger@laposte.net>
Message-ID: <46E4F280.6010001@sonic.net>

Nicolas Weeger wrote:
>>   However, at the same time, it would not be desirable for the casual
>> player to go onto one of those servers.
>>
>>   So my thought is to add something like a test/expirimental server flag (T
>> or E perhaps).  The client should not show those unless player clicks on
>> button with something like 'show test servers'.
> 
> IMO the news file stating that fact is enough.
> I'm not sure people will know what 'experimental' means, also. What is the 
> meaning? Experimental maps? features? monsters? code being tested?

  While the news file is certainly useful, I think it would be annoying to 
select something from the metaserver, connect to it, only to find out it isn't a 
very suitable server.

  I had previously mentioned that once metaserver2 hits more widespread usage, 
it probably makes sense for the client to automatically filter out servers that 
are not compatible with it.  I'd also suggest that the client should filter out 
these experimental servers unless a command line option or something is given. 
In that way, developers have a way to advertise their test servers to other 
developers in an easy fashion, but it is effectively hidden from the casual 
players that really should be playing on more stable/official servers.

  But maybe this really just isn't a problem.



From nicolas.weeger at laposte.net  Mon Sep 10 12:44:41 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Mon, 10 Sep 2007 19:44:41 +0200
Subject: [crossfire] Metaserver2 / schmorp
Message-ID: <200709101944.44954.nicolas.weeger@laposte.net>

Hello.

Schmorp server appears on metaserver2. But the officiel client (latest) SVN 
does *not* work with this server.

This server shouldn't be on metaserver2 until it supports the official 
Crossfire client, since metaserver2 is the future 2.0 version.

Nicolas
-- 
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/20070910/eaf6582b/attachment.pgp 

From mwedel at sonic.net  Tue Sep 11 00:29:07 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Mon, 10 Sep 2007 22:29:07 -0700
Subject: [crossfire] Project Vote results
Message-ID: <46E627A3.4070103@sonic.net>


  Not that many votes - next time it will need to get better publicized I think. 
    Because I didn't say I would, I'm not going to publicize how people votes (I 
think it would be unfair since there wasn't much advanced notice).  Very few non 
developers voted, which perhaps skew these results some.

  Figuring out the winner was quite easy, given that more than half the people 
had it as their first choice.  I did run the results through votengine to get a 
full breakdown - by the borda elimination method, the results are below.  I 
think anything beyond the third or fourth place is probably pretty meaningless - 
I found that for myself, trying to figure out how to prioritize two things a bit 
down the list starting to become fairly arbitrary.  One problem with this vote, 
and maybe something I'll include in future votes, is there wasn't an actual 
question of whether some item should even be done.

  For example, are some things at the bottom of the list because people don't 
think they should be done (and thus would vote very low), or at the bottom of 
the list simply because relative to everything else, they were not important - 
there really isn't much way to know (one person that did vote note which ones he 
disagreed with, but it wasn't consistently done.

 From this list, 1 is top priority (thing to work on next), 2 would be to work 
on after that, etc.  I'd probably say the first 2-3 things could be completed 
before another vote is held - redoing votes periodically is I think a good idea 
because they changes we are talking about here are big - they may change 
gameplay enough that certain things that did not seem important become more 
important, etc.  I also expect there may be new points raised (BTW, if you there 
was something you think should have been on the voting list but wasn't, send me 
an e-mail and I'll put it on the next ballot)

  I'll start a new thread discussing the top point - that way the subject will 
be more meaningful.

1) Slow down combat so one can use tactics
2) Balance magic & combat skills so they are more equal
3) Redo races & classes
4) Rebalance spells, so meaningful from level 1 to 100
5) Improve party support
6) Add/improve lore
7) Make a new beginner area/town
8) Re-do/fix/improve alchemy
9 (tie) Make AC into dodge, with most armor giving AC penalty
9 (tie) Add class guild halls
11) Improve NPC chat
12) Re-organize the world into different difficulty areas


From mwedel at sonic.net  Tue Sep 11 01:25:25 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Mon, 10 Sep 2007 23:25:25 -0700
Subject: [crossfire] Metaserver2 / schmorp
In-Reply-To: <200709101944.44954.nicolas.weeger@laposte.net>
References: <200709101944.44954.nicolas.weeger@laposte.net>
Message-ID: <46E634D5.8060008@sonic.net>

Nicolas Weeger wrote:
> Hello.
> 
> Schmorp server appears on metaserver2. But the officiel client (latest) SVN 
> does *not* work with this server.
> 
> This server shouldn't be on metaserver2 until it supports the official 
> Crossfire client, since metaserver2 is the future 2.0 version.

  My $.02 is that the SC_VERSION on the svn trunk for crossfire should have been 
updated when the older commands were removed, because effectively clients 
(either crossfire or other) can not play on a trunk server.  It is sort of 
problem that because that hasn't been done, a client would have to connect to 
the server to find out it doesn't have any compatible way for map updates (this 
also applies to turnk releases of the client talking to fairly old 'real' 
crossfire servers)

  I note that schmorp does currently report older cs/sc versions, so in that 
sense, I think it is proper.  I think the clients should filter out servers that 
have protocol levels is does not support, so in this case, trunk clients should 
not show schmorp as an available server in its list of metaservers.

  I say this because as we move forward with 2.0, I expect to see those servers 
running 1.x branches until 2.0 becomes stable, and alpha/beta/test 2.0 servers. 
  And I also expect at some point protocol changes may be made so that 2.0 
servers will not be compatible with 1.x servers, and client should show 
appropriate servers (1.x client show 1.x servers, trunk client show trunk 
servers - it is conceivable that outdated trunk clients (eg, checkout 6 months 
old), may not have any servers to show).

  As such, it would seem banning servers from metaserver2 because they do not 
support latest trunk would be wrong, because that would likely result in us 
banning 1.x servers also.

  If schmorp was not playable with either the 1.x client or trunk client, then 
it seems reasonable it shouldn't be listed.

  Looking what is there right now, it does seem that schmorp is reporting some 
incorrect information, which would be grounds for blacklisting - in particular, 
it clearly isn't running off a standard code base (and I'm not sure about maps 
or arches), so that should get fixed.  It also doesn't seem to be reporting 
bytecounts, but I don't think we have an actual official policy that it has to 
do that.



From yann.chachkoff at myrealbox.com  Tue Sep 11 02:04:13 2007
From: yann.chachkoff at myrealbox.com (Yann Chachkoff)
Date: Tue, 11 Sep 2007 09:04:13 +0200
Subject: [crossfire] Metaserver2 / schmorp
In-Reply-To: <46E634D5.8060008@sonic.net>
References: <200709101944.44954.nicolas.weeger@laposte.net>
	<46E634D5.8060008@sonic.net>
Message-ID: <200709110904.19666.yann.chachkoff@myrealbox.com>

Le mardi 11 septembre 2007, Mark Wedel a ?crit :
> Nicolas Weeger wrote:
> > Hello.
> >
> > Schmorp server appears on metaserver2. But the officiel client (latest)
> > SVN does *not* work with this server.
> >
> > This server shouldn't be on metaserver2 until it supports the official
> > Crossfire client, since metaserver2 is the future 2.0 version.
>
<snip>
>   As such, it would seem banning servers from metaserver2 because they do
> not support latest trunk would be wrong, because that would likely result
> in us banning 1.x servers also.
>
I don't see this as a problem: keep the metaserver version 1 for 1.xx servers, 
and the metaserver2 for 2.xx versions.

It seems rather logical to me that two series of servers that are not using 
interoperable communication protocols with their respective clients appear in 
different lists.

>   If schmorp was not playable with either the 1.x client or trunk client,
> then it seems reasonable it shouldn't be listed.
>
If we let incompatible servers in either of the metaserver lists, then what 
will new players think of the game when they attempt to connect with the 
wrong version of the client to a given server ?

This could be excused if one connects with a client marked "2.x", to a server 
marked "1.x" - the difference would give him a clue about the problem. But 
what when he connects to a "2.x-trt" with a trunk client, and sees it fail ?

Do we want to damage the reputation of Crossfire just because we don't have 
the guts to ban a not fully compliant fork from our public server lists ?

>   Looking what is there right now, it does seem that schmorp is reporting
> some incorrect information, which would be grounds for blacklisting - in
> particular, it clearly isn't running off a standard code base (and I'm not
> sure about maps or arches), so that should get fixed.  It also doesn't seem
> to be reporting bytecounts, but I don't think we have an actual official
> policy that it has to do that.
>
You are the boss. Why does it take so long dodging around the problem ? Is the 
2.x-trt server fully compliant with 2.x (trunk) clients ? No. Hence its 
marking is not proper, its presence in metaserver 2 isn't either, so scrap it 
from it - problem solved.

-------------- 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/20070911/896b9487/attachment.pgp 

From mwedel at sonic.net  Tue Sep 11 02:13:10 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Tue, 11 Sep 2007 00:13:10 -0700
Subject: [crossfire] Project: Slow down combat
Message-ID: <46E64006.6020004@sonic.net>


  The results of the vote were pretty overwhelming for this, so going to start 
some discussions.

  I'm also going to include the #2 point - "Balance magic & combat skills so 
they are more equal" a little bit - I don't think slowing down combat is going 
to make that all work out, but it does seem to me that if the speed of combat is 
radically changed, that is likely to have some effects in that balance, either 
for better or worse (seems unlikely it would remain completely the same).

  there is also this point on the TODO list 
(http://wiki.metalforge.net/doku.php/dev_todo:change_player_speed_ - change 
player speed, but that is more related to movement speed, not combat speed.  I 
think that helps/contributes to the combat speed problem, but isn't the only fix.

  I'm going to formalize this a bit.  I'll also note that when talking about 
these things, everything should really be on the table - things should not be 
excluded because it is different than it is now, would result in incompatible 
characters (while this change could probably be made without requiring fresh 
characters, some of the other big points can't be), etc.  I think if we try to 
focus too narrowly we won't be able to find good solutions.

PROBLEM:
Combats in crossfire right now are generally very fast - less than a second to 
kill most any monster.  This is too fast to really react in much of any way, 
think tactically, etc.

SOLUTION (from a very high level fiew):
Combat should take a real amount of time.  30 seconds to kill high level boss 
monsters does not seem unreasonable to me.  I think at lower levels, this time 
will be less (maybe a few seconds for most monsters?).  I don't think there 
should ever be case (except with maybe things like rats) that a player actually 
mows through creatures.

PLAN/DETAILS:
This is the hard part.  Just slowing down the character really isn't sufficient 
unless they were made painfully slow.

  Just for reference, I decided to quickly create a starting human warrior. 
With his chain armor and long sword equipped, his movement speed is 1.0, weapon 
speed  is 1.60.  When he got second level, weapon speed went to 1.68.  Third 
level it was 1.74.

  So one thing I quickly see is that perhaps starting weapon speed is just too 
fast, and goes up too fast.  If that got reduced to say .8 at first level, that 
quickly doubles time it takes to kill things.  Maybe even a lower weapon speed - 
if you look at some games, you can move quite a bit, but get limited attacks - 
so a weapon_speed of .2 could be interesting (if this was done, then 
weapon_speed_left would need to be added, and it get added up separately to see 
if the player can attack, etc).  And interesting thing here is that this may 
open up new tactics - fire a bow, run away for a bit, fire bow again, etc.  Or 
in party player, characters swapping position based on when their next attack 
happens.

The characters damage was 9, which means that pretty much every kobold (2 hp) is 
killed in one blow, on average, orcs (4 hp) get killed in one blow, and gnolls 
(8 hp) need 2 blows.  The starting character WC was 16.  This means that the 
character will basically hit every time (mechanism is basically ac + d20 > wc 
means a hit, so tuning wc would also help.  Or maybe tuning creature AC.  If 
instead of hitting every time, the character hit only 25% of the time, that 
slows things down by a factor of 4.

  I realize that my basic test here was just at low level, but I would think the 
correct approach would be to try and tune low level combat and then adjust the 
upper level combat, and not try to get level 100 combat balance then figure out 
how to do it at level 1.

  I think stat bonuses may also need to be tuned.  But I doubt adjusting this 
will still be enough.  It would also be nice to try to reduce the hp disparity 
some, but not sure how to do that.

  It seems to me that adjusting base weapon damage isn't really a fix - most 
starting weapons go from 1->10 damage, which seems reasonable to me - you can't 
reduce that too much without loosing meaning of weapons (if a dagger does 2 
damage and sword 3, that would seem fairly meaningless).  Perhaps a lot more 
lower monsters should have better armor values, so not all the damage goes through.

  But adjusting monster kill rate from players is really only half the problem. 
  The other problem is rate of damage that monsters do to players.  It may be 
that if it now takes several seconds for me to kill a monsters, I'll be able to 
watch my HP more closely, but there are lots of attacks that can kill players 
quick quickly - especially bolt spells if the player doesn't move out of the way 
quickly.  I suspect if that player to monster hp disparity is reduced, then the 
damage that things like bolts do to players would effectively be reduced.

  One idea, which is probably controversial, is to increase player HP.  Rather 
than trying to adjust all the monster HP, maybe we give players more HP.

  For example, if players (and monsters) had 50 HP at first level, but damage 
and other things were unchanged, that effectively slows things down by a factor 
of 5 (5 times more hp than before).  It also means that unlike right now, where 
basically 2 hits may kill the player (which if player just gets unlucky and they 
happen right at the same time and not far apart, player can't do much about it), 
it would take many hits.

  I think under this system, the number of hp gained after first would still be 
more modest, like in the range of 10.  But maybe also remove the cap, which 
right now at level 10 or so, means hp rate goes way down - maybe the level 110 
people should have 2000 hp instead of the 500 they have now.

  Anyways, got a bit off topic, and don't have real solutions.  Relative easy 
first steps might be:

1) Reduce player speed & weapon speed.
2) Increase creature AC
3) Increase armor value of creatures

  But before starting work, I'd like to see other peoples thoughts and ideas.  I 
think this may actually be a very good starting one, as at some point, I don't 
think doing the solution will be that hard - the harder part will be finding the 
solution.  This may also branch off into other areas, like if the stat 
adjustments are redone, we'd need to think about how that works if that stat 
range itself is redone.



From mwedel at sonic.net  Tue Sep 11 02:19:34 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Tue, 11 Sep 2007 00:19:34 -0700
Subject: [crossfire] Metaserver2 / schmorp
In-Reply-To: <200709110904.19666.yann.chachkoff@myrealbox.com>
References: <200709101944.44954.nicolas.weeger@laposte.net>	<46E634D5.8060008@sonic.net>
	<200709110904.19666.yann.chachkoff@myrealbox.com>
Message-ID: <46E64186.8060805@sonic.net>

Yann Chachkoff wrote:
> Le mardi 11 septembre 2007, Mark Wedel a ?crit :
>> Nicolas Weeger wrote:
>>> Hello.
>>>
>>> Schmorp server appears on metaserver2. But the officiel client (latest)
>>> SVN does *not* work with this server.
>>>
>>> This server shouldn't be on metaserver2 until it supports the official
>>> Crossfire client, since metaserver2 is the future 2.0 version.
> <snip>
>>   As such, it would seem banning servers from metaserver2 because they do
>> not support latest trunk would be wrong, because that would likely result
>> in us banning 1.x servers also.
>>
> I don't see this as a problem: keep the metaserver version 1 for 1.xx servers, 
> and the metaserver2 for 2.xx versions.

  That is certainly an option, although I did backport the metaserver2 support 
to the 1.x branches.

  One thought behind that was for the metaserver1 to go away.  Another was for 
clients to filter out incompatible servers, so for example, if I connect with a 
2.x client and because of protocol changes it is not compatible with 1.x 
servers, it wouldn't even show them in the selection list (and vice versa for 
1.x clients on 2.x servers)


>>   If schmorp was not playable with either the 1.x client or trunk client,
>> then it seems reasonable it shouldn't be listed.
>>
> If we let incompatible servers in either of the metaserver lists, then what 
> will new players think of the game when they attempt to connect with the 
> wrong version of the client to a given server ?
> 
> This could be excused if one connects with a client marked "2.x", to a server 
> marked "1.x" - the difference would give him a clue about the problem. But 
> what when he connects to a "2.x-trt" with a trunk client, and sees it fail ?

  That is why I think the client should be modified to not show/drop 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.


> You are the boss. Why does it take so long dodging around the problem ? Is the 
> 2.x-trt server fully compliant with 2.x (trunk) clients ? No. Hence its 
> marking is not proper, its presence in metaserver 2 isn't either, so scrap it 
> from it - problem solved.

  If we agree that metaserver2 is only for 2.x clients/servers, I agree with 
that.  But I'd personally rather see metaserver1 go away, and the clients filter 
out entries that they are not compatible with (if one looks way forward, this 
could get repeated with 3.0 - do we want to/need to set up another metaserver 
for that?  Maybe).


From yann.chachkoff at myrealbox.com  Tue Sep 11 02:40:58 2007
From: yann.chachkoff at myrealbox.com (Yann Chachkoff)
Date: Tue, 11 Sep 2007 09:40:58 +0200
Subject: [crossfire] Metaserver2 / schmorp
In-Reply-To: <46E64186.8060805@sonic.net>
References: <200709101944.44954.nicolas.weeger@laposte.net>
	<200709110904.19666.yann.chachkoff@myrealbox.com>
	<46E64186.8060805@sonic.net>
Message-ID: <200709110941.03628.yann.chachkoff@myrealbox.com>

>   That is certainly an option, although I did backport the metaserver2
> support to the 1.x branches.
>
>   One thought behind that was for the metaserver1 to go away.  Another was
> for clients to filter out incompatible servers, so for example, if I
> connect with a 2.x client and because of protocol changes it is not
> compatible with 1.x servers, it wouldn't even show them in the selection
> list (and vice versa for 1.x clients on 2.x servers)
>
Then, I wonder why the TRT servers are not filtered out, given that they're 
clearly not compatible with the trunk client.

>   That is why I think the client should be modified to not show/drop
> 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. 

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

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

- 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 ?

I agree that the filtering is the solution to sort out between the various 
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, reporting 
false informations just to increase their visibility - for those, 
blacklisting (until the issues can be solved with the server administrator) 
seems to be the only option.
-------------- 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/20070911/1fa9cb26/attachment.pgp 

From nicolas.weeger at laposte.net  Tue Sep 11 12:06:00 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Tue, 11 Sep 2007 19:06:00 +0200
Subject: [crossfire] Metaserver2 / schmorp
In-Reply-To: <200709110941.03628.yann.chachkoff@myrealbox.com>
References: <200709101944.44954.nicolas.weeger@laposte.net>
	<46E64186.8060805@sonic.net>
	<200709110941.03628.yann.chachkoff@myrealbox.com>
Message-ID: <200709111906.03437.nicolas.weeger@laposte.net>

> Indeed. The problem is when the server itself is not "honest", and does not
> report accurate information.
>
> - Should I remind you that TRT is reporting "Standard" for the arch, map,
> and code base ?
>
> - Should I remind you that TRT is reporting "2.2" as its version string,
> increasing the confusion furthermore ?
>
> - 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 ?
>
> I agree that the filtering is the solution to sort out between the various
> 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, reporting
> false informations just to increase their visibility - for those,
> blacklisting (until the issues can be solved with the server administrator)
> seems to be the only option.

I support the blacklisting of this server from metaserver2, unless they make a 
good faith effort to help solve the issues. Notice also that they were warned 
(on IRC and through mail) of the removal of the map commands their server 
used for our client, and didn't act on it.

Nicolas
-- 
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/20070911/e95a60d4/attachment.pgp 

From kbulgrien at worldnet.att.net  Tue Sep 11 07:30:37 2007
From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien)
Date: Tue, 11 Sep 2007 07:30:37 -0500
Subject: [crossfire] Branch/1.x and libglade client, etc.
Message-ID: <200709110730.37277.kbulgrien@worldnet.att.net>

I have pretty much decided not to port the Libglade changes back onto
branches/1.x.  I've looked at it, and the volume of labor to backport it
is not something that I want to do.  Too much already has been done on
trunk that would have to be filtered out in a merge.

Further, it seems the libglade feature is indeed a new enough feature to
warrant staying on trunk.  Unfortunately, it appears that the libglade
conversion has some bug-slugging to do.  There are subtle differences
between libglade and glade-2 generated code.  I haven't tracked it down
yet to be sure, but it seems magic-maps are broken in a bad way.  I play
the libglade client all the time now, so its not bad, but it was not so
good do a magic map inside a dungeon and then have to disconnect/reconnect
to get my play map back.  It could be during my recent (unchecked in)
work that I induced the error, but I don't think it is that.  There are
clues to a fix, but it will take some time.  So, the point is, going
"unstable" on branch is yet another reason I won't backport it.

BTW, there is a lot of sentiment against porting everything back to
branches/1.x.  It would be nice to officially declare at least client
done except for bug fixes.  I'd like to keep working on the client, but
I don't want to fight the diffs anymore.  For example, the volume of
trivial changes on trunk is HUGE in maps, and does not seem worth the
time to sort through.

Kevin


From nicolas.weeger at laposte.net  Tue Sep 11 16:32:11 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Tue, 11 Sep 2007 23:32:11 +0200
Subject: [crossfire] Python guilds
Message-ID: <200709112332.15612.nicolas.weeger@laposte.net>

Hello.

The patch http://sourceforge.net/support/tracker.php?aid=1782975 completes the 
Python-based guilds, with all items and such.

Did anyone test them? I merely glanced through the editor, and they seem fine.

If no one objects, I'll commit them in a few days/weeks.

Nicolas
-- 
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/20070911/7ea02426/attachment.pgp 

From mwedel at sonic.net  Tue Sep 11 23:56:30 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Tue, 11 Sep 2007 21:56:30 -0700
Subject: [crossfire] Metaserver2 / schmorp
In-Reply-To: <200709111906.03437.nicolas.weeger@laposte.net>
References: <200709101944.44954.nicolas.weeger@laposte.net>	<46E64186.8060805@sonic.net>	<200709110941.03628.yann.chachkoff@myrealbox.com>
	<200709111906.03437.nicolas.weeger@laposte.net>
Message-ID: <46E7717E.1040201@sonic.net>


  I agree that they should be removed/blacklisted for not using proper 
map/arch/codebase fields.

  I haven't looked into their code, but if in fact they are using a 
different/incompatible protocol (different format for commands, or different 
commands), they should also be removed - in that case, they should set up and 
run their own metaserver.

  My point is more that if a server states it is running some specific version 
of the protocol, and is in fact compatible with that version of the protocol, it 
shouldn't be blacklisted just because of that (otherwise as mentioned, we'd get 
cases of slightly out of date servers getting blacklisted)

  OTOH, protocol compatibility is a bit of mess simply because so much stuff is 
negotiated with the 'setup' commands, so lots of commands were even added to the 
base crossfire server without the protocol ever changing.  So I suppose the real 
test then is if the official client of the corresponding protocol version can 
play on the server, it is OK to be listed, if it can't (because of removal of 
common communication or need for client to support commands it doesn't), then it 
should not be on the metaserver.



From mwedel at sonic.net  Wed Sep 12 00:02:44 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Tue, 11 Sep 2007 22:02:44 -0700
Subject: [crossfire] Branch/1.x and libglade client, etc.
In-Reply-To: <200709110730.37277.kbulgrien@worldnet.att.net>
References: <200709110730.37277.kbulgrien@worldnet.att.net>
Message-ID: <46E772F4.1050505@sonic.net>

Kevin R. Bulgrien wrote:
> I have pretty much decided not to port the Libglade changes back onto
> branches/1.x.  I've looked at it, and the volume of labor to backport it
> is not something that I want to do.  Too much already has been done on
> trunk that would have to be filtered out in a merge.

  That is fine by me.  In fact, I'd say this is something that should not be 
ported back, because of the size of the changes.


> BTW, there is a lot of sentiment against porting everything back to
> branches/1.x.  It would be nice to officially declare at least client
> done except for bug fixes.  I'd like to keep working on the client, but
> I don't want to fight the diffs anymore.  For example, the volume of
> trivial changes on trunk is HUGE in maps, and does not seem worth the
> time to sort through.

  My personal opinion is that the 1.x branch of pretty much everything should be 
bugfix only.  OTOH, I've also broken that by porting back the metaserver2 logic.

  but I certainly don't think every fix/change needs to be ported back and 
forth.  Minor changes may not be a big deal, but certainly big changes should 
not be fixed.

  An interesting question, given these different glade files (including one that 
is gtk-1 like, from my understanding), is should the x11 client and gtk client 
directories be removed from the trunk client area, and the gtk2 client really be 
the only official C based trunk client?



From nicolas.weeger at laposte.net  Wed Sep 12 16:53:25 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Wed, 12 Sep 2007 23:53:25 +0200
Subject: [crossfire] Project: Slow down combat
In-Reply-To: <46E64006.6020004@sonic.net>
References: <46E64006.6020004@sonic.net>
Message-ID: <200709122353.28427.nicolas.weeger@laposte.net>

>   The results of the vote were pretty overwhelming for this, so going to
> start some discussions.

Thanks for the vote handling :)

>   I'm also going to include the #2 point - "Balance magic & combat skills
> so they are more equal" a little bit - I don't think slowing down combat is
> going to make that all work out, but it does seem to me that if the speed
> of combat is radically changed, that is likely to have some effects in that
> balance, either for better or worse (seems unlikely it would remain
> completely the same).

Yes, both should be taken into account, because we're talking about 
potentially massive changes in hp/damage/speed.
I would also consider, even if later, the implications on map. If it takes 5s 
to kill a "middle-level" monster, we probably don't want a map with 500 of 
them, could be messy.

>   there is also this point on the TODO list
> (http://wiki.metalforge.net/doku.php/dev_todo:change_player_speed_ - change
> player speed, but that is more related to movement speed, not combat speed.
>  I think that helps/contributes to the combat speed problem, but isn't the
> only fix.

That will also help, and should be considered. Also there is the "logic" 
factor: if I run really fast, it seems weird that I fight really slowly.

>   I'm going to formalize this a bit.  I'll also note that when talking
> about these things, everything should really be on the table - things
> should not be excluded because it is different than it is now, would result
> in incompatible characters (while this change could probably be made
> without requiring fresh characters, some of the other big points can't be),
> etc.  I think if we try to focus too narrowly we won't be able to find good
> solutions.

Agreed, let's consider the most things possible.

> SOLUTION (from a very high level fiew):
> Combat should take a real amount of time.  30 seconds to kill high level
> boss monsters does not seem unreasonable to me.  I think at lower levels,
> this time will be less (maybe a few seconds for most monsters?).  I don't
> think there should ever be case (except with maybe things like rats) that a
> player actually mows through creatures.

Well, maybe when the level/skill difference is real high?
But agreed on the concept, it should take some time to grind through many 
monsters. This could also introduce new fun spells, "repel"?

>   So one thing I quickly see is that perhaps starting weapon speed is just
> too fast, and goes up too fast.  If that got reduced to say .8 at first
> level, that quickly doubles time it takes to kill things.  Maybe even a
> lower weapon speed - if you look at some games, you can move quite a bit,
> but get limited attacks - so a weapon_speed of .2 could be interesting (if
> this was done, then weapon_speed_left would need to be added, and it get
> added up separately to see if the player can attack, etc).  And interesting
> thing here is that this may open up new tactics - fire a bow, run away for
> a bit, fire bow again, etc.  Or in party player, characters swapping
> position based on when their next attack happens.

Separating moving/attack speed could indeed help. It can be argued that it's 
easy/fast to move, but slightly harder to attack - must find weakness in 
opponent's defence, and such.

> The characters damage was 9, which means that pretty much every kobold (2
> hp) is killed in one blow, on average, orcs (4 hp) get killed in one blow,
> and gnolls (8 hp) need 2 blows.  The starting character WC was 16.  This
> means that the character will basically hit every time (mechanism is
> basically ac + d20 > wc means a hit, so tuning wc would also help.  Or
> maybe tuning creature AC.  If instead of hitting every time, the character
> hit only 25% of the time, that slows things down by a factor of 4.

That's a warrior, though, so that could be a reason.

>   I realize that my basic test here was just at low level, but I would
> think the correct approach would be to try and tune low level combat and
> then adjust the upper level combat, and not try to get level 100 combat
> balance then figure out how to do it at level 1.

*nods*

>   I think stat bonuses may also need to be tuned.  But I doubt adjusting
> this will still be enough.  It would also be nice to try to reduce the hp
> disparity some, but not sure how to do that.

Make all living things have the same magnitude of stats/skills?
What about we make monsters have skill levels matching the player's handling?
So a level 50 monster could have level 49 one handed attack, and 5 pyromancy 
(assuming the sum of experience makes it level 50 total), and corresponding 
hp/gr/sp.
Granted, it may limit some interesting combinations...

>   It seems to me that adjusting base weapon damage isn't really a fix -
> most starting weapons go from 1->10 damage, which seems reasonable to me -
> you can't reduce that too much without loosing meaning of weapons (if a
> dagger does 2 damage and sword 3, that would seem fairly meaningless). 
> Perhaps a lot more lower monsters should have better armor values, so not
> all the damage goes through.

Or more hp? One (partial) alternative solution is to up the maxhp of 
creatures. Even if you attack fast, you need time to kill due to high hp.

>   But adjusting monster kill rate from players is really only half the
> problem. The other problem is rate of damage that monsters do to players. 
> It may be that if it now takes several seconds for me to kill a monsters,
> I'll be able to watch my HP more closely, but there are lots of attacks
> that can kill players quick quickly - especially bolt spells if the player
> doesn't move out of the way quickly.  I suspect if that player to monster
> hp disparity is reduced, then the damage that things like bolts do to
> players would effectively be reduced.

Well, the bolt spell's speed could be reduced, maybe? And change based on 
casting level?
Note that, I think, the idea isn't to prevent an instant kill if the level 
disparity is too high :)

>   One idea, which is probably controversial, is to increase player HP. 
> Rather than trying to adjust all the monster HP, maybe we give players more
> HP.
>
>   For example, if players (and monsters) had 50 HP at first level, but
> damage and other things were unchanged, that effectively slows things down
> by a factor of 5 (5 times more hp than before).  It also means that unlike
> right now, where basically 2 hits may kill the player (which if player just
> gets unlucky and they happen right at the same time and not far apart,
> player can't do much about it), it would take many hits.

I'd say to adjust both speed and hp.

>   I think under this system, the number of hp gained after first would
> still be more modest, like in the range of 10.  But maybe also remove the
> cap, which right now at level 10 or so, means hp rate goes way down - maybe
> the level 110 people should have 2000 hp instead of the 500 they have now.

Depending on the various changes we make to monsters.
Also, maybe we should introduce more attacktypes for weapons, 
like "bash", "cut", so eg a mass against a skeleton is powerful, but a sword 
isn't?
There may actually be some support for that in the code.
But it will add much complexity to the game, of course - could be left for 
after speed rebalancing, so you'll have time to swap weapon for the skeleton.
In the same topic, there is an old patch for "advanced combat" (somewhere on 
the tracker, in request features, I guess), this may give ideas for more 
tactical things (slightly offtopic, probably).

>   Anyways, got a bit off topic, and don't have real solutions.  Relative
> easy first steps might be:
>
> 1) Reduce player speed & weapon speed.
> 2) Increase creature AC
> 3) Increase armor value of creatures

Don't forget to reduce monster's attack, or increase player's hp :)
Note that increasing player's hp will imply tweaking the various healing 
spells, and maybe meditation.

>   But before starting work, I'd like to see other peoples thoughts and
> ideas.  I think this may actually be a very good starting one, as at some
> point, I don't think doing the solution will be that hard - the harder part
> will be finding the solution.  This may also branch off into other areas,
> like if the stat adjustments are redone, we'd need to think about how that
> works if that stat range itself is redone.

I think the hardest part will be correct balancing of everything, whatever 
solution we use :)


Nicolas
-- 
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/20070912/bdeec173/attachment.pgp 

From mwedel at sonic.net  Thu Sep 13 00:04:27 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Wed, 12 Sep 2007 22:04:27 -0700
Subject: [crossfire] Project: Slow down combat
In-Reply-To: <200709122353.28427.nicolas.weeger@laposte.net>
References: <46E64006.6020004@sonic.net>
	<200709122353.28427.nicolas.weeger@laposte.net>
Message-ID: <46E8C4DB.70507@sonic.net>

Nicolas Weeger wrote:

> Yes, both should be taken into account, because we're talking about 
> potentially massive changes in hp/damage/speed.
> I would also consider, even if later, the implications on map. If it takes 5s 
> to kill a "middle-level" monster, we probably don't want a map with 500 of 
> them, could be messy.

  Yes - rooms full of monsters would likely need to be changed.

  This actually has some other dramatic effects - large area of effect spells 
are less useful (if the room only has a few creatures, the spell only hits a 
few, and not a dozen).

  But this also would reduce treasure income quite a bit (probably a good 
thing).  I think exp of monsters would have to be adjusted - maybe not the first 
and second level monsters (where killing them slower menas it takes longer to 
gain a level - not a problem given how quickly one can gain the low levels), but 
when you start to get into mid and higher levels, if the monster count is 
reduced by a whole bunch, the exp for them maybe should go up - dunno.  We can 
sort that out as things get adjusted.


>> SOLUTION (from a very high level fiew):
>> Combat should take a real amount of time.  30 seconds to kill high level
>> boss monsters does not seem unreasonable to me.  I think at lower levels,
>> this time will be less (maybe a few seconds for most monsters?).  I don't
>> think there should ever be case (except with maybe things like rats) that a
>> player actually mows through creatures.
> 
> Well, maybe when the level/skill difference is real high?
> But agreed on the concept, it should take some time to grind through many 
> monsters. This could also introduce new fun spells, "repel"?

  Right - in my times there, I was basically thinking of fighting a creature of 
roughly the same power as the character.  If a level 50 creature wants to go 
kill some orcs, then yeah, I'd expect him to move through them quite quickly (he 
will hit all the time, and most likely, his weapon damage will kill one each blow).

  I'm just thinking that at low levels, having to take 30 seconds to kill a 
creature would be a bit extreme - one reason is most maps are just monster 
heavy, but another is that at low levels, characters typically have fewer 
options (you don't have a choice of weapons, rods, spells, to choose from, so 
the character really has limited tactical offerings.)


> Separating moving/attack speed could indeed help. It can be argued that it's 
> easy/fast to move, but slightly harder to attack - must find weakness in 
> opponent's defence, and such.

  Right - especially given the games scale.  If you figure that for most indoor 
maps, each space is 5', the current system is such that a character can swing a 
sword 2 times in the space it takes him to run that 5'.  That seems unreasonably 
faster, and this is a low level character.  So having weapon speed be below 
movement speed, when one thinks about the scales involved, wouldn't be that 
unreasonable.

> 
>> The characters damage was 9, which means that pretty much every kobold (2
>> hp) is killed in one blow, on average, orcs (4 hp) get killed in one blow,
>> and gnolls (8 hp) need 2 blows.  The starting character WC was 16.  This
>> means that the character will basically hit every time (mechanism is
>> basically ac + d20 > wc means a hit, so tuning wc would also help.  Or
>> maybe tuning creature AC.  If instead of hitting every time, the character
>> hit only 25% of the time, that slows things down by a factor of 4.
> 
> That's a warrior, though, so that could be a reason.

  True, but at the same time, this wasn't a totally maxed out fighter - this was 
a human warrior.  I think a half troll or half orc barbarian would actually have 
even higher numbers than that.  And actually, at low level, it really doesn't 
make a difference - all classes are going to be level 1 in 1 handed combat - the 
things that really would change are the stat bonuses.  I think right now that 
stats are actually too important for many values, and would like to go more like 
a 3rd edition AD&D system, where the bonuses are linear - that also allows 
effectively unlimited stat values, since it is now a simple formula.  I'm not 
sure if that is something to talk about as this point or elsewhere.



>>   I think stat bonuses may also need to be tuned.  But I doubt adjusting
>> this will still be enough.  It would also be nice to try to reduce the hp
>> disparity some, but not sure how to do that.
> 
> Make all living things have the same magnitude of stats/skills?
> What about we make monsters have skill levels matching the player's handling?
> So a level 50 monster could have level 49 one handed attack, and 5 pyromancy 
> (assuming the sum of experience makes it level 50 total), and corresponding 
> hp/gr/sp.
> Granted, it may limit some interesting combinations...

  Making monsters have the same effect as stats on players makes sense (right 
now, the meanings for monsters is completely different).  If nothing else, that 
actually simplifies the code.

  The issue with skills gets trickier, because I may be making a monster and say 
'I want its wc to be -3'.  However, it may not be obvious what level weapon 
skill that corresponds to, etc.

  Certainly for stock monsters, one could update their treasurelists to give 
them the various skills, and perhaps even add some hooks into the magic system 
to denote what level the skill is (just like there is a way to denote how 
magical the item is).  But I'm not sure if that makes things more complicated 
than necessary.

  One thing I think will be useful, and can be determined somewhat by playing, 
is what ac/wc/damage/hp creatures should have to be a challenged to players. 
Right now, that is somewhat guesswork I think, and I have a feeling a lot of 
monsters are not good challenges/balanced because certain of those attributes 
are out of whack (monster never hits, or hits too often, etc).

> 
>>   It seems to me that adjusting base weapon damage isn't really a fix -
>> most starting weapons go from 1->10 damage, which seems reasonable to me -
>> you can't reduce that too much without loosing meaning of weapons (if a
>> dagger does 2 damage and sword 3, that would seem fairly meaningless). 
>> Perhaps a lot more lower monsters should have better armor values, so not
>> all the damage goes through.
> 
> Or more hp? One (partial) alternative solution is to up the maxhp of 
> creatures. Even if you attack fast, you need time to kill due to high hp.

  Yes - increase maxhp helps, but I think the maxhp of players would have to be 
increased - I thought that might be controversial.

  The harder part here I think may be balance.  For example, at first level, 1 
or 2 goblins should be a challenge, and if I go into a round and am surrounded, 
I should really die.

> 
>>   But adjusting monster kill rate from players is really only half the
>> problem. The other problem is rate of damage that monsters do to players. 
>> It may be that if it now takes several seconds for me to kill a monsters,
>> I'll be able to watch my HP more closely, but there are lots of attacks
>> that can kill players quick quickly - especially bolt spells if the player
>> doesn't move out of the way quickly.  I suspect if that player to monster
>> hp disparity is reduced, then the damage that things like bolts do to
>> players would effectively be reduced.
> 
> Well, the bolt spell's speed could be reduced, maybe? And change based on 
> casting level?
> Note that, I think, the idea isn't to prevent an instant kill if the level 
> disparity is too high :)

  True - if the level difference is 20, then dying rapidly should be somewhat 
expected, be that if spells or with melee attacks.

  I suspect the problem with spells right now is that most spells do a lot of 
damage, relative to how many hp players have.  The reason is pretty simple - in 
order to be able to kill monsters, it needs to do this damage - otherwise, you'd 
need to cast a hundred spells, and that really isn't very feasible.

  So if the hp disparity between players and monsters is sorted out, and we say 
it is reasonable to cast 10 spells to kill tough creatures, that means it would 
take 10 spells to kill a same level player.  That to me is quite reasonable.


> 
>>   One idea, which is probably controversial, is to increase player HP. 
>> Rather than trying to adjust all the monster HP, maybe we give players more
>> HP.
>>
>>   For example, if players (and monsters) had 50 HP at first level, but
>> damage and other things were unchanged, that effectively slows things down
>> by a factor of 5 (5 times more hp than before).  It also means that unlike
>> right now, where basically 2 hits may kill the player (which if player just
>> gets unlucky and they happen right at the same time and not far apart,
>> player can't do much about it), it would take many hits.
> 
> I'd say to adjust both speed and hp.

  I think if hp is adjusted, grace and mana would have to go up also.  Simply 
because if creatures have 50 hp, and we say the target is 10 spells to kill a 
creature, a player will need to have the grace/mana to cast those 10 spells.

  Some spells may need less casting - ones that are more selective, like holy 
word perhaps.  Also, if the monster count is reduced, that changes the spells 
one might want to use - if you don't have gobs of monsters, cones and exploding 
balls are less useful, and things like bolts and bullets become more useful.

> 
>>   I think under this system, the number of hp gained after first would
>> still be more modest, like in the range of 10.  But maybe also remove the
>> cap, which right now at level 10 or so, means hp rate goes way down - maybe
>> the level 110 people should have 2000 hp instead of the 500 they have now.
> 
> Depending on the various changes we make to monsters.
> Also, maybe we should introduce more attacktypes for weapons, 
> like "bash", "cut", so eg a mass against a skeleton is powerful, but a sword 
> isn't?
 > There may actually be some support for that in the code.

  The typical breakdown is usually something like blunt, slashing, and piercing.

  Other than the changes to the weapons and armor, it really is just adding 
another attacktype.  As you mentioned, support was added for discrete damage 
types, so nothing should be needed there.

  I note that armor would have to be updated here - thus, certain armors may be 
good against certain attacks but not others.  This adds a new mix of things in. 
  But it does require a bit of archetype changes.


> But it will add much complexity to the game, of course - could be left for 
> after speed rebalancing, so you'll have time to swap weapon for the skeleton.
> In the same topic, there is an old patch for "advanced combat" (somewhere on 
> the tracker, in request features, I guess), this may give ideas for more 
> tactical things (slightly offtopic, probably).

  I have a feeling that the advanced combat patch is probably so out of date 
that other than looking for ideas, it wouldn't be very useful.

  that said, general concepts, like I should be able to disarm opponents, or 
parry them, etc, are valid ideas.  I think before, combat was so fast that the 
advanced combat stuff didn't work out very well, because you just didn't have 
time to try those different maneuvers.

> 
>>   Anyways, got a bit off topic, and don't have real solutions.  Relative
>> easy first steps might be:
>>
>> 1) Reduce player speed & weapon speed.
>> 2) Increase creature AC
>> 3) Increase armor value of creatures
> 
> Don't forget to reduce monster's attack, or increase player's hp :)
> Note that increasing player's hp will imply tweaking the various healing 
> spells, and maybe meditation.

  Yes - but looking at things like orcs and goblin, there base damage is 
actually quite low (1 and 3 respectively).  As I think about this more, 
increasing player HP is more appealing.   I'm even tempted to put it in 
something like the settings file (base_player_hp), as that then makes an easy 
tunable for how hard/easy you want the game - tougher servers use a lower total, 
easy servers make it easier.

> 
>>   But before starting work, I'd like to see other peoples thoughts and
>> ideas.  I think this may actually be a very good starting one, as at some
>> point, I don't think doing the solution will be that hard - the harder part
>> will be finding the solution.  This may also branch off into other areas,
>> like if the stat adjustments are redone, we'd need to think about how that
>> works if that stat range itself is redone.
> 
> I think the hardest part will be correct balancing of everything, whatever 
> solution we use :)

  I agree - I almost wonder if we should do this, and perhaps some of the other 
things on the vote before trying to balance everything - it may not make sense 
to try to balance it after this, and then balance again after spell changes, 
then balance again after ...

  But I think we should try to come up with what base values for different 
levels are, so you can basically say 'a level 50 creature should have ... to be 
competitive'.



From news at jonasstein.de  Fri Sep 14 12:27:37 2007
From: news at jonasstein.de (Jonas Stein)
Date: Fri, 14 Sep 2007 19:27:37 +0200
Subject: [crossfire] Schmorp back on metalist
Message-ID: <200709141927.37296.news@jonasstein.de>

Dear opensource community,

i was very disappointed, when Schmorp disappeared from the metalist. 

I had no problems with any client on Schmorp in the last weeks. Although this 
is no evidence, that there are no bugs or problems.

It would be the correct and fair way to include this server in the metalist as 
it would be comletly against the idea of opensource to constrain inventions 
and forks.

I think it is a good solution to inform the user about what he can expect from 
the server. As long there are bugs reported someone can include a MOTD 
message wich informs the user. 

Indeed we all do not want to force the user to select a particular software or 
user. He should have the chance to select free between a new testing 
environment or an old stable system.

It would be a shame for the nice community on schmorp, when user will no more 
login because its invisible in the list. Many people have high level 
characters there and have a lot of fun to play there in their leisure time. 
So we should not annoy them.

Thanks for reading so far, 

-- 
kind regards,

Jonas Stein <news at jonasstein.de>


From yann.chachkoff at myrealbox.com  Fri Sep 14 16:45:18 2007
From: yann.chachkoff at myrealbox.com (Yann Chachkoff)
Date: Fri, 14 Sep 2007 23:45:18 +0200
Subject: [crossfire] Schmorp back on metalist
In-Reply-To: <200709141927.37296.news@jonasstein.de>
References: <200709141927.37296.news@jonasstein.de>
Message-ID: <200709142345.18279.yann.chachkoff@myrealbox.com>

Le Friday 14 September 2007 19:27:37 Jonas Stein, vous avez ?crit?:
> Dear opensource community,
>
> i was very disappointed, when Schmorp disappeared from the metalist.
>
> I had no problems with any client on Schmorp in the last weeks. Although
> this is no evidence, that there are no bugs or problems.
>
> It would be the correct and fair way to include this server in the metalist
> as it would be comletly against the idea of opensource to constrain
> inventions and forks.
>
> I think it is a good solution to inform the user about what he can expect
> from the server. As long there are bugs reported someone can include a MOTD
> message wich informs the user.
>
> Indeed we all do not want to force the user to select a particular software
> or user. He should have the chance to select free between a new testing
> environment or an old stable system.
>
> It would be a shame for the nice community on schmorp, when user will no
> more login because its invisible in the list. Many people have high level
> characters there and have a lot of fun to play there in their leisure time.
> So we should not annoy them.
>
> Thanks for reading so far,

Dear user,

Just as a side note, I'm writing in my own name, and not of the whole 
project - keep that in mind when reading.

I can understand that you are disappointed. Especially after you have (I 
guess) read the latest news entry on Schmorp's Crossfire TRT website, where 
he explains that

" Both our servers have silently been removed from the Crossfire metaservers. 
While this was expected to happen at one point due to the friction between 
the projects, its unexpectedly harsh to do this without giving us any advance 
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..."

Which indeed made you wonder something like "why are those Crossfire jerks 
blocking those servers ? That's mean ! Maybe they are jealous !" And if I 
were you, I'd ask myself that as well, and would probably write the same kind 
of letter as you did.

Now, given that you wrote that letter, I guess you deserve an explanation - 
from the point of view of a Crossfire (non TRT) developer.

First, let's make this clear: this is not a question of "being jealous". 
Schmorp chose to explore new ways of developing the game. This, in return, 
gave ideas for the next development path of Crossfire itself. There is 
nothing wrong about a derivative of our original code to be successful, or to 
invent new things to improve the gaming experience. I don't care who is the 
project leader - what does are things like "does this change make the game 
better ?" or "What issues players get into ? How can we solve them ?"

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. They'll wonder why, of course, since those are labeled as versions 
2.x, and may conclude that the whole game is crap. I doubt this is a goal 
either the CF team or the TRT one seeks;

- Second, there are obviously some annoying compatibility irks noted on 
Schmorp's side - else, why are they bothering to print all those 
compatibility notes in red letters when you use the gcfclient to connect ? 
Given that they themselves have to use workarounds to make both 
interoperable, this is probably not a good idea to continue that way on the 
long run, forcing them to support other clients than their own one.

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. Exchanges 
of ideas and freedom of choice can only properly work when all involved sides 
agree to "play the game".

You point out that it is good to inform the user what he can expect about a 
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.
Now, again, this can only work if each server "follows the rules" and provide 
proper informations about its content. TRT clearly isn't using a standard 
content (this is one of its major differences with the original Crossfire), 
yet was saying otherwise to the metaserver2. Same with the version number. Or 
for the "code base" used. Or for the archetypes set.

Why didn't they "play nice" and provide accurate information is a question 
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.

Next, you underline the importance of not forcing the user to select a 
particular software. That's in perfect sync with what we believe ourselves, 
and that's why you are always free to type the address of a server that is 
not listed in the metas. That's also why there is not name appearing in red 
in the list, with a message telling you that "this may be dangerous to 
connect to this !" - because this is basically bad mouthing, providing little 
help to the player.

Just as a side note, there is nothing like selecting between "a new testing 
environment or an old stable system" here. Our new testing playground is made 
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". 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. That they chose to number their project as 2.x added much to 
confusion, because people mistook their project for an advanced version of 
the CF 1.x, while it was nothing else than a different development path.

Finally, you are saying it is a shame for the players on Schmorp. 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. Notice that the issue is not a new one - it has already been 
discussed in a not so distant past. I find pretty disappointing - and 
somewhat childish - that they preferred pointing fingers on their website 
than come and discuss on the issue.

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 hope that my answer put 
a different light on your view of the events; I also hope that your call to 
respect, freedom, and fair play will be heard on both sides of what appears 
to be a thickening wall between Crossfire and TRT.

Yours,

Y.E.J Chachkoff


From nicolas.weeger at laposte.net  Sat Sep 15 04:15:00 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Sat, 15 Sep 2007 11:15:00 +0200
Subject: [crossfire] Schmorp back on metalist
In-Reply-To: <200709142345.18279.yann.chachkoff@myrealbox.com>
References: <200709141927.37296.news@jonasstein.de>
	<200709142345.18279.yann.chachkoff@myrealbox.com>
Message-ID: <200709151115.03586.nicolas.weeger@laposte.net>

Hello.

(including the whole reply of Yann in case Jonas isn't on the list)

I think Yann's description of the issues is pretty accurate.

The issue is basically that schmorp is, now, an incompatible fork, thus 
Crossfire clients can't connect, leading to confusion.

Note also that Schmorp, through Elmex (IRC) / Robin (mail), was warned when 
the old map support (the one Schmorp uses for the Crossfire client) was 
removed, which was some months ago. They didn't react as far as I'm aware 
(and the fact their server appeared on our few weeks-old metaserver shows 
they do follow our development enough to bother to implement the new 
support).



Nicolas

Le vendredi 14 septembre 2007, Yann Chachkoff a ?crit?:
> Le Friday 14 September 2007 19:27:37 Jonas Stein, vous avez ?crit?:
> > Dear opensource community,
> >
> > i was very disappointed, when Schmorp disappeared from the metalist.
> >
> > I had no problems with any client on Schmorp in the last weeks. Although
> > this is no evidence, that there are no bugs or problems.
> >
> > It would be the correct and fair way to include this server in the
> > metalist as it would be comletly against the idea of opensource to
> > constrain inventions and forks.
> >
> > I think it is a good solution to inform the user about what he can expect
> > from the server. As long there are bugs reported someone can include a
> > MOTD message wich informs the user.
> >
> > Indeed we all do not want to force the user to select a particular
> > software or user. He should have the chance to select free between a new
> > testing environment or an old stable system.
> >
> > It would be a shame for the nice community on schmorp, when user will no
> > more login because its invisible in the list. Many people have high level
> > characters there and have a lot of fun to play there in their leisure
> > time. So we should not annoy them.
> >
> > Thanks for reading so far,
>
> Dear user,
>
> Just as a side note, I'm writing in my own name, and not of the whole
> project - keep that in mind when reading.
>
> I can understand that you are disappointed. Especially after you have (I
> guess) read the latest news entry on Schmorp's Crossfire TRT website, where
> he explains that
>
> " Both our servers have silently been removed from the Crossfire
> metaservers. While this was expected to happen at one point due to the
> friction between the projects, its unexpectedly harsh to do this without
> giving us any advance 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..."
>
> Which indeed made you wonder something like "why are those Crossfire jerks
> blocking those servers ? That's mean ! Maybe they are jealous !" And if I
> were you, I'd ask myself that as well, and would probably write the same
> kind of letter as you did.
>
> Now, given that you wrote that letter, I guess you deserve an explanation -
> from the point of view of a Crossfire (non TRT) developer.
>
> First, let's make this clear: this is not a question of "being jealous".
> Schmorp chose to explore new ways of developing the game. This, in return,
> gave ideas for the next development path of Crossfire itself. There is
> nothing wrong about a derivative of our original code to be successful, or
> to invent new things to improve the gaming experience. I don't care who is
> the project leader - what does are things like "does this change make the
> game better ?" or "What issues players get into ? How can we solve them ?"
>
> 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. They'll wonder why, of course, since those are
> labeled as versions 2.x, and may conclude that the whole game is crap. I
> doubt this is a goal either the CF team or the TRT one seeks;
>
> - Second, there are obviously some annoying compatibility irks noted on
> Schmorp's side - else, why are they bothering to print all those
> compatibility notes in red letters when you use the gcfclient to connect ?
> Given that they themselves have to use workarounds to make both
> interoperable, this is probably not a good idea to continue that way on the
> long run, forcing them to support other clients than their own one.
>
> 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.
> Exchanges of ideas and freedom of choice can only properly work when all
> involved sides agree to "play the game".
>
> You point out that it is good to inform the user what he can expect about a
> 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.
> Now, again, this can only work if each server "follows the rules" and
> provide proper informations about its content. TRT clearly isn't using a
> standard content (this is one of its major differences with the original
> Crossfire), yet was saying otherwise to the metaserver2. Same with the
> version number. Or for the "code base" used. Or for the archetypes set.
>
> Why didn't they "play nice" and provide accurate information is a question
> 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.
>
> Next, you underline the importance of not forcing the user to select a
> particular software. That's in perfect sync with what we believe ourselves,
> and that's why you are always free to type the address of a server that is
> not listed in the metas. That's also why there is not name appearing in red
> in the list, with a message telling you that "this may be dangerous to
> connect to this !" - because this is basically bad mouthing, providing
> little help to the player.
>
> Just as a side note, there is nothing like selecting between "a new testing
> environment or an old stable system" here. Our new testing playground is
> made 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". 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. That they chose to number their project as 2.x
> added much to confusion, because people mistook their project for an
> advanced version of the CF 1.x, while it was nothing else than a different
> development path.
>
> Finally, you are saying it is a shame for the players on Schmorp. 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. Notice that the issue is not a new one - it has already been
> discussed in a not so distant past. I find pretty disappointing - and
> somewhat childish - that they preferred pointing fingers on their website
> than come and discuss on the issue.
>
> 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 hope that my answer
> put a different light on your view of the events; I also hope that your
> call to respect, freedom, and fair play will be heard on both sides of what
> appears to be a thickening wall between Crossfire and TRT.
>
> Yours,
>
> Y.E.J Chachkoff
>
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire



-- 
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/20070915/903d3fa5/attachment.pgp 

From schmorp at schmorp.de  Sat Sep 15 06:55:51 2007
From: schmorp at schmorp.de (Marc Lehmann)
Date: Sat, 15 Sep 2007 13:55:51 +0200
Subject: [crossfire] Metaserver2 / schmorp
Message-ID: <20070915115551.GA13597@schmorp.de>

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


From schmorp at schmorp.de  Sat Sep 15 07:36:52 2007
From: schmorp at schmorp.de (Marc Lehmann)
Date: Sat, 15 Sep 2007 14:36:52 +0200
Subject: [crossfire] Metaserver2 / schmorp
Message-ID: <20070915123652.GA13758@schmorp.de>

One minor thing I forgot. "our" client was a full crossfire
client. Although it ran with reduced features (worse graphics, no
graphical dialogs etc. for lack of server support), we faithfully
implemented all Crossfire features, in some cases at a lack of fidelity
to support the limited protocol options available from Crossfire
servers. There is tons of code the exists solely to give a nice impression
for people playing on Crossfire servers (not just graphics, also music,
sound, dialogs and so on). We really wanted to support Crossfire servers,
too, in the best possible way.

We faithfully tried to support players as neutrally as possible. We didn't
advertise against Crossfire, we didn't tell our users how much better our
server is (because we believe in more than just fair/legal play and are
confident (adn history has proven us right) that our players can make
educated choices themselves). We always and fairly included all servers
from the metaserver, even though plaing on crossfire servers came at a big
loss of functionality.

(Quite to the contrary, whenever a I joined metalforge e.g. to see wether
a bug is older or not, I was greeted rather derogatively "schmorp the
asshole", "go away", "your server stinks" etc. This does never happen to
anybody joining our servers. While those players (or debelopers) can say
whatever they want, this is just another datapoint at how nice we played
(or actually, to me, thats not "playing nice" but actually the minimum
honesty one can humanly give, something the Crossfire project by actively
spreading lies about us does not grant us)

Unlike supporting gcfclient (which I agree is, or at lats was, is a
practical necessity) we didn't have to do that at all, we did that because
we were always friendly and open towards Crossfire.

Just the opposite: our client was never included in the list of clients
(despite being compatible and the most gamelike/highest fidelity client).
Our servers were barred from being included in the forums, although it was
initially offered to us.

Any service available and possible, most simple help or support was REJECT by
the Crossfire project. It was always *us* who were open and compatible and
trying to improve the situation.

(And in hindsight, the choice to use our own metaserver for our client,
which of course came at a cost, turned out to be a blessing).

Almost needless to say, however, I will personally rip out each and any
support for Crossfire in the future. This latest behaviour is just too
much to bear, and even the most forgiving man (which decidedly I am not)
would not see a reason to continue supporting a project that always tries
to hurt whereever possible.

Also, my relations to Crossfire as a project officially end here except
keeping the memory of "those guys who tried to harm us all the time".
(Yes, I am aware its just leaf, nicholas, yann and a few others, but I
do condemn all of you who actively supporting crossfire for supporting
those).

-- 
First they ignore you, then they laugh at you,
then they fight you, then you win.
Mahatma Gandhi


From nicolas.weeger at laposte.net  Mon Sep 17 12:25:37 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Mon, 17 Sep 2007 19:25:37 +0200
Subject: [crossfire] Metaserver2 / schmorp
In-Reply-To: <20070915115551.GA13597@schmorp.de>
References: <20070915115551.GA13597@schmorp.de>
Message-ID: <200709171925.41637.nicolas.weeger@laposte.net>

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 <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/20070917/a298108d/attachment.pgp 

From nicolas.weeger at laposte.net  Sun Sep 16 03:14:17 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Sun, 16 Sep 2007 10:14:17 +0200
Subject: [crossfire] Metaserver2 / schmorp
In-Reply-To: <20070915115551.GA13597@schmorp.de>
References: <20070915115551.GA13597@schmorp.de>
Message-ID: <200709161014.20692.nicolas.weeger@laposte.net>

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