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. > > 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. > >> 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 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 > > 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 > 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 > > > > > 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 > > 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 > > > > > 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 > > guess) read the latest news entry on Schmorp's Crossfire TRT website, > > where > > > > notice or explanation. But thats the ways of the Crossfire developers: if > > you can't convince with quality, try to shut them down with other > > means..." > > > > You are speaking about the absence of technical problems between the > > "stock" CF client and the TRT servers. I'd like to mitigate this by > > underlining two important points: > > > > - First, the "old" network protocol commands used to transmit map data, > > still used in the 1.10 client, has been removed from the "trunk" code > > (that is, the code for the 2.x version of Crossfire). This means that, > > for all those people using the trunk code for the client, they are unable > > to connect to a TRT server. > > When the original design goals for the metaserver2 were layed down, this > problem was meant to be solved by the version field. Again, refer to Mark > Wedels posts who clearly thinks the same. > > These rules have obviously been changed unilaterally, and used as a reason > to exclude us from both old and new metaservers. > > Won't do. > > > - Second, there are obviously some annoying compatibility irks noted on > > Schmorp's side - else, why are they bothering to print all those > > We don't note any compatibility irks at all. If you mean the bug > workarounds we have to enable for gcfclient users, those are just that - > bug workarounds. > > As an example (as you obviously didn't care to investigate or verify but > just made up lies), we have a workaround in place that avoids larged > mapscrolls, as most if not all gcfclients overflow their internal buffer. > > This happens on Crossfire servers too, e.g. when doing dimension door. It > is less often then on TRT servers, but still happens. > > Again, the fatc that TRT has a higher quality codebase which enables more > people to play crash-free is used as a reason against us. > > Won't do. > > It would be less ugly if you gave the pretense of actually having tried to > verify your claims, but you don't even do that. > > > Given that they themselves have to use workarounds to make both > > interoperable, > > Thats a lie. We do not need any workarounds to make the server > interoperable with gcfclient any more than Crossfire servers do. The only > difference is that we implement some workarounds for bugs, keeping clients > from crashing or worse (silent memory corruption), and Crossfire servers > don't. > > > Then, you are underlining the fact that it is correct and fair to include > > their server in our metaserver lists, because it is "how opensource > > spirit works". Sure - I just wonder why they forgot that spirit and > > forgot to display all the other CF servers in their own client's server > > list > > Thats a loaded question, because you claim we forgot that. This is another > outright lie that could easily have been verified by you, but finding > truth is painfully obviously not your goal. > > The truth is easy to explain: > > - I didn't have time to create our own metaserver that would be compatible > with gcfclient, so this was a temporary stop-gap measure (as can be seen > as we do not even include all of our servers in the list). > - our server was removed from the Crossfire metaservers FIRST. why we > should include the servers from the metaserver when our servers have been > excluded in the most rude way (i.e. without even telling us why) escapes > me. - my server was blocked from accessing the metaserver information. This > made it *impossible* to provide the list of servers to cfplus clients, for > purely technical reasons, as those servers do not report to us. > > Again, see the pattern: we are blocked from *accessing* the Crossfire > metaserver information and providing that to our clients, which is *then* > construed as unfair behaviour from our side. > > And again, the metaserver operator has removed the other crossfire servers > from our list. We didn't "forget" anything. > > You are so full of shit. This really tops it all. > > > Exchanges of ideas and freedom of choice can only properly work when all > > involved sides agree to "play the game". > > If you would only heed your own advise. Or is telling lies about us and > fabricating obviously false information "playing the game" for you? I > don't want to play any such games, sorry. > > > server. Definitely - and that's all what the metaserver2 was about: > > providing more accurate informations about what a server offers. This is > > why metaserver2 includes a field about the map set used, for example. > > Indeed. And we did and still do provide honest and correct information > there, as was agreed upon earlier. > > > proper informations about its content. TRT clearly isn't using a standard > > content (this is one of its major differences with the original > > Crossfire), > > Of course, we use the standard TRT map set, codebase and archetypes. If > you want to redefine the meaning of standard, do it without me. If the > columsn would contain sthe project name (Crossfire vs. Crossfire TRT) > there would be merit, but it doesn't, it only contains wether the standard > set was used or some variant thereof, and in our case, all of our servers > use the standard set. > > Also rmeember that we didn't want to become our own project in the first > place. The Crossfire developers forced this on us, together with two > name changes to which we complied, upon threat of removing us from the > metaserver. > > Yet again this is used against us. > > Won't do. > > > yet was saying otherwise to the metaserver2. Same with the version > > number. Or for the "code base" used. Or for the archetypes set. > > See earlier discussion in that the version number must not include the > project name. > > I understand changing the rules makes it easy to fabricate reasons for > exclusion. > > > Why didn't they "play nice" and provide accurate information is a > > question > > Again, you are lieing because you are claiming we didn't "play nice". Or > your definition of "play nice" is seveerly distorted, as we did follow all > the rules laid upon us, wether we greed to them or not. > > The one person who repeatedly doesn't play nice is you, by making up > easily refuted lies... > > > you'd want to ask them, not us. The fact is that I believe our own gamers > > have the right to get infos as accurate as possible. If a server fakes > > those, then it is better for the players themselves to remove it from the > > list. > > Then why do you use the fatc we provide accurate information against us? > > > of servers running the trunk code. CF-TRT, on the other hand, is a fork > > of the original project, and cannot be compared to it in terms of "newer" > > or "older". > > Yes, but in "better" or "worse". In fact, whenever I presented features > that would doubtlessly be very useful (such as asynchronous I/O so the > server doesn'T stutter like mad when many players are logged in, certainly > not a problem for existing Crossfire servers but for TRT servers), I was > told (e.g. by Nicholas) "I doubt this". > > Yeah sure, you doubt all the features (see > http://cvs.schmorp.de/cf.schmorp.de/server/Changes) we created, many of > which already achieve the goals set for your own 2.0 release, but why do > you even open your mouth while freely admitting you have no clue (because > you didn't even try to look at the facts, such as code, or simply cared to > ask for clarification). > > > Both are developed in parallel. That's why it was asked several > > times to the TRT team to clearly report that on the version string sent > > to the metaserver. > > I don't really remember that, but fine, we did it in any case after we > were asked to do so. It was also agreed thta this is only a temporary > measure ebcasue the old metaserver doesn't support a project column, and > this would be fixed with the new metaserver. > > > That they chose to number their project as 2.x added much to > > confusion, because people mistook their project for an advanced version > > of > > We chose so because a) we added a ton of features b) we rewrote most of > the server (which includes many times faster loading, fixing game exploits > and most of all basically fixing all crashes) and c) if thats not > warranting a new version number, we also implemented most if not all > features planned for the Crossfire 2.x release, too. > > In any case, being a separate project, we are in need of using version > numbers to indicate progress. > > And yes, you keepr epeating that this is confusing, but there ahs yet > to come up *any single player* who supports that he/she was confused by > that. As such, its an empty claim. > > > the CF 1.x, while it was nothing else than a different development path. > > Of course, and that obviously needs its own version numbers, wether we are > feature-compatible with the original crossfire or not. > > > Finally, you are saying it is a shame for the players on Schmorp. > > I agree. Your behaviour of blocking us from both metaservers without any > notice and not even caring to explain why to us to this date is ratehr > shameful behaviour. > > I might have not have had the best opinion of some Crossfire developers, > but I never in my worst bad dreams imagined that all of them would let this > happen in such a shameful way. > > And you, especially, put on a lot of extremely "shameful" behaviour on you > by fabricating lies about us and using them against us. > > > At the risk of sounding repetitive, I'll say again: if the TRT servers > > played nice and provided accurate, non-confusing informations, this > > would never have happened. > > Again, a lie, we did play nice and by all rules forced on us (our > informaton is completely accurate and in line with earlier agreements, and > is apperently completely non-confusing by all available evidence), wether > we found them sensible or not. The fatc that you a) keep hanging the rules > beneath our feet and b) spread FUD and outright lies to reach decision > cannot be called "play nice", in fact, it can be called criminal behaviour > > :( > > As such, your statement again is untrue, we did play nice, and still were > removed from both metaservers in the most ugly way. > > > Notice that the issue is not a new one - it has already been > > discussed in a not so distant past. > > Yes indeed, and we always complied, as can *easily* be verified. > > > I find pretty disappointing - and somewhat childish - that they > > preferred pointing fingers on their website than come and discuss on the > > issue. > > All evidence available supports that, as the *only* possibly available > reasons for removal were fabricated by you and Nicholas. The fact that you > could easy have come by with truths instead of untruths makes them simply > lies. > > The only ones acting childish are indeed the cf developers, as they let > that happen on the grounds of fabrications. > > > Well, I think that's all. Again, note that this is only my opinion, not > > representative of the whole CF developers community (even if I tend to > > believe most of what I wrote is a shared opinion). > > I believe so, too, as most people either agreed or didn't speak up against > it. > > > I hope that my answer put a different light on your view of the events; > > No, you are still a liar. > > > I also hope that your call to respect, freedom, and fair play will be > > heard on both sides > > *puke* > > > of what appears to be a thickening wall between Crossfire and TRT. > > And certainly not caused by the TRT developers. > > In any case, after this dreadful episode, I think everybody can understand > why I certainly will not have anything to do with you or your project > anymore. If you can get along with continued lieing in your community, I > do not want to have anything to do with them anymore. > > *Quite* understandably I hope everybody who has brain enough to verify your > lies sees :( > > *plonk* > > PS: to the few honest (or willing) people left: sorry for using such strong > language, but I think you should not punish me for that, as my outrage at > yanns behaviour is quite justified. He may sound cool, but the fact he > continously lied to you should weigh strong with you. -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070916/da726770/attachment-0001.pgp From yann.chachkoff at myrealbox.com Sat Sep 15 20:39:13 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun, 16 Sep 2007 03:39:13 +0200 Subject: [crossfire] Metaserver2 / schmorp In-Reply-To: <20070915115551.GA13597@schmorp.de> References: <20070915115551.GA13597@schmorp.de> Message-ID: <200709160339.13302.yann.chachkoff@myrealbox.com> 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, condemnable by law. > 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. > Most of the "honest" people here (and I believe all of the CF devs nowadays are honest and willing) already know what I said on several occasions: "This is *my* opinion. See for yourself, and make your own idea about it". Do I sound cool ? No idea. Do I try to stay polite ? Yes; and that's why I'll not point accusing fingers. This will be my final message on this topic. There is nothing left to discuss, unless the goal is to bind me on a mast and burn me on the public place - but Witch Hunting is sooo old-fashioned these days... :) From nicolas.weeger at laposte.net Mon Sep 17 16:39:06 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 17 Sep 2007 23:39:06 +0200 Subject: [crossfire] Project: Slow down combat In-Reply-To: <46E8C4DB.70507@sonic.net> References: <46E64006.6020004@sonic.net> <200709122353.28427.nicolas.weeger@laposte.net> <46E8C4DB.70507@sonic.net> Message-ID: <200709172339.09423.nicolas.weeger@laposte.net> 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 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 :) > 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. Possibly, yes, else you run the risk of making spells harder - unless they are compensated later on with really powerful things? > 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. *nods* > 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. Yes, of course, but we're talking of redoing the whole combat system in the first place ;) > 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. *nods* Let's just take the time this time :) > 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 ... Yes, I think too we should change many things before balancing correctly. That's a long shot, of course, will take time :) > 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'. Possibly... 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/20070917/d38cf31a/attachment.pgp From mwedel at sonic.net Mon Sep 17 23:42:21 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 17 Sep 2007 21:42:21 -0700 Subject: [crossfire] Project: Slow down combat In-Reply-To: <200709172339.09423.nicolas.weeger@laposte.net> References: <46E64006.6020004@sonic.net> <200709122353.28427.nicolas.weeger@laposte.net> <46E8C4DB.70507@sonic.net> <200709172339.09423.nicolas.weeger@laposte.net> Message-ID: <46EF572D.4070700@sonic.net> 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, slaying, etc, can all mix things up. that one of the interesting things about giving characters more starting hp. If characters start at say 50, and at level 10 have 150, that is a 3 times improvement, so would still generally take 3 spells from that 10th level person to kill that level 1 person. > >> 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. > > Possibly, yes, else you run the risk of making spells harder - unless they are > compensated later on with really powerful things? Maybe, but I think it would be very boring to play a mage in that case - cast a couple spells, maybe not kill anything with them, have to rest to regain mana, cast some more spells, etc. One goal is to balance things such that mages and fighters are both fairly equal at all levels, so I think low level mages need to be effective. With the changes, it may be some different spells are needed - maybe 1st level firebolt and the like. >> 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. > > Yes, of course, but we're talking of redoing the whole combat system in the > first place ;) Right - I'm open to this, but would like to hear more discussion on this - do people generally think it is a good idea? I also wonder how much long term impact it has - it seems that at a fairly low level, characters will have weapons that do non physical damage (eg, fire, cold, electricity, whatever), and at that point, the distinction on physical attack types is lost. Maybe as part of this, all weapons that do extra attacktypes needs to be redone some, so that the damage of the attacktype is minor extra damage. For example, that firebrand may still do mostly physical (slashing) damage, but also do some amount of fire damage. This greatly changes weapon combat, but once again, maybe not a bad thing. From mwedel at sonic.net Tue Sep 18 00:03:05 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 17 Sep 2007 22:03:05 -0700 Subject: [crossfire] Project: Slow down combat In-Reply-To: <46EF572D.4070700@sonic.net> References: <46E64006.6020004@sonic.net> <200709122353.28427.nicolas.weeger@laposte.net> <46E8C4DB.70507@sonic.net> <200709172339.09423.nicolas.weeger@laposte.net> <46EF572D.4070700@sonic.net> Message-ID: <46EF5C09.9030205@sonic.net> 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? From mwedel at sonic.net Tue Sep 18 01:17:09 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 17 Sep 2007 23:17:09 -0700 Subject: [crossfire] Release of 1.11 in a week or two Message-ID: <46EF6D65.6000404@sonic.net> 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. From crossfire at kahnert.de Tue Sep 18 01:14:45 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Tue, 18 Sep 2007 08:14:45 +0200 Subject: [crossfire] Project Vote results In-Reply-To: <46E627A3.4070103@sonic.net> References: <46E627A3.4070103@sonic.net> Message-ID: <20070918061445.GA9145@apollo.kahnert.local> 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 working on a consistent world before coding. http://wiki.metalforge.net/doku.php/dev_todo:cf2.0:roadmap Without the big picture working on single points is wasted time. So I'm out if you continue this way. That doesn't mean you have to do it my way it's just that I will spent time only if there is a clear concept. I suggest to work on the roadmap until we got a consistent world. That will take some time (many months) without coding on this points. And for those who needs to code should concentrate on bugfixes. Make the server more stable (no crashes, less lags, ...) and clean the codebase. No changes in gameplay at all. Both will take some time. After the 1.x server is stable and the concept for the gameplay changes is complete, the coding work on CF2 will start. J?rgen From kbulgrien at worldnet.att.net Tue Sep 18 02:24:17 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 18 Sep 2007 02:24:17 -0500 Subject: [crossfire] Release of 1.11 in a week or two In-Reply-To: <46EF6D65.6000404@sonic.net> References: <46EF6D65.6000404@sonic.net> Message-ID: <200709180224.17682.kbulgrien@worldnet.att.net> > 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. On that note, the libglade client is debugged so far as I know... It would be nice to consider releasing it as an indication of its stability and to get it in general use. So far there are a variety of things not backported to 1.x in addition to the libglade conversion. Does anyone know of anything in the trunk client that is unsuitable for a general release as a branch client? Kevin From nicolas.weeger at laposte.net Tue Sep 18 11:50:54 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 18 Sep 2007 18:50:54 +0200 Subject: [crossfire] Release of 1.11 in a week or two In-Reply-To: <46EF6D65.6000404@sonic.net> References: <46EF6D65.6000404@sonic.net> Message-ID: <200709181850.57736.nicolas.weeger@laposte.net> Le mardi 18 septembre 2007, Mark Wedel a ?crit?: > 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. Stopper thing: Windows support. With the new metaserver and curl, pthread is needed too, so one should take the time to see how to make everything work nicely. Also, AFAIK, GTK2 with Kevin's patches hasn't been tested under Windows either. Unfortunately I don't have much time lately, so I can't guarantee that I'll be able to test everything. If anyone has the time and will, of course, that's another issue :) 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/20070918/e1013200/attachment.pgp From huet.o at free.fr Tue Sep 18 15:32:21 2007 From: huet.o at free.fr (Olivier Huet) Date: Tue, 18 Sep 2007 22:32:21 +0200 Subject: [crossfire] Release of 1.11 in a week or two In-Reply-To: <200709181850.57736.nicolas.weeger@laposte.net> References: <46EF6D65.6000404@sonic.net> <200709181850.57736.nicolas.weeger@laposte.net> Message-ID: <000001c7fa33$044f4b10$0cede130$@o@free.fr> Hello, Something like a month ago, I did try some minor modifications on the windows gtk1 client : - make it compile on vs2005 (because I didn't have vs 6 installed anymore on my current pc) - activate back the sdl support (like it is in on gtk2 client, it's only a macro use to add) But I finally did not post it here when I saw that pthread and curl are now needed and mandatory : I couldn't make a patch without compiling it on the last svn version. (BTW I didn't tried thoses but pthread and curl do exists too on windows, and pthread do probably works well because it is used in at least one good software : the mpeg 4 (h264) decoder of PowerDVD). --> I don't have a lot of time these days - not sure if I can find some to test those libraries. And still regarding pthread and curl, they looks mandatory now (not always bracketed in #ifdef). --> Is it normal ? And I don't know if anyone else did test the gtk2 client on windows but personally, the last I did try is something like the 6881 in svn's trunk : just before the integration of glade lib. It was on a version I did compile with the MinGW. It was working very well and fast with OpenGL. In addition, I forgot to ask here or on bug reports, but on SDL client (both gtk 1 and gtk 2 - windows versions), when you click somewhere on the ground, SDL do probably catch the focus instead of gtk : after, you can't use any key before you switch to another application and go back to the cf client. --> is it only in SDL's version in windows, or is it the same on linux or other OS ? Olivier Huet (findufin & findragon on metalforge) -----Message d'origine----- De?: crossfire-bounces at metalforge.org [mailto:crossfire-bounces at metalforge.org] De la part de Nicolas Weeger Envoy??: mardi 18 septembre 2007 18:51 ??: Crossfire Discussion Mailing List Objet?: Re: [crossfire] Release of 1.11 in a week or two Le mardi 18 septembre 2007, Mark Wedel a ?crit?: > 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. Stopper thing: Windows support. With the new metaserver and curl, pthread is needed too, so one should take the time to see how to make everything work nicely. Also, AFAIK, GTK2 with Kevin's patches hasn't been tested under Windows either. Unfortunately I don't have much time lately, so I can't guarantee that I'll be able to test everything. If anyone has the time and will, of course, that's another issue :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Tue Sep 18 23:34:20 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 18 Sep 2007 21:34:20 -0700 Subject: [crossfire] Release of 1.11 in a week or two In-Reply-To: <200709180224.17682.kbulgrien@worldnet.att.net> References: <46EF6D65.6000404@sonic.net> <200709180224.17682.kbulgrien@worldnet.att.net> Message-ID: <46F0A6CC.2010101@sonic.net> Kevin R. Bulgrien wrote: >> 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. > > On that note, the libglade client is debugged so far as I know... It would be > nice to consider releasing it as an indication of its stability and to get it > in general use. So far there are a variety of things not backported to 1.x > in addition to the libglade conversion. Does anyone know of anything in > the trunk client that is unsuitable for a general release as a branch > client? IMO, and others may vary, the 1.x branches should really be for bug fixes, and not new features. Also, just recently playing with the glade client, a few issues: 1) Run using opengl mode, get lots of these messages: (crossfire-client-gtk2:25842): Gdk-CRITICAL **: gdk_draw_drawable: assertion `src != NULL' failed (crossfire-client-gtk2:25842): Gdk-CRITICAL **: gdk_draw_drawable: assertion `src != NULL' failed I haven't looked into them yet. I suspect it is something to do with mapscroll, as I get them, and only get them, when I move about on the map. I don't see those in pixmap mode. As a very quick guess, I'm thinking that when the client is getting a mapscroll request, it is always trying to scroll as if pixmap mode was used. 2) Haven't looked at this either, but just tried with -sdl, and client died even before getting a log in screen. But my personal thought is SDL code should perhaps be removed. 3) The menubar stuff seems to stop working at times - its not 100% consistent, as sometimes I can select the disconnect or quit client and it works, and other times, I select those, and nothing happens. These are all probably minor issues, but may be things that probably should get fixed before making a release of it. From mwedel at sonic.net Tue Sep 18 23:39:45 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 18 Sep 2007 21:39:45 -0700 Subject: [crossfire] Release of 1.11 in a week or two In-Reply-To: <000001c7fa33$044f4b10$0cede130$@o@free.fr> References: <46EF6D65.6000404@sonic.net> <200709181850.57736.nicolas.weeger@laposte.net> <000001c7fa33$044f4b10$0cede130$@o@free.fr> Message-ID: <46F0A811.7090105@sonic.net> Olivier Huet wrote: > Hello, > > > Something like a month ago, I did try some minor modifications on the > windows gtk1 client : > - make it compile on vs2005 (because I didn't have vs 6 installed anymore on > my current pc) > - activate back the sdl support (like it is in on gtk2 client, it's only a > macro use to add) > > But I finally did not post it here when I saw that pthread and curl are now > needed and mandatory : I couldn't make a patch without compiling it on the > last svn version. > > (BTW I didn't tried thoses but pthread and curl do exists too on windows, > and pthread do probably works well because it is used in at least one good > software : the mpeg 4 (h264) decoder of PowerDVD). > --> I don't have a lot of time these days - not sure if I can find some to > test those libraries. > > > And still regarding pthread and curl, they looks mandatory now (not always > bracketed in #ifdef). > --> Is it normal ? It shouldn't be. It's possible that a few things or other changes were outside of #ifdefs. For both client & server, having curl shouldn't be a requirement. Having pthread, at least for client, may be, as even for metaserver1 support, it now uses pthread to get the data from the server in its own thread. pthread may get used for more stuff - threading the client is an interesting idea (one thread to deal with drawing, another for socket) - in this way, GUI is always snappy, and the number of locks needed to make this happen actually isn't that many. > > > And I don't know if anyone else did test the gtk2 client on windows but > personally, the last I did try is something like the 6881 in svn's trunk : > just before the integration of glade lib. It was on a version I did compile > with the MinGW. It was working very well and fast with OpenGL. > > > In addition, I forgot to ask here or on bug reports, but on SDL client (both > gtk 1 and gtk 2 - windows versions), when you click somewhere on the ground, > SDL do probably catch the focus instead of gtk : after, you can't use any > key before you switch to another application and go back to the cf client. > --> is it only in SDL's version in windows, or is it the same on linux or > other OS ? Haven't tried, but see comment about SDL map support getting removed in other message. While I know there is always desire to have as many options as available, as the person that has done considerable work with SDL and opengl for drawing logic, opengl seems a much better solution (it seems to provide many more acceleration options than SDL. For example, if at some point we move lighting effects to the client, opengl has interfaces for that. For SDL, we'd need to write our own lighting routines) Now I realize that everyone may not have working opengl, etc, but for those people, pixmap mode is still there. From huet.o at free.fr Wed Sep 19 14:09:20 2007 From: huet.o at free.fr (Olivier Huet) Date: Wed, 19 Sep 2007 21:09:20 +0200 Subject: [crossfire] just a comment for SDL (was RE: Release of 1.11 in a week or two) In-Reply-To: <46F0A811.7090105@sonic.net> References: <46EF6D65.6000404@sonic.net> <200709181850.57736.nicolas.weeger@laposte.net> <000001c7fa33$044f4b10$0cede130$@o@free.fr> <46F0A811.7090105@sonic.net> Message-ID: <000c01c7faf0$955e9fd0$c01bdf70$@o@free.fr> Hello, Just for SDL, there is perhaps a better chance to have hardware acceleration with it than with OpenGL only : I don't know SDL but looking a little sources and documentations, I think that it do try several ways to have hardware acceleration available on hosting operating system (DirectX & OpenGL for Windows, DGA & OpenGL on Linux + XFree86, etc.). For a little example, on Windows, OpenGL drivers are not always directly installed on recent laptop with "modified for laptop" video cards : you have to wait to have some new drivers or to use some tricks to install standard drivers (thoses normally for non laptop but that do works perfectly with laptops :-) ). When I used to use Linux, there was almost never hardware OpenGL driver available. I hope it did change now :-) but you probably have more recent news than me on that subject. But on the other hand, I do know a good proverb in computer science : the less "external library" you use, the more stable your application will be :-) --> so regarding what you say and this proverb, it's perhaps a good idea to remove SDL mode, in benefit to adding more functionalities in OpenGL mode :-) Olivier Huet (findufin & findragon on mf) -----Message d'origine----- De?: crossfire-bounces at metalforge.org [mailto:crossfire-bounces at metalforge.org] De la part de Mark Wedel Envoy??: mercredi 19 septembre 2007 06:40 ??: Crossfire Discussion Mailing List Objet?: Re: [crossfire] Release of 1.11 in a week or two Olivier Huet wrote: > Hello, > > > Something like a month ago, I did try some minor modifications on the > windows gtk1 client : > - make it compile on vs2005 (because I didn't have vs 6 installed anymore on > my current pc) > - activate back the sdl support (like it is in on gtk2 client, it's only a > macro use to add) > > But I finally did not post it here when I saw that pthread and curl are now > needed and mandatory : I couldn't make a patch without compiling it on the > last svn version. > > (BTW I didn't tried thoses but pthread and curl do exists too on windows, > and pthread do probably works well because it is used in at least one good > software : the mpeg 4 (h264) decoder of PowerDVD). > --> I don't have a lot of time these days - not sure if I can find some to > test those libraries. > > > And still regarding pthread and curl, they looks mandatory now (not always > bracketed in #ifdef). > --> Is it normal ? It shouldn't be. It's possible that a few things or other changes were outside of #ifdefs. For both client & server, having curl shouldn't be a requirement. Having pthread, at least for client, may be, as even for metaserver1 support, it now uses pthread to get the data from the server in its own thread. pthread may get used for more stuff - threading the client is an interesting idea (one thread to deal with drawing, another for socket) - in this way, GUI is always snappy, and the number of locks needed to make this happen actually isn't that many. > > > And I don't know if anyone else did test the gtk2 client on windows but > personally, the last I did try is something like the 6881 in svn's trunk : > just before the integration of glade lib. It was on a version I did compile > with the MinGW. It was working very well and fast with OpenGL. > > > In addition, I forgot to ask here or on bug reports, but on SDL client (both > gtk 1 and gtk 2 - windows versions), when you click somewhere on the ground, > SDL do probably catch the focus instead of gtk : after, you can't use any > key before you switch to another application and go back to the cf client. > --> is it only in SDL's version in windows, or is it the same on linux or > other OS ? Haven't tried, but see comment about SDL map support getting removed in other message. While I know there is always desire to have as many options as available, as the person that has done considerable work with SDL and opengl for drawing logic, opengl seems a much better solution (it seems to provide many more acceleration options than SDL. For example, if at some point we move lighting effects to the client, opengl has interfaces for that. For SDL, we'd need to write our own lighting routines) Now I realize that everyone may not have working opengl, etc, but for those people, pixmap mode is still there. _______________________________________________ crossfire mailing list crossfire at metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Wed Sep 19 23:12:20 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 19 Sep 2007 21:12:20 -0700 Subject: [crossfire] just a comment for SDL (was RE: Release of 1.11 in a week or two) In-Reply-To: <000c01c7faf0$955e9fd0$c01bdf70$@o@free.fr> References: <46EF6D65.6000404@sonic.net> <200709181850.57736.nicolas.weeger@laposte.net> <000001c7fa33$044f4b10$0cede130$@o@free.fr> <46F0A811.7090105@sonic.net> <000c01c7faf0$955e9fd0$c01bdf70$@o@free.fr> Message-ID: <46F1F324.8020808@sonic.net> Olivier Huet wrote: > Hello, > > > Just for SDL, there is perhaps a better chance to have hardware acceleration > with it than with OpenGL only : I don't know SDL but looking a little > sources and documentations, I think that it do try several ways to have > hardware acceleration available on hosting operating system (DirectX & > OpenGL for Windows, DGA & OpenGL on Linux + XFree86, etc.). Maybe. For whatever reason, on my system, SDL didn't offer much in way of acceleration over pixmap, while opengl does (unfortunately, it isn't a direct apples to apples type of thing, as there may have been other changes I made to my system). > > For a little example, on Windows, OpenGL drivers are not always directly > installed on recent laptop with "modified for laptop" video cards : you have > to wait to have some new drivers or to use some tricks to install standard > drivers (thoses normally for non laptop but that do works perfectly with > laptops :-) ). Right - which is one reason I'm not really suggesting it by the only drawing mode (pixmap could be used for that edge case). I imagine even in such cases as no hardware driver yet, there may also be software driver to do it, but performance on that may be quite bad. > > When I used to use Linux, there was almost never hardware OpenGL driver > available. I hope it did change now :-) but you probably have more recent > news than me on that subject. It sort of depends. If you're a firm believer in only using open source drivers, support may be limited or lacking. If you don't mind using binary only drivers, both nvidia and ati provide those, and that probably covers 90% of the cards out there. I _think_ that for older models of both ATI & Nvidia cards, there may also be 3D drivers for that. There are also rumors (or maybe it has happened - can't remember) that ATI (amd) is going to release detailed specs for their cards to the public, so that should make it possible to write good opengl drivers. > But on the other hand, I do know a good proverb in computer science : the > less "external library" you use, the more stable your application will be > :-) > --> so regarding what you say and this proverb, it's perhaps a good idea to > remove SDL mode, in benefit to adding more functionalities in OpenGL mode > :-) The real issue is that having 3 drawing modes really seems excessive to me. And from what I see, with SDL, it is really up to the application to define the bits (including lighting effects, etc) and SDL can blit those bits, but in itself, it doesn't have any way to do much than 'here are some bits - draw them to the screen'. Opengl as lots of more advanced features (I keep thinking about adding a zoom out feature to the map, so one could see areas that were visible but now fogged off - very easy to do with opengl, as it will handle rescaling of all the image data internally for example). From juolja at csc.fi Tue Sep 18 03:34:47 2007 From: juolja at csc.fi (Juha =?utf-8?q?J=C3=A4ykk=C3=A4?=) Date: Tue, 18 Sep 2007 11:34:47 +0300 Subject: [crossfire] Project: Slow down combat In-Reply-To: <46EF5C09.9030205@sonic.net> References: <46E64006.6020004@sonic.net> <46EF572D.4070700@sonic.net> <46EF5C09.9030205@sonic.net> Message-ID: <200709181134.48488.juolja@csc.fi> > 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 One example that comes to mind is dragon breath - at the moment dragons basically have unlimited mana and dragonbreath/icestorm/poison cloud/lightning at very quick casting times at their disposal. While the flying dragons (can they really fly in dungeons?) are supposedly quite fast and not easily outrun by PCs, they might well take some time between using their breath weapons. Of course this makes dragons easier prey than currently, which is bad I think (dragons should be tough), but that could easily be fixed in some other manner. Generally, I like Mark's idea. -Juha -- Juha J?ykk?, Application specialist non-e mail: CSC, P.O. Box 405, FI-02101 Espoo, Finland phone: 09-457 2280 From nicolas.weeger at laposte.net Sun Sep 23 04:36:41 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 23 Sep 2007 11:36:41 +0200 Subject: [crossfire] Project: Slow down combat In-Reply-To: <46EF5C09.9030205@sonic.net> References: <46E64006.6020004@sonic.net> <46EF572D.4070700@sonic.net> <46EF5C09.9030205@sonic.net> Message-ID: <200709231136.44473.nicolas.weeger@laposte.net> > One thought I just had about this is changing weapon speed vs normal > speed. > Thoughts/comments? Seems nice :) 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/20070923/63dbfd7f/attachment.pgp From nicolas.weeger at laposte.net Sun Sep 23 04:48:31 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 23 Sep 2007 11:48:31 +0200 Subject: [crossfire] Project: Slow down combat In-Reply-To: <46EF572D.4070700@sonic.net> References: <46E64006.6020004@sonic.net> <200709172339.09423.nicolas.weeger@laposte.net> <46EF572D.4070700@sonic.net> Message-ID: <200709231148.35570.nicolas.weeger@laposte.net> > Maybe everyone just agrees with my brilliant insights :) More likely, it'll be like every other discussion - people will whine AFTER we implement, saying that we could have done this and this :p > 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. Or larg area spells could be used for things other than combat - remove trees? destroy items? have fun? > 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. Indeed, we should probably keep the monster's specific wc/ac/... This way map makers can do exactly what they want :) > 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. *nods* > 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, slaying, etc, can > all mix things up. > > that one of the interesting things about giving characters more starting > hp. If characters start at say 50, and at level 10 have 150, that is a 3 > times improvement, so would still generally take 3 spells from that 10th > level person to kill that level 1 person. It's a global discussion, yes - if spells and hp are increased, what will it give, and such. > Maybe, but I think it would be very boring to play a mage in that case - > cast a couple spells, maybe not kill anything with them, have to rest to > regain mana, cast some more spells, etc. One goal is to balance things > such that mages and fighters are both fairly equal at all levels, so I > think low level mages need to be effective. > > With the changes, it may be some different spells are needed - maybe 1st > level firebolt and the like. My opinion is that we have too many spells, actually. Small, medium, large fireball? I'd rather see one fireball, maybe with possibility to adjust it in real time - cast for 1s get a small fireball, cast for 3s get a large one? Note also that currently, for some spells, it gives a weird delay - it's probably faster to cast 5 small healing spells than one medium healing, and you get roughly the same amount of hp. > I also wonder how much long term impact it has - it seems that at a > fairly low level, characters will have weapons that do non physical damage > (eg, fire, cold, electricity, whatever), and at that point, the distinction > on physical attack types is lost. > > Maybe as part of this, all weapons that do extra attacktypes needs to be > redone some, so that the damage of the attacktype is minor extra damage. > For example, that firebrand may still do mostly physical (slashing) damage, > but also do some amount of fire damage. This greatly changes weapon > combat, but once again, maybe not a bad thing. Well, I guess the 'attacktype' can be seen in 2 ways: * 'absolute' value, ie 3 phy dam + 5 fire dam * 'proportion' value, ie 5 phy dam + 5% fire + 10% cold, or something like that Ideally, we could have: * damage dependant on overall level difference, or 'attack' vs 'defense' difference? ie you're highly skilled against a low level monster, you'll aim for weak spots and do high damage ; you fight a higher level monster, you have issues hitting correctly, opponent defends nicely * damage dependant on 'monster's type', ie mace against skeleton gives high damage, sword against skeleton isn't that great * 'elemental' (fire, cold, ...) damage could be either a proportion of dealed damage (ie you hit the monster for 15 phy and 10% fire), or a random value (you hit the monster for 12 phy, and randomly for 5 fire). This could lead to a greater variety of items. 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/20070923/f34b2046/attachment.pgp From kbulgrien at worldnet.att.net Sun Sep 23 09:34:21 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 23 Sep 2007 09:34:21 -0500 Subject: [crossfire] Project: Slow down combat (vs magic) In-Reply-To: <46EF572D.4070700@sonic.net> References: <46E64006.6020004@sonic.net> <200709172339.09423.nicolas.weeger@laposte.net> <46EF572D.4070700@sonic.net> Message-ID: <200709230934.21450.kbulgrien@worldnet.att.net> Playing with permadeath on ailesse recently has been very enlightening. I have a very hard time keeping characters alive, so I've finally become so frustrated that I have been trying out different characters. Those experiences are making me have a different viewpoint on slowing down combat than I had during the vote since I've had to play many low-level characters. In short, magic use is terrible. If you choose to play a magic-use only player, you are totally and completely disadvantaged. A magic-only user will die very, very easily, and will level very, very slowly compared to a physical combat character. > > 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. They already need re-balancing. > >> 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. > 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, slaying, etc, can all mix things up. > that one of the interesting things about giving characters more starting hp. > If characters start at say 50, and at level 10 have 150, that is a 3 times > improvement, so would still generally take 3 spells from that 10th level person > to kill that level 1 person. > > > > >> 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. > > > > Possibly, yes, else you run the risk of making spells harder - unless they are > > compensated later on with really powerful things? No! Do not make them harder. They are already harder. The more I see in this discussion, the more I agree with other sentiments on thread by Juha J?ykk? , and on an IRC commentary by Michael Toennies. I am thinking more and more that any change here needs to be looked at with a system perspective first, and not tackled piece by piece. At the same time I say that, I do not know how one pulls that off very well with a distributed development team where only e-mails, irc, etc are the available ways of communicating, so, then I wonder how possible suggesting such a thing is. > Maybe, but I think it would be very boring to play a mage in that case - cast > a couple spells, maybe not kill anything with them, have to rest to regain mana, > cast some more spells, etc. One goal is to balance things such that mages and > fighters are both fairly equal at all levels, so I think low level mages need to > be effective. > > With the changes, it may be some different spells are needed - maybe 1st level > firebolt and the like. I really think I would vote differently today, and if work on one thing or another had to be done, rather than a rework of the entire system, I think I would now say that magic should be adjusted before attempting to slow down combat. > > Yes, of course, but we're talking of redoing the whole combat system in the > > first place ;) > > Right - I'm open to this, but would like to hear more discussion on this - do > people generally think it is a good idea? I believe I agree that looking at all the combat is critical, and, that magic is severely handicapped at the moment (for low-level characters at least, which is all I know since in all these years I don't think I've every topped level 40). Ok, Ryo, you can stop complaining by at least one increment... I commented... ;-) and stopped lurking. Kevin From kbulgrien at worldnet.att.net Sun Sep 23 09:49:59 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 23 Sep 2007 09:49:59 -0500 Subject: [crossfire] Project: Slow down combat (stamina?) In-Reply-To: <46EF5C09.9030205@sonic.net> References: <46E64006.6020004@sonic.net> <46EF572D.4070700@sonic.net> <46EF5C09.9030205@sonic.net> Message-ID: <200709230949.59332.kbulgrien@worldnet.att.net> > 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? I suspect it is going to be difficult to balance combat and effectively slow down the combat without making physical combat metered like mana/grace combat is. A proposal for making physical combat speed controlled by a metered resource like "stamina" is hereby on the table for discussion. Physical combat is extremely unbalanced a the moment, IMO. Kevin From crossfire at kahnert.de Sun Sep 23 12:33:57 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sun, 23 Sep 2007 19:33:57 +0200 Subject: [crossfire] Project: Slow down combat (vs magic) In-Reply-To: <200709230934.21450.kbulgrien@worldnet.att.net> References: <46E64006.6020004@sonic.net> <200709172339.09423.nicolas.weeger@laposte.net> <46EF572D.4070700@sonic.net> <200709230934.21450.kbulgrien@worldnet.att.net> Message-ID: <20070923173357.GA19341@apollo.kahnert.local> On Sun, Sep 23, 2007 at 09:34:21AM -0500, Kevin R. Bulgrien wrote: > In short, magic use is terrible. FACK I compared how easy it is to clear the beginners map with a fireborn sorcerer and a troll warrior (search for fireborn sorcerer): http://mailman.metalforge.org/pipermail/crossfire/2007-July/011729.html > If you choose to play a magic-use only player, you are totally and > completely disadvantaged. A magic-only user will die very, very > easily, and will level very, very slowly compared to a physical combat > character. It's a pain to play a magic character in a role playing manner at the moment, yes. > I am thinking more and more that any change here needs to be looked at > with a system perspective first, and not tackled piece by piece. That's the point. Voting on single points will hardly help to improve the system at all. > At the same time I say that, I do not know how one pulls that off very > well with a distributed development team where only e-mails, irc, etc > are the available ways of communicating, Collect all ideas at the wiki and discuss each point until we get a consistent system. > so, then I wonder how possible suggesting such a thing is. Good question. As long as the coding itself has the priority without looking for the entire result, it's unlikely to end with a great system. J?rgen From nicolas.weeger at laposte.net Sun Sep 23 13:11:06 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 23 Sep 2007 20:11:06 +0200 Subject: [crossfire] Release of 1.11 in a week or two In-Reply-To: <46F0A811.7090105@sonic.net> References: <46EF6D65.6000404@sonic.net> <000001c7fa33$044f4b10$0cede130$@o@free.fr> <46F0A811.7090105@sonic.net> Message-ID: <200709232011.10219.nicolas.weeger@laposte.net> > It shouldn't be. It's possible that a few things or other changes were > outside of #ifdefs. For both client & server, having curl shouldn't be a > requirement. What's the point of metaserver2, then? :) I think curl is needed, so newer clients use newer servers. > Having pthread, at least for client, may be, as even for metaserver1 > support, it now uses pthread to get the data from the server in its own > thread. > > pthread may get used for more stuff - threading the client is an > interesting idea (one thread to deal with drawing, another for socket) - in > this way, GUI is always snappy, and the number of locks needed to make this > happen actually isn't that many. Actually, pthread is probably harder to get for Windows than curl ;) And threading the client, what for? I mean, that's not a small task, what is the point of threading for now? > Haven't tried, but see comment about SDL map support getting removed in > other message. While I know there is always desire to have as many options > as available, as the person that has done considerable work with SDL and > opengl for drawing logic, opengl seems a much better solution (it seems to > provide many more acceleration options than SDL. For example, if at some > point we move lighting effects to the client, opengl has interfaces for > that. For SDL, we'd need to write our own lighting routines) > > Now I realize that everyone may not have working opengl, etc, but for > those people, pixmap mode is still there. Well, SDL is nice because you can use audio things too, so you get sound support. But maybe openal could be used, as another thread mentioned. Also, if I remember correctly, pixmap does not support alpha transparency, which is something it'd be great to have (ok, in a few years / centuries, when we have artists...) 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/20070923/9e4df687/attachment.pgp From mwedel at sonic.net Sun Sep 23 19:45:14 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 23 Sep 2007 17:45:14 -0700 Subject: [crossfire] Project: Slow down combat In-Reply-To: <200709231148.35570.nicolas.weeger@laposte.net> References: <46E64006.6020004@sonic.net> <200709172339.09423.nicolas.weeger@laposte.net> <46EF572D.4070700@sonic.net> <200709231148.35570.nicolas.weeger@laposte.net> Message-ID: <46F7089A.7090106@sonic.net> Nicolas Weeger wrote: >> Maybe, but I think it would be very boring to play a mage in that case - >> cast a couple spells, maybe not kill anything with them, have to rest to >> regain mana, cast some more spells, etc. One goal is to balance things >> such that mages and fighters are both fairly equal at all levels, so I >> think low level mages need to be effective. >> >> With the changes, it may be some different spells are needed - maybe 1st >> level firebolt and the like. > > My opinion is that we have too many spells, actually. Small, medium, large > fireball? I'd rather see one fireball, maybe with possibility to adjust it in > real time - cast for 1s get a small fireball, cast for 3s get a large one? > Note also that currently, for some spells, it gives a weird delay - it's > probably faster to cast 5 small healing spells than one medium healing, and > you get roughly the same amount of hp. This is perhaps getting ahead of discussions related to hand to hand combat, but I do agree, refining the number of spells will be needed. This is especially true because there is the goal to have meaningful spells from level 1 to 100 (or thereabouts). That would then equate to something like 10 different variety of fireballs. Being able to tune spells is interesting idea. the hardest part is figuring out correct balance (how much more should the large fireball cost vs small, etc). If in the end, there are archetypes for these different versions, that doesn't really help things out. You want to be able to do something like 'cast fireball (radius=5, dam=20)' type of things. You obviously can not cast a spell of higher power than you're allowed (for example, based on your level, maybe maximum damage you can do is 15). Adding this change in wouldn't be hard - but balancing it would be (in terms of mana cost and speed). > >> I also wonder how much long term impact it has - it seems that at a >> fairly low level, characters will have weapons that do non physical damage >> (eg, fire, cold, electricity, whatever), and at that point, the distinction >> on physical attack types is lost. >> >> Maybe as part of this, all weapons that do extra attacktypes needs to be >> redone some, so that the damage of the attacktype is minor extra damage. >> For example, that firebrand may still do mostly physical (slashing) damage, >> but also do some amount of fire damage. This greatly changes weapon >> combat, but once again, maybe not a bad thing. > > Well, I guess the 'attacktype' can be seen in 2 ways: > * 'absolute' value, ie 3 phy dam + 5 fire dam > * 'proportion' value, ie 5 phy dam + 5% fire + 10% cold, or something like > that > Ideally, we could have: Right now, code has been added so you can do things like: dam_physical 10 dam_fire 5 dam_magic 3 in the objects/archetypes, so damage for weapons can be tuned in any way. However, I think very few objects have been adjusted, so it comes down to a question if most weapons should be adjusted to have mostly dam_slashing (or the like) and minor amounts of the elemental damage. Otherwise, if I can get a 'dam_fire 20' weapon, adding slashing/piercing/blunt damage types really doesn't do much. > * damage dependant on overall level difference, or 'attack' vs 'defense' > difference? ie you're highly skilled against a low level monster, you'll aim > for weak spots and do high damage ; you fight a higher level monster, you > have issues hitting correctly, opponent defends nicely In theory, this should amount to ac vs wc - if something has a high AC, it is difficult to hit. Some game systems do use the method that based on how much you hit by determines how much damage. For example, using a d20 as a basis, if you need to roll an 18+ to hit the creature, you'd never do much damage (at best, you can hit by 2). But if you need a 5+, then if you roll a 5, you still hit but don't do much damage, but if you roll a 18, your hit and do a lot of damage. I don't think I'd really like that with crossfire - adjusting damage based on how well you hit, and then adjusting it further based on resistances of the creature would in many cases meaning doing virtually no damage. I think with this, it would also make it harder to tune monsters. The game systems that do use this relative damage based on how well you hit tend not to have damage reduction/absorption like crossfire. > * damage dependant on 'monster's type', ie mace against skeleton gives high > damage, sword against skeleton isn't that great That is easy enough to do based on resist values - skeletons would probably have something like resist_slashing 90 and resist_piercing 90, and probably resist_blunt 0 (or maybe even negative). > * 'elemental' (fire, cold, ...) damage could be either a proportion of dealed > damage (ie you hit the monster for 15 phy and 10% fire), or a random value > (you hit the monster for 12 phy, and randomly for 5 fire). This could lead to > a greater variety of items. So you're then saying that if you have a weapon that is 'dam_physical 10' and 'dam_fire 5', if the creature is largely resistance to physical, then the fire damage also go away? Or are you supposing that the attacktypes are not split apart, so you only have a 'attacktype fire|physical' to work with, and thus you need to adjust damage? From mwedel at sonic.net Sun Sep 23 20:04:38 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 23 Sep 2007 18:04:38 -0700 Subject: [crossfire] Project: Slow down combat (vs magic) In-Reply-To: <200709230934.21450.kbulgrien@worldnet.att.net> References: <46E64006.6020004@sonic.net> <200709172339.09423.nicolas.weeger@laposte.net> <46EF572D.4070700@sonic.net> <200709230934.21450.kbulgrien@worldnet.att.net> Message-ID: <46F70D26.6010809@sonic.net> Kevin R. Bulgrien wrote: > In short, magic use is terrible. If you choose to play a magic-use only player, > you are totally and completely disadvantaged. A magic-only user will die very, > very easily, and will level very, very slowly compared to a physical combat > character. I think most everyone knows magic is messed up in many ways - many of the top vote getters were related to magic. And certainly once melee combat is done, the spell system gets redone I also do agree that larger pictures need to be kept in mind. I personally don't think a total system perspective/design can be done. Things like that just don't generally work on a distributed system - the amount of work needed is quite large, such that one person can't do it in a timely fashion, and trying to coordinate that amongst a bunch of people, especially given the time differences, is very difficult. I'd also say that is only really required if the current system (code) was deemed completely unsuitable and thus needed to be redone from scratch. Obviously, in that case, you'd need want to try and design most of the system before writing code. I don't think crossfire is in that state. Combat needs to adjustments, as do spells. Some of those adjustments may be pretty big. But I also think that archetype changes will be a much bigger piece than code changes. My perspective is that since the code is largely sound, one can do things in smaller pieces. In this particular case, it sort of falls into a 'redo melee combat, and then balance the spells so they are comparable to melee' or 'redo spells, and then rebalance melee so it is in balance with the spells'. I don't think 'redo both spells & melee simultaneously and balance the two together at the same time' is especially doable, given resources available. Now in terms of rebalancing spells first and then combat, or combat first then spells, I'd sort of call that a tossup. I personally think it will be easier to do combat first and then balance spells to that, but may be wrong. I'm more than happy to take part in discussion on what the spell system should look like, ways to balance it, etc. I'm not particularly interested in getting into discussions about how things should be designed/discussed, etc, as most likely that is a large time sync that won't show much in the way of results. From mwedel at sonic.net Sun Sep 23 20:12:32 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 23 Sep 2007 18:12:32 -0700 Subject: [crossfire] Release of 1.11 in a week or two In-Reply-To: <200709232011.10219.nicolas.weeger@laposte.net> References: <46EF6D65.6000404@sonic.net> <000001c7fa33$044f4b10$0cede130$@o@free.fr> <46F0A811.7090105@sonic.net> <200709232011.10219.nicolas.weeger@laposte.net> Message-ID: <46F70F00.9030706@sonic.net> Nicolas Weeger wrote: >> It shouldn't be. It's possible that a few things or other changes were >> outside of #ifdefs. For both client & server, having curl shouldn't be a >> requirement. > > What's the point of metaserver2, then? :) > I think curl is needed, so newer clients use newer servers. There is a difference of something being highly desirable and something being strictly required. I can think of some number of cases where people may not use the metaserver2 for various reasons, and thus don't really want to bother downloading what may be extra libraries. The configure in the client is supposed to error out if curl is not found, but there is also an option to bypass that and compile the client without it. Now any ones I compile and official distribute will have metaserver2 support, but if it isn't hard to remove requirements of certain libraries, then probably not a bad thing to do so. > >> Having pthread, at least for client, may be, as even for metaserver1 >> support, it now uses pthread to get the data from the server in its own >> thread. >> >> pthread may get used for more stuff - threading the client is an >> interesting idea (one thread to deal with drawing, another for socket) - in >> this way, GUI is always snappy, and the number of locks needed to make this >> happen actually isn't that many. > > Actually, pthread is probably harder to get for Windows than curl ;) > And threading the client, what for? I mean, that's not a small task, what is > the point of threading for now? I didn't say I was going to hop right on it and do it. The most basic would be something like what is done right now for metaserver - have one thread to deal with handling the gui, and another thread to deal with taking the data from the socket and figuring out what to do with it. In this way, the gui should always remain responsive even if the client is spending a bit of time digesting data from the socket. And in retrospect, having the sound stuff done in a separate thread instead of a separate program would likely have been better. > >> Haven't tried, but see comment about SDL map support getting removed in >> other message. While I know there is always desire to have as many options >> as available, as the person that has done considerable work with SDL and >> opengl for drawing logic, opengl seems a much better solution (it seems to >> provide many more acceleration options than SDL. For example, if at some >> point we move lighting effects to the client, opengl has interfaces for >> that. For SDL, we'd need to write our own lighting routines) >> >> Now I realize that everyone may not have working opengl, etc, but for >> those people, pixmap mode is still there. > > Well, SDL is nice because you can use audio things too, so you get sound > support. But maybe openal could be used, as another thread mentioned. There are like 20 different sound mechanisms for linux it seems. I do think openal would be a better long term solution, as it supports more advanced sound handling, so instead of the client having to deal with mixing, etc, openal would take care of it. > > Also, if I remember correctly, pixmap does not support alpha transparency, > which is something it'd be great to have (ok, in a few years / centuries, > when we have artists...) opengl also supports alpha transparencies also. I won't really dispute that SDL is better than pixmap mode. I'm just not sure if both SDL and opengl support really makes sense. Also, I'd have to look at how the SDL code was done - while I know SDL does support alpha transparencies, I'm not sure if the implementation done in the client does or not. From mwedel at sonic.net Mon Sep 24 02:19:14 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 24 Sep 2007 00:19:14 -0700 Subject: [crossfire] flame touch & immolation Message-ID: <46F764F2.20505@sonic.net> bug report 1742632 states that immolation (from ruggilli) does not work with flame touch. I've confirmed that that is in fact true, and this is my response. I'm posting to the list to get some more responses/input on this, since I'm not sure how many people actually read the bug reports. --- If you're using flame touch, you will never immolate anything. One can take it to be that the burning nature kills the immolation disease itself. On a more exact basis, only if the attacktype does some sort of physical damage can immolation be transferred. This also means that other races of characters that worship Ruggilli and use special weapons that do not have do physical damage will never immolate anything either. If you really want to use immolation, using another skill like karate or punching would transfer the disease. I do think that to some extent, it would make sense for fire attacks to transfer immolation. Unfortunately, the code really isn't set up that good to handle it. So I'll likely put this into a 'this is a feature' and 'won't fix' category, but will leave this open to some discussion. --- there is one fairly simple fix - make flame touch do 1 point of physical damage - it then would tranfer the disease (transferring of diseases has nothing to do with amount of damage done). That still doesn't fix it for other physical attacktypes that do pure fire damage. I don't know if there are other types of diseases out there which would also need rework. From lalo.martins at gmail.com Mon Sep 24 17:02:34 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 24 Sep 2007 22:02:34 +0000 (UTC) Subject: [crossfire] Project: Slow down combat References: <46E64006.6020004@sonic.net> Message-ID: Here's a relatively simple alternative suggestion: Actions have a speed rating. Essentially, this represents how often an average character would be able to perform that action. So this will be an attribute of weapons and of skills (specially interesting for unarmed combat skills), and possibly spells. A special case is walking. Either just decide that this is a constant value, or make that an attribute of the living creature. Then, on top of that, every living creature has a speed modifier: a multiplier that is applied to every action's speed. While I call that "speed", we could just as well do the opposite and call it "time" (T for the purposes of this email), meaning how many seconds, ticks, or whatever the action takes. Or call it "speed" to make archetype writing easier to understand, but internally convert that to T. So when your "turn" arrives, if you have an action queued, you perform that action, and then your next "turn" is after this action finishes, T ticks(/seconds/...) later. If there is no action queued, you're assumed to take the default action of "wait", which has a (low) constant T. I believe this is simple to implement, easy for map/arch writers to grok, and easy for new players to understand. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Mon Sep 24 23:16:54 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 24 Sep 2007 21:16:54 -0700 Subject: [crossfire] Project: Slow down combat In-Reply-To: References: <46E64006.6020004@sonic.net> Message-ID: <46F88BB6.1060206@sonic.net> Lalo Martins wrote: > Here's a relatively simple alternative suggestion: > > Actions have a speed rating. Essentially, this represents how often an > average character would be able to perform that action. So this will be > an attribute of weapons and of skills (specially interesting for unarmed > combat skills), and possibly spells. > > A special case is walking. Either just decide that this is a constant > value, or make that an attribute of the living creature. > > Then, on top of that, every living creature has a speed modifier: a > multiplier that is applied to every action's speed. > > While I call that "speed", we could just as well do the opposite and call > it "time" (T for the purposes of this email), meaning how many seconds, > ticks, or whatever the action takes. Or call it "speed" to make > archetype writing easier to understand, but internally convert that to T. > > So when your "turn" arrives, if you have an action queued, you perform > that action, and then your next "turn" is after this action finishes, T > ticks(/seconds/...) later. If there is no action queued, you're assumed > to take the default action of "wait", which has a (low) constant T. > > I believe this is simple to implement, easy for map/arch writers to grok, > and easy for new players to understand. In some sense, this is sort of an inverse of how things work now - all actions more or less take the same time, but the characters speed differs. And in many ways, the above makes a fair amount of sense - some objects should modify certain action speeds, and not others - for example, speed boots should reduce cost of movement, but really shouldn't reduce cost of swinging a weapon. But visibility to the player probably is important. In the above system, I would think that the amount of stuff being carried should have some effect on the cost of movement. But in that system, it is unclear how you would display that to the player - since they may be doing any number of possible actions, you can't really say 'action cost is xxx'. I think this would also need to be explored more - one quick concern I have off the top of my head is that all the different actions may now have custom code to figure out extra cost for this action based on various attributes. It also seems to me that a basic speed multiplier for each living creature may be a bit simplistic - if one were to do that approach, one would think different actions should perhaps have different costs based on races (some may be fast at spell casting, slow at combat). OTOH, that is a distinction that is currently missing from crossfire. From nicolas.weeger at laposte.net Wed Sep 26 12:11:39 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 26 Sep 2007 19:11:39 +0200 Subject: [crossfire] Release of 1.11 in a week or two In-Reply-To: <46F70F00.9030706@sonic.net> References: <46EF6D65.6000404@sonic.net> <200709232011.10219.nicolas.weeger@laposte.net> <46F70F00.9030706@sonic.net> Message-ID: <200709261911.42948.nicolas.weeger@laposte.net> > There is a difference of something being highly desirable and something > being strictly required. > > I can think of some number of cases where people may not use the > metaserver2 for various reasons, and thus don't really want to bother > downloading what may be extra libraries. *shrug* We're talking about Windows version, at least that's the start of the thread, and I must say I don't see many people building the client from SVN :) > There are like 20 different sound mechanisms for linux it seems. I do > think openal would be a better long term solution, as it supports more > advanced sound handling, so instead of the client having to deal with > mixing, etc, openal would take care of it. There are maybe many, but we should at least ensure they work under Windows and Mac too :) 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/20070926/3670bbef/attachment.pgp From nicolas.weeger at laposte.net Wed Sep 26 12:20:31 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 26 Sep 2007 19:20:31 +0200 Subject: [crossfire] flame touch & immolation In-Reply-To: <46F764F2.20505@sonic.net> References: <46F764F2.20505@sonic.net> Message-ID: <200709261920.31099.nicolas.weeger@laposte.net> > bug report 1742632 states that immolation (from ruggilli) does not work > with flame touch. I've confirmed that that is in fact true, and this is my > response. I'm posting to the list to get some more responses/input on this, > since I'm not sure how many people actually read the bug reports. From what I understand, immolation is a disease, correct? > there is one fairly simple fix - make flame touch do 1 point of physical > damage - it then would tranfer the disease (transferring of diseases has > nothing to do with amount of damage done). That still doesn't fix it for > other physical attacktypes that do pure fire damage. I don't know if there > are other types of diseases out there which would also need rework. Seems ok to me. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Fri Sep 28 11:45:46 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 28 Sep 2007 18:45:46 +0200 Subject: [crossfire] Project: Slow down combat In-Reply-To: <46F88BB6.1060206@sonic.net> References: <46E64006.6020004@sonic.net> <46F88BB6.1060206@sonic.net> Message-ID: <200709281845.49777.nicolas.weeger@laposte.net> > In some sense, this is sort of an inverse of how things work now - all > actions more or less take the same time, but the characters speed differs. Hum no, spell casting for instance takes a variable amount of time depending on the spell :) Also some commands take more time, I think > And in many ways, the above makes a fair amount of sense - some objects > should modify certain action speeds, and not others - for example, speed > boots should reduce cost of movement, but really shouldn't reduce cost of > swinging a weapon. > > I think this would also need to be explored more - one quick concern I > have off the top of my head is that all the different actions may now have > custom code to figure out extra cost for this action based on various > attributes. It also seems to me that a basic speed multiplier for each > living creature may be a bit simplistic - if one were to do that approach, > one would think different actions should perhaps have different costs based > on races (some may be fast at spell casting, slow at combat). OTOH, that > is a distinction that is currently missing from crossfire. Having different speeds for races is maybe not required for now? Let's have variable speed for different actions first, then adjust slowly :) 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/20070928/63067af3/attachment.pgp From nicolas.weeger at laposte.net Fri Sep 28 11:47:45 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 28 Sep 2007 18:47:45 +0200 Subject: [crossfire] Project: Slow down combat (vs magic) In-Reply-To: <46F70D26.6010809@sonic.net> References: <46E64006.6020004@sonic.net> <200709230934.21450.kbulgrien@worldnet.att.net> <46F70D26.6010809@sonic.net> Message-ID: <200709281847.45074.nicolas.weeger@laposte.net> > I think most everyone knows magic is messed up in many ways - many of the > top vote getters were related to magic. And certainly once melee combat is > done, the spell system gets redone I'd say we should try to do both. Fixing melee implies to balance monsters, so we should take the time to balance for magic too. > I'd also say that is only really required if the current system (code) > was deemed completely unsuitable and thus needed to be redone from scratch. > Obviously, in that case, you'd need want to try and design most of the > system before writing code. If we were to rewrite from scratch, yes, designing beforehand is nice :) > I don't think crossfire is in that state. Combat needs to adjustments, > as do spells. Some of those adjustments may be pretty big. But I also > think that archetype changes will be a much bigger piece than code changes. Probably, yes. And restarting from scratch isn't that fun, and not required imo. 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/20070928/d2deb84b/attachment.pgp From mwedel at sonic.net Sat Sep 29 02:44:27 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 29 Sep 2007 00:44:27 -0700 Subject: [crossfire] Project: Slow down combat In-Reply-To: <46E64006.6020004@sonic.net> References: <46E64006.6020004@sonic.net> Message-ID: <46FE025B.5070309@sonic.net> I decided to spend a little time playing with the code. The tavern.santa-clara.ca.us server is running with these changes. Note that I've only modified orcs, goblins, kobolds, and gnolls as far as AC goes. I also made some server changes as far as speed goes - it turns out that for first level characters, movement speed isn't that much different by default, but the attacks are slower. I must say that for a few hours work, I'm pleasantly surprised. My brand new human fighter no mows through the kobolds - they weren't a serious threat of killing him, but definitely slower - in many cases, taking several seconds to kill some orcs and kobolds. I think this may still be a bit too fast, but probably the limit of tuning with just speed and AC. It certainly does make the game a bit tougher. I think playing with HP is next step - I still like the idea of upping both monster & character HP at low levels, so a few stray hits don't kill a character. Feel free to log onto the server and try things out. Note that weapon speed number in client is misleading - it basically takes the weapon speed and divides it by normal speed. The way it is calculated now, it shouldn't be divided. While combat is slower, it didn't have as much effect on exp as I might have expected. This may be because more monsters get generated as you can't kill them as fast. Looking through the routines, some things stuck out at me: Wc bonus: Currently goes up based on fixed ratio (1 wc/6 levels of combat skill) - should this perhaps be settable in combat skill? Also, dam goes up as combat level goes up - 1 point/4 levels. Given other things are also improving (quality of weapon, characters strength, etc), is that extra bonus really necessary? I did notice that there was some strange logic that it may go up more if you had dam bonus from strength - it was divide that by 5. So if your str damage bonus was 5, every 4 levels it would go up 2, but if dam bonus was 4, would still only go up 1, because it didn't do anything clever regarding rounding. This then means a major benefit for high strength - a 29 str would give +10 base dam bonus, and if level 50 in combat skill, give another 24 bonus (2 per 4 levels, beyond the +1 per 4 levels just by itself). I wonder if this was a way to beef up dragons, but has the effect of beefing up all combat. search items - there is a speed penalty for using that. First question - is it even still used? Second, should that speed penalty perhaps be removed, since it is really more a convenience to the player? armor speed: Currently, the speed values are hard maximums (can not move faster than X), but if you're not moving that fast, no effect. Should these maybe be changed, and instead this becomes sort of like a speed penalty? Wearing plate will slow you down some, no matter what your current speed, etc? It seems that a lot of them have speed around or above 1.0 - with the speed values I put in the system, that is going to be a lot harder to reach. Weapon speed: The previous formula was certainly out of date - had many hard coded values in (basically if dex was above 14, bonus increased - probably wasn't as big a deal when max dex was 20, but with 25, bonus went up). But also, it factored in current loading of character. But it also factored in other things, like weapon weight, Strength, speed, etc. I've simplified it greatly - in summary: There is a based weapon_speed. Your dex will give some adjustment. the weapon_speed of the weapon itself will slow it down. Combat skills will increase speed a bit, character loading slow it down a bit. Prior to these changes, character level did not affect melee speed - not directly (stats improve as level does, etc) - I think this makes a bit more sense. My rationale for not factoring in the weight of the weapon is that should be included in weapon_speed itself. If I set a weapon_speed of 5, that should have clear meaning. If the weapon is really heavy, I should put in a slower speed in the object - if weapon is light, I put in a faster speed. This may require weapons to be adjusted, but I think it is more flexible (one could have a really slow light weapon in this system, or a really fast heavy weapon) From yann.chachkoff at myrealbox.com Sun Sep 30 00:15:49 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun, 30 Sep 2007 07:15:49 +0200 Subject: [crossfire] Project: Slow down combat In-Reply-To: <200709172339.09423.nicolas.weeger@laposte.net> References: <46E64006.6020004@sonic.net> <46E8C4DB.70507@sonic.net> <200709172339.09423.nicolas.weeger@laposte.net> Message-ID: <200709300715.49199.yann.chachkoff@myrealbox.com> Some short comments about all this... > I'm concerned no one replied already, but well... > My brain is slow, and needs time to formalize thoughts :) Shortly summarized (so that those who do not like to read a lot don't need to): I am not convinced at all that you can isolate the combat system from the rest of the gaming system. I'm also not convinced that tweaking the current system a bit can provide a very good answer to the current issues perceived by players. Now, for the less impatient ones, I'll provide a little more details on why I think so. First, there is a problem of content. All the current maps were designed with the base idea that "combats are fast and furious" in mind. It means large rooms full of monsters in which the player runs and "harvest". Slowing down combat would dramatically change this, and involve the complete redesign of most - if not all - maps in which combat happens. This is probably the most important issue in making combat pace changes, especially given that there are not a lot of map-makers out there. Second, there is the problem of other combat skills - basically, spells. Those were too designed with the idea of large-scale battles, with a single players fighting lots of monsters at the same time. Cone spells, as well as the "explosive" spells (like fireball) were obviously made with the idea of damaging a lot of opponents in a single cast. If the combat pace is slowed down, then it means the player will, on average, face less monsters at a given time, and thus this will reduce the effectiveness of those combat spells. The result will be that magic will get harder to use - and given that it *already* is hard (try to play a spellcaster in the context of a permadeath server if you don't believe it ! :) ), it would ultimately mean changes in the magic system as well. Third, archetypes will need massive changes - if the combat pace changes, so does the game balance; and thus, the monsters and weapons characteristics. Although some of such adaptations can be performed automatically by scripts, I believe that "handwriting" will also be required to balance the result in an appropriate way. Finally, the whole mechanism of combat needs to be rethought, and not only its pace, IMHO. Currently, melee combat is nothing more than "run into a monster". There is no combat visuals, little tactics, and no real variations between "melee techniques" - whatever the weapon or the melee skill used, it is just a matter of "running into monsters". As a fighter, I'd like to have to choose between various techniques, to have special hits, or simply to enjoy seeing my character swinging its poleaxe all around orcs :). Overall, I tend to agree with Kevin R. Bulgrien's point of view: I don't think designing things piece by piece is a good idea. But given that the boss already expressed lack of interest on that point, I'll not extend furthermore on this. Just my 2 eurocents. (Now, Ryo, you have one more reply - and before the rewrite was finished. :) ) From mwedel at sonic.net Sun Sep 30 02:24:43 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 30 Sep 2007 00:24:43 -0700 Subject: [crossfire] Project: Slow down combat (vs magic) In-Reply-To: <200709281847.45074.nicolas.weeger@laposte.net> References: <46E64006.6020004@sonic.net> <200709230934.21450.kbulgrien@worldnet.att.net> <46F70D26.6010809@sonic.net> <200709281847.45074.nicolas.weeger@laposte.net> Message-ID: <46FF4F3B.4060207@sonic.net> Nicolas Weeger wrote: >> I think most everyone knows magic is messed up in many ways - many of the >> top vote getters were related to magic. And certainly once melee combat is >> done, the spell system gets redone > > I'd say we should try to do both. Fixing melee implies to balance monsters, so > we should take the time to balance for magic too. I'm not denying that magic needs to be redone - in fact, I know magic needs to be redone. A baseline against what to tune is needed however. If monsters are still getting adjusted to be right power in melee, any adjustment to spells is hard, because the monster may still be in flux. But what may work is something like deferred tuning. What I tend to see for melee tuning is that it will basically start at low levels and work up. So we may be at a point where we say 'melee combat up to about level 5 is correct', and we could then start working on the spells that tune magic up to about level 5. And if some major problem is found in how things are working that requires re-tuning of monsters, at least things are not so far along that it prevents major effort on retuning everthing. From mwedel at sonic.net Sun Sep 30 03:05:57 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 30 Sep 2007 01:05:57 -0700 Subject: [crossfire] Project: Slow down combat In-Reply-To: <200709300715.49199.yann.chachkoff@myrealbox.com> References: <46E64006.6020004@sonic.net> <46E8C4DB.70507@sonic.net> <200709172339.09423.nicolas.weeger@laposte.net> <200709300715.49199.yann.chachkoff@myrealbox.com> Message-ID: <46FF58E5.4090502@sonic.net> Yann Chachkoff wrote: > Some short comments about all this... > >> I'm concerned no one replied already, but well... >> > My brain is slow, and needs time to formalize thoughts :) > > Shortly summarized (so that those who do not like to read a lot don't need > to): I am not convinced at all that you can isolate the combat system from > the rest of the gaming system. I'm also not convinced that tweaking the > current system a bit can provide a very good answer to the current issues > perceived by players. I'd probably disagree with that some. One could certainly have a game system that didn't have a spell system and only did melee combat. It may not be a very interesting game system or may have other issues. and I'm not saying that should be done here. This isn't aimed at you in particular, as other people have also brought up similar points: It would be constructive to bring forth/start a conversation on what the system should look like. The main reason here is to try and keep things moving and make forward progress. Very easy to get into a situation where things are stated as not right approaches or bad ideas, but unless alternatives are provided, end result is nothing happens. My current thinking is that at some level, it is better to try things out, even if some may end up being the wrong solution, as some may end up being the right solution. I almost think that now days, we sometimes get into too much discussion about varios things on crossfire (and I'm definitely guilty on that count) instead of just making the changes and seeing what breaks or who complains. But that is a fine line. I'm certainly interested in seeing what peoples thoughts/ideas are on a grand unified combat and magic system (gucams?) would look like. Putting ideas out there is never bad, even if not used. > First, there is a problem of content. All the current maps were designed with > the base idea that "combats are fast and furious" in mind. It means large > rooms full of monsters in which the player runs and "harvest". Slowing down > combat would dramatically change this, and involve the complete redesign of > most - if not all - maps in which combat happens. This is probably the most > important issue in making combat pace changes, especially given that there > are not a lot of map-makers out there. I agree that a fair number of maps may need to be changed. It certainly depends on how much slower combat is. Some maps are already more or less set up with a fewer set of boss monsters. Probably the biggest change on most maps will be removing some/all of the generators. But I also think that modifying existing content will be easier to handle/do than writing new content. I can easily enough go into existing maps and remove some monsters/generators or make some adjustments. However, for me to write a good map with good storyline, quest, traps, etc, that I'd be satisfied with would be a lot harder. And I think that as long as combat is slowed down, no matter how it is slowed down, these maps will need to get updated. If you have thoughts on ways to slow down combat without needing to adjust/change maps, I'm more than interested in hearing about it. > > Second, there is the problem of other combat skills - basically, spells. Those > were too designed with the idea of large-scale battles, with a single players > fighting lots of monsters at the same time. Cone spells, as well as > the "explosive" spells (like fireball) were obviously made with the idea of > damaging a lot of opponents in a single cast. If the combat pace is slowed > down, then it means the player will, on average, face less monsters at a > given time, and thus this will reduce the effectiveness of those combat > spells. The result will be that magic will get harder to use - and given that > it *already* is hard (try to play a spellcaster in the context of a > permadeath server if you don't believe it ! :) ), it would ultimately mean > changes in the magic system as well. As stated in other message, magic has to get redone, and I see doing it as part, or maybe shortly after, doing combat. > > Third, archetypes will need massive changes - if the combat pace changes, so > does the game balance; and thus, the monsters and weapons characteristics. > Although some of such adaptations can be performed automatically by scripts, > I believe that "handwriting" will also be required to balance the result in > an appropriate way. I think the note about maps also applies here - I think most any change of system will require archetype changes. Ideally, those are minimized (try to keep armor, shields, etc the same). The number of archetypes isn't huge however - taking a quick look, there are about 30 armor types (plate, leather, etc ) - if those needed to be changed, doing 30 archetypes wouldn't take too much time. the monsters are a bigger issue, as a lot more of those. But I think of the work, it is the maps that would be the biggest. > > Finally, the whole mechanism of combat needs to be rethought, and not only its > pace, IMHO. Currently, melee combat is nothing more than "run into a > monster". There is no combat visuals, little tactics, and no real variations > between "melee techniques" - whatever the weapon or the melee skill used, it > is just a matter of "running into monsters". As a fighter, I'd like to have > to choose between various techniques, to have special hits, or simply to > enjoy seeing my character swinging its poleaxe all around orcs :). I'm certainly willing to read your thoughts on this, and as noted above, what other people want to see in a new combat system. I don't think I ever said I didn't want to see peoples thoughts. What I've basically said is that I want to try and keep the different pieces small enough so that they can get done in some sort of timely manner. Really big projects are just really hard to do in the model in which we develop crossfire. From news at jonasstein.de Sun Sep 30 11:23:36 2007 From: news at jonasstein.de (Jonas Stein) Date: Sun, 30 Sep 2007 18:23:36 +0200 Subject: [crossfire] Spam and subject in mailing list Message-ID: <200709301823.36212.news@jonasstein.de> Hi, actually some messages in the mailing list is not marked with [crossfire] this is a bit uncomfortable for sorting in mailclients. I suggest to change this. A lot of spam comes through this list. Is it possible, to filter it more restrictive and deny the relay of email from mailserver without static DNS? -- regards, Jonas Stein From leaf at real-time.com Sun Sep 30 15:34:14 2007 From: leaf at real-time.com (Rick Tanner) Date: Sun, 30 Sep 2007 15:34:14 -0500 Subject: [crossfire] Spam and subject in mailing list In-Reply-To: <200709301823.36212.news@jonasstein.de> References: <200709301823.36212.news@jonasstein.de> Message-ID: <47000846.30603@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonas Stein wrote: > > actually some messages in the mailing list is not marked with [crossfire] this > is a bit uncomfortable for sorting in mailclients. I suggest to change this. > > A lot of spam comes through this list. Is it possible, to filter it more > restrictive and deny the relay of email from mailserver without static DNS? Mailing list archives at http://mailman.metalforge.org/pipermail/crossfire/ and http://dir.gmane.org/gmane.games.crossfire.general shows all messages with the [crossfire] subject header and 0 (zero) spam messages. Can you provide specific examples/samples with the mail message header? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHAAhGhHyvgBp+vH4RAg4kAKCYGx/Y2p+SKHQAHpxw63vgAVLr9wCeL+Eq 8+RdyR6LXrIGzZoqt6M+8sg= =ECn5 -----END PGP SIGNATURE----- From subs at eracc.com Sun Sep 30 19:08:34 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Sun, 30 Sep 2007 19:08:34 -0500 Subject: [crossfire] Spam and subject in mailing list In-Reply-To: <200709301823.36212.news@jonasstein.de> References: <200709301823.36212.news@jonasstein.de> Message-ID: <200709301908.35429.subs@eracc.com> On Sunday 30 September 2007 Jonas Stein wrote: [...] > A lot of spam comes through this list. Is it possible, to filter it more > restrictive and deny the relay of email from mailserver without static DNS? I have not seen any SPAM come through this list. Are you certain it is this list that is generating SPAM for you? Gene Alexander -- ERA Computers & Consulting Preloaded computers - eComStation, Linux and Unix Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From kbulgrien at worldnet.att.net Sun Sep 30 19:35:27 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 30 Sep 2007 19:35:27 -0500 Subject: [crossfire] Project: Slow down combat In-Reply-To: <46FE025B.5070309@sonic.net> References: <46E64006.6020004@sonic.net> <46FE025B.5070309@sonic.net> Message-ID: <200709301935.27461.kbulgrien@worldnet.att.net> > I decided to spend a little time playing with the code. The > tavern.santa-clara.ca.us server is running with these changes. Note that I've > only modified orcs, goblins, kobolds, and gnolls as far as AC goes. I also made > some server changes as far as speed goes - it turns out that for first level > characters, movement speed isn't that much different by default, but the attacks > are slower. > > I must say that for a few hours work, I'm pleasantly surprised. My brand new > human fighter no mows through the kobolds - they weren't a serious threat of > killing him, but definitely slower - in many cases, taking several seconds to > kill some orcs and kobolds. I think this may still be a bit too fast, but > probably the limit of tuning with just speed and AC. It certainly does make the > game a bit tougher. I think playing with HP is next step - I still like the > idea of upping both monster & character HP at low levels, so a few stray hits > don't kill a character. I set up a character on tavern... a gnome priest because that is what I was trying on ailesse when I commented on this before. I suggest testing with a non-warrior... not a warrior, for important observations in balance where the new player does not have a good armor class. Melee with the priest and his default two-handed quarterstaff is no match for the orc and his bow. The low hit rate for the priest is pretty much a death sentence. The orc's arrows deal out a lot of damage, and getting my licks in is so slow that going physical is asking for death. Has the orc's firing rate slowed proportionately to the player's attack rate? Newbie tower's kobolds are seemingly not possible with him even at second level even trying to use hit and run tactics... and this is even with a priest who can regen grace by praying. We do not want to bore people to tears at the beginning of the game, or no-one will stick it out. I'd hate to think how a mana magic user would fare with their limited mana regen. This strengthens concern about the feasibility of looking at physical combat only. I think it might be tough to keep disciplined at checking how stuff affects all characters. Testing with a character that uses primarily physical combat is going to tend to off-balance those that have to use physical combat as a backup because they are going to be affected even more than the warrior class. Also, on a side note, how much sense does it make that my guy is going hand to hand and this guy can fire arrows with a bow and kill me? A bow is not exactly something that works well for close combat. How possible is it for bow use to be impeded somewhat when right next to the defender? Kevin From kbulgrien at worldnet.att.net Sun Sep 30 19:51:59 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 30 Sep 2007 19:51:59 -0500 Subject: [crossfire] Project: Slow down combat In-Reply-To: <200709301935.27461.kbulgrien@worldnet.att.net> References: <46E64006.6020004@sonic.net> <46FE025B.5070309@sonic.net> <200709301935.27461.kbulgrien@worldnet.att.net> Message-ID: <200709301951.59921.kbulgrien@worldnet.att.net> > Newbie tower's kobolds are seemingly not possible with him even at second > level even trying to use hit and run tactics... and this is even with a > priest who can regen grace by praying. We do not want to bore people to > tears at the beginning of the game, or no-one will stick it out. I'd hate > to think how a mana magic user would fare with their limited mana regen. Once I got up to level 2 praying, I was finally able to take out generators near the door, so I was able to figure I was making headway, but this took a long time... maybe over 15 minutes. Now I am no expert crossfire tactician but I cannot buy stuff because the guy doesn't have any money, so not much to be done, and he has died a couple of times already without hope of being able to get a potion to restore stats. > This strengthens concern about the feasibility of looking at physical combat > only. I think it might be tough to keep disciplined at checking how stuff > affects all characters. Testing with a character that uses primarily physical > combat is going to tend to off-balance those that have to use physical combat > as a backup because they are going to be affected even more than the warrior > class. Remember that combat speed isn't all about how fast I hit them. The more I play, the more I realize that mostly what changed is I can't hit as fast. I am still extremely vulnerable to buffered keystrokes... maybe even more so now because action is so much more slow. I have to play "very fast" to avoid death. I can't say that I think this is an improvement. I don't want to be slower on one hand, I want to be able to be faster at saving my life. OTOH, regarding balance of physical combat vs. magic, yes, there is an element of wanting to be slower so I can really play a magic user without always having to defer to saving myself with physical combat. The player should not always be on the edge of death due to things like buffered up keystrokes... Michtoen seemed to address this in his comments on being able to interrupt the incoming commands when a monster was beside the player, but I didn't really find out what all he was talking about when he reviewed what was done with Daimonin. This, to me, was a lot of what was behind my vote for slowing down combat. Kevin From mwedel at sonic.net Sun Sep 30 22:20:41 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 30 Sep 2007 20:20:41 -0700 Subject: [crossfire] Project: Slow down combat In-Reply-To: <200709301935.27461.kbulgrien@worldnet.att.net> References: <46E64006.6020004@sonic.net> <46FE025B.5070309@sonic.net> <200709301935.27461.kbulgrien@worldnet.att.net> Message-ID: <47006789.8080502@sonic.net> Kevin R. Bulgrien wrote: > I set up a character on tavern... a gnome priest because that is what I was > trying on ailesse when I commented on this before. As noted, nothing has been done relating to spells, so balance in those areas gets odd - things like spells likely do need to get adjusted for the new system - exactly how is an interesting question. But you're experience does give some interesting thoughts and pose some interesting questions, more on that later. > I suggest testing with a non-warrior... not a warrior, for important observations > in balance where the new player does not have a good armor class. Melee with the > priest and his default two-handed quarterstaff is no match for the orc and his > bow. The low hit rate for the priest is pretty much a death sentence. The orc's > arrows deal out a lot of damage, and getting my licks in is so slow that going > physical is asking for death. Has the orc's firing rate slowed proportionately > to the player's attack rate? Other than AC, orcs (and the other creatures) have not been changed - they move at the same speed. What I plan to do next is increase HP for both players and monsters (starting HP), as the current starting HP even had problems before - while the priests hit rate was better, a couple hits from an orc would still likely kill the character, with either new or old combat system. The changes I made didn't really address that. > > Newbie tower's kobolds are seemingly not possible with him even at second > level even trying to use hit and run tactics... and this is even with a > priest who can regen grace by praying. We do not want to bore people to > tears at the beginning of the game, or no-one will stick it out. I'd hate > to think how a mana magic user would fare with their limited mana regen. Can you provide the WC and damage numbers for you're character? These are interesting data points, and helps better understand the problem. My thought here, since all combat will be slowed down, is that characters starting grace and mana would also be higher. I'm not sure how to fix the regen problem, but and interesting thought is this - within the game, it is known when a character is doing and action of being idle. It would seem reasonable to me that perhaps hp/grace/mana does not regen unless the character is idle (or maybe rates are lower if not idle, or a lot faster if idle). In this way, a character would not get many hp/mana/grace while actively adventuring and killing things, but if he stops for a short while, he'd get it back pretty quickly. > > This strengthens concern about the feasibility of looking at physical combat > only. I think it might be tough to keep disciplined at checking how stuff > affects all characters. Testing with a character that uses primarily physical > combat is going to tend to off-balance those that have to use physical combat > as a backup because they are going to be affected even more than the warrior > class. I'm interested in having/seeing a discussion about how everything should work together, but someone needs to do something more than 'we should have this discussion' - someone needs to start it, with the ideas of how they thing it should work out. But this does lead to an interesting question - how do we deal with classes that are not good at melee, especially hybrid classes? For example, a character that is pure fighter is lets say level 80 in one handed weapon. That has some pretty well defined bonus (wc, etc). Against a tough creature, hitting probably should not be guaranteed, etc. but now lets take a character that is say level 50/50 fighter/magic, but overall same level (and therefor, power) as that fighter. A gap of 30 levels in combat is significant - significant enough that hitting would probably be very difficult. And a character that is pure mage (70/20 mage/fighter lets say) would pretty much have no hope in melee. For this character, that is probably appropriate. But that middle case is more difficult. Obviously, that 50/50 fighter/magic character should not be as good a melee fighter as that person that is level 80. There could perhaps be some spells to help him out (increase wc or other stats). The other thought might be to greatly reduce how fast wc increase of combat skills, so that 30 level gap is not as big (3 wc instead of 7 like it would be now). Maybe also basically make the target that a pure melee character should hit creatures 50% of the time - in this case, a 3 wc penalty would mean character hits creatures 35% of the time - a pretty big jump, but probably not so big as to make it impossible for the character to kill the creature. > > Also, on a side note, how much sense does it make that my guy is going hand to > hand and this guy can fire arrows with a bow and kill me? A bow is not exactly > something that works well for close combat. How possible is it for bow use to > be impeded somewhat when right next to the defender? In some sense, probably is a much bigger deal if the person using the bow is being attacked - trying to use a bow while dodging, etc, is probably next to impossible. Changes could perhaps be made, but they should affect players and monsters equally - players should not be able to use a bow if next to monster. The simplest fix would just can't use a bow if next to monster (and vice versa) whether it is attacking you or not. From mwedel at sonic.net Sun Sep 30 22:29:09 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 30 Sep 2007 20:29:09 -0700 Subject: [crossfire] Project: Slow down combat In-Reply-To: <200709301951.59921.kbulgrien@worldnet.att.net> References: <46E64006.6020004@sonic.net> <46FE025B.5070309@sonic.net> <200709301935.27461.kbulgrien@worldnet.att.net> <200709301951.59921.kbulgrien@worldnet.att.net> Message-ID: <47006985.1020906@sonic.net> Kevin R. Bulgrien wrote: > Remember that combat speed isn't all about how fast I hit them. The more I > play, the more I realize that mostly what changed is I can't hit as fast. I > am still extremely vulnerable to buffered keystrokes... maybe even more so > now because action is so much more slow. I have to play "very fast" to avoid > death. I can't say that I think this is an improvement. I don't want to be > slower on one hand, I want to be able to be faster at saving my life. OTOH, > regarding balance of physical combat vs. magic, yes, there is an element of > wanting to be slower so I can really play a magic user without always having > to defer to saving myself with physical combat. > > The player should not always be on the edge of death due to things like > buffered up keystrokes... Michtoen seemed to address this in his comments on > being able to interrupt the incoming commands when a monster was beside the > player, but I didn't really find out what all he was talking about when he > reviewed what was done with Daimonin. This, to me, was a lot of what was > behind my vote for slowing down combat. So something like that is doable. The way to explain it is that the server looks at all commands sent by the player every tick (not just the one at the top of the queue), and some commands have precedence and are perhaps meta commands, like a 'cancel all previous commands'. In that way, you're playing, having buffered up a bunch of stuff, and then something happens that changes the dynamic of the battle. You hit the 'cancel' button, it cancels the previous commands, and then starts doing the commands after the cancel. I've wanted to right this irrespective of slowing down combat - it sounds like to some extent that this is perhaps more relevant now. It also has some other advantages - some commands should be freebie commands, and thus executed whether or not the character actually has an action (things like who, maps, chat). One could also extend this so that all commands have a priority, and the server processes in priority order. So you're in the middle of combat, and have hit the keys to cast some spells. You notice your hp are low, so you drink the potion of healing. In general, you probably want the potion quaffing to be very high priority, so it happens first, but your casting of spells still goes off. This is a bit more flexible than the cancel action. Programatically, it isn't that much harder - the harder part is an interface for the players to set these different priorities - it probably be simplest just to having things like 'high, normal, low' instead of a number scheme, as that would be easier to understand. > > Kevin > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From kbulgrien at worldnet.att.net Sun Sep 30 23:30:47 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 30 Sep 2007 23:30:47 -0500 Subject: [crossfire] Project: Slow down combat In-Reply-To: <200709301951.59921.kbulgrien@worldnet.att.net> References: <46E64006.6020004@sonic.net> <200709301935.27461.kbulgrien@worldnet.att.net> <200709301951.59921.kbulgrien@worldnet.att.net> Message-ID: <200709302330.47166.kbulgrien@worldnet.att.net> Getting up to level 6 with the gnome priest gave a bit of time to review. The first few levels were very hard, but, as playing progressed, it did strike me that some of that perception could be attributable to having played so much on servers where the physical combat was so effective that one expected to do that on the new server. It became a little more easy to see that maybe tweaking physical combat first might be a decent way to start changing expectations about how fast game play should be... so there is likely merit in playing around with things so long as people are testing it and giving feedback on real experiences with a variety of characters... It is a fine line though. There are so many subjective areas that come into play. This character had high stats and so a reasonable amount of grace. With a mid-range character I think there is still a chance for being quite frustrated. In the end though, I do believe playing a mana-based magic user would be extremely dangerous / tedious. It seems very hard to think that an adjustment will not be needed there immediately even if grace based magic is left alone. Anyway, since I've spoken about balancing everything, figured it would be good to show that I see some merit to experimenting on a smaller scale also. It was a fun evening... Thanks for putting that server up. Kevin