From mwedel at sonic.net Sun Apr 1 01:16:29 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 31 Mar 2007 23:16:29 -0700 Subject: [crossfire] Maps passwords/phrases text In-Reply-To: <45F77618.8090003@sonic.net> References: <45F642B3.5020006@sonic.net> <200703132000.58981.nicolas.weeger@laposte.net> <45F77618.8090003@sonic.net> Message-ID: <460F4E3D.2040705@sonic.net> Just a note that I put this on the TODO list of the wiki, so this conversation is recorded. From nicolas.weeger at laposte.net Tue Apr 3 12:59:01 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 3 Apr 2007 19:59:01 +0200 Subject: [crossfire] Material Message-ID: <200704031959.01573.nicolas.weeger@laposte.net> Hello. I'm wondering if there is documentation on the material system. Couldn't really find much :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Tue Apr 3 15:20:09 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 3 Apr 2007 22:20:09 +0200 Subject: [crossfire] Skill subtypes/names Message-ID: <200704032220.09229.nicolas.weeger@laposte.net> Hello. Right now, one can't create 2 skills behaving similarly but with different names. The reason is because there is a skill_names array, indexed by subtype. Thus there is a conflict when 2 skills have the same. This array is used to quickly find skills objects, through eg SK_DISARM_TRAPS. I'd like to remove this restriction (assuming it isn't too hard, but shouldn't be, most of the code doesn't rely on the array - appears a total of 17 times, including declaration, filling, and such). This would mean splitting skills subtype number - hardcoded - and skills count - generated from archetype list. Also, it could mean we'd be able to "merge" eg pyromancy / evocation / ... (only need to fix IS_MANA_SPELL, or use 2 different subtypes, one for mana spells, one for grace spells). Any objection? -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Tue Apr 3 16:32:56 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 3 Apr 2007 23:32:56 +0200 Subject: [crossfire] New skill: fishing Message-ID: <200704032332.56970.nicolas.weeger@laposte.net> Hello. I just committed a fishing pole (picture courtesy Maligor), and the corresponding fishing skill. I also changed the 'fish' archetype to be fishable :) Technical documentation is at http://wiki.metalforge.net/doku.php/dev:skills#sk_harvesting Short summary: to enable a player to fish at a certain spot (sea/river preferably), just put a fish in the sea's inventory, you're set :) Of course, ideally, new fish could be created, with their own specifics ^_- The pole currently isn't part of any treasure list, so if a mapmaker felt like doing a quest, or some fishing shop, that'd be great :) My implementation of fishing is such that other "harvesting" skills could easily be added (provided the skill name issue in my previous mail is fixed), and I may add some later on :) Many possibly ideas: honey from bees (even monsters, that'd work i think), milk from cows, wool from sheep, wheat from field, apples from tree, you name it Caveats, known issues, future ideas: * there is no limit on number of items one can get from a spot. Maybe such a limit could be implemented (through the nrof field), or some time-based regeneration * this skill could probably contribute only 10% to the overall experience, instead of current 100% * the skill requires a tool. I'm not sure it's always required (who'd need a tool to grab apples from a tree?), but it's a way to prevent player from using the skill without the tool * there could be some other requirement to use the tool - maggot to fish, ... or consume the tool (bucket + cow => filled milk bucket?) * adding a probability to destroy the tool could be interesting, too, maybe based on harvested item - break your pole when trying to get a biiiiiig fish ^_- As usual, flames and comments welcome :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Tue Apr 3 16:47:26 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 3 Apr 2007 23:47:26 +0200 Subject: [crossfire] Polymorph spell Message-ID: <200704032347.26856.nicolas.weeger@laposte.net> Hello. I'm wondering whether the polymorph spell couldn't be reactivated. It's been desactivated for eons, but IMO it could be a fun one - with some limits. Maybe create some scrolls, and have them at end of hard quests only? Or the code should simply be removed if not used, but IMO that'd be a waste :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Tue Apr 3 16:58:11 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 3 Apr 2007 23:58:11 +0200 Subject: [crossfire] Build command Message-ID: <200704032358.11784.nicolas.weeger@laposte.net> Hello. The "build" command (server/c_object.c:command_build()) has been desactivated since ages. IMO alchemy could replace it, and the code should be removed (even though it has some fun ideas - or maybe it could be reenabled & fixed?) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Wed Apr 4 00:55:24 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 03 Apr 2007 22:55:24 -0700 Subject: [crossfire] Polymorph spell In-Reply-To: <200704032347.26856.nicolas.weeger@laposte.net> References: <200704032347.26856.nicolas.weeger@laposte.net> Message-ID: <46133DCC.1030305@sonic.net> Nicolas Weeger wrote: > Hello. > > I'm wondering whether the polymorph spell couldn't be reactivated. It's been > desactivated for eons, but IMO it could be a fun one - with some limits. > > Maybe create some scrolls, and have them at end of hard quests only? > > Or the code should simply be removed if not used, but IMO that'd be a waste :) It certainly can be re-activated. The main concerns I recall: 1) You could polymorph tough boss monsters into easy to kill monsters. 2) Related to items, you could get better items and/or make money. IMO, #2 isn't that much an issue, as long as really great artifact items can't be created. Money is easy enough to come by, that so long as getting polymorph objects mean you are high level, the money gain/less isn't likely to be an issue. #1 could be an issue, but fixed by some monsters not being polymorphable. I also recall that polymorph only worked for single space monsters, so already had some limits. The spell was always in bolt format - I suppose this can be done with scrolls, but aiming scrolls always seemed a little harder than with wands. But wands with limited number of charges makes sense. Since wands have levels, one thought is that it can not affect a monster of higher level than the wand - that makes things interesting then - a level 100 polymorph wand could become a pretty good 'kill one creature' type of weapon, but if sufficiently hard to get, not a big deal there. From alex_sch at telus.net Wed Apr 4 01:21:13 2007 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 04 Apr 2007 00:21:13 -0600 Subject: [crossfire] Polymorph spell In-Reply-To: <46133DCC.1030305@sonic.net> References: <200704032347.26856.nicolas.weeger@laposte.net> <46133DCC.1030305@sonic.net> Message-ID: <461343D9.9010806@telus.net> Mark Wedel wrote: > > #1 could be an issue, but fixed by some monsters not being polymorphable. I > also recall that polymorph only worked for single space monsters, so already had > some limits. > > > Since wands have levels, one thought is that it can not affect a monster of > higher level than the wand - that makes things interesting then - a level 100 > polymorph wand could become a pretty good 'kill one creature' type of weapon, > but if sufficiently hard to get, not a big deal there. One thought about this, is most 'boss' monsters already have their level set greater than 115 in order to make them uncharmable, which by extension also makes them un-polymorphable. Therefore, I don't really think that is much of an issue with things are they are right now. Alex Schultz From lalo.martins at gmail.com Wed Apr 4 05:21:52 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 4 Apr 2007 10:21:52 +0000 (UTC) Subject: [crossfire] New skill: fishing References: <200704032332.56970.nicolas.weeger@laposte.net> Message-ID: On Tue, 03 Apr 2007 23:32:56 +0200, Nicolas Weeger wrote: > I just committed a fishing pole (picture courtesy Maligor), and the > corresponding fishing skill. That's great, some of us wanted that for quite some time :-) thanks > Short summary: to enable a player to fish at a certain spot (sea/river > preferably), just put a fish in the sea's inventory, you're set :) > Of course, ideally, new fish could be created, with their own specifics ^_- I'd like to suggest a small change, if it isn't too pok?mon-ish: if the harvested item is a monster, then instead of coming into your inventory, it comes in the space next to you (maybe on the space you're harvesting), and it will attack you. The uses are obvious -- for a hard item, you'd put it in the monster's inventory instead (eg, sea serpent's scale). Or you could charm it. 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/ 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 nicolas.weeger at laposte.net Wed Apr 4 13:02:56 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 4 Apr 2007 20:02:56 +0200 Subject: [crossfire] Polymorph spell In-Reply-To: <46133DCC.1030305@sonic.net> References: <200704032347.26856.nicolas.weeger@laposte.net> <46133DCC.1030305@sonic.net> Message-ID: <200704042002.56982.nicolas.weeger@laposte.net> > 1) You could polymorph tough boss monsters into easy to kill monsters. From the current code, monsters >= level 20 just aren't affected... That limit will probably need to be adjusted on casting level ;) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Wed Apr 4 13:00:58 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 4 Apr 2007 20:00:58 +0200 Subject: [crossfire] New skill: fishing In-Reply-To: References: <200704032332.56970.nicolas.weeger@laposte.net> Message-ID: <200704042000.58352.nicolas.weeger@laposte.net> > I'd like to suggest a small change, if it isn't too pok?mon-ish: if the > harvested item is a monster, then instead of coming into your inventory, it > comes in the space next to you (maybe on the space you're harvesting), and > it will attack you. The uses are obvious -- for a hard item, you'd put it > in the monster's inventory instead (eg, sea serpent's scale). Or you could > charm it. Committed that in SVN ;) Note that you can put both regular items and monsters, one'll be chosen randomly (up to 10 are chosen from). Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Fri Apr 6 15:03:08 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 6 Apr 2007 22:03:08 +0200 Subject: [crossfire] Release schedule/notes In-Reply-To: <4608BE0B.4010305@sonic.net> References: <4608BE0B.4010305@sonic.net> Message-ID: <200704062203.09020.nicolas.weeger@laposte.net> Hello. Reacting kind of lately, but well :) > The client, as of right now, should be compatible with older server (eg, > a trunk client can player on a 1.10.0 server without problems), so we could > do releases of those. I almost wonder if it makes sense to completely > decouple the numbering schemes between those, and instead have a > compatibility chart. My expectation is that trunk client will likely be > able to play on 1.x servers until some protocol changes are made and the > legacy support for older protocol is removed from the client. What this > effectively means is that one day the trunk client could work with 1.x, and > the next day it doesn't. We should already clear some really old stuff, which has been left over from previous things. That would make some room :) > I really thing, relative to the trunk, this is a brief outline of steps: > 1) Finish with the major overhaul of whatever we plan to overhaul in the > trunk server for 2.0 > 2) Set up some test server(s), see how they work. > 3) start worrying about making pre 2.0 releases once we have a pretty good > idea that what we have will have some semblance to what final 2.0 will look > like. Concerning point 2), we should have such servers starting from now. There are many things in trunk that aren't in branch, so it'd be a waste to wait too much before trunk becomes the officiel version :) IMO, doing a 1.11 release isn't necessary. We should concentrate on trunk (yes, there are many bugs, which is why we need to focus on fixing that), and only do bug fix releases of 1.x branch. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sat Apr 7 06:06:32 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 7 Apr 2007 13:06:32 +0200 Subject: [crossfire] Polymorph spell In-Reply-To: <200704032347.26856.nicolas.weeger@laposte.net> References: <200704032347.26856.nicolas.weeger@laposte.net> Message-ID: <200704071306.32614.nicolas.weeger@laposte.net> Spell is now enabled :) I tweaked some parameters and caps (polymorphed monster can't be more than casting level / 2). It should work with multipart mobs. IMO such a powerful spell should be only available in scrolls and wands. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Sat Apr 7 20:32:01 2007 From: mwedel at sonic.net (mwedel at sonic.net) Date: Sat, 7 Apr 2007 18:32:01 -0700 (PDT) Subject: [crossfire] Release schedule/notes In-Reply-To: <200704062203.09020.nicolas.weeger@laposte.net> References: <4608BE0B.4010305@sonic.net> <200704062203.09020.nicolas.weeger@laposte.net> Message-ID: <5152.70.148.14.117.1175995921.squirrel@webmail.sonic.net> >> I really thing, relative to the trunk, this is a brief outline of >> steps: >> 1) Finish with the major overhaul of whatever we plan to overhaul in the >> trunk server for 2.0 >> 2) Set up some test server(s), see how they work. >> 3) start worrying about making pre 2.0 releases once we have a pretty >> good >> idea that what we have will have some semblance to what final 2.0 will >> look >> like. > > Concerning point 2), we should have such servers starting from now. There > are > many things in trunk that aren't in branch, so it'd be a waste to wait too > much before trunk becomes the officiel version :) Maybe. To do so would require the following: a) It should be difficult to impossible for 1.x clients to connect to a server. b) Perhaps they should not even be visible on the metaserver, or a new metaserver architecture is needed. I say this because I think that the _worst_ thing that can happen for crossfire is for unaware users to play on a 2.0 server. They'd probably say things like it is buggy as hell, unreliable, and be PO'd when at some point the server is wiped because of imcompatible changes If the only way for someone to play is to download the SVN client and compile it themselves, then at that point, I say they probably know the risks. This gets a bit messed up as related to windows clients, as presumably ones would need to be made available, and people unaware would say 'hey - 2.0 looks the latest, I'll download that'. The main thing here is that one bad experience probably carries the weight of 10 good ones. > > IMO, doing a 1.11 release isn't necessary. We should concentrate on trunk > (yes, there are many bugs, which is why we need to focus on fixing that), > and > only do bug fix releases of 1.x branch. If that is the case, that is fine. But if that is the case, then a lot of stuff that is getting backported to the 1.x branch probably shouldn't get backported. The problem is how do you define a bug? Or maybe the question here is severity of bugs. Because if only 'bugs' are backported, there are going to be enough changes to warrant more 1.x releases, and portentially enough changes in those to call them 1.11, 1.12, etc. Also, backporting some 'features' to 1.x could be a good way to get testing on them. Polymorph might be such an example, and there may be others. But from lots of previous discussions, it was decided that 1.x would remain the stable branch, with regular releases, with the trunk branch not making releases for quite a while. We could of course change this policy, but this was something decided/discussed not too long ago. At some point, if we revisit every decision 6 months after it is made, it sort of calls into question what is the point of having these discussions and making decisions if we just decide something new a few months from now. > > Nicolas > -- > http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, > bref > de l'al?atoire !] > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From nicolas.weeger at laposte.net Sun Apr 8 08:13:37 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 8 Apr 2007 15:13:37 +0200 Subject: [crossfire] SF issue? Message-ID: <200704081513.37164.nicolas.weeger@laposte.net> Hello. Anyone has issues with Sourceforge when adding files? I'm getting: svn: COPY of skills/Skill_Tools/fishing_pole.arc: 403 Forbidden (https://svn.sourceforge.net) in branch tree. Couldn't find anything worth testing... Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sun Apr 8 08:17:40 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 8 Apr 2007 15:17:40 +0200 Subject: [crossfire] New skill: fishing In-Reply-To: <200704032332.56970.nicolas.weeger@laposte.net> References: <200704032332.56970.nicolas.weeger@laposte.net> Message-ID: <200704081517.40433.nicolas.weeger@laposte.net> > I just committed a fishing pole (picture courtesy Maligor), and the > corresponding fishing skill. And merged to branch too :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From alex_sch at telus.net Sun Apr 8 10:34:50 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 08 Apr 2007 09:34:50 -0600 Subject: [crossfire] SF issue? In-Reply-To: <200704081513.37164.nicolas.weeger@laposte.net> References: <200704081513.37164.nicolas.weeger@laposte.net> Message-ID: <46190B9A.8020107@telus.net> Nicolas Weeger wrote: > Hello. > > Anyone has issues with Sourceforge when adding files? > > I'm getting: > svn: COPY of skills/Skill_Tools/fishing_pole.arc: 403 Forbidden > (https://svn.sourceforge.net) > > in branch tree. Couldn't find anything worth testing... > > Nicolas > Recently certain operations are giving weird 403 Forbidden errors on svn.sourceforge.net, not only for Crossfire from what I hear. A way around it was added (but still undocumented, unless you count an sf.net admin comment in their issue tracker), which is to use projectname.svn.sourceforge.net instead of svn.sourceforge.net. To miagrate your checkout to it use this command: svn switch --relocate https://svn.sourceforge.net/svnroot/crossfire https://crossfire.svn.sourceforge.net/svnroot/crossfire Alex Schultz From nicolas.weeger at laposte.net Sun Apr 8 12:38:44 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 8 Apr 2007 19:38:44 +0200 Subject: [crossfire] SF issue? In-Reply-To: <46190B9A.8020107@telus.net> References: <200704081513.37164.nicolas.weeger@laposte.net> <46190B9A.8020107@telus.net> Message-ID: <200704081938.44152.nicolas.weeger@laposte.net> > Recently certain operations are giving weird 403 Forbidden errors on > svn.sourceforge.net, not only for Crossfire from what I hear. A way > around it was added (but still undocumented, unless you count an sf.net > admin comment in their issue tracker), which is to use > projectname.svn.sourceforge.net instead of svn.sourceforge.net. To > miagrate your checkout to it use this command: I also just noted: when merging from trunk to branch, added files can't be added. So need to copy from trunk and manually add - there it works... Weird :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Tue Apr 10 13:33:21 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 10 Apr 2007 20:33:21 +0200 Subject: [crossfire] Getting more artists Message-ID: <200704102033.21084.nicolas.weeger@laposte.net> Hello. I'd like to put some messages on graphism-related forums, to call for some help for graphisms - which do need some work imo :) Of course I won't post anywhere, just on relevant forums or subsections of forums. To be honest, I'd like to give the more accurate description of the project, including its shortcomings or what can be seen as a weeknesses: * we aren't many developers or mapmakers (number varies, of course) * sometimes no one replies to questions asked, or it can take some (3+) days/weeks * player base is pretty low, ~10 players on Metalforge for instance * (insert other things you can think of here) and of course the basic information: * what is Crossfire * GPL code and graphics and what not * more than 10 years of development, so long-time project (it shouldn't die soon) * 32x32 base sprites, can be multitiled * and other things we can think of What do you think? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Tue Apr 10 13:55:45 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 10 Apr 2007 20:55:45 +0200 Subject: [crossfire] Undead flag Message-ID: <200704102055.45779.nicolas.weeger@laposte.net> Hello. Concerning feature request https://sourceforge.net/tracker/index.php?func=detail&aid=985488&group_id=13833&atid=363833 I'm wondering if this isn't the case already? AFAIK, undead dragons and such recover when leaving Devourers. Or am I mistaking? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Tue Apr 10 21:36:48 2007 From: mwedel at sonic.net (mwedel at sonic.net) Date: Tue, 10 Apr 2007 19:36:48 -0700 (PDT) Subject: [crossfire] Getting more artists In-Reply-To: <200704102033.21084.nicolas.weeger@laposte.net> References: <200704102033.21084.nicolas.weeger@laposte.net> Message-ID: <13603.65.15.174.120.1176259008.squirrel@webmail.sonic.net> > To be honest, I'd like to give the more accurate description of the > project, > including its shortcomings or what can be seen as a weeknesses: > * we aren't many developers or mapmakers (number varies, of course) > * sometimes no one replies to questions asked, or it can take some (3+) > days/weeks I'd probably say that needs to be clarified. The difference between 3 days and 3 weeks is pretty big. I'd probably say that in general, most questions will be answered within a few days. Certainly, some times people are on vacation, etc, but to me, it seems that it is a rare occurence that something that hasn't been discussed for several weeks is responded to. And most often, this is the case when someone that has been on vacation, etc, comes back and wants to respond, which is different than basic developer questions, which tend to be answered within a week. Might also want to mention the irc channel, as another place for support/asking questions. > * player base is pretty low, ~10 players on Metalforge for instance > * (insert other things you can think of here) I might try to avoid specific numbers. Number we know about on specific public servers is relatively low, and we don't really know how many people play on private servers. So you might want to leave out a specific number, but instead say something like 'relative small userbase' > > and of course the basic information: > * what is Crossfire > * GPL code and graphics and what not > * more than 10 years of development, so long-time project (it shouldn't > die > soon) > * 32x32 base sprites, can be multitiled > * and other things we can think of Might want to also mention that graphics or other changes are likely to be incorporated relatively quickly, which may be a plus. Should probably make it clear that any contributed graphics must be under GPL. Note that given GPL rules, we could probably go hunting for graphics that are already under GPL and incorporate them into crossfire. From antonoussik at gmail.com Wed Apr 11 04:53:44 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Wed, 11 Apr 2007 10:53:44 +0100 Subject: [crossfire] Undead flag In-Reply-To: <200704102055.45779.nicolas.weeger@laposte.net> References: <200704102055.45779.nicolas.weeger@laposte.net> Message-ID: On 10/04/07, Nicolas Weeger wrote: > AFAIK, undead dragons and such recover when leaving Devourers. > Or am I mistaking? Yes, but when the dragons are undead, they are no longer dragons, they are just undead. This means any dragon-specific checks will fail on them, such as access to the dragons guild to change focus. From antonoussik at gmail.com Wed Apr 11 05:00:45 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Wed, 11 Apr 2007 11:00:45 +0100 Subject: [crossfire] Getting more artists In-Reply-To: <13603.65.15.174.120.1176259008.squirrel@webmail.sonic.net> References: <200704102033.21084.nicolas.weeger@laposte.net> <13603.65.15.174.120.1176259008.squirrel@webmail.sonic.net> Message-ID: On 11/04/07, mwedel at sonic.net wrote: > Note that given GPL rules, we could probably go hunting for graphics that > are already under GPL and incorporate them into crossfire. I have thought about this before, and it will not really work, as you want a complete matching tileset if possible, otherwise you end up with a strange mixture of styles, which looks messy. If we could attract an artist (or 5 or 6) who would be willing to create 3D models of things, animate them, and then produce a complete tileset of the universe from those, it would be ideal. From subs at eracc.com Wed Apr 11 10:07:11 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Wed, 11 Apr 2007 10:07:11 -0500 Subject: [crossfire] Getting more artists In-Reply-To: References: <200704102033.21084.nicolas.weeger@laposte.net> <13603.65.15.174.120.1176259008.squirrel@webmail.sonic.net> Message-ID: <200704111007.13024.subs@eracc.com> On Wednesday 11 April 2007 05:00 am Anton Oussik wrote: > If we could attract an artist (or 5 or 6) who would be willing to > create 3D models of things, animate them, and then produce a complete > tileset of the universe from those, it would be ideal. Call me crazy if you wish. :-p I prefer the 2D version we have now. Granted we could always use more and better 2D graphics. But 3D and animation then locks out a lot of marginal graphics makers (like me for example) that could "make do" with the 2D tiles. Once we go 3D we would *have to* have some 3D artists on board the project to go forward. The problem with that is good 3D graphics folks are not easy to find and keep. The really good ones are probably working only on closed source projects for a salary. I say this based on the lack of excellent 3D graphics in the open source projects I have seen. I am willing to be proven wrong though. ;-) But I still would prefer we keep Crossfire a 2D game. Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From leaf at real-time.com Wed Apr 11 11:39:55 2007 From: leaf at real-time.com (Rick Tanner) Date: Wed, 11 Apr 2007 11:39:55 -0500 Subject: [crossfire] Undead flag In-Reply-To: <200704102055.45779.nicolas.weeger@laposte.net> References: <200704102055.45779.nicolas.weeger@laposte.net> Message-ID: <461D0F5B.3040204@real-time.com> > Concerning feature request > https://sourceforge.net/tracker/index.php?func=detail&aid=985488&group_id=13833&atid=363833 > > I'm wondering if this isn't the case already? > > AFAIK, undead dragons and such recover when leaving Devourers. Correct, this was fixed in bug# 1157459 https://sourceforge.net/tracker/index.php?func=detail&aid=1157459&group_id=13833&atid=113833 While following Devourers == player is undead; Leave Devourers for another cult == return to your normal race The exception is Wraiths, they are always undead. It would appear that the feature request can be closed as it has been implemented. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070411/b716fa0e/attachment.pgp From leaf at real-time.com Wed Apr 11 11:52:31 2007 From: leaf at real-time.com (Rick Tanner) Date: Wed, 11 Apr 2007 11:52:31 -0500 Subject: [crossfire] Getting more artists In-Reply-To: <200704102033.21084.nicolas.weeger@laposte.net> References: <200704102033.21084.nicolas.weeger@laposte.net> Message-ID: <461D124F.1090706@real-time.com> Common questions that seem to come up in regards to new graphics: * Color count or color palette information * What exactly is the "Crossfire Perspective" on graphics and how that can be replicated or duplicated; the psuedo isometric and not quite top-down perspective on graphics * Animation of graphics and howto animate them and name the necessary files for proper animation * How to easily test new graphics via local server or client * The 32x32 base size vs why not something larger? That's all I can think of right now. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070411/3e11df8c/attachment-0001.pgp From antonoussik at gmail.com Wed Apr 11 14:15:18 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Wed, 11 Apr 2007 20:15:18 +0100 Subject: [crossfire] Getting more artists In-Reply-To: <200704111007.13024.subs@eracc.com> References: <200704102033.21084.nicolas.weeger@laposte.net> <13603.65.15.174.120.1176259008.squirrel@webmail.sonic.net> <200704111007.13024.subs@eracc.com> Message-ID: On 11/04/07, ERACC Subscriptions wrote: > On Wednesday 11 April 2007 05:00 am > Anton Oussik wrote: > > > If we could attract an artist (or 5 or 6) who would be willing to > > create 3D models of things, animate them, and then produce a complete > > tileset of the universe from those, it would be ideal. > > Call me crazy if you wish. :-p I prefer the 2D version we have now. Granted we > could always use more and better 2D graphics. But 3D and animation then locks > out a lot of marginal graphics makers (like me for example) that could "make > do" with the 2D tiles. Once we go 3D we would *have to* have some 3D artists > on board the project to go forward. 2D reduces portability and ability to animate graphics. For example, if someone creates an animation of a running orc, and someone else creates an animation of an orc swinging an axe, given the models, some 3rd person can easily add an animation of an orc firing an arrow. Generating everything from a different perspective or of a different resolution can then also be automated, and colours can be easily be adjusted over all frames featuring the same model. A talented 3D artist should be able to get more work done, and be able to keep the work easy to change better than several 2D artists might. As a bonus, same models can be used to make CF truly 3D some day, instead of 3D-rendered snapshots as currently proposed. Since I think some day within the next 10-15 years CF needs to make a transition to 3D to stay current, this would be a natural evolving route to take. > The problem with that is good 3D graphics folks are not easy to find and keep. That is true, and there are good chances that none will be attracted. > The really good ones are probably working only on closed source projects for > a salary. I say this based on the lack of excellent 3D graphics in the open > source projects I have seen. I am willing to be proven wrong though. ;-) But > I still would prefer we keep Crossfire a 2D game. 3D-rendered tileset can be provided as alternative to the 2D one, and even after transition to full 3D if the game is still tile-based there is no reason current tileset can not be used in 2D mode. From fuchs.andy at gmail.com Wed Apr 11 15:08:39 2007 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Wed, 11 Apr 2007 16:08:39 -0400 Subject: [crossfire] Getting more artists In-Reply-To: References: <200704102033.21084.nicolas.weeger@laposte.net> <13603.65.15.174.120.1176259008.squirrel@webmail.sonic.net> <200704111007.13024.subs@eracc.com> Message-ID: <1176322120.4827.10.camel@pluto> On Wed, 2007-04-11 at 20:15 +0100, Anton Oussik wrote: > On 11/04/07, ERACC Subscriptions wrote: > > On Wednesday 11 April 2007 05:00 am > > Anton Oussik wrote: > > > > > If we could attract an artist (or 5 or 6) who would be willing to > > > create 3D models of things, animate them, and then produce a complete > > > tileset of the universe from those, it would be ideal. > > > > Call me crazy if you wish. :-p I prefer the 2D version we have now. Granted we > > could always use more and better 2D graphics. But 3D and animation then locks > > out a lot of marginal graphics makers (like me for example) that could "make > > do" with the 2D tiles. Once we go 3D we would *have to* have some 3D artists > > on board the project to go forward. > > 2D reduces portability and ability to animate graphics. For example, > if someone creates an animation of a running orc, and someone else > creates an animation of an orc swinging an axe, given the models, some > 3rd person can easily add an animation of an orc firing an arrow. > Generating everything from a different perspective or of a different > resolution can then also be automated, and colours can be easily be > adjusted over all frames featuring the same model. A talented 3D > artist should be able to get more work done, and be able to keep the > work easy to change better than several 2D artists might. As a bonus, > same models can be used to make CF truly 3D some day, instead of > 3D-rendered snapshots as currently proposed. Since I think some day > within the next 10-15 years CF needs to make a transition to 3D to > stay current, this would be a natural evolving route to take. Agreed. These two, are the only advantages that I see for going with 3D models. Also, as noted in one of Rick Tanner's emails, we would need to create standards to ensure that all the graphics fit together. This is especially true since we are using pre-rendered tiles. > > The problem with that is good 3D graphics folks are not easy to find and keep. > > That is true, and there are good chances that none will be attracted. I might be able to do some work, though I probably won't have much time to do so. > > The really good ones are probably working only on closed source projects for > > a salary. I say this based on the lack of excellent 3D graphics in the open > > source projects I have seen. I am willing to be proven wrong though. ;-) But > > I still would prefer we keep Crossfire a 2D game. ... As for finding artists, there are a lot of people who do 3d work as a hobby. Although I don't have a clue about what they do for their normal work. From fuchs.andy at gmail.com Wed Apr 11 15:27:13 2007 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Wed, 11 Apr 2007 16:27:13 -0400 Subject: [crossfire] Graphics Standards (was Re: Getting more artists) In-Reply-To: <461D124F.1090706@real-time.com> References: <200704102033.21084.nicolas.weeger@laposte.net> <461D124F.1090706@real-time.com> Message-ID: <1176323234.4827.28.camel@pluto> The 2d graphics as they are now, seem to use a mix of standards. On Wed, 2007-04-11 at 11:52 -0500, Rick Tanner wrote: > Common questions that seem to come up in regards to new graphics: > > * Color count or color palette information > > * What exactly is the "Crossfire Perspective" on graphics and how that > can be replicated or duplicated; the psuedo isometric and not quite > top-down perspective on graphics IIRC, something going straight up in real life, is drawn 1 unit left for every 2 units up. There are no vanishing points, so lines along an objects width and depth are straight. If we are going to move to a 2d tileset generated from 3d sources, a standard template for everything to be placed into before its rendered would be useful. Also, the issue of how multipart images will be rendered comes up. > * Animation of graphics and howto animate them and name the necessary > files for proper animation Best to look at how everything is now. IIRC, for mobiles we probably will have a few frames of a standard movement animation for each, with the object rotated for each view (every 45 degrees). > * How to easily test new graphics via local server or client How the tiles render? We would have to make sure that everyone has the same renderer, and the template. Or actually placing them into the game? For that, look at how everyone does it now. > * The 32x32 base size vs why not something larger? Well, if everything is done in 3d, it would be easy to change the size of the tiles later. From leaf at real-time.com Wed Apr 11 15:44:50 2007 From: leaf at real-time.com (Rick Tanner) Date: Wed, 11 Apr 2007 15:44:50 -0500 Subject: [crossfire] Graphics Standards (was Re: Getting more artists) In-Reply-To: <1176323234.4827.28.camel@pluto> References: <200704102033.21084.nicolas.weeger@laposte.net> <461D124F.1090706@real-time.com> <1176323234.4827.28.camel@pluto> Message-ID: <461D48C2.6030602@real-time.com> >> * How to easily test new graphics via local server or client > > How the tiles render? We would have to make sure that everyone has the > same renderer, and the template. Or actually placing them into the > game? For that, look at how everyone does it now. How the artist or tester could view their new graphic within the game|client -- for testing purposes, screen shot samples, et al. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070411/9c971747/attachment.pgp From alex_sch at telus.net Wed Apr 11 17:29:36 2007 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 11 Apr 2007 16:29:36 -0600 Subject: [crossfire] Getting more artists In-Reply-To: <200704111007.13024.subs@eracc.com> References: <200704102033.21084.nicolas.weeger@laposte.net> <13603.65.15.174.120.1176259008.squirrel@webmail.sonic.net> <200704111007.13024.subs@eracc.com> Message-ID: <461D6150.4020402@telus.net> ERACC Subscriptions wrote: > On Wednesday 11 April 2007 05:00 am > Anton Oussik wrote: > > >> If we could attract an artist (or 5 or 6) who would be willing to >> create 3D models of things, animate them, and then produce a complete >> tileset of the universe from those, it would be ideal. >> > > Call me crazy if you wish. :-p I prefer the 2D version we have now. Granted we > could always use more and better 2D graphics. But 3D and animation then locks > out a lot of marginal graphics makers (like me for example) that could "make > do" with the 2D tiles. Once we go 3D we would *have to* have some 3D artists > on board the project to go forward. > > The problem with that is good 3D graphics folks are not easy to find and keep. > The really good ones are probably working only on closed source projects for > a salary. I say this based on the lack of excellent 3D graphics in the open > source projects I have seen. I am willing to be proven wrong though. ;-) But > I still would prefer we keep Crossfire a 2D game. Agreed that we should keep it to 2D based graphics, UNLESS we can find rendering settings/methods (or write code :)) that can allow a 3D renderer to generate graphics that match "CF style" such that 3D and 2D graphics could be seamlessly used at once. If one is discussing redoing graphics however, I believe we may want to change the perspective the graphics are using anyways. I believe that the current "psudo-isometric"ish look is a style that is not easy to do in 2d and is similarly not the easiest to replicate in 3D generally. I believe that whether 2D or 3D, if we are to redo a large amount of graphics anyways, it would be beneficial to switch to a perspective that is easier to use. I propose that it would be good to switch to a perspective where "tall" things are not skewed to the side and just appear directly vertical, but not directly top view, just tilted slightly so you can see the fronts of things. Basically I propose that if we are redoing a significant amount of graphics, we should get rid of the "horizontal skew" because that changes it to a perspective both more familiar to 2D artists and easier to replicate in 3D. Alex Schultz From antonoussik at gmail.com Wed Apr 11 19:16:17 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Thu, 12 Apr 2007 01:16:17 +0100 Subject: [crossfire] Getting more artists In-Reply-To: <461D6150.4020402@telus.net> References: <200704102033.21084.nicolas.weeger@laposte.net> <13603.65.15.174.120.1176259008.squirrel@webmail.sonic.net> <200704111007.13024.subs@eracc.com> <461D6150.4020402@telus.net> Message-ID: At the end of the day this would be mostly up the the artist(s) contributing art. There seems to be an agreement of 2D vs 3D, so now someone able and willing to contribute needs to be found. From nicolas.weeger at laposte.net Thu Apr 12 13:30:34 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 12 Apr 2007 20:30:34 +0200 Subject: [crossfire] Game balance: potion of life, healing, cure disease Message-ID: <200704122030.34934.nicolas.weeger@laposte.net> Hello. Having just started a new character, I think potions of life / healing / cure disease should be way less expensive than they are now. My level 8 character died a lot (ok, Navar is a bad starting place). I have ~50 plat, potions of life cost ~2500, others are probably the same. IMO, those potions should be easily findable (ie monsters drop more, or you can find them in shops), and cost like 20 or 30 platinum. When you're higher level, and start having money, you just don't need potions - you pray at your god's altar when you die or use your own spells to protect yourself, you got enough platinum to buy in shops, and so on. Just my 2 cents ;) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From lalo.martins at gmail.com Thu Apr 12 16:04:43 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 12 Apr 2007 21:04:43 +0000 (UTC) Subject: [crossfire] Game balance: potion of life, healing, cure disease References: <200704122030.34934.nicolas.weeger@laposte.net> Message-ID: On Thu, 12 Apr 2007 20:30:34 +0200, Nicolas Weeger wrote: > Hello. > > Having just started a new character, I think potions of life / healing / cure > disease should be way less expensive than they are now. > > My level 8 character died a lot (ok, Navar is a bad starting place). I have > ~50 plat, potions of life cost ~2500, others are probably the same. > > IMO, those potions should be easily findable (ie monsters drop more, or you > can find them in shops), and cost like 20 or 30 platinum. > > When you're higher level, and start having money, you just don't need > potions - you pray at your god's altar when you die or use your own spells to > protect yourself, you got enough platinum to buy in shops, and so on. maybe the reason they're expensive is the fear that level 10-30 chars will buy all they can find, leaving none for the real beginners to find? One possible solution for this is to have a "restoration service", probably on the house of healing in Scorn 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 nicolas.weeger at laposte.net Thu Apr 12 16:28:12 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 12 Apr 2007 23:28:12 +0200 Subject: [crossfire] Game balance: potion of life, healing, cure disease In-Reply-To: References: <200704122030.34934.nicolas.weeger@laposte.net> Message-ID: <200704122328.12906.nicolas.weeger@laposte.net> > maybe the reason they're expensive is the fear that level 10-30 chars will > buy all they can find, leaving none for the real beginners to find? But then if they are expensive only high level players can buy them :) > One possible solution for this is to have a "restoration service", probably > on the house of healing in Scorn Need to have such services everywhere, then - not everyone starts in Scorn! ^_- Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Thu Apr 12 21:16:07 2007 From: mwedel at sonic.net (mwedel at sonic.net) Date: Thu, 12 Apr 2007 19:16:07 -0700 (PDT) Subject: [crossfire] Game balance: potion of life, healing, cure disease In-Reply-To: <200704122328.12906.nicolas.weeger@laposte.net> References: <200704122030.34934.nicolas.weeger@laposte.net> <200704122328.12906.nicolas.weeger@laposte.net> Message-ID: <4813.70.147.193.98.1176430567.squirrel@webmail.sonic.net> One issue to perhaps better look at is what is the desired penalty for death. If potions of life become relatively cheap or easy to come buy, then the stat depletion on death actually is fairly meaningless, and we might as well just remove that. I think there are already some things in the settings file that relate to that - I don't know if there is a way right now to just completely turn stat loss off. An interesting thought would be to have different level potions, just like different level wands and scrolls. When a player dies, IIRC, right now the depletion force for the stat is inserted into them. It would be simple enough to record the level of the character when that force was inserted. Then, a simple check that the level of the potion (or scroll or other device, since it is a spell IIRC) is higher, it removes all those depletions, if not, it doesn't. In this way, you could have 'wimpy' potions of life that go up to maybe level 5, and are relatively cheap, and better ones that go up and up. I do think that instead of the current method used for wands/scrolls, it would be better to make archetypes of these so they can be put in appropriate treasure lists, and the costs of them controlled. Maybe the 'supreme potions of life', which is unlimited level, cost 50,000 pp or something. From mwedel at sonic.net Thu Apr 12 21:34:38 2007 From: mwedel at sonic.net (mwedel at sonic.net) Date: Thu, 12 Apr 2007 19:34:38 -0700 (PDT) Subject: [crossfire] Getting more artists In-Reply-To: <461D124F.1090706@real-time.com> References: <200704102033.21084.nicolas.weeger@laposte.net> <461D124F.1090706@real-time.com> Message-ID: <5629.70.147.193.98.1176431678.squirrel@webmail.sonic.net> > > Common questions that seem to come up in regards to new graphics: > > * Color count or color palette information Now days, it is really unlimited. We are not doing any tricky palette information. At one point in the distant past, we had a limited set of colors, simply because back in the day, most people only had 8 bit displays. Now days, 8 bit displays would be rare, but even then, the client will do its own color matching - not great, but should work. > > * What exactly is the "Crossfire Perspective" on graphics and how that > can be replicated or duplicated; the psuedo isometric and not quite > top-down perspective on graphics Yes - that needs to be sorted out. In the wishful thinking department, you'd almost want 3 image sets: 1) True flat - don't try to force a perspective on the monsters. This doesn't look as pretty, but is perhaps simpler to do and is more consistent related to other objects. Question in this case is where you try to force perspective on other things, like buildings. To some extent, the classic image set falls into this category. 2) Proper isometric - sort of where some of the things are now. However, in this mode, things should actually be drawn in an isomorphic perspective, and not on the flat view we currently have. IIRC, for opengl, this is easy - just a simple call someplace to change the view perspective - however, images and everything else is needed for it - some could perhaps be taken from daimonin. This isn't a view I really like, but seems popular. 3) 3d models. I'd think these could be rendered in either 2d or isomorphic, depending on perspective used for rendering. May even be able to do true 3d, but IMO that changes things a lot (the game is designed a lot right now in that you will see everything around you - a 3d games really is designed to give a front view). But questions for this is what modeling language is used to store that 3d data. I'd also think that for it to really be useful, the client would need to do the drawing of the models itself. IIRC, there are currently a few 3d models in place, but these are used to generate static images. That works, but can be trickier to deal with. OTOH, some of this depends on other changes. If for example, the idea is to used 3d models for animation (these points move in this method), animation logic on the client probably needs a bit of changes, etc. > > * Animation of graphics and howto animate them and name the necessary > files for proper animation I thought that is documented someplace. > > * How to easily test new graphics via local server or client The ideal case would be for the editor to do it somehow, but that is trickier. This could be documented fairly easily, but does require person to have local server. this isn't that tricky on unix side, but I don't know if it is easy for users to collect images/archetypes on windows or other platforms. > > * The 32x32 base size vs why not something larger? I know some developers have stated that current image sizes are too small. We could certainly do something larger - doing 64x64 for base size is simple enough, and a quick resize of all images into a 'large' imageset could easily enough be done. The problem here is really that there is now 2 image sets to maintain. OTOH, I'd think that in most case, if things were drawn for the larger size and scaled down, it might work OK. 64x64 may be too large a size however, and 48x48 may be a better middle ground, but more discussion would be needed on that. From elmex at ta-sa.org Fri Apr 13 11:41:56 2007 From: elmex at ta-sa.org (Robin Redeker) Date: Fri, 13 Apr 2007 18:41:56 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver Message-ID: <20070413164156.GA9256@elmex> Hi! Some time ago we heard on the irc channel (some month/weeks ago) that some users find the '+' suffix of the crossfire+ servers confusing. Now that we removed it, it seems to be even more confusing (as far as gros or others on the IRC channel are concerned). So, now the question: What version should we send to the metaserver? What would you like most? 'CF+' would be an alternative that would distinguish the crossfire+/crossfire2 servers from others. We would also be fine with '++', it would also sign nicely that our codebase is C++. Or also the old '+' scheme is fine with us. ('cf++-perl' would be a bit too cumbersome IMO :-) Maybe in the long run a column that has the header 'Gamebase' or 'Codebase' on the metaserver would distinguish server types best. Also w.r.t. to our project name that we lateley changed to 'Crossfire2': What should we name us? What would you like most? We would be fine with going back to 'Crossfire+', but we changed it in the first place in response to the discussions on #crossfire. It would help to have an official position from you. Also, an official decision on what 'Crossfire' is and what not would be nice. Not long ago in the decision about the metaserver w.r.t to the playercounts and misinformation it was decided that 'Crossfire' is what speaks the protocol. Greetings, Robin From alex_sch at telus.net Fri Apr 13 16:31:57 2007 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 13 Apr 2007 15:31:57 -0600 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <20070413164156.GA9256@elmex> References: <20070413164156.GA9256@elmex> Message-ID: <461FF6CD.2070508@telus.net> Robin Redeker wrote: > Hi! > > Some time ago we heard on the irc channel (some month/weeks ago) that > some users find the '+' suffix of the crossfire+ servers confusing. > > Now that we removed it, it seems to be even more confusing (as far as > gros or others on the IRC channel are concerned). > Indeed, I would agree that both ways are quite confusing and without the "+" perhaps moreso. > So, now the question: What version should we send to the metaserver? > What would you like most? 'CF+' would be an alternative that would > distinguish the crossfire+/crossfire2 servers from others. > We would also be fine with '++', it would also sign nicely that > our codebase is C++. Or also the old '+' scheme is fine with us. > ('cf++-perl' would be a bit too cumbersome IMO :-) > Similar to what I talk about a few paragraphs below, '++' I feel would imply too much that it's a 'successor project' (which it isn't by my definition) as opposed to a fork. I do agree though that 'cf++-perl' would be cumbersome, however at least it does not imply incorrect things that appending a "++" would. IMHO there is no good solution with the version column as is and a single metaserver, and thus solutions as you mention below or a separate metaserver would be best in my opinion. > Maybe in the long run a column that has the header 'Gamebase' or > 'Codebase' on the metaserver would distinguish server types best. > Given the nature of things lately, it would seem that either a column for such would be necessary, OR that separate metaservers be used for separate servers running with each codebase. Another thought, somewhat off topic from this thread, is it would also probably be a good idea for the metaserver to contain the "protocol version" that is in the protocol. This hasn't been used much lately, in favor of setup flags, however in Crossfire 2.0 we plan to remove compatibility for really old protocol mechanisms and that would mean it would be best to remove some 'setup' flags and increment the "protocol version". In a few discussions on such there's been a consensus that between major version we'd increment the "protocol version" while within a given major release number, we'd add setup flags, however this is not an official decision. Relating back to the topic of this thread, how will the protocol's builtin "protocol version" number be handled in light of forks such as "CF+"? > Also w.r.t. to our project name that we lateley changed to 'Crossfire2': > What should we name us? What would you like most? We would be fine with > going back to 'Crossfire+', but we changed it in the first place in > response to the discussions on #crossfire. > It would help to have an official position from you. > I feel that Crossfire2 is even worse personally. Firstly that would imply that it's a 'successor project' as opposed to a fork ("Crossfire+" was a little bad in terms of that too IMHO, but not as bad as "Crossfire2"). To me, the naming of the fork implying that it is a successor project is one of the most annoying (and potentially confusing) part about it. Secondly, over on this side, we are intending on having a Crossfire 2.0, this it probably at least a year away from being released probably, however a fork named Crossfire2 would be extremely confusing once Crossfire 2.0 is released. Note, this is not an official position as I am one member of the project, however "Crossfire2" vs. "Crossfire 2.0" confusion is certainly an issue, and I have a feeling that many of us on this side feel some agitation at how "CF+" tends to present itself as if it was a 'successor project' as opposed to a fork. (Quick note: I define a true "successor project" as a project that is an official successor where the original is generally dead and the developers have moved over.) Alex Schultz From elmex at x-paste.de Fri Apr 13 05:54:46 2007 From: elmex at x-paste.de (Robin Redeker) Date: Fri, 13 Apr 2007 12:54:46 +0200 Subject: [crossfire] Getting more artists In-Reply-To: <5629.70.147.193.98.1176431678.squirrel@webmail.sonic.net> References: <200704102033.21084.nicolas.weeger@laposte.net> <461D124F.1090706@real-time.com> <5629.70.147.193.98.1176431678.squirrel@webmail.sonic.net> Message-ID: <20070413105446.GA8732@elmex> On Thu, Apr 12, 2007 at 07:34:38PM -0700, mwedel at sonic.net wrote: > IIRC, there are currently a few 3d models in place, but these are used to > generate static images. That works, but can be trickier to deal with. Just FYI: I've lately checked in all the 3D models we use to render our (now 64x64) tileset: http://cvs.schmorp.de/cf.schmorp.de/arch3d/ All of them come with a yafray xml file (and a .cfg file for the cfxmlrender script that comes with the Crossfire perl module. the cfg file says what the output filename should be, where in the arch tree it belongs and the size and direction from which to render the face). And most of them come with a blender scene file or at least a wings model file (I'm working on exporting all of them to blender files, as I prefer blender these days for it's animation capabilites). With regard to the perspective: cfxmlrender adjusts the model in the file on the fly before setting up an orthogonal camera. Basically it goes like this: for 4 units height go one unit to the right and two units up. It basically applies this transformation matrix to the yafray scene: 1 0 0 0.25 0 0 1 0 0.5 0 0 0 1 0 0 0 0 0 0 1 > > * Animation of graphics and howto animate them and name the necessary > > files for proper animation We currently animate the models in the modeller and write out a yafray file for each frame. Integrating a bone-animation framework alogn with real 3d rendering in the client would be very nice, but thats really really a lot of work and unneccessary at the moment. > > * The 32x32 base size vs why not something larger? > > I know some developers have stated that current image sizes are too > small. We could certainly do something larger - doing 64x64 for base > size is simple enough, and a quick resize of all images into a 'large' > imageset could easily enough be done. The problem here is really that > there is now 2 image sets to maintain. OTOH, I'd think that in most > case, if things were drawn for the larger size and scaled down, it might > work OK. We've recently changed to 64x64 tiles (see also the latest screenshots on http://cf.schmorp.de/screenshots.shtml ). We have a script that processes our arch/ tree before generating the face and archetype files from it. It looks whether there is a 64x64 version of the tile and if there is no 32x32 version it scales it down. Scaling down rendered tiles looks nicely. And if there is only a 32x32 tile version, it is scaled up to 64x64 with a derivation of the hq2x algorithm (see also http://www.hiend3d.com/hq2x.html and for the hq2x implementation here: http://cvs.schmorp.de/cf.schmorp.de/server/utils/ ) The technical problems that come with 64x64 were for us for example the 10kb facesize limit. First we tried to send gcfclient bigfaces for everything, but that didn't work well due some weird restrictions in the client. We were also bitten by other limitations, eg. the fixed upper limit of the number of faces in gcfclient. In the end we now provide 32x32 tiles for gcfclient and the 64x64 tiles to cfplus. Schmorp also extended the protocol to be able to send images larger than 10kb (afaik it does transfers them in multiple pieces). (I currently don't know more details on the implementation, as it was done by schmorp). > 64x64 may be too large a size however, and 48x48 may be a better middle > ground, but more discussion would be needed on that. Well, 64x64 offers a lot more pixels for details, which really boost the immersiveness of the game IMO. Having so large tiles also makes it possible to make some things smaller than others (eg. making the booze not as big as a player character). Greetings, Robin From yann.chachkoff at myrealbox.com Fri Apr 13 17:27:15 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat, 14 Apr 2007 00:27:15 +0200 Subject: [crossfire] Getting more artists Message-ID: <1176503235.c7cf017cyann.chachkoff@myrealbox.com> About the tiles size: I do believe that having the feeling of game objects being bigger on the screen makes the whole gaming experience more immersive. I've made tests with 32x32 tiles enlarged to 64x64 on the fly, and the feeling was really different, not looking anymore like a "stamp-sized" game. Now, I would not suggest using 64x64 as a new size for tiles. Instead, keep the base tile as 32x32, and enlarge various objects, so that they take more than a single tile. Why ? Because having a base tile (32x32) that is smaller than the default tile (64x64) allows you to make more complex shapes - for example, L-shaped tiles. I guess that at some point, the way graphics are transmitted and displayed should also be revised, to allow proper pictures overlapping. Just my 2 (Euro)cents :) From yann.chachkoff at myrealbox.com Fri Apr 13 16:52:56 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Fri, 13 Apr 2007 23:52:56 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver Message-ID: <1176501176.c7cf017cyann.chachkoff@myrealbox.com> >Some time ago we heard on the irc channel (some month/weeks ago) that some users find the '+' suffix of the crossfire+ servers confusing. > Now that we removed it, it seems to be even more confusing (as far as gros or others on the IRC channel are concerned). > Let's be clear: people found it confusing in the first place because it was not obvious enough that the software was different. People thought that 2.0+ was the version following the 1.9 one. It seems somewhat obvious to me that even if the '+' was not giving enough clues about the difference, removing it only made the problem worse. I believe distinguishing both projects is important - after all, they are two different projects, with different goals and ways to achieve them. > So, now the question: What version should we send to the metaserver? > In the short term, I'd say that having a marker that clearly says: "this is CF+" would suffice. Hence, I think that "CF+' is not a bad idea - it is short, yet clearly shows this is a CF+ server. On the long term, I think having a "Gamebase" column would be a good thing for sure. > Also w.r.t. to our project name that we lateley changed to 'Crossfire2': > What should we name us? What would you like most? We would be fine with > going back to 'Crossfire+', but we changed it in the first place in > response to the discussions on #crossfire. > It would help to have an official position from you. > I'm not an "official". But I think that "Crossfire2" is not a good choice, as it gives the impression that it is the next version of the original Crossfire game. Probably a more distinctive name would be a better choice for both sides - it would solve the issue of confusing both projects, and would also allow CF+ to get a more independent "self-identity" feel. >Also, an official decision on what 'Crossfire' is and what not would be >nice. Not long ago in the decision about the metaserver w.r.t to the >playercounts and misinformation it was decided that 'Crossfire' is what >speaks the protocol. > (Again, I'm not an "official representative", so I speak only in my name here). I think there is a misunderstanding there, or more exactly a mix between the "protocol standard" and the "server software". Any server that "talks" the same protocol as the original Crossfire is indeed "Crossfire-compatible", and should probably go into the metaserver lists. Yet speaking the same language does not make the server software the same. The code is sufficiently different between CF and CF+ to clearly point them as different. I understand the will of CF+ to clearly mark its common roots with Crossfire; however, I believe that giving your project its own name would be a good idea, for the sake of clarity, and maybe for the "cultural identity" of both :). From mwedel at sonic.net Fri Apr 13 22:09:19 2007 From: mwedel at sonic.net (mwedel at sonic.net) Date: Fri, 13 Apr 2007 20:09:19 -0700 (PDT) Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <20070413164156.GA9256@elmex> References: <20070413164156.GA9256@elmex> Message-ID: <12126.74.223.6.98.1176520159.squirrel@webmail.sonic.net> My quick thougths on this: Crossfire+/crossfire2/schmorp should really come up with its own unique name for the project, just as daimonin did when it split off. Calling it most anything with crossfire in its name is confusing. crossfire+ isn't great, as isn't really clear what it is. crossfire2 is even worse. If you look at a lot of packaging for linux, often packages are often called with their version names some multiple versions can be installed at the same time (gtk and gtk2 being such examples). Under a crossfire2 name, any rpms are sure to cause confusion. I can't think of any good reason why cf+ shouldn't change to a different name. Now certainly the metaserver probably should store more information. And there is certainly a longer run question of what all information should it store - isn't really my goal to address that here. I would say that as long as the server is protocol compatible, it could perhaps be listed. But I'd probably have this as the list of rules: 1) Information it reports must be honest (player count, version, etc) 2) The standard crossfire client must be able to play on any listed servers. If a server has branched so that the standard crossfire client can not play on that server due to various incompatiblities, it should not be listed. 3) Any client that gets metaserver data must be able to play on the standard crossfire server. That is to say that if you write your own client that isn't compatible in some way, it should not present invalid choices to the player (if it has a good way to filter them, I suppose that is OK then). 4) Any servers should be free and open, that is to say, not pay for use/play. I think there is another that I'm forgetting right now. From elmex at ta-sa.org Sat Apr 14 04:50:47 2007 From: elmex at ta-sa.org (Robin Redeker) Date: Sat, 14 Apr 2007 11:50:47 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <12126.74.223.6.98.1176520159.squirrel@webmail.sonic.net> References: <20070413164156.GA9256@elmex> <12126.74.223.6.98.1176520159.squirrel@webmail.sonic.net> Message-ID: <20070414095047.GA11921@elmex> On Fri, Apr 13, 2007 at 08:09:19PM -0700, mwedel at sonic.net wrote: > > My quick thougths on this: > > Crossfire+/crossfire2/schmorp should really come up with its own unique > name for the project, just as daimonin did when it split off. The difference between Crossfire+ and Daimonin is that we currently still are protocol compatible. Aside from that only some of our maps differ and the overall gamebalance was changed (from the users view). (If gamebalance and maps are significant, then I wonder whether cat2 is Crossfire). > Calling it most anything with crossfire in its name is confusing. I don't really understand that, who finds it confusing and why? Robin From antonoussik at gmail.com Sat Apr 14 05:10:16 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Sat, 14 Apr 2007 11:10:16 +0100 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <12126.74.223.6.98.1176520159.squirrel@webmail.sonic.net> References: <20070413164156.GA9256@elmex> <12126.74.223.6.98.1176520159.squirrel@webmail.sonic.net> Message-ID: On 14/04/07, mwedel at sonic.net wrote: > 4) Any servers should be free and open, that is to say, not pay for use/play. I am not sure 4) is fair. If people have hardware and time they can donate to run a server that is one thing, but if a CF derivative ever becomes very popular and needs a farm to run on, it is likely a fee would have to be introduced to cover hardware costs, and possibly even hire full time admins/dms/mapmakers/artists. As long as the source code is released under GPL and anyone is free to set up their own server I would still consider that server "free and open", I see no problems there. The subscribers would be paying for services that accompany the game, not the game itself. When/if pay for play servers are introduced they could send pay for play information to the metaserver, thus avoiding confusion. Then again someone could also make a new tileset and their own maps, and say "do not redistribute" whilst running them on their own server, for which they could charge money. I am not sure there is anything GPL can do about that. There is also a potential issue of someone creating a compatible server/client from scratch not using any GPL code, and charging for using it. Ultimately there is very little that can be done about that as far as I can see, as any proprietary server/client could be made to pretend to be one of the free ones. From elmex at ta-sa.org Sat Apr 14 05:20:22 2007 From: elmex at ta-sa.org (Robin Redeker) Date: Sat, 14 Apr 2007 12:20:22 +0200 Subject: [crossfire] Getting more artists In-Reply-To: <20070413105446.GA8732@elmex> References: <200704102033.21084.nicolas.weeger@laposte.net> <461D124F.1090706@real-time.com> <5629.70.147.193.98.1176431678.squirrel@webmail.sonic.net> <20070413105446.GA8732@elmex> Message-ID: <20070414102022.GA12026@elmex> On Fri, Apr 13, 2007 at 12:54:46PM +0200, Robin Redeker wrote: > With regard to the perspective: cfxmlrender adjusts the model in the > file on the fly before setting up an orthogonal camera. > Basically it goes like this: > > for 4 units height go one unit to the right and two units up. > It basically applies this transformation matrix to the yafray scene: > > 1 0 0 0.25 0 > 0 1 0 0.5 0 > 0 0 1 0 0 > 0 0 0 0 1 That is of course a wrong matrix, I meant this: 1 0 0.25 0 0 1 0.5 0 0 0 1 0 0 0 0 1 Robin From yann.chachkoff at myrealbox.com Sat Apr 14 06:20:40 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat, 14 Apr 2007 13:20:40 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver Message-ID: <1176549640.c7c550dcyann.chachkoff@myrealbox.com> >> >> My quick thougths on this: >> >> Crossfire+/crossfire2/schmorp should really come up with its own unique >> name for the project, just as daimonin did when it split off. >The difference between Crossfire+ and Daimonin is that we currently >still are protocol compatible. Aside from that only some of our maps >differ and the overall gamebalance was changed (from the users view). >(If gamebalance and maps are significant, then I wonder whether cat2 is Crossfire). > Correct me if I'm wrong, but the code has changed as well, including switching parts to C++ and integrating Perl as a scripting language. That, more than the content, makes the project different IMHO. AFAIK, cat2 is still Crossfire: although some of the game content is different, the server code is basically the same. Thus, yes, that's the same application for me. >> Calling it most anything with crossfire in its name is confusing. >I don't really understand that, who finds it confusing and why? Are you joking ? "Crossfire2" presents your project as the 'next version' of Crossfire (which is still in the 1.x series). Are you so naive to believe that using the same name for both projects does not create confusion between both ? From yann.chachkoff at myrealbox.com Sat Apr 14 06:28:53 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat, 14 Apr 2007 13:28:53 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver Message-ID: <1176550133.c7c550dcyann.chachkoff@myrealbox.com> >> 4) Any servers should be free and open, that is to say, not pay for use/play. >I am not sure 4) is fair. If people have hardware and time they can >donate to run a server that is one thing, but if a CF derivative ever >becomes very popular and needs a farm to run on, it is likely a fee >would have to be introduced to cover hardware costs, and possibly even >hire full time admins/dms/mapmakers/artists. As long as the source >code is released under GPL and anyone is free to set up their own >server I would still consider that server "free and open", I see no >problems there. The subscribers would be paying for services that >accompany the game, not the game itself. When/if pay for play servers >are introduced they could send pay for play information to the >metaserver, thus avoiding confusion. >Then again someone could also make a new tileset and their own maps, >and say "do not redistribute" whilst running them on their own server, >for which they could charge money. I am not sure there is anything GPL >can do about that. I agree that it would be fair to still put servers that require a fee to play in the metaserver - it is indeed true that somebody may want to pay the server costs in that way. However, I think that any new content material (maps, graphics) should be freely redistributable as part of the Crossfire project. A server that refuses to share its content with the rest of the community should not be allowed to stay in the metaserver listing, IMHO, because it goes against the spirit of freedom that drives the project. From antonoussik at gmail.com Sat Apr 14 06:57:35 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Sat, 14 Apr 2007 12:57:35 +0100 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <1176550133.c7c550dcyann.chachkoff@myrealbox.com> References: <1176550133.c7c550dcyann.chachkoff@myrealbox.com> Message-ID: On 14/04/07, Yann Chachkoff wrote: > >Then again someone could also make a new tileset and their own maps, > >and say "do not redistribute" whilst running them on their own server, > >for which they could charge money. I am not sure there is anything GPL > >can do about that. > > However, I think that any new content material (maps, graphics) should be freely redistributable as part of the Crossfire project. A server that refuses to share its content with the rest of the community should not be allowed to stay in the metaserver listing, IMHO, because it goes against the spirit of freedom that drives the project. That is a good theory, but is quite impossible to enforce in practice, for several reasons: A) There is no way the metaserver can reliably determine the license of all the content that is on a particular server. B) There is no way a human can reliably determine the license of all the content that is on a particular server. Say, I run my own server. I make a change to the source allowing all characters of level 115 to become DMs (a silly change, but then I am not too bright). I also make a series of new maps avaliable for them, to play as DM quests, i.e. things that need DM powers to complete, but are designed to be challenging even to someone who has DM powers. I do not release the code changes. I do not release the new content. Since I run the server myself, and do not distribute it, I am not required to provide the source code for my change. Since the maps I have made are not derived work, I can license them however I like. Hence, I am able to run a CF derivative without needing to disclose any of my source or the content. However, until you have a character that reaches level 115 and becomes DM, there is no effective way of telling that my server even contains "closed" content, and so the metaserver can not be expected to handle an issue like this. From elmex at ta-sa.org Sat Apr 14 07:39:36 2007 From: elmex at ta-sa.org (Robin Redeker) Date: Sat, 14 Apr 2007 14:39:36 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <1176549640.c7c550dcyann.chachkoff@myrealbox.com> References: <1176549640.c7c550dcyann.chachkoff@myrealbox.com> Message-ID: <20070414123935.GA13365@elmex> On Sat, Apr 14, 2007 at 01:20:40PM +0200, Yann Chachkoff wrote: > >> > >> My quick thougths on this: > >> > >> Crossfire+/crossfire2/schmorp should really come up with its own > >> unique name for the project, just as daimonin did when it split > >> off. > > >The difference between Crossfire+ and Daimonin is that we currently > >still are protocol compatible. Aside from that only some of our maps > >differ and the overall gamebalance was changed (from the users view). > >(If gamebalance and maps are significant, then I wonder whether cat2 > >is Crossfire). > > > Correct me if I'm wrong, but the code has changed as well, including > switching parts to C++ and integrating Perl as a scripting language. > That, more than the content, makes the project different IMHO. Not only parts, the whole C code has been made compileable with g++. But to the _user_ there isn't a big change. I mean, if the current crossfire server is rewritten in for example scheme and speaks the same protocol and has the same or similar rules, would it be crossfire? The project is indeed different, but why shouldn't it have 'crossfire' somewhere in it's name when it's inheritance is still so much visible? (Daimonin has indeed nearly nothing to do with Crossfire anymore, but thats mostly because they use completly different rules, graphics and overall design). > AFAIK, cat2 is still Crossfire: although some of the game content is > different, the server code is basically the same. Thus, yes, that's > the same application for me. So the difference that makes us Un-Crossfire is something that can't be noticed by players/users!? > >> Calling it most anything with crossfire in its name is confusing. > > >I don't really understand that, who finds it confusing and why? > > Are you joking ? "Crossfire2" presents your project as the 'next > version' of Crossfire (which is still in the 1.x series). Are you so > naive to believe that using the same name for both projects does not > create confusion between both ? Could you re-read my question? I'm not asking about 'Crossfire2', I was asking about the confusion that is created when we have 'Crossfire' in our name. Eg. 'Crossfire+' or 'Blabla-Crossfire-BlubbBlubb'. The original statement was: Calling it most >>anything<< with crossfire in its name is _confusing_. I understand that 'Crossfire2' might cause confusion. But the question is: who is really confused? Is a user/player who just runs cfplus or gcfclient and connect to cf.schmorp.de confused because the server software that runs there has a similar name to the server software that runs on metalforge? - I guess not. I agree that 'Crossfire2' is propably a bit confusing when it is mixed on sites like freshmeat or linux game tome. But at least as far as I see it: a name like 'Crossfire+' or 'Crossfire-ng' is pretty different from 'Crossfire' and shouldn't cause confusion. Similar as 'syslogng' isn't confused with 'syslog' or 'quake' with 'quake2'. In the jabber community there is jabberd14 and jabberd2. First jabberd2 was meant as successor of jabberd14, but jabberd14 couldn't be replaced by jabberd2 and it still persists and is developed. And there is only few confusion about the differences of both as they are distinguished by the '2' and '14' in the _name_ part of the project. jabberd14 has the version 1.6.x now. It seemed indeed to have seeded some confusion, so the placed a note on the website of jabber14 that jabberd2 is a different project. But at least to me they are very distinct. We don't object to change the project name to 'Crossfire+' again. But some rationale or explanation why that still is confusing would be nice. Robin From mwedel at sonic.net Sat Apr 14 09:29:35 2007 From: mwedel at sonic.net (mwedel at sonic.net) Date: Sat, 14 Apr 2007 07:29:35 -0700 (PDT) Subject: [crossfire] Metaserver policy, was Re: Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: References: <1176550133.c7c550dcyann.chachkoff@myrealbox.com> Message-ID: <15809.74.223.6.98.1176560975.squirrel@webmail.sonic.net> I basically came up with those rules fairly quickly. My thought on #4 - no fee for players, is to prevent confusion. If a random person downloaded the client, fired it up, and connect to a server only to find out he had to pay, he may or may not try additional servers. Thus, a player could be lost. This can easily be fixed by including those notes in the metaserver area. However, best I recall, only the gtk2 client actually displays all those notes because for the other clients, they just display a short list in the text info window, and the notes field is too long. Extra fields could be added to denote pay just to be clear. The point about the content is perhaps more valid. One could certainly assume right now that content is free. For maps, this is trickier, as it would be difficult in many places to grab map data just from the client (you could more or less grab visual details, but would have a harder time figuring out all the workings underneath it). But images are trickier - one could rightfully assume that any image they see is GPL. And given the client can cache these images, a person could then assume that any image they have in that cache is also GPL. So a server using non GPL images could be confusing to players. That would be more concern to me than some map changes or server changes. What the server does/how it runs isn't as big a concern - right now with just different settings available, the server itself could behave a bit different, yet still be standard crossfire server, code wise. Making some code changes might be a smaller issue than those details. If a server is radically different, code wise or map wise, probably good to know that, just so new players sort of know what the experience is - this is also relevant because there are various how-to guides, and many describe the starting maps, etc, and if what they actually start playing has no resemblance, that could be pretty frustrating. From fuchs.andy at gmail.com Sat Apr 14 14:26:13 2007 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 14 Apr 2007 15:26:13 -0400 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: References: <20070413164156.GA9256@elmex> <12126.74.223.6.98.1176520159.squirrel@webmail.sonic.net> Message-ID: <1176578774.4183.3.camel@pluto> On Sat, 2007-04-14 at 11:10 +0100, Anton Oussik wrote: > On 14/04/07, mwedel at sonic.net wrote: > > 4) Any servers should be free and open, that is to say, not pay for use/play. > > I am not sure 4) is fair. If people have hardware and time they can > donate to run a server that is one thing, but if a CF derivative ever > becomes very popular and needs a farm to run on, it is likely a fee > would have to be introduced to cover hardware costs, and possibly even > hire full time admins/dms/mapmakers/artists. As long as the source > code is released under GPL and anyone is free to set up their own > server I would still consider that server "free and open", I see no > problems there. The subscribers would be paying for services that > accompany the game, not the game itself. When/if pay for play servers > are introduced they could send pay for play information to the > metaserver, thus avoiding confusion. They could possibly have something like runescape (ew) where it can be played for free, but offers subscriptions that enable you to do more. Though I still see issues with this model. > Then again someone could also make a new tileset and their own maps, > and say "do not redistribute" whilst running them on their own server, > for which they could charge money. I am not sure there is anything GPL > can do about that. > > There is also a potential issue of someone creating a compatible > server/client from scratch not using any GPL code, and charging for > using it. Ultimately there is very little that can be done about that > as far as I can see, as any proprietary server/client could be made to > pretend to be one of the free ones. I think someone did something like this already, not sure about the name. From nicolas.weeger at laposte.net Sat Apr 14 14:31:59 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 14 Apr 2007 21:31:59 +0200 Subject: [crossfire] Build command In-Reply-To: <200704032358.11784.nicolas.weeger@laposte.net> References: <200704032358.11784.nicolas.weeger@laposte.net> Message-ID: <200704142131.59858.nicolas.weeger@laposte.net> > The "build" command (server/c_object.c:command_build()) has been > desactivated since ages. I removed the code :) Optionally, alchemy could be made to use sp, too (would emulate the build command behaviour). Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From fuchs.andy at gmail.com Sat Apr 14 14:39:21 2007 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 14 Apr 2007 15:39:21 -0400 Subject: [crossfire] Metaserver policy, was Re: Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <15809.74.223.6.98.1176560975.squirrel@webmail.sonic.net> References: <1176550133.c7c550dcyann.chachkoff@myrealbox.com> <15809.74.223.6.98.1176560975.squirrel@webmail.sonic.net> Message-ID: <1176579562.4183.14.camel@pluto> On Sat, 2007-04-14 at 07:29 -0700, mwedel at sonic.net wrote: > I basically came up with those rules fairly quickly. > > My thought on #4 - no fee for players, is to prevent confusion. If a > random person downloaded the client, fired it up, and connect to a server > only to find out he had to pay, he may or may not try additional servers. > > Thus, a player could be lost. > This can easily be fixed by including those notes in the metaserver > area. However, best I recall, only the gtk2 client actually displays all > those notes because for the other clients, they just display a short list > in the text info window, and the notes field is too long. > > Extra fields could be added to denote pay just to be clear. Agreed, if we end up allowing paid subscription servers, definitely add a column that would contain an icon to indicate pay servers. > The point about the content is perhaps more valid. One could certainly > assume right now that content is free. For maps, this is trickier, as it > would be difficult in many places to grab map data just from the client > (you could more or less grab visual details, but would have a harder time > figuring out all the workings underneath it). IIRC, there where a few servers that had their own maps (exclusive to that server). Also, giving away a map is equivalent to giving away a spoiler, which some people wouldn't want to do. > But images are trickier - one could rightfully assume that any image they > see is GPL. And given the client can cache these images, a person could > then assume that any image they have in that cache is also GPL. So a > server using non GPL images could be confusing to players. IMO, it is easier for most people to just grab the images from svn, instead of from the client cache. > That would be more concern to me than some map changes or server changes. > What the server does/how it runs isn't as big a concern - right now > with just different settings available, the server itself could behave a > bit different, yet still be standard crossfire server, code wise. Making > some code changes might be a smaller issue than those details. > > If a server is radically different, code wise or map wise, probably good > to know that, just so new players sort of know what the experience is - > this is also relevant because there are various how-to guides, and many > describe the starting maps, etc, and if what they actually start playing > has no resemblance, that could be pretty frustrating. You also have different map sets, etc. It would be nice to have the metaserver show this also. What should the regular map set be referred to if this is done? From fuchs.andy at gmail.com Sat Apr 14 14:58:26 2007 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 14 Apr 2007 15:58:26 -0400 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <20070414095047.GA11921@elmex> References: <20070413164156.GA9256@elmex> <12126.74.223.6.98.1176520159.squirrel@webmail.sonic.net> <20070414095047.GA11921@elmex> Message-ID: <1176580706.4183.32.camel@pluto> Ok, this whole argument is showing the need for a "codebase type" field for the metaserver. A description of this field should also be provided to the user of the client if it is implemented. A couple of other fields i can think of that would be useful would be for "map set" and "server configuration". As for the version string, something like "CF+2.1" looks like it should be read as "Crossfire (plus/and) 2.1", where the "CF+" indicating an alternative codebase is not very obvious to those who are computer illiterate (which most of our player base is not at this moment), and people who are not familiar with either project. I personally think something like "CFP-2.1" or "NG-2.1" would be less confusing to those people. As for the name "Crossfire2", "Quake2" comes logically after "Quake". Thus it is inferred that one replaces the other. Because of that, I would avoid naming a fork as such, unless the project it was forked from was completely dead. From nicolas.weeger at laposte.net Sat Apr 14 17:25:59 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 15 Apr 2007 00:25:59 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <20070413164156.GA9256@elmex> References: <20070413164156.GA9256@elmex> Message-ID: <200704150025.59524.nicolas.weeger@laposte.net> Hello. I agree to various points made, about name confusion and such. IMO, the best way is for you to find a specific name, which can't be confused with Crossfire, like Daimonin did. In the meantime, could you ASAP change your version to eg 'CF+2.0' or something like that? Unless I'm mistaking version is an arbitrary string anyway. This is to avoid confusion now, and you can change that later to match your new name :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From yann.chachkoff at myrealbox.com Sat Apr 14 18:09:18 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun, 15 Apr 2007 01:09:18 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver Message-ID: <1176592158.c7bac71cyann.chachkoff@myrealbox.com> > But to the _user_ there isn't a big change. I mean, if the current > crossfire server is rewritten in for example scheme and speaks the same > protocol and has the same or similar rules, would it be crossfire? > No, unless the rewritten version is made by the people of the original crossfire project as a new version of it, superceding the C code. That case would be a replacement/new version, and not a fork. > The project is indeed different, but why shouldn't it have 'crossfire' > somewhere in it's name when it's inheritance is still so much visible? > Because it is confusing. > So the difference that makes us Un-Crossfire is something that can't > be noticed by players/users!? > Yes. If I code a clone of vi, even if it perfectly mimicks the original, it would still not be the original, and I would still have no right to call it "vi" - it would still be a clone/rewrite, regardless on how users perceive it. Telling them it is "vi" would be dishonest, but also a bit dangerous: can I really guarantee that the behavior is absolutely identical in all cases ? I doubt so. > Could you re-read my question? I'm not asking about 'Crossfire2', I was > asking about the confusion that is created when we have 'Crossfire' in > our name. Eg. 'Crossfire+' or 'Blabla-Crossfire-BlubbBlubb'. No need to re-read your question, I understood it pretty well. But Crossfire-whatever definitely seems confusing to me, whatever is that -whatever. > I understand that 'Crossfire2' might cause confusion. But the question is: who is really confused? Is a user/player who just runs cfplus or > gcfclient and connect to cf.schmorp.de confused because the server > software that runs there has a similar name to the server software that > runs on metalforge? - I guess not. > Actually, such a user is fooled. If I'm a new CF player, I'll not pick a server randomly, but will probably select the latest one, because it probably got the most interesting features. Hence, of course, if I have the choice between an "1.10" and a "2.1", I'll definitely select the 2.1 one, and label the 1.10 one as "outdated server". > a name like 'Crossfire+' or 'Crossfire-ng' is pretty different from 'Crossfire' and shouldn't cause confusion. Except that with those both examples, one gets the idea that the project is the next version of an older software. > Similar as 'syslogng' isn't confused with 'syslog' or 'quake' with 'quake2'. > syslog-ng is a tool for system administrators, not lambda players. I think there is a rather important difference between both publics. And AFAIK, quake2 is the second version of quake; so this is similar as if we decided to name "crossfire" "crossfire2" for our next major release. > In the jabber community there is jabberd14 and jabberd2. > But again, those are software that already require some understanding of the computer world - installing a Jabber server is not something very common. Even so, it already created confusion. I'm not convinced that players will not be confused when server administrators sometimes were. > We don't object to change the project name to 'Crossfire+' again. But > some rationale or explanation why that still is confusing would be nice. > Note that the confusion is not limited to the name of the project - the discussion started because of the displayed version number (remember that the project name appears nowhere in the metaserver infos). Even if you estimate that "Crossfire-xxx" is not confusing, having a "2.1" number without anything else definitely is. From mwedel at sonic.net Sat Apr 14 18:28:12 2007 From: mwedel at sonic.net (mwedel at sonic.net) Date: Sat, 14 Apr 2007 16:28:12 -0700 (PDT) Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <20070414123935.GA13365@elmex> References: <1176549640.c7c550dcyann.chachkoff@myrealbox.com> <20070414123935.GA13365@elmex> Message-ID: <25515.74.223.6.98.1176593292.squirrel@webmail.sonic.net> > On Sat, Apr 14, 2007 at 01:20:40PM +0200, Yann Chachkoff wrote: > Not only parts, the whole C code has been made compileable with g++. > But to the _user_ there isn't a big change. I mean, if the current > crossfire server is rewritten in for example scheme and speaks the same > protocol and has the same or similar rules, would it be crossfire? No - that would be some other server/program. It could certainly be called 'crossfire compatible' or the like, but claiming it is crossfire would be false. This is true for any program - if I rewrote the 'cat' program completely from scratch, I really shouldn't call it cat. I could call it mcat (marks cat), or ncat (new cat), or whatever, but I'd be loathe to call it new cat, as that doesn't say a whole lot about the name. A better real life example may be emacs - there are forks or derivative programs, but they do have a different naming scheme - xemacs, emacs, etc. They change the name in some regard - xemacs doesn't call itself emacs10, they did make some noticable change - more than adding a number which is easy to confuse with a version, or a + which is somewhat misleading. They don't have a name that in any way suggests it is the successor of suprerior, but rather have a name that suggests it is different. So I guess call it scrossfire (schmorps crossfire) may be reasonable, as that is a different name. But calling different programs that same logical name even though they share no code base is wrong IMO. > > The project is indeed different, but why shouldn't it have 'crossfire' > somewhere in it's name when it's inheritance is still so much visible? > (Daimonin has indeed nearly nothing to do with Crossfire anymore, but > thats mostly because they use completly different rules, graphics and > overall design). Note however that when they forked off, they switched the name immediately, when they were still basically crossfire. AS time passed, things drifted apart. A valid question of course is whether that version will always remain compatible. Saying yes implies that any and all protocol changes we make will also be done in your server also - can you say 100% that you are going to do that? > Could you re-read my question? I'm not asking about 'Crossfire2', I was > asking about the confusion that is created when we have 'Crossfire' in > our name. Eg. 'Crossfire+' or 'Blabla-Crossfire-BlubbBlubb'. It depends on how you form your name. After typing above, I'd say that having crossfire in your name is OK, but it should be named such that it does not create confusion suggesting it is the successor or latest version of crossfire. Both crossfire+ and crossfire2 suggest those things. Likewise, crossfire-extended was another such name. So I wouldn't mind it being called scrossfire, or rcrossfire, as that more clear suggest it is different in some regard. ncrossfire (new crossfire) I would not like, as once again it suggests it is a replacement to crossfire, which IMO is patently false, since crossfire is still being developed. > > I agree that 'Crossfire2' is propably a bit confusing when it is > mixed on sites like freshmeat or linux game tome. But at least as far > as I see it: a name like 'Crossfire+' or 'Crossfire-ng' is pretty > different from 'Crossfire' and shouldn't cause confusion. > Similar as 'syslogng' isn't confused with 'syslog' or 'quake' with > 'quake2'. crossfire+ is, as that is just like crossfire2 - suggests it is a later version. Crossfire-ng is probably ok, depending on what the ng stands for. The quake analogy is I think false, given the people who wrote quake wrote quake, and/or those people had no intention of doing a quak2 themselves. In fact, I'd say it is reasonable that at some point, we may in fact be releasing packages called crossfire2 - I don't think we would change the project name, but perhaps the packages. > > In the jabber community there is jabberd14 and jabberd2. First jabberd2 > was meant as successor of jabberd14, but jabberd14 couldn't be replaced > by jabberd2 and it still persists and is developed. And there is only > few confusion about the differences of both as they are distinguished by > the '2' and '14' in the _name_ part of the project. jabberd14 has the > version 1.6.x now. > It seemed indeed to have seeded some confusion, so the placed a note on > the website of jabber14 that jabberd2 is a different project. But at > least to me they are very distinct. I don't know the details about jabberd2, but I better know gtk+, which has both gtk+2 and gtk+1, since like you describe in jabberd, there was some need to still use/support the old version even though there was a new version. A major difference in that case vs yours is that for gtk+2, it is the same people that did gtk+, and thus that naming was done with their permission (and probably same developers), same web site, etc. And in the case of gtk+, while I think a lot was rewritten, it certainly shared some common code. My main complaint with calling yours crossfire2 or crossfire+ is that both of those suggest it is a successor to the crossfire project, which it isn't. It is really (at least from what I gather) a parallel project that is crossfire compatible. If I (as the official maintainer for crossfire) and the bulk of the developers stopped doing work on crossfire, I'd have less complaint about someone else taking up the torch and calling their project crossfire2, crossfire3, whatever, but that isn't the case. Crossfire is still quite alive an kicking, and anything that suggests it is the successor is misleading. There are probably good reasons to use it, just like there are reasons to use syslog-ng instead of syslog, but there is a difference between that and choosing a name which suggests you have the latest version. > > We don't object to change the project name to 'Crossfire+' again. But > some rationale or explanation why that still is confusing would be nice. crossfire+ - suggests later version of crossfire. Eg, if I see crossfire+-1.10.0, I'd think 'hey, that is a crossfire server running 1.10 with some extra patches/content'. I wouldn't think 'that is a completely different codebase'. I've already stated crossfire2 naming. As said above, having the name crossfire in yours is probably OK, if its naming is somehow done to suggest a difference. But to come up with a detailed list of what is or is not OK is difficult - probably easier for you to provide a few names and see what people think. On the flip side of this, you can look at another project/protocol - httpd. There are lots of httpd servers out there, but they have different names (apache, java web server, whatever else). They don't all have httpd in their name - they rely on people to know that they are a web server. So from that basis, there isn't a requirement that a program have crossfire in its name just because it is crossfire compatible. From mwedel at sonic.net Sat Apr 14 18:35:59 2007 From: mwedel at sonic.net (mwedel at sonic.net) Date: Sat, 14 Apr 2007 16:35:59 -0700 (PDT) Subject: [crossfire] Metaserver policy, was Re: Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <1176579562.4183.14.camel@pluto> References: <1176550133.c7c550dcyann.chachkoff@myrealbox.com> <15809.74.223.6.98.1176560975.squirrel@webmail.sonic.net> <1176579562.4183.14.camel@pluto> Message-ID: <7225.74.223.6.98.1176593759.squirrel@webmail.sonic.net> > On Sat, 2007-04-14 at 07:29 -0700, mwedel at sonic.net wrote: > > Agreed, if we end up allowing paid subscription servers, definitely add > a column that would contain an icon to indicate pay servers. So maybe that rule should be revised to something like 'If the server requires paid subscription, the server must report that to the metaserver'. > > IIRC, there where a few servers that had their own maps (exclusive to > that server). Also, giving away a map is equivalent to giving away a > spoiler, which some people wouldn't want to do. I'd say the issue is more if the beginner maps are different. If one server has level 50 maps that another server doesn't, that isn't a big deal to me, as by then, the player is likely to be savvy enough to know about some differences. > >> But images are trickier - one could rightfully assume that any image >> they >> see is GPL. And given the client can cache these images, a person could >> then assume that any image they have in that cache is also GPL. So a >> server using non GPL images could be confusing to players. > > IMO, it is easier for most people to just grab the images from svn, > instead of from the client cache. But my point was this: I fire up crossfire client and select something from the metaserver. I play around and see some image I like - something not in SVN. I say 'that is a cool image'. Now the right thing to do is send that server admin an e-mail, but then again, I know about those things - I could certainly see less savvy people thing 'hey, crossfire is GPL, so this image should be also. I think it would be cool to use elsewhere', and go off an do so. From mwedel at sonic.net Sat Apr 14 18:45:10 2007 From: mwedel at sonic.net (mwedel at sonic.net) Date: Sat, 14 Apr 2007 16:45:10 -0700 (PDT) Subject: [crossfire] Metaserver info, was Re: Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <1176580706.4183.32.camel@pluto> References: <20070413164156.GA9256@elmex> <12126.74.223.6.98.1176520159.squirrel@webmail.sonic.net> <20070414095047.GA11921@elmex> <1176580706.4183.32.camel@pluto> Message-ID: <16937.74.223.6.98.1176594310.squirrel@webmail.sonic.net> > Ok, this whole argument is showing the need for a "codebase type" field > for the metaserver. A description of this field should also be provided > to the user of the client if it is implemented. > > A couple of other fields i can think of that would be useful would be > for "map set" and "server configuration". > So a question here would be what info should be in the metaserver beyond what we have now. Quick thoughts, gathered here and from other areas: 1) Server code base 2) Map code base 3) Archetype code base? 4) The SC_VERSION and CS_VERSIONS that the server supports (this could be handy as the clients could filter out servers they know they can't use) 5) A flags field with single letter flags that could denote various things, like: $ - pay to pay P - player killing allowed p - permadeath etc - ideally, these flags get interperted by the client, so perhaps filtering can be done, icons, etc. Any that the client doesn't understand, it either ignores or displays in some way. The flags don't necessary have to match what they stand for, and if they grow enough, they certainly wouldn't. But that gives spaces for 90+ flags in one field, so it means expanding to new things is easier than having to add new fields. Another question related to this is whether we should re-do the metaserver connection method all together - in shorter term, the servers could use both new and old methods to report data, but then at some point, they only use new method. There were discussions in the past about this - I bring it up now, because if we add all these new fields, it may make it hard to keep things compatible. From alex_sch at telus.net Sun Apr 15 02:42:56 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 15 Apr 2007 01:42:56 -0600 Subject: [crossfire] Metaserver info, was Re: Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <16937.74.223.6.98.1176594310.squirrel@webmail.sonic.net> References: <20070413164156.GA9256@elmex> <12126.74.223.6.98.1176520159.squirrel@webmail.sonic.net> <20070414095047.GA11921@elmex> <1176580706.4183.32.camel@pluto> <16937.74.223.6.98.1176594310.squirrel@webmail.sonic.net> Message-ID: <4621D780.2040003@telus.net> mwedel at sonic.net wrote: > The proposed fields you mentioned look good to me. One other quick thought, is perhaps the "codebase" fields should have a flag or other standard way of representing the case of something being mostly of a "codebase" but with a minor patch or two. > Another question related to this is whether we should re-do the > metaserver connection method all together - in shorter term, the servers > could use both new and old methods to report data, but then at some > point, they only use new method. There were discussions in the past > about this - I bring it up now, because if we add all these new fields, > it may make it hard to keep things compatible. And another thought, is if it would be worthwhile for a redone metaserver connection method to actually be a distributed metaserver as was once thought about a long while back. I'm not sure that would be good, but if the connection method were to be redone, it would be worth thinking about those sorts of things. Alex From elmex at ta-sa.org Sun Apr 15 04:32:41 2007 From: elmex at ta-sa.org (Robin Redeker) Date: Sun, 15 Apr 2007 11:32:41 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <1176592158.c7bac71cyann.chachkoff@myrealbox.com> References: <1176592158.c7bac71cyann.chachkoff@myrealbox.com> Message-ID: <20070415093241.GA4190@elmex> On Sun, Apr 15, 2007 at 01:09:18AM +0200, Yann Chachkoff wrote: > > I understand that 'Crossfire2' might cause confusion. But the > > question is: who is really confused? Is a user/player who just runs cfplus or > > gcfclient and connect to cf.schmorp.de confused because the server > > software that runs there has a similar name to the server software > > that runs on metalforge? - I guess not. > > > Actually, such a user is fooled. If I'm a new CF player, I'll not pick > a server randomly, but will probably select the latest one, because it > probably got the most interesting features. Hence, of course, if I > have the choice between an "1.10" and a "2.1", I'll definitely select > the 2.1 one, and label the 1.10 one as "outdated server". So the best would be if the metaserver would only contain metalforge, so that users can't accidentally choose another server with more players or higher version or different server project. > > We don't object to change the project name to 'Crossfire+' again. > > But some rationale or explanation why that still is confusing would > > be nice. > > > Note that the confusion is not limited to the name of the project - > the discussion started because of the displayed version number > (remember that the project name appears nowhere in the metaserver > infos). Even if you estimate that "Crossfire-xxx" is not confusing, > having a "2.1" number without anything else definitely is. Yes, the length of the 'comment' column is very limited. If that would be fixed we could also write the project name there and an explanation. From yann.chachkoff at myrealbox.com Sun Apr 15 09:40:22 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun, 15 Apr 2007 16:40:22 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver Message-ID: <1176648022.c7c78fbcyann.chachkoff@myrealbox.com> > So the best would be if the metaserver would only contain metalforge, so > that users can't accidentally choose another server with more players > or higher version or different server project. > No. I never suggested such "cultural closedness". I never said anything about the number of players, either, or a higher version number. The problem is that in the current situation, the CF+ servers appear as higher versions of CF, which definitely is *not* the case. The user has *no* way to guess the "2.1" displayed refers to a different project. You can keep trying dodging the issue by focusing the debate on details, but you'll not change the basical equation "Game named Crossfire2 > Game named Crossfire 1.10" in the mind of most (if not all) players, and especially the newcomers. Really, this is getting tiresome. What's so hard to understand in that for most, "+" carries the idea of superiority/improvement, or that "2 > 1" ? > Yes, the length of the 'comment' column is very limited. If that would > be fixed we could also write the project name there and an explanation. > Yes, but it currently isn't the case. I don't think waiting for new releases of the clients to solve the issue is acceptable, when you could have done it in a few minutes. I'm sorry if I sound rude, but I have more and more the feeling that you're playing dumb with us on this on purpose. I hope the future will prove me wrong on this. From schmorp at schmorp.de Sun Apr 15 12:10:01 2007 From: schmorp at schmorp.de (Marc Lehmann) Date: Sun, 15 Apr 2007 19:10:01 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <1176592158.c7bac71cyann.chachkoff@myrealbox.com> References: <1176592158.c7bac71cyann.chachkoff@myrealbox.com> Message-ID: <20070415171001.GA27258@schmorp.de> On Sun, Apr 15, 2007 at 01:09:18AM +0200, Yann Chachkoff wrote: > > The project is indeed different, but why shouldn't it have 'crossfire' > > somewhere in it's name when it's inheritance is still so much visible? > > > Because it is confusing. We asked a number of times for indications of that, but received none. Obviously (all of) "you" are not confused about it at all, so who is, and how? We asked our players, and they do not seem to be confused by that. > Actually, such a user is fooled. If I'm a new CF player, I'll not pick > a server randomly, but will probably select the latest one, because it > probably got the most interesting features. Then wouldn't it make to keep it as it is? Looking at all servers on a "most interesting feature" basis clearly makes the 2.x servers "more interesting", both for internal features as well as player-visible ones. (Remember that crossfire 2.x does implement most of the features that the crossfire 1.x "team" plans for their version 2, so in a very definite sense the current 2.0+ server is much closer to what the crossfire project wants as 2.0 than the 1.x servers). So if you want to make a discussion about technical merrit, the 2.x servers (both 2.0+ and 2.1) win: they support more users with _much_ less cpu and bandwith usage, no lag due to I/O, much less crash-related and game-related bugs, better and safer object management and a lot more user-visible features such as greatly enhanced balancing, less frustration, better graphics (at least for 2.1, only partly for 2.0+), etc. etc. If you think version numbers should reflect "most interesting" features, then the current situation is your goal, and no confusion could come from it. > > a name like 'Crossfire+' or 'Crossfire-ng' is pretty different from 'Crossfire' and shouldn't cause confusion. > > Except that with those both examples, one gets the idea that the project is the next version of an older software. That is an empty claim. People did not get the impression that "C++" is the next version of "C", either, similar for other cases. People will think it might be an enhanced version, or a new generation of something, which is actually what is the case. > > Similar as 'syslogng' isn't confused with 'syslog' or 'quake' with 'quake2'. > > syslog-ng is a tool for system administrators, not lambda players. I think there is a rather important difference between both publics. Care to name it? > > We don't object to change the project name to 'Crossfire+' again. But > > some rationale or explanation why that still is confusing would be nice. > > Note that the confusion is not limited to the name of the project - the > discussion started because of the displayed version number (remember > that the project name appears nowhere in the metaserver infos). Even > if you estimate that "Crossfire-xxx" is not confusing, having a "2.1" > number without anything else definitely is. Thats your opinion, but there is no evidence for that so far. I find it interesting to get that claim repeated without any evidence, and when challenged for evidence, we never get any reply. Honestly, I am a bit annoyed at crossfire 1.x. We wanted to use the "+", and we constantly being told that the + should go from the version number. Now that we did we are asked (or some cases commanded) to add it again. Before shoving perceived or made-up problems into our direction, couldn't all of you first agree on what you really want and then ask us? Obviously we are happy to comply, but it is no fun if you make a full 180 every few months. Could it be that the reason you are annoyed at us is actually of your own making? I think it is unfair to call us "arrogant" when all we do is try to play nice but only earn arbitrariness in return? (This is not directly aimed at you, Yann. Actually: thanks a lot to you because you are one of the few people who actually tried to explain things instead of just whining without trying to be constructive). -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ pcg at goof.com --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE From yann.chachkoff at myrealbox.com Sun Apr 15 13:29:20 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun, 15 Apr 2007 20:29:20 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver Message-ID: <1176661760.c7cc449cyann.chachkoff@myrealbox.com> > Obviously (all of) "you" are not confused about it at all, so who is, and > how? We asked our players, and they do not seem to be confused by that. > "We" (as in the CF devs) are not all the players by far. I think the most confused ones will be the newcomers, of course - and those hardly express themselves on the ML or on the IRC channel about that. I'll not comment about your player base - I have not enough knowledge about them to estimate the value of that answer they gave you. > Then wouldn't it make to keep it as it is? Looking at all servers on a > "most interesting feature" basis clearly makes the 2.x servers "more > interesting", both for internal features as well as player-visible ones. > That's your opinion, which is subjective. I myself don't state one project is better than another - and thus, I don't think it is appropriate to label one as "superior" to the other (as the "+" suggested), or "newer" (which the 2.x numbering implies). Even if I accept the hypothesis that "CF+ is better than CF", CF is not a dead project, and CF+ is in no way its successor. The current version numbering system leads to think exactly that. > So if you want to make a discussion about technical merrit, No. It is not the point, and I'll go no further in that direction, which involves lots of subjective views and personal bias on both sides. > If you think version numbers should reflect "most interesting" features, > then the current situation is your goal, and no confusion could come from > it. > You misunderstood what I meant: it should reflect "the most interesting/advanced features *for the given application*". It seems logical that Crossfire 1.10 is an improved iteration of 1.9, which in turn is an improvement of 1.8, and so on. Now, CF+ is *not* the same project. It is a fork, and is now developed in parallel. Hence, "Crossfire+ 2.0" is *not* the next improved iteration of "Crossfire 1.10", but the start of a new branch. And as time passes, both projects will diverge more and more. > That is an empty claim. People did not get the impression that "C++" is > the next version of "C", either, similar for other cases. People will > think it might be an enhanced version, or a new generation of something, > which is actually what is the case. > Except that C and C++ are languages made for developers, not a game for a wide audience. Moreover, when C++ initially came out, it wasn't called "C++", but "C with classes", which clearly removed the possible confusion. And, as Stroustrup itself expressed, C++ is an extension of C. CF+ is not an extension of CF, but a diverging branch. Unless you can guarantee that CF+ will forever stay compatible with CF, and keep all the features CF has; that, I guess, would be a rather bold assumption. > Thats your opinion, but there is no evidence for that so far. I find it > interesting to get that claim repeated without any evidence, and when > challenged for evidence, we never get any reply. > And what do you want us to do ? Get ten testing people at random, show them the game, and ask them the question ? And when the 2.x series of CF are out, how will we distinguish both ? Or maybe Crossfire should use odd version numbers (3.x, 5.x, etc), while CF+ would be using even ones (2.x, 4.x, etc) ? > Honestly, I am a bit annoyed at crossfire 1.x. We wanted to use the "+", and > we constantly being told that the + should go from the version number. Now > that we did we are asked (or some cases commanded) to add it again. > Where was that asked ? I do remember that it was asked to use something else, as "2.0+" was not clearly enough different - it looked like a regular 2.0 version with some add-ins. I doubt anybody ever asked you to remove the "+" and simply use "2.x" - and if somebody did, I'd be curious to see the log of that conversation. > Before shoving perceived or made-up problems into our direction, couldn't > all of you first agree on what you really want and then ask us? Obviously > we are happy to comply, but it is no fun if you make a full 180 every few > months. Could it be that the reason you are annoyed at us is actually of > your own making? I think it is unfair to call us "arrogant" when all we do > is try to play nice but only earn arbitrariness in return? > The request is pretty easy to understand, though: change the version number displayed and the project name so that it cannot be perceived as a newer version of Crossfire. We never asked anything else than that, and there was no 180? turn. "Make your project name clearly distinguishable from ours" was always the only request we ever made. I guess that if your only goal is to "play nice", then you'll happily change the version number displayed to something clearly distinguishable - a change that has no impact on the game itself, and that requires less than 5 minutes to achieve. From alex_sch at telus.net Sun Apr 15 13:50:57 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 15 Apr 2007 12:50:57 -0600 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <20070415171001.GA27258@schmorp.de> References: <1176592158.c7bac71cyann.chachkoff@myrealbox.com> <20070415171001.GA27258@schmorp.de> Message-ID: <46227411.6090808@telus.net> Marc Lehmann wrote: > On Sun, Apr 15, 2007 at 01:09:18AM +0200, Yann Chachkoff wrote: > >>> The project is indeed different, but why shouldn't it have 'crossfire' >>> somewhere in it's name when it's inheritance is still so much visible? >>> >> Because it is confusing. >> > > We asked a number of times for indications of that, but received none. > Obviously (all of) "you" are not confused about it at all, so who is, and > how? We asked our players, and they do not seem to be confused by that. > We have from time to time seen new players enter the #crossfire IRC channel on freenode, who were somewhat confused at your server and project. Most of the confusion was with regards to the version reported on the metaserver, but I do recall some confusing regarding the project name and the general relation between the projects. I do not believe that the name containing "Crossfire" is inherently confusing (perhaps a small amount of disagreement about this detail on our side), but the lack of other distinguishing elements that is confusing. The metaserver confusing users would be highest priority however, as that has created by far the most confusion among users. For example, it has not been uncommon to see a newbie show up in #crossfire and ask some question (or complain about some issue), and it turns out they were on schmorp as opposed to something running normal crossfire, and they were unaware of the separate projects, and simply thought it was nothing more than a newer version. I hope you can understand that this can be rather frustrating. >> Actually, such a user is fooled. If I'm a new CF player, I'll not pick >> a server randomly, but will probably select the latest one, because it >> probably got the most interesting features. >> > > Then wouldn't it make to keep it as it is? Looking at all servers on a > "most interesting feature" basis clearly makes the 2.x servers "more > interesting", both for internal features as well as player-visible ones. > > (Remember that crossfire 2.x does implement most of the features that the > crossfire 1.x "team" plans for their version 2, so in a very definite > sense the current 2.0+ server is much closer to what the crossfire project > wants as 2.0 than the 1.x servers). > In some regards yes, however I doubt this is 'most' and there are quite a number of various differences in goals and methods of achieving them. However what I feel is more significant however is how what you are doing is very much akin to creating a fork of apache, making some changes like offloading non-core functions to a scripting language and deeply integrating it, adding some features, and then calling it "Apache 3". Can you note any sort of significant difference between such things? I see no relevant difference myself. > Honestly, I am a bit annoyed at crossfire 1.x. We wanted to use the "+", and > we constantly being told that the + should go from the version number. Now > that we did we are asked (or some cases commanded) to add it again. > Your annoyance is understandable, however I do not believe anyone simply said to remove the "+" (perhaps someone did and I was not aware of it). To my understanding the issue with the version strings like "2.0+" was that it wasn't clear enough to users it was a separate project, and when the "+" was simply removed that made it even more unclear that it is a separate project. I'm not sure what the best solution would be in this regard, however to avoid confusion, until the metaserver supports another relevant column or two, the easiest way to avoid user confusion as I've noted above would be to add a more distinguishing elements to the version string, not simply remove one distinguishing element that wasn't sufficient to avoid confusion. > Before shoving perceived or made-up problems into our direction, couldn't > all of you first agree on what you really want and then ask us? Obviously > we are happy to comply, but it is no fun if you make a full 180 every few > months. Could it be that the reason you are annoyed at us is actually of > your own making? I think it is unfair to call us "arrogant" when all we do > is try to play nice but only earn arbitrariness in return? > I apologize for calling you "arrogant"; I was feeling rather flustered at how you seem to present your project as the "successor project" (which you seem to believe it is) while a majority of the Crossfire community does not accept CF+ as being a true successor. I believe some of my statements were too harsh, and that us on this side are not quite in 100% agreement on every detail, however I do not believe it is not fair of you to be saying we are just making up problems despite honest attempts to explain what we see as problems. Alex From nicolas.weeger at laposte.net Mon Apr 16 15:48:16 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 16 Apr 2007 22:48:16 +0200 Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <20070415171001.GA27258@schmorp.de> References: <1176592158.c7bac71cyann.chachkoff@myrealbox.com> <20070415171001.GA27258@schmorp.de> Message-ID: <200704162248.16813.nicolas.weeger@laposte.net> Hello. (for those who didn't notice: CF+ is now called Crossfire TRT, and servers on the metaserver are versioned as 2.1trt) Thanks for the name change (what does TRT mean, btw?) :) Would it be possible for you to change the order of your version string, ie put "trt 2.1"? I think (and others will say if they disagree) that it would be less ambiguous this way - as people are more likely to see first 2.1, and forget the trt part. Cheers Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Tue Apr 17 02:03:25 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 17 Apr 2007 00:03:25 -0700 Subject: [crossfire] Metaserver info, was Re: Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <4621D780.2040003@telus.net> References: <20070413164156.GA9256@elmex> <12126.74.223.6.98.1176520159.squirrel@webmail.sonic.net> <20070414095047.GA11921@elmex> <1176580706.4183.32.camel@pluto> <16937.74.223.6.98.1176594310.squirrel@webmail.sonic.net> <4621D780.2040003@telus.net> Message-ID: <4624713D.7050705@sonic.net> Alex Schultz wrote: > mwedel at sonic.net wrote: >> > The proposed fields you mentioned look good to me. One other quick > thought, is perhaps the "codebase" fields should have a flag or other > standard way of representing the case of something being mostly of a > "codebase" but with a minor patch or two. codebase, like most fields, would be free form. So one could be something like 'standard + a few custom maps' in for a codebase - pretty clear there. I think the issue here is more what people should put in for codebase. I'm not sure if special flags are needed. > >> Another question related to this is whether we should re-do the >> metaserver connection method all together - in shorter term, the servers >> could use both new and old methods to report data, but then at some >> point, they only use new method. There were discussions in the past >> about this - I bring it up now, because if we add all these new fields, >> it may make it hard to keep things compatible. > And another thought, is if it would be worthwhile for a redone > metaserver connection method to actually be a distributed metaserver as > was once thought about a long while back. I'm not sure that would be > good, but if the connection method were to be redone, it would be worth > thinking about those sorts of things. In my ideal case, which I believe borrows a lot from that discussion, would be to have metaservers web based (http). That makes it so that most anyone can set them up (everyone probably has a web page, or can get one with cgi-bin, but being able to run a persistent server that listens to some port is a lot harder). Also, it being web based takes care of parallelism for us - the web server would launch multiple copies. My initial thought is that a fairly simple php script that handles the requests (and can also provide a page) and storing the data in a mysql would do this, and both are pretty standard functions. mysql may sound like overhead, but has the advantage that it in a sense takes care of file locking for us. All of that is actually pretty easy to do. The harder part is the synchronization between metaservers - or maybe we don't care. Simplest thing is that on both the client and server, you have a list of of metaservers to try. Each server will try to update all the metaservers. If a metaserver is down, it obviously can't update it. However, a pretty basic method can be used so that it tries periodically to send it updates, so when it comes back alive, it would start getting updates. Remember also that the down metaserver will still have its old data when it starts up (sitting in that database), so it would really just have stale data, not missing data. For clients, it would choose one of the metaservers from the list, randomly. There could be an override for players that really know what they are doing (eg, the routing to metaserver B sucks, so I always want to use A). If the client is unable to connect to a metaserver, it tries the next one, etc. Note that the web side doesn't have to be php - it could be perl or most anything else, but if it gets too obscure, that sort of eliminates the ability for it to be easy for a wide number of users to set up. Also, there could be a second database that the metaserver has, which is blacklisted hosts. These would mostly be used for misconfigured servers that are sending bad data to the metaserver. So simple matter to add into that table, and server is now blacklisted. The most complicated part about all of this is that it is a tcp connection for the server - that can time out (the server can not open it at start up and hope it stays open forever), so a helper application that runs on the same host that the server relays (proxies) through would be used. This could most simply be done via pipe with popen. From antonoussik at gmail.com Tue Apr 17 02:12:00 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Tue, 17 Apr 2007 08:12:00 +0100 Subject: [crossfire] Build command In-Reply-To: <200704142131.59858.nicolas.weeger@laposte.net> References: <200704032358.11784.nicolas.weeger@laposte.net> <200704142131.59858.nicolas.weeger@laposte.net> Message-ID: On 14/04/07, Nicolas Weeger wrote: > Optionally, alchemy could be made to use sp, too (would emulate the build > command behaviour). Interesting. This would solve a lot of problems. What do others think? From fuchs.andy at gmail.com Tue Apr 17 13:56:17 2007 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Tue, 17 Apr 2007 14:56:17 -0400 Subject: [crossfire] Build command In-Reply-To: References: <200704032358.11784.nicolas.weeger@laposte.net> <200704142131.59858.nicolas.weeger@laposte.net> Message-ID: <1176836177.4588.1.camel@pluto> On Tue, 2007-04-17 at 08:12 +0100, Anton Oussik wrote: > On 14/04/07, Nicolas Weeger wrote: > > Optionally, alchemy could be made to use sp, too (would emulate the build > > command behaviour). > > Interesting. This would solve a lot of problems. What do others think? Good idea for general alchemy, IMO. Stuff like general cooking or smithing (non magical) shouldn't have to use sp though. From aaron at baugher.biz Tue Apr 17 15:41:33 2007 From: aaron at baugher.biz (Aaron Baugher) Date: Tue, 17 Apr 2007 15:41:33 -0500 Subject: [crossfire] Getting more artists In-Reply-To: <1176503235.c7cf017cyann.chachkoff@myrealbox.com> (Yann Chachkoff's message of "Sat, 14 Apr 2007 00:27:15 +0200") References: <1176503235.c7cf017cyann.chachkoff@myrealbox.com> Message-ID: <86wt0a7myq.fsf@bannor.baugher.biz> "Yann Chachkoff" writes: > Now, I would not suggest using 64x64 as a new size for > tiles. Instead, keep the base tile as 32x32, and enlarge various > objects, so that they take more than a single tile. > Why ? Because having a base tile (32x32) that is smaller than the > default tile (64x64) allows you to make more complex shapes - for > example, L-shaped tiles. I tend to agree. If you stay with 32x32 tiles while making most objects bigger than that, you could have a 64x64 table, but be able to put four different food items on it for example. If all the tiles are 64x64, you may be able to make the actual booze bottle very small, but you can still only put one of them within a 64x64 area. -- Aaron -- aaron.baugher.biz From nicolas.weeger at laposte.net Tue Apr 17 15:48:58 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 17 Apr 2007 22:48:58 +0200 Subject: [crossfire] Build command In-Reply-To: <1176836177.4588.1.camel@pluto> References: <200704032358.11784.nicolas.weeger@laposte.net> <1176836177.4588.1.camel@pluto> Message-ID: <200704172248.58386.nicolas.weeger@laposte.net> > Good idea for general alchemy, IMO. Stuff like general cooking or > smithing (non magical) shouldn't have to use sp though. Well, just need to not set any sp for those formuleas then :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From subs at eracc.com Tue Apr 17 16:18:35 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Tue, 17 Apr 2007 16:18:35 -0500 Subject: [crossfire] Build command In-Reply-To: <200704172248.58386.nicolas.weeger@laposte.net> References: <200704032358.11784.nicolas.weeger@laposte.net> <1176836177.4588.1.camel@pluto> <200704172248.58386.nicolas.weeger@laposte.net> Message-ID: <200704171618.36916.subs@eracc.com> On Tuesday 17 April 2007 03:48 pm Nicolas Weeger wrote: > > Good idea for general alchemy, IMO. Stuff like general cooking or > > smithing (non magical) shouldn't have to use sp though. > > Well, just need to not set any sp for those formuleas then :) > > Nicolas Awwwwww nuts! You guys gonna nerf (as in make less useful and friendly) alchemy too? Well, there goes my idea of starting a pure alchemist. If one has to wait for Sp to regenerate after every use of the *SKILL* alchemy that is just silly. No, I do not think doing away with the *skill* and using the spell instead is a good idea either. Fellas, traditional alchemists were not magic users, they were early scientists. Sure, some of the things alchemists can make *appear* magic but that is only because they resemble purely magical spells in effect, not actuality. Gene Alexander (... mumbles something about "darn game balance police") :-p -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From nicolas.weeger at laposte.net Tue Apr 17 16:32:12 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 17 Apr 2007 23:32:12 +0200 Subject: [crossfire] Build command In-Reply-To: <200704171618.36916.subs@eracc.com> References: <200704032358.11784.nicolas.weeger@laposte.net> <200704172248.58386.nicolas.weeger@laposte.net> <200704171618.36916.subs@eracc.com> Message-ID: <200704172332.13080.nicolas.weeger@laposte.net> > Awwwwww nuts! You guys gonna nerf (as in make less useful and friendly) > alchemy too? Well, there goes my idea of starting a pure alchemist. If one > has to wait for Sp to regenerate after every use of the *SKILL* alchemy > that is just silly. > > No, I do not think doing away with the *skill* and using the spell instead > is a good idea either. Fellas, traditional alchemists were not magic users, > they were early scientists. Sure, some of the things alchemists can make > *appear* magic but that is only because they resemble purely magical spells > in effect, not actuality. Hum, let me be more precise, then: "What about adding the possibility to have alchemy-related recipes use sp too? Of course we'll let current recipes as they are, but when we extend recipes to eg create powerful armors, that sp use may come in handy (think charging the armor with sp to protect you?)" :) I didn't mean to alter existing formuleas. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From subs at eracc.com Tue Apr 17 16:42:54 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Tue, 17 Apr 2007 16:42:54 -0500 Subject: [crossfire] Build command In-Reply-To: <200704172332.13080.nicolas.weeger@laposte.net> References: <200704032358.11784.nicolas.weeger@laposte.net> <200704171618.36916.subs@eracc.com> <200704172332.13080.nicolas.weeger@laposte.net> Message-ID: <200704171642.55777.subs@eracc.com> On Tuesday 17 April 2007 04:32 pm Nicolas Weeger wrote: > Hum, let me be more precise, then: Okie dokie. :-) > "What about adding the possibility to have alchemy-related recipes use sp > too? Of course we'll let current recipes as they are, but when we extend > recipes to eg create powerful armors, that sp use may come in handy (think > charging the armor with sp to protect you?)" That sounds more like wizardry or sorcery to me so using Sp for that makes sense. > I didn't mean to alter existing formuleas. Whew! Good! :-) Gene Alexander (the relieved whiner :-D ) -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From antonoussik at gmail.com Tue Apr 17 17:16:26 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Tue, 17 Apr 2007 23:16:26 +0100 Subject: [crossfire] Getting more artists In-Reply-To: <86wt0a7myq.fsf@bannor.baugher.biz> References: <1176503235.c7cf017cyann.chachkoff@myrealbox.com> <86wt0a7myq.fsf@bannor.baugher.biz> Message-ID: On 17/04/07, Aaron Baugher wrote: > "Yann Chachkoff" writes: > > > Now, I would not suggest using 64x64 as a new size for > > tiles. Instead, keep the base tile as 32x32, and enlarge various > > objects, so that they take more than a single tile. > > > Why ? Because having a base tile (32x32) that is smaller than the > > default tile (64x64) allows you to make more complex shapes - for > > example, L-shaped tiles. > > I tend to agree. If you stay with 32x32 tiles while making most > objects bigger than that, you could have a 64x64 table, but be able to > put four different food items on it for example. If all the tiles are > 64x64, you may be able to make the actual booze bottle very small, but > you can still only put one of them within a 64x64 area. Unless you start to allow fractional coordinates, such as (2.5, 8.3). I am unsure if a move away from 100% tile-based would be a good thing at this time though. From antonoussik at gmail.com Tue Apr 17 17:22:49 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Tue, 17 Apr 2007 23:22:49 +0100 Subject: [crossfire] Build command In-Reply-To: <200704171642.55777.subs@eracc.com> References: <200704032358.11784.nicolas.weeger@laposte.net> <200704171618.36916.subs@eracc.com> <200704172332.13080.nicolas.weeger@laposte.net> <200704171642.55777.subs@eracc.com> Message-ID: Hmm, actually I think it would be a good idea to nerf existing alchemy. It would go a long way towards fixing the game balance. At the moment being a pure alchemist is far too easy (money-wise). I would also nerf experience gained up though, to make success more rewarding and eliminate the "identification" stage where you have to aimlessly ID things with alchemy until you can make simple stuff reliably. From subs at eracc.com Tue Apr 17 19:43:02 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Tue, 17 Apr 2007 19:43:02 -0500 Subject: [crossfire] Build command In-Reply-To: References: <200704032358.11784.nicolas.weeger@laposte.net> <200704171642.55777.subs@eracc.com> Message-ID: <200704171943.04255.subs@eracc.com> On Tuesday 17 April 2007 05:22 pm Anton Oussik wrote: > Hmm, actually I think it would be a good idea to nerf existing > alchemy. It would go a long way towards fixing the game balance. At > the moment being a pure alchemist is far too easy (money-wise). I > would also nerf experience gained up though, to make success more > rewarding and eliminate the "identification" stage where you have to > aimlessly ID things with alchemy until you can make simple stuff > reliably. I knew it! I knew it! I knew it! You want to ruin it (from a player's perspective). :-p Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From alex_sch at telus.net Wed Apr 18 00:37:00 2007 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 17 Apr 2007 23:37:00 -0600 Subject: [crossfire] Build command In-Reply-To: <200704171943.04255.subs@eracc.com> References: <200704032358.11784.nicolas.weeger@laposte.net> <200704171642.55777.subs@eracc.com> <200704171943.04255.subs@eracc.com> Message-ID: <4625AE7C.3050306@telus.net> ERACC Subscriptions wrote: > On Tuesday 17 April 2007 05:22 pm > Anton Oussik wrote: > > >> Hmm, actually I think it would be a good idea to nerf existing >> alchemy. It would go a long way towards fixing the game balance. At >> the moment being a pure alchemist is far too easy (money-wise). I >> would also nerf experience gained up though, to make success more >> rewarding and eliminate the "identification" stage where you have to >> aimlessly ID things with alchemy until you can make simple stuff >> reliably. >> > > I knew it! I knew it! I knew it! You want to ruin it (from a player's > perspective). :-p Well... I would say that the overall player perspective could be improved indirectly in the long term by "nerfing" certain things that are "overpowered". The thing is, once methods of getting money too easily are fixed so different methods of getting it tend to be on similar orders of magnitude, then we can do a better job of setting up the shop buying/selling algorithms better. Just remember, "nerfing" correctly selected things won't make the game harder in the long term necessarily, it just evens the playing field between different things (different spells, ways of getting money) enough that we can better judge any adjustments to such things as wholes. :) I'd say we definitely need to work on these things in 2.0 (IMHO 1.x isn't the place to be "nerfing" long standing things though unless it's considered a true bug) Alex From yann.chachkoff at myrealbox.com Wed Apr 18 02:43:37 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Wed, 18 Apr 2007 09:43:37 +0200 Subject: [crossfire] Getting more artists Message-ID: <1176882217.c7cc08fcyann.chachkoff@myrealbox.com> > Unless you start to allow fractional coordinates, such as (2.5, 8.3). > I am unsure if a move away from 100% tile-based would be a good thing > at this time though. > Moving to fractional coordinates would be somewhat more complex to implement; enlarging objects so they occupy more tiles requires no changes in the code (except, maybe, to manage multitiled players). From antonoussik at gmail.com Wed Apr 18 07:54:56 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Wed, 18 Apr 2007 13:54:56 +0100 Subject: [crossfire] Build command In-Reply-To: <4625AE7C.3050306@telus.net> References: <200704032358.11784.nicolas.weeger@laposte.net> <200704171642.55777.subs@eracc.com> <200704171943.04255.subs@eracc.com> <4625AE7C.3050306@telus.net> Message-ID: On 18/04/07, Alex Schultz wrote: > ERACC Subscriptions wrote: > > On Tuesday 17 April 2007 05:22 pm > > Anton Oussik wrote: > > > > > >> Hmm, actually I think it would be a good idea to nerf existing > >> alchemy. It would go a long way towards fixing the game balance. At > >> the moment being a pure alchemist is far too easy (money-wise). I > >> would also nerf experience gained up though, to make success more > >> rewarding and eliminate the "identification" stage where you have to > >> aimlessly ID things with alchemy until you can make simple stuff > >> reliably. > >> > > > > I knew it! I knew it! I knew it! You want to ruin it (from a player's > > perspective). :-p > Well... I would say that the overall player perspective could be > improved indirectly in the long term by "nerfing" certain things that > are "overpowered". The thing is, once methods of getting money too > easily are fixed so different methods of getting it tend to be on > similar orders of magnitude, then we can do a better job of setting up > the shop buying/selling algorithms better. Just remember, "nerfing" > correctly selected things won't make the game harder in the long term > necessarily, it just evens the playing field between different things > (different spells, ways of getting money) enough that we can better > judge any adjustments to such things as wholes. :) > I'd say we definitely need to work on these things in 2.0 (IMHO 1.x > isn't the place to be "nerfing" long standing things though unless it's > considered a true bug) In fact it would be good if someone could go through the various money sources with a calculator and computed money earned per hour of work at every level. Then it could be decided what a good balance is, and everything could be nerfed to match that theoretical money earning curve, instead of being chosen randomly. From rbrockway at opentrend.net Wed Apr 18 23:34:01 2007 From: rbrockway at opentrend.net (Robert Brockway) Date: Thu, 19 Apr 2007 00:34:01 -0400 (EDT) Subject: [crossfire] Crossfire+/Crossfire2 Versioning and Metaserver In-Reply-To: <20070414095047.GA11921@elmex> References: <20070413164156.GA9256@elmex> <12126.74.223.6.98.1176520159.squirrel@webmail.sonic.net> <20070414095047.GA11921@elmex> Message-ID: On Sat, 14 Apr 2007, Robin Redeker wrote: >> Calling it most anything with crossfire in its name is confusing. > > I don't really understand that, who finds it confusing and why? Well me for one. I've been away from the Crossfire scene for a while and am just back tonight. This is the first I'd heard of CF+. With a name like that it did not immediately appear to be a fork. I really think a distinct name is better - and besides it lets the new fork grow in its own direction. Cheers, Rob -- Robert Brockway B.Sc. Phone: +1-905-821-2327 Senior Technical Consultant Urgent Support: +1-416-669-3073 OpenTrend Solutions Ltd Email: support at opentrend.net Web: www.opentrend.net Contributing Member of Software in the Public Interest From nicolas.weeger at laposte.net Fri Apr 20 12:39:06 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 20 Apr 2007 19:39:06 +0200 Subject: [crossfire] Game balance: potion of life, healing, cure disease In-Reply-To: <4813.70.147.193.98.1176430567.squirrel@webmail.sonic.net> References: <200704122030.34934.nicolas.weeger@laposte.net> <200704122328.12906.nicolas.weeger@laposte.net> <4813.70.147.193.98.1176430567.squirrel@webmail.sonic.net> Message-ID: <200704201939.06166.nicolas.weeger@laposte.net> > An interesting thought would be to have different level potions, just > like different level wands and scrolls. When a player dies, IIRC, right > now the depletion force for the stat is inserted into them. It would be > simple enough to record the level of the character when that force was > inserted. > > Then, a simple check that the level of the potion (or scroll or other > device, since it is a spell IIRC) is higher, it removes all those > depletions, if not, it doesn't. Just implemented that, and added "minor" (lvl 5), "medium" (lvl 30) and "major" (lvl 50) potions of life :) Current potion of life is renamed to "supreme potion of life", with level 130. I tweaked prices, not sure of the result, but well, can always be adjusted. (this concerns both trunk and branch) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sat Apr 21 04:51:57 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 21 Apr 2007 11:51:57 +0200 Subject: [crossfire] Obsolete flags Message-ID: <200704211151.57626.nicolas.weeger@laposte.net> Hello. There are quite many obsolete things in loader.l, so I'd like to remove'em, but not sure on some things. Also it'll require some map/arch cleaning. First, those flags: * has_ready_rod * has_ready_horn * has_ready_wand mapped to FLAG_READY_RANGE From what i read from the monster handling code, this ready_range flag is actually not required, it'll be calculated again. So IMO those three flags should be removed totally. * can_use_wand mapped to FLAG_USE_RANGE many archetypes use this flag, many in maps... So should be cleaned like crazy :) * immune * protected * vulnerable those kind of conflict with the resist_ values, they'll "override" or mess with them. Unfortunately many (~400) maps still use those, so updating won't be easy. * armour, which should be resist_physical, doesn't seem to be used much. Any volunteers for helping to clean ? :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sat Apr 21 06:13:17 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 21 Apr 2007 13:13:17 +0200 Subject: [crossfire] Discrete damage type Message-ID: <200704211313.17882.nicolas.weeger@laposte.net> Hello. I just committed to SVN trunk changes that enable weapons to have discrete damage for each attack type. It works quite simply: * new object fields 'damage_', so 'damage_fire' and so, like the 'dam' field in living structure * if at least one field is set, 'dam' is ignored for attack, and the discrete values are used instead Implementation details, issues to check/fix: * the discrete damage are stored in a 'discrete_damage' array allocated only if one value is set in archetype definition * i only changed hit_player_attacktype to handle this discrete damage. It is used by many things, including spells attacks, i think. * i know some parts (specially spell attacks) alter dam based on casting spell level. Thus that code should be changed to modify discrete_damage instead - shouldn't be too hard Feel free to flame/comment/..., as usual. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Sun Apr 22 00:22:29 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 21 Apr 2007 22:22:29 -0700 Subject: [crossfire] Obsolete flags In-Reply-To: <200704211151.57626.nicolas.weeger@laposte.net> References: <200704211151.57626.nicolas.weeger@laposte.net> Message-ID: <462AF115.2000600@sonic.net> Nicolas Weeger wrote: > Hello. > > There are quite many obsolete things in loader.l, so I'd like to remove'em, > but not sure on some things. Also it'll require some map/arch cleaning. > > First, those flags: > * has_ready_rod > * has_ready_horn > * has_ready_wand > mapped to FLAG_READY_RANGE >>From what i read from the monster handling code, this ready_range flag is > actually not required, it'll be calculated again. So IMO those three flags > should be removed totally. Probably true - I can't remember now, but certainly at one point, they were used internally - I don't know if they were ever saved out to any maps. > > * can_use_wand mapped to FLAG_USE_RANGE > > many archetypes use this flag, many in maps... So should be cleaned like > crazy :) At the same time, are there any other can_use_... flags out that that have been replaced/supserseded? > > > * immune > * protected > * vulnerable > those kind of conflict with the resist_ values, they'll "override" or mess > with them. > Unfortunately many (~400) maps still use those, so updating won't be easy. yes - like most things in the loader, it supported using these values along with the new, but having both set in the same object was never really considered supported. > > * armour, which should be resist_physical, doesn't seem to be used much. > > Any volunteers for helping to clean ? :) Can't most of this be automated with scripts? For flags that just go away, it'd seem to be a simple 'remove this line' type of logic - not hard at all. The immune/protected/vulnerable may be a little trickier, because if an object is using those plus the resist values, just putting in the corresponding values based on the immune may conflict with those other ones. However, I'd think that would be something pretty easy to catch - only in those cases where that is happening would manual interaction be needed - otherwise, this could be automated. It'd also seem to be that baseline scripts that do this conversion would be useful - it would be a good starting point so if down the road, something else is obsoleted, change the script a little bit and you are good to go. I think there may already be some scripts out there that do this sort of thing. I know I wrote some for the map updates (to update exits & whatnot). From mwedel at sonic.net Sun Apr 22 00:32:44 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 21 Apr 2007 22:32:44 -0700 Subject: [crossfire] Discrete damage type In-Reply-To: <200704211313.17882.nicolas.weeger@laposte.net> References: <200704211313.17882.nicolas.weeger@laposte.net> Message-ID: <462AF37C.1030803@sonic.net> Nicolas Weeger wrote: > Hello. > > I just committed to SVN trunk changes that enable weapons to have discrete > damage for each attack type. > > It works quite simply: > * new object fields 'damage_', so 'damage_fire' and so, like > the 'dam' field in living structure > * if at least one field is set, 'dam' is ignored for attack, and the discrete > values are used instead Random question to everyone at a whole - should the old 'dam' field go away at some point, that is to say, everything should use the discrete damage? This would require map & archetype updates, but that could all be automated - if attacktype is set for say AT_FIRE and AT_PHYSICAL, and dam is 10, then script would just remove that and add damage_fire 10 and damage_physical 10. It also means that attacktype basically goes away - instead, that information is conveyed in the discrete damage fields. Which leads to an interesting question right now: If I set up the discrete damage values for an item, but don't update the attacktype to include those attacks, what happens? I can think of 1 of 2 things: 1) Attacktype is ignored - if the discrete damage is set, that is used no matter what (meaning that attacktype basically could go away if everything was updated) 2) The discrete damage isn't used, since the attacktype isn't set. If #2, should probably be documented someplace. > > > Implementation details, issues to check/fix: > * the discrete damage are stored in a 'discrete_damage' array allocated only > if one value is set in archetype definition Are things smart enough to handle the case where I modify an archetype on the map to included a discrete damage type? For example, suppose I take the standard longsword, which just has a standard dam value, but want to make a specialized weapon - something that still does mostly physical, but a little bit of fire, so I use the discrete damage values to do that. Will that work? IMO, it should, because that is a pretty likely scenario, and from a map maker perspective, I shouldn't have to know the internals of how things work - I should be able to set up discrete damage types and just have it work. > * i only changed hit_player_attacktype to handle this discrete damage. It is > used by many things, including spells attacks, i think. > * i know some parts (specially spell attacks) alter dam based on casting spell > level. Thus that code should be changed to modify discrete_damage instead - > shouldn't be too hard Don't know if done, but I'd also suggest that things like examine object should dump that information. From nicolas.weeger at laposte.net Sun Apr 22 03:11:49 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 22 Apr 2007 10:11:49 +0200 Subject: [crossfire] Discrete damage type In-Reply-To: <462AF37C.1030803@sonic.net> References: <200704211313.17882.nicolas.weeger@laposte.net> <462AF37C.1030803@sonic.net> Message-ID: <200704221011.49389.nicolas.weeger@laposte.net> > Random question to everyone at a whole - should the old 'dam' field go > away at some point, that is to say, everything should use the discrete > damage? In the future, probably, yes. But we must take care, as this field is used for other things than damage, IIRC... Also, we already have many obsolete things to remove :) > This would require map & archetype updates, but that could all be > automated - if attacktype is set for say AT_FIRE and AT_PHYSICAL, and dam > is 10, then script would just remove that and add damage_fire 10 and > damage_physical 10. Yes, that can probably easily be automated. > It also means that attacktype basically goes away - instead, that > information is conveyed in the discrete damage fields. > > Which leads to an interesting question right now: If I set up the > discrete damage values for an item, but don't update the attacktype to > include those attacks, what happens? I can think of 1 of 2 things: > > 1) Attacktype is ignored - if the discrete damage is set, that is used no > matter what (meaning that attacktype basically could go away if everything > was updated) 2) The discrete damage isn't used, since the attacktype isn't > set. > > If #2, should probably be documented someplace. Right now, it's #2. I still use attacktype to know if I should use that attacktype or not. Reason is that no item already has the discrete damage, so I still must "dispatch" to attacktypes. IMO, we should move to #1 at some point - discrete damage should handle that, I think. > Are things smart enough to handle the case where I modify an archetype on > the map to included a discrete damage type? For example, suppose I take > the standard longsword, which just has a standard dam value, but want to > make a specialized weapon - something that still does mostly physical, but > a little bit of fire, so I use the discrete damage values to do that. > > Will that work? IMO, it should, because that is a pretty likely > scenario, and from a map maker perspective, I shouldn't have to know the > internals of how things work - I should be able to set up discrete damage > types and just have it work. Yes, loader will handle that nicely. But it'll totally ignore the 'damage' value you set, in this case. > Don't know if done, but I'd also suggest that things like examine object > should dump that information. True, will do that at some point if no one does that. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sun Apr 22 03:57:13 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 22 Apr 2007 10:57:13 +0200 Subject: [crossfire] Inventories in artifacts/archetypes Message-ID: <200704221057.13444.nicolas.weeger@laposte.net> Hello. I just finished committed to SVN code to handle inventories in artifacts and archetypes. Just put an 'arch xxx', with 'end', like in maps, and it should be handled correctly. All fields can be customized, this is a 'real' loading. Technically, caveats: * if you have more than 10 levels of items in items, you'll get a nice crash - change the MAXDEPTH value in load_object :) (no check, but easy to add) * lex_load (main object loading) now uses an array of items, to be able to track what item is being loaded. This is required for LO_LINEMODE loading mode. As a side node: the existence of LO_LINEMODE is due to loader's inability to 'put back' the stream at last character loaded when returning, from what I see. Thus we "hack" to load line by line manually. If anyone knows a way to force loader to put back file to last read position when 'end' is encountered, that'd be great to simplify the code. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sun Apr 22 08:53:19 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 22 Apr 2007 15:53:19 +0200 Subject: [crossfire] Background music Message-ID: <200704221553.19304.nicolas.weeger@laposte.net> Hello. I just added a 'background_music' field to maps. 'sound' setup has been changed. If client sends '2' as value (instead of 1), support for background music is enabled. When player enters a map, background music name is sent, or 'NONE' if nothing is defined for the map. There is still no client-side support, though. Not sure of the library to use for that (SDL sound, maybe?) background_music value is a free string, so it's up to us to decide what to use. It could be 'style:xxx' to specify a generic style, the client choosing one randomly from its curpus. And 'specific:xxx' to signify a particular background one, for special maps. IMO we could just get some musics from other free software projets :) Next step, sound support! Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From fuchs.andy at gmail.com Sun Apr 22 12:07:13 2007 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun, 22 Apr 2007 13:07:13 -0400 Subject: [crossfire] Background music In-Reply-To: <200704221553.19304.nicolas.weeger@laposte.net> References: <200704221553.19304.nicolas.weeger@laposte.net> Message-ID: <1177261634.5146.9.camel@pluto> On Sun, 2007-04-22 at 15:53 +0200, Nicolas Weeger wrote: > Hello. > > I just added a 'background_music' field to maps. > > 'sound' setup has been changed. If client sends '2' as value (instead of 1), > support for background music is enabled. > > When player enters a map, background music name is sent, or 'NONE' if nothing > is defined for the map. > > There is still no client-side support, though. Not sure of the library to use > for that (SDL sound, maybe?) > > background_music value is a free string, so it's up to us to decide what to > use. > > It could be 'style:xxx' to specify a generic style, the client choosing one > randomly from its curpus. And 'specific:xxx' to signify a particular > background one, for special maps. How is the client going to get the music? Is it going to be included, or will it download it from the server? I would prefer that the "default" sounds get included, and that custom ones can be downloaded by the client. Though in the case of downloading sounds, we need a way to make sure that the client won't mix up two different servers custom music (like two files having the same name). A hash could possibly solve this problem. > IMO we could just get some musics from other free software projets :) This can get annoying, since things can get to a state where almost every gpled game has the exact same music. Another place to find music would be to get public domain scores, and convert them to midi, then put them through a decent interpreter (in terms of sound), though I think a few projects might do this already. From mwedel at sonic.net Sun Apr 22 13:34:38 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 22 Apr 2007 11:34:38 -0700 Subject: [crossfire] Background music In-Reply-To: <200704221553.19304.nicolas.weeger@laposte.net> References: <200704221553.19304.nicolas.weeger@laposte.net> Message-ID: <462BAABE.10102@sonic.net> Nicolas Weeger wrote: > Hello. > > I just added a 'background_music' field to maps. > > 'sound' setup has been changed. If client sends '2' as value (instead of 1), > support for background music is enabled. > > When player enters a map, background music name is sent, or 'NONE' if nothing > is defined for the map. I almost wonder if it is worthwhile for the server to know/care about the client sound settings - it keeps the server simpler if it doesn't. The only reason it makes any sense is some bandwidth savings, but the savings for this, especially for the backgrounds ones on the map, is pretty trivial. > > There is still no client-side support, though. Not sure of the library to use > for that (SDL sound, maybe?) A fair amount depends on the format we use for the sound files. For the current unix client, I think the current sound program could be used pretty easily with a few minor modifications (basically, it just keeps copying in the sound data to the sound card). > > background_music value is a free string, so it's up to us to decide what to > use. > > It could be 'style:xxx' to specify a generic style, the client choosing one > randomly from its curpus. And 'specific:xxx' to signify a particular > background one, for special maps. That sounds good. > From mwedel at sonic.net Sun Apr 22 13:47:45 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 22 Apr 2007 11:47:45 -0700 Subject: [crossfire] Background music In-Reply-To: <1177261634.5146.9.camel@pluto> References: <200704221553.19304.nicolas.weeger@laposte.net> <1177261634.5146.9.camel@pluto> Message-ID: <462BADD1.2010000@sonic.net> Andrew Fuchs wrote: > > How is the client going to get the music? Is it going to be included, > or will it download it from the server? I would prefer that the > "default" sounds get included, and that custom ones can be downloaded by > the client. Though in the case of downloading sounds, we need a way to > make sure that the client won't mix up two different servers custom > music (like two files having the same name). A hash could possibly > solve this problem. Currently, all sounds are managed by the client - the server has no idea what sound files are, etc, and can't supply them. That keeps things simple and tends to work, since sound isn't a required part of the game. If servers do start using custom sound files, it'd probably work just fine for them to make those available on an ftp server someplace and tell the players to download them if they want. What I'd suggest for a directory layout, on the client side, is something like this: sounds/music/general/*.wav - sounds files explicitly mentioned by name sounds/music/