Re: [crossfire] Project Vote results
On Mon, Sep 10, 2007 at 10:29:07PM -0700, Mark Wedel wrote: > Not that many votes - next time it will need to get better > publicized I think. I don't think that's the problem. It's more about that this kind of voting is suboptimal at all, as I already stated here: http://mailman.metalforge.org/pipermail/crossfire/2007-August/011780.html > I think anything beyond the third or fourth place is probably pretty > meaningless I don't think so, see below. > 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. This won't help either. > 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 I don't think that redoing of this vote is a good idea, see below. > 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 Now the problem starts: On Tue, Sep 11, 2007 at 12:13:10AM -0700, Mark Wedel wrote: > I'm also going to include the #2 point Before you started to discuss #1 you have to include #2. What about your "2 would be to work on after that" (see above)? > - "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, That's it, but #2 in combination with #1 won't do it either. You have to design a consistent world, not work on single points without taking care of the big picture. > 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. Trying to make #1 that you can keep old characters is wasted time if #2, #3, #4 or any later points will break this compatibility... > I think if we try to focus too narrowly we won't be able to find good > solutions. Right, but you have to think about _all_ changes first before you start coding. > I think stat bonuses may also need to be tuned. Now you're talking about #3, too. > 2) Increase creature AC > 3) Increase armor value of creatures That's part of #12. On Wed, Sep 12, 2007 at 11:53:25PM +0200, Nicolas Weeger wrote: > 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. That's also #12. > it should take some time to grind through many monsters. This could > also introduce new fun spells, "repel"? That's #4. > 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. #12 > Well, the bolt spell's speed could be reduced, maybe? And change based on > casting level? #2, #4 > 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? Not even part of the list... > Don't forget to reduce monster's attack, or increase player's hp :) #12 > Note that increasing player's hp will imply tweaking the various healing > spells, and maybe meditation. #3 > I think the hardest part will be correct balancing of everything, > whatever solution we use :) #1 - #12 + more On Wed, Sep 12, 2007 at 10:04:27PM -0700, Mark Wedel wrote: > Yes - rooms full of monsters would likely need to be changed. #12 > 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). #4 > But this also would reduce treasure income quite a bit (probably a > good thing). I think exp of monsters would have to be adjusted #12 > that also allows effectively unlimited stat values, since it is now a > simple formula. #3 > 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). #12 > I suspect the problem with spells right now is that most spells do a > lot of damage, relative to how many hp players have. #2, #4 > I think if hp is adjusted, grace and mana would have to go up also. #3 And so on, I guess you know what I mean. > 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 ... You got it! So stop talking about single points and start work
[crossfire] Release of 1.11 in a week or two
I'll likely be packing up a release of 1.11 of server/client in a week or two. If you have fixes that you haven't committed yet, please do so. Also, if there are any bugs that you see as critical that need to be fixed before the release, please let me know. There's a fair number of bugs on the tracker, but not clear which are critical and which are not. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Project: Slow down combat
One thought I just had about this is changing weapon speed vs normal speed. Right now, normal speed is used for movement, and if you attack something, what is currently your weapon speed gets moved into speed left for those extra attacks. This also creates other odd effects, as now it is also movement speed. My thought is to completely separate them. speed (and speed_left) is only used for movement, and is used like things are now. weapon_speed (& weapon_speed_left- abbreviated wsl) work like the speed ones - each tick, wsl is increased by weap_sp, not to exceed it. If moving onto a space would result in an attack, an attack is made so long as wsl>0. For the attack, wsl is decreased by one. speed_left is not modified, or perhaps decreased by some amount so that it becomes difficult to do a 'move, attack, move' in same tick. I'd say that weapon_speed itself doesn't get directly changed by this, but it may be reasonable that if advanced combat options are added, some actions take more time than other (disarm maybe decreases wsl by 2 for example). Now what I thought would make this interesting is instead of weapon_speed being just a player attributed, make it an object/monster attribute. This gives another way to tune monsters. Now you can have monsters that move really quickly, but perhaps don't attack very fast - things that are hard to run from. And you could have other monsters that move slowly, but attack fast if nearby. In a sense, this could be used to mimic creatures that should get multiple attacks (think something like a squid with multiple tentacles). the default behavior for monsters would be weapon_speed = speed, so that every monster does not need to be modified. Thoughts/comments? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Project: Slow down combat
Nicolas Weeger wrote: > Hello. > > I'm concerned no one replied already, but well... Maybe everyone just agrees with my brilliant insights :) > >> 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. > > Maybe large area spells will be used for fast monsters, so you're sure to > hurt > them? Or for monsters less powerful than you? If the change is such that large area effect spells are not so useful, that may not be bad. Larger effect spells, like fireball, will still have their uses. If monsters are far away, things like fireball still quite useful (the cone spells have a more limited range). Also, so long as each space of a big monster takes damage, large spells still have some advantage there. I'm sure these changes will require rebalancing of spells, but that is also on the list of things to do, so I'm less worried about spells right now, but just trying to keep it in mind. >> 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. > > Scale is another issue - the world itself isn't that well scaled in the first > place ;) True - scale isn't consistent. But I'd say that even at the lowest scale, each square is probably about 5'. Outdoor scale is much larger (each space being 50 to 100'?) But my point being that given the scale, one could certainly ask if it is reasonable if one can attack multiple times in less time than it takes to move 5'. If the answer is no, then that would certainly also hold true if the character is outdoors and scale is 50' per square. >> 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. > > Yes, so maybe this isn't that a good issue :) > Or we rely on items, armor and such? Right, but if when went the skill approach and wanted the monster to have a wc of -3, what level should its skills have? One nice thing with the basic wc, ac, etc attributes is it is very easy - I want it to have a wc of -3, so I put 'wc -3' in the monster. That said, items the monster picks up can dramatically change things, in both armor and WC. But then that makes things more interesting - not every monster is the same difficulty. >> 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). > > That is the hardship of balancing a game :) Yes. But if guidelines/a table is established, that helps out a great deal. If I know that a level 10 character has ac/wc/armor/dam if X, then I can have a pretty good idea of the stats the monster needs to be a good challenge. And arguably, this shouldn't be that hard to figure out - as one plays the game, one records this information and sees what it is. >> 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. > > Could be. Of course if too big level difference, one hit kill :) that's always the potential. However, it also depends on difference of HP based on level. If say a level 10 character has 100 hp, and a level 50 has 500 HP, that is only a difference of 5, so even then, unlikely 1 hit will kill a character, since target would be 10 spells for 500 hp damage (or 50 dam/spell). That said, things like resistances, slayin
Re: [crossfire] Project: Slow down combat
Hello. I'm concerned no one replied already, but well... > 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. Maybe large area spells will be used for fast monsters, so you're sure to hurt them? Or for monsters less powerful than you? > 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). *node* > 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.) I think a reasonable delay would be 5 to 10s, depending on the monster. Of course, a big boss could take more time. > 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. Scale is another issue - the world itself isn't that well scaled in the first place ;) > 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. *shrug* > 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. Yes, so maybe this isn't that a good issue :) Or we rely on items, armor and such? > 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. Makes it more messy, I'd think > 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). That is the hardship of balancing a game :) > 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. Agreed. > 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
Re: [crossfire] Metaserver2 / schmorp
Le Saturday 15 September 2007 13:55:51 Marc Lehmann, vous avez é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 don't like answering personal attacks, because most of the time, there is so much hatred behind them that it is pointless to attempt to conduct a reasonable debate. I'll do anyway, not because of the answer you could provide, or the exchange of ideas we may have (none of this being possible, I think), but so that all other readers may make their own opinion by knowing both points of view. I'll try to keep this short, as I don't think spending hours on this is very useful. 1. On the issue of "reporting absolutely accurate information" The metaserver2 is, in case people forgot, "The Crossfire Metaserver List". This means that the reference implementation is the "original" Crossfire server, mapset, and archetypes. To distinguish between it and other variants without having to use complex version strings as in the metaserver1, the arch/maps/codebase fields were introduced. This is clearly the only way one can distinguish a CF and a CF-TRT. It is true that the project name should not be used in the version field - there are the arch/maps/codebase fields for that purpose. This was clear from the start; AFAIK, none of the TRT developers asked for any clarification on their meaning on the Mailing List; the metaserver webpage (crossfire.real-time.com/metaserver2/meta_html.php) makes quite obvious that outside those three fields and the version one, there is no way for the client to guess the variant. 2. On the various code improvements and code quality I never questioned the code quality of the TRT project in this debate - this never was the issue discussed, and it has little to do with protocol-level interoperability. Neither did I discuss about the server stability in a comparative or particular way. Bringing those points on the table only helps derivating from the central point. 3. About "forgetting the CF servers in the TRT clients lists" Schmorp used the following arguments to explain that they didn't forget anything at all: a) they didn't have time to create their own metaserver compatible with gcfclient; b) they were removed first from the metaserver; c) his server was blocked from accessing metaserver information. I find point a) rather strange, actually. There was already a working metaserver; metaserver2 is now also available. Both provide the infos required to connect to a game server, and are completely independent of the particular implementation of the server notifying its presence. Both metaserver implementations are freely available and can be deployed to provide an alternate metaserver in a matter of minutes. Both are also obviously recognized by the TRT servers, and they actually used them. It seems quite odd that TRT developers weren't able to make their client interoperable with any of those, to display the whole list of available servers, and not only the TRT ones. Point b) is simply not true. The TRT servers were removed from the CF metaservers only a few days ago; original CF servers were already missing before that date. Point c) could have easily been solved by discussing the blocking issue with the metaservers administrator. Note that this is somewhat irrelevant, as the TRT client could simply have read the infos from the CF metaservers directly (see point a) above). Whatever the reasons, the result was the same: TRT servers used the CF infrastructure to advertise their presence, but TRT clients didn't bother listing the CF servers. 4. On being blocked "without any notice" First, the discussion was conducted on the public mailing list. One that some of the TRT developers are subscribers of. They (or you) had the opportunity to participate in the discussion, and formulate objections. If you chose not to take part on the debate and expose your own position, it was up to you. Second, *I* didn't block TRT from both metaservers without any notice; I just exposed my point of view that they should be. I never prevented the metaserver maintainer to ask the TRT team complementary information if they deemed it necessary - they have a brain and can decide by themselves if my proposal is grounded or not. As a side note, the original discussion that led to the exclusion of TRT servers, was about the metaserver2, and not the metaserver1. Note that my original proposal was to use metaserver1 for 1.xx compatible servers (TRT is one of them), and metaserver2 for 2.xx only (this means that I'd have "banned" CF 1.xx servers from metaserver2 as well as TRT ones). 5. About "criminal behavior" On this, I'd just like to point out that calling somebody a criminal on a public discussion when no crime has been committed is, in most countries, conde
Re: [crossfire] Metaserver2 / schmorp
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 <[EMAIL PROTECTED]> > > > > > entries from servers that are not compatible with the client. Thus, > > > the player would never see a 2.x-trt server if in fact the client they > > > have won't be able to play on it. > > > > Indeed. The problem is when the server itself is not "honest", and does > > not report accurate information. > > We report absolutely accurate information. > > I was told personally on IRC that the metaserver2 will make it possible to > distinguish between the projects, and that I should NOT use the project > name in the version. > > This has apperently not happened, as there is no project column or > whatever. Still, I followed the rules originally agreed upon. You changed > them, and are now using this against us, without giving us even the > slightest chance to react (we still haven't been notified on why we have > been removed form both metaservers). > > > - Should I remind you that TRT is reporting "Standard" for the arch, map, > > and code base ? > > Which is completely honest and true, we do use the standard arch map and > code bases for both of our servers. > > > - Should I remind you that TRT is reporting "2.2" as its version string, > > increasing the confusion furthermore ? > > Thats what was agreed upon. > > > - Should I also underline that TRT reports "1026/1023" as the protocol > > version, despite the fact it uses elements that were never included in > > the original Crossfire 1026/1023 protocol ? > > It was agreed upon that the next version of the metaserver will allow > clients to filter out servers according to the protocol version. We > honestly use this mechanism, and its an outright lie that we use elements > never included in the original 1026/1023 protocol (when talking to clients > supporting that protocol). > > (something Mark Wedel seems to agree to, so I am not the only one who was > tricked into thinking this. I say tricked because it was obviously done > just to change the rules later and use it against us). > > What you say is that extensions to the protocol are not allowed even when > not used. Sorry, but how stupid is thta a reason? > > The reason we report such a low protocol version to the client is to work > around bugs in gcfclient that happen when we use a newer version of the > protocol and sometimes cause hangs in the client on startup. > > We are 100% compatible with gcfclient. I even invested days of work to > make that happen by working around the many security problems, buffer > overflows, crash bugs, map bugs etc. in gcfclient. > > Construing this quality work as a reason to exclude us is deeply dishonest > :( > > > versions of servers reporting accurate information. But I do think it > > isn't an option for servers who don't "play nice" with the metaserver2, > > I fully agree. But it has nothing to do with us, as we completely play nice > and honest with the metaserver and metaserver2. > > In either case, this would only apply to the metaserver2, not the > currently metaserver. > > > false informations just to increase their visibility - for those, > > Which hasn't been done, and there is no indication for that. Thus > blacklisting was done for other reasons. > > > From: Yann Chachkoff <[EMAIL PROTECTED]> > > guess) read the latest news entry on Schmorp's Crossfire TRT website, > > where > > > > notice or explanation. But thats the ways of the Crossfire developers: if > > you can't convince with quality, try to shut them down with other > > means..." > > > > You are speaking about the absence of technical problems between the > > "stock" CF client and the TRT servers. I'd like to mitigate this by > > underlining two important points: > > > > - First, the "old" network protocol commands used to transmit map data, > > still used in the 1.10 client, has been removed from the "trunk" code > > (that is, the code for the 2.x version of Crossfire). This means that, > > for all those people using the trunk code for the client, they are unable > > to connect to a TRT server. > > When the original design goals for the metaserver2 were layed down, this > problem was meant to be solved by the version field. Again, refer to Mark > Wedels posts who clearly thinks the same. > > These rules have obviously been changed unilaterally, and used as a reason > to exclude us from both old and new metaservers. > > Won't d
Re: [crossfire] Metaserver2 / schmorp
This nicely sums all the issues I have with schmorp - our common sense, perception of the world and diplomacy are too different to lead to anything positive. Nicolas Le samedi 15 septembre 2007, Marc Lehmann a écrit : > Yann, you are a liar, and you know it. There is no excuse for the amount of > FUD you spread, as what you say can easily be verified. The fact that you > didn't even try to verify your claims and sitll do them has no excuse. > > I originally didn't want to react to your postings, but your ongoing fuding > really left me little choice, personally. > > > Subject: Re: [crossfire] Metaserver2 / schmorp > > From: Yann Chachkoff <[EMAIL PROTECTED]> > > > > > entries from servers that are not compatible with the client. Thus, > > > the player would never see a 2.x-trt server if in fact the client they > > > have won't be able to play on it. > > > > Indeed. The problem is when the server itself is not "honest", and does > > not report accurate information. > > We report absolutely accurate information. > > I was told personally on IRC that the metaserver2 will make it possible to > distinguish between the projects, and that I should NOT use the project > name in the version. > > This has apperently not happened, as there is no project column or > whatever. Still, I followed the rules originally agreed upon. You changed > them, and are now using this against us, without giving us even the > slightest chance to react (we still haven't been notified on why we have > been removed form both metaservers). > > > - Should I remind you that TRT is reporting "Standard" for the arch, map, > > and code base ? > > Which is completely honest and true, we do use the standard arch map and > code bases for both of our servers. > > > - Should I remind you that TRT is reporting "2.2" as its version string, > > increasing the confusion furthermore ? > > Thats what was agreed upon. > > > - Should I also underline that TRT reports "1026/1023" as the protocol > > version, despite the fact it uses elements that were never included in > > the original Crossfire 1026/1023 protocol ? > > It was agreed upon that the next version of the metaserver will allow > clients to filter out servers according to the protocol version. We > honestly use this mechanism, and its an outright lie that we use elements > never included in the original 1026/1023 protocol (when talking to clients > supporting that protocol). > > (something Mark Wedel seems to agree to, so I am not the only one who was > tricked into thinking this. I say tricked because it was obviously done > just to change the rules later and use it against us). > > What you say is that extensions to the protocol are not allowed even when > not used. Sorry, but how stupid is thta a reason? > > The reason we report such a low protocol version to the client is to work > around bugs in gcfclient that happen when we use a newer version of the > protocol and sometimes cause hangs in the client on startup. > > We are 100% compatible with gcfclient. I even invested days of work to > make that happen by working around the many security problems, buffer > overflows, crash bugs, map bugs etc. in gcfclient. > > Construing this quality work as a reason to exclude us is deeply dishonest > :( > > > versions of servers reporting accurate information. But I do think it > > isn't an option for servers who don't "play nice" with the metaserver2, > > I fully agree. But it has nothing to do with us, as we completely play nice > and honest with the metaserver and metaserver2. > > In either case, this would only apply to the metaserver2, not the > currently metaserver. > > > false informations just to increase their visibility - for those, > > Which hasn't been done, and there is no indication for that. Thus > blacklisting was done for other reasons. > > > From: Yann Chachkoff <[EMAIL PROTECTED]> > > guess) read the latest news entry on Schmorp's Crossfire TRT website, > > where > > > > notice or explanation. But thats the ways of the Crossfire developers: if > > you can't convince with quality, try to shut them down with other > > means..." > > > > You are speaking about the absence of technical problems between the > > "stock" CF client and the TRT servers. I'd like to mitigate this by > > underlining two important points: > > > > - First, the "old" network protocol commands used to transmit map data, > > still used in the 1.10 client, has been removed from the "trunk" code > > (that is, the code for the 2.x version of Crossfire). This means that, > > for all those people using the trunk code for the client, they are unable > > to connect to a TRT server. > > When the original design goals for the metaserver2 were layed down, this > problem was meant to be solved by the version field. Again, refer to Mark > Wedels posts who clearly thinks the same. > > These rules have obviously been changed unilaterally, and used as a reason > to exclude us from both old and new metaservers. > > Won't do. >
