From juhaj at iki.fi Thu Jan 1 19:46:18 2009 From: juhaj at iki.fi (Juha =?iso-8859-1?q?J=E4ykk=E4?=) Date: Fri, 02 Jan 2009 03:46:18 +0200 Subject: [crossfire] What about a gameplay revolution? In-Reply-To: <4951BB91.3000104@sonic.net> References: <200812141316.12165.nicolas.weeger@laposte.net> <200812231630.38455.juhaj@iki.fi> <4951BB91.3000104@sonic.net> Message-ID: <200901020346.36362.juhaj@iki.fi> > > Nice point. Perhaps the recipies should be force-objects on the > > character? > Yes - that would work. It would also allow something along the line of > 'what recipes do I know'. Instead of having to jot down recipes you find > in the game someplace else (or keep all those scrolls), one could get a > listing of all recipes you found, etc. This would imply that one cannot learn recipies by talking to other players, would it not? That may be good but it could also be bad. (I'm assuming a character cannot create items whose recipies are unknown to the character.) Either some recipies would have to be much more common or there would need to be a shop for them. > I think you do have a valid point. One problem (IMO - others don't see > it this way) is that any class can pick up any skill. So while racial > bonuses do matter, what class you start with doesn't have much impact. I belong to the sect which supports almost meaningless classes, but there would need to be some incentive to specialise in a single class. Somewhere in this (or some other?) thread the suggestion of using the highest skill level for HP and perhaps something else, too, would be one step in that direction. Another might be gradual loss of skills if they are unused. That would definitely be realistic, but would it be fun? I don't know (I usually only play heavy magic users without much focus on melee so it would not matter much to my style of playing). > Another possibility is limiting certain items by class and/or race. > Maybe only spellcasters can use a wand in their hand instead of some other > weapon. If like above, that wand has affinities for spellcasting type > skills, it effectively gives them a leg up. Likewise, certain weapons > should probably only be usable by fighter. If we want to prevent fighters > from be mages, mages also shouldn't be able to be fighters. I agree that the prevention must go both ways, but I have always disliked the [A]D&D way of class preventing use of an item. There might be a skill to use wand (one that magic users initially have) or something, but not a total block. Also, to increase the effectiveness of wands in magic users' hands, their power might be tied not only to the level of the wand, but also to the magic-skill-level of the user, or even Pow score or something (Str gives fighters bonus to damage, why not Pow to wands?). Also, it might be nice to have race-bound items. There's a lot more basis for requiring a certain race to use an item - no other race has a fireborn's tentacles or an elf's pointy ears, for example; skills to use items can be acquired, racial features cannot - especially racial "mystical" features like "elven soul" or something. Bind items to those and they effectively belong to that race (there might be a quest brewing here, too...) A little less drastic race-item would be one which acquires an extra powers (or loses some) or becomes more (or less!) powerful when wielded by members of certain race(s). A mystic dwarven battle axe might give an additional "slay orcs" power when wielded by a dwarf etc. (And if wielded by an orc it might behave as a Damned weapon?) -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20090102/671d8b28/attachment.pgp From mwedel at sonic.net Thu Jan 1 22:45:08 2009 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 01 Jan 2009 20:45:08 -0800 Subject: [crossfire] What about a gameplay revolution? In-Reply-To: <200901020346.36362.juhaj@iki.fi> References: <200812141316.12165.nicolas.weeger@laposte.net> <200812231630.38455.juhaj@iki.fi> <4951BB91.3000104@sonic.net> <200901020346.36362.juhaj@iki.fi> Message-ID: <495D9BD4.2010800@sonic.net> Juha J?ykk? wrote: >>> Nice point. Perhaps the recipies should be force-objects on the >>> character? >> Yes - that would work. It would also allow something along the line of >> 'what recipes do I know'. Instead of having to jot down recipes you find >> in the game someplace else (or keep all those scrolls), one could get a >> listing of all recipes you found, etc. > > This would imply that one cannot learn recipies by talking to other players, > would it not? That may be good but it could also be bad. (I'm assuming a > character cannot create items whose recipies are unknown to the character.) > Either some recipies would have to be much more common or there would need to > be a shop for them. Note that right now, a recipe does not disappear when read. So in practice, characters/players could share recipes fairly easily as long as they keep the recipe books. That seems reasonable. A character would not be able to write down recipes (or maybe only could do so with appropriate skill level) and hand it off. The recipe management is really a convenience for the player (and some other benefits) - it may not imply an ability to impart that knowledge to other people. In real life, one could see this as most people know how to make some number of food items without following a recipe. But if you tried to tell someone else how to do it, especially if they are novice, you may leave out steps, put something in the wrong order, etc. When you make it yourself, this would be apparent - but for someone else that doesn't know better, this could be a real problem. Some number of recipes should probably basically be common knowledge. One doesn't have a recipe to tell people how to boil water, and same could be true for some basics in crossfire. And some number of recipes probably should be allowed without all that complexity, so could be found out reading the formulae file, talking to other players. But the more advanced recipes probably require actual having learned it. It may also be that at certain levels of those skills (including level 1), you learn various recipes. Level 1 might be the the basics. Level 10 you might learn some recipes automatically - this in a sense is that after enough experience, you'd probably figure out how to do some more complex stuff even if you don't have a recipe. And just like spell books having been made more available by the bookshop (sells common spells but at inflated prices), same could perhaps be true of recipes - finding more recipes should be easier to do, but maybe it costs something. > >> I think you do have a valid point. One problem (IMO - others don't see >> it this way) is that any class can pick up any skill. So while racial >> bonuses do matter, what class you start with doesn't have much impact. > > I belong to the sect which supports almost meaningless classes, but there > would need to be some incentive to specialise in a single class. Somewhere in > this (or some other?) thread the suggestion of using the highest skill level > for HP and perhaps something else, too, would be one step in that direction. > Another might be gradual loss of skills if they are unused. That would > definitely be realistic, but would it be fun? I don't know (I usually only > play heavy magic users without much focus on melee so it would not matter > much to my style of playing). There are those two schools of thoughts, as it relates to skills. I don't think there is necessary a right or wrong answer to it, but that answer probably needs to be decided. I'm not fond of taking away exp for lack of use of skills. Defining lack of use becomes problematic (if I kill 1 orc every hour, is that enough to not have my fighting skill go down, etc?) Simplest way to do it is that for every X ticks of play, exp in all skills go down Y%. Values of X and Y would have to be determined. In a sense, skills you don't use would eventually lose all exp. The problem here is that this messes up folks that want to hang around and help other players, chat, etc. It also means you really want to optimize the time you're not gaining exp (taking half an hour to sell your items means you have lost some exp, etc). And things brings a new meaning of characters who forget to log out - you no longer die of starvation - you just lack any exp. So rather than penalize folks, I'd much rather reward certain behavior. I think that is generally easier to do with fewer side effects. >> Another possibility is limiting certain items by class and/or race. >> Maybe only spellcasters can use a wand in their hand instead of some other >> weapon. If like above, that wand has affinities for spellcasting type >> skills, it effectively gives them a leg up. Likewise, certain weapons >> should probably only be usable by fighter. If we want to prevent fighters >> from be mages, mages also shouldn't be able to be fighters. > > I agree that the prevention must go both ways, but I have always disliked the > [A]D&D way of class preventing use of an item. There might be a skill to use > wand (one that magic users initially have) or something, but not a total > block. Also, to increase the effectiveness of wands in magic users' hands, > their power might be tied not only to the level of the wand, but also to the > magic-skill-level of the user, or even Pow score or something (Str gives > fighters bonus to damage, why not Pow to wands?). > This sort of goes back to that decision above - should crossfire have stricter classes, or should classes be meaningless (aside from starting skills). If the former, then tieing things to skills makes sense - you can't use a sword because you don't have the skill, etc. And in a strict class system, you wouldn't be able to learn the skill. Crossfire currently has teh second case, where classes are meaningless, so skill restrictions don't mean much, because you'll just learn the skill at some point - its only meaning is the first few levels until you find/can afford the appropriate skill scroll. > Also, it might be nice to have race-bound items. There's a lot more basis for > requiring a certain race to use an item - no other race has a fireborn's > tentacles or an elf's pointy ears, for example; skills to use items can be > acquired, racial features cannot - especially racial "mystical" features > like "elven soul" or something. Bind items to those and they effectively > belong to that race (there might be a quest brewing here, too...) Yes - race bound items should be used more. From mwedel at sonic.net Thu Jan 1 22:54:33 2009 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 01 Jan 2009 20:54:33 -0800 Subject: [crossfire] [Rebootworld] Priests and prayers and cults In-Reply-To: <200901010057.41026.juhaj@iki.fi> References: <4959B37A.4010703@sonic.net> <200901010057.41026.juhaj@iki.fi> Message-ID: <495D9E09.1010309@sonic.net> Juha J?ykk? wrote: >> 4) could also have competing quests. Maybe half a dozen different folks >> want the goblin king killed. Player has to decide which one he really goes >> for (an example here could be that basically all the different classes >> (skills) want him killed and give some form of exp reward or maybe >> something different. In this way, every class can get something from it - >> do you want that fighter experience of praying experience. Sort of >> counters the problem I mentioned above with only healers having quests for >> exp. This also helps out the problem where in a sense, you don't have to >> write as many quests - a bunch of quests could use the same maps. > > This sounds excellent. There is a big problem in 1.x giving mainly weapons as > quest rewards. The above would both help that AND help keeping map-making > work at a sane level. There should be some way of handling parties, though, > in this case. And also perhaps a way to prevent the magic-using class from > getting the basher reward. Perhaps most quests would be given out by > guilds/kings/temples/ and they might not accept you > since you "are too low in bashing level/have too little reputation/are of > wrong religion/pick your favourite again". There are diffferent ways to handle this. Even right now, most of the quests don't work very well because they require some form of proof (body part) of which there is one of, or they let the party into a common treasure room where the party has to divide the loot. Recording everyone 'near' the boss creature when it was killed as a force object could easily enough be done. Sure there are some ways to abuse this, but we can't 100% eliminate those, and more have to focus on making things fun than trying to solve all potential abuses. When you go get the reward, it checks to make sure you have appropriate force to indicate you where there when creature was killed, gives you the reward, removes that force and adds a new one that denotes quest completed or the like (to prevent repeating it for all the other rewards) If a magic user wants to get the basher reward, maybe not a problem. That said, just as the scorn nobility quest is a chain quest (you have to do them in order), same could basically be true for these class based quests. If you've done the first 4 as a wizard, and try to get the fighter reward for the fifth one, they might say 'who the hell are you?' type of thing. Or maybe base it on skill level. The fighter guild may not care about order of quests, but they are not going to give out some good item to some newbie fighter, even if the character has lots of exp. However, if the character has 10 levels of a fighter type skill, that may be considered good enough for them to give the reward. > > -Juha > > > > ------------------------------------------------------------------------ > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From juhaj at iki.fi Tue Jan 6 16:32:18 2009 From: juhaj at iki.fi (Juha =?iso-8859-1?q?J=E4ykk=E4?=) Date: Wed, 07 Jan 2009 00:32:18 +0200 Subject: [crossfire] What about a gameplay revolution? In-Reply-To: <495D9BD4.2010800@sonic.net> References: <200812141316.12165.nicolas.weeger@laposte.net> <200901020346.36362.juhaj@iki.fi> <495D9BD4.2010800@sonic.net> Message-ID: <200901070032.50650.juhaj@iki.fi> > And just like spell books having been made more available by the bookshop > (sells common spells but at inflated prices), same could perhaps be true of > recipes - finding more recipes should be easier to do, but maybe it costs > something. This sounds reasonable and actually quite good, too. > don't think there is necessary a right or wrong answer to it, but that > answer probably needs to be decided. Yup. And you raised a good point about reducing xp when not using skills. Something else would need to be done - or nothing. > This sort of goes back to that decision above - should crossfire have > stricter classes, or should classes be meaningless (aside from starting > skills). I'd prefer to find a middle ground. Something where we can let everyone be capable of using all skills, but with some class-features still intact so that there is no way a basher can become as good a magic-user as a wizard. Perhpas simply requiring the "main skill", i.e. whatever is tied to the class, to always be higher than any other skill? Or higher than all other skills combined (this would need some adjustment on first level). There could be a guild whose services are necessary to gain a new level (or something) and the guild would simply kick you out if you violate the above rule. Or something. > Yes - race bound items should be used more. Could not agree more. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20090107/0fd51ded/attachment.pgp From juhaj at iki.fi Tue Jan 6 16:44:29 2009 From: juhaj at iki.fi (Juha =?iso-8859-1?q?J=E4ykk=E4?=) Date: Wed, 07 Jan 2009 00:44:29 +0200 Subject: [crossfire] [Rebootworld] Priests and prayers and cults In-Reply-To: <495D9E09.1010309@sonic.net> References: <200901010057.41026.juhaj@iki.fi> <495D9E09.1010309@sonic.net> Message-ID: <200901070044.46076.juhaj@iki.fi> > If a magic user wants to get the basher reward, maybe not a problem. > That said, just as the scorn nobility quest is a chain quest (you have to > do them in order), same could basically be true for these class based > quests. If you've done the first 4 as a wizard, and try to get the fighter > reward for the fifth one, they might say 'who the hell are you?' type of > thing. > > Or maybe base it on skill level. The fighter guild may not care about > order of quests, but they are not going to give out some good item to some > newbie fighter, even if the character has lots of exp. However, if the > character has 10 levels of a fighter type skill, that may be considered > good enough for them to give the reward. Sounds fair enough. The reward might also not be static at all, but depend on the skill level. Or perhaps even the number of previous same-type quest rewards given to the player. So if you suddenly decide you want the basher reward after first getting 10 wizard rewards, you'd get the "low-level" reward. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20090107/bb9c8ee1/attachment.pgp From leaf at real-time.com Tue Jan 6 16:52:46 2009 From: leaf at real-time.com (Rick Tanner) Date: Tue, 06 Jan 2009 16:52:46 -0600 Subject: [crossfire] GTKv2 trunk client to branches/1.x client (was Release 1.12) Message-ID: <4963E0BE.7060004@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lalo Martins wrote: > > - By January 20th I'd like to merge all trunk changes that are > sufficiently tested into branch and cut a RC1. Since I haven't > been following everything that happened in the last year and a > half, I kindly ask people to tell me which changes are known > good, which are known bad, and the rest we'll make an effort to > test in this time window. In regards to the client, here's what one distro (debian) had to say.. >> Subj: Re: Bug#510778: Please drop crossfire-client-gtk binary package >> >> Package: crossfire-client-gtk >> Severity: normal >> >> GTK 1.2 will be removed after Lenny release. Please drop the binary >> crossfire-client-gtk binary package. >> >> Cheers, >> Moritz >> >> -- System Information: >> Debian Release: 4.0 >> APT prefers stable >> APT policy: (990, 'stable') >> Architecture: i386 (i686) >> Shell: /bin/sh linked to /bin/bash >> Kernel: Linux 2.6.18 >> Locale: LANG=de_DE.UTF-8 at euro, LC_CTYPE=de_DE.UTF-8 at euro (charmap=UTF-8) My thoughts: Due to the significant layout changes between the GTKv1 and GTKv2 client and to ease the transition for players - I think the gtk-v1.glade layout should be set as the default layout. What we have in Trunk right now should become the current branches/1.x client that all the Linux distros would then release through their repository. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJY+C+hHyvgBp+vH4RAtSiAJ9XRfOIdUTnddflbZUnk9N/GgvN2gCaA+Ny cMt2t3LEU+bLYmctaCkuR+U= =2g5i -----END PGP SIGNATURE----- From leaf at real-time.com Tue Jan 6 16:58:11 2009 From: leaf at real-time.com (Rick Tanner) Date: Tue, 06 Jan 2009 16:58:11 -0600 Subject: [crossfire] Release 1.12 In-Reply-To: References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> Message-ID: <4963E203.1030201@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lalo Martins wrote: > - As suggested earlier on this thread, current trunk will become > further 1.x releases. I remind you, that's for content; the > decision whether or not to do the same wrt server and clients > will be left to the people who take charge of code. Going with the assumption that this takes place... Some sort of clear notification or announcement will need to be included that that player files and content from 1.11 servers are incompatible with the 1.12 release. AFAIK, there are maps in trunk that require (as in will only work with..) archetypes and server code changes in trunk. So, migrating just map(?) content from trunk will likely cause complications or break things. Or, has this been addressed and I missed such a post? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJY+IDhHyvgBp+vH4RAtVXAKCDSUp3BpWyO8o0yjiDY4GGRiRsPQCg02OY 3sg/X+KKlbK01A8dHkCYTlA= =5zPj -----END PGP SIGNATURE----- From lalo.martins at gmail.com Tue Jan 6 18:22:52 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 7 Jan 2009 00:22:52 +0000 (UTC) Subject: [crossfire] Release 1.12 References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> Message-ID: quoth Rick Tanner as of Tue, 06 Jan 2009 16:58:11 -0600: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Lalo Martins wrote: >> - As suggested earlier on this thread, current trunk will become >> further 1.x releases. I remind you, that's for content; the decision >> whether or not to do the same wrt server and clients will be left to >> the people who take charge of code. > > Going with the assumption that this takes place... > > Some sort of clear notification or announcement will need to be included > that that player files and content from 1.11 servers are incompatible > with the 1.12 release. > > AFAIK, there are maps in trunk that require (as in will only work > with..) archetypes and server code changes in trunk. So, migrating just > map(?) content from trunk will likely cause complications or break > things. > > Or, has this been addressed and I missed such a post? Maps and arch are "content". The fact that the server ships with collected archetypes is a bit confusing there, as is the fact that the artifacts, recipes, etc files are in the server tree; I'd like those bits of confusion to be cleared up in 2.x. On the other side, there are scripts in maps that can be considered both code and content :-) Can you make a list, either here or the wiki, of known points where 1.12 would break backwards compatibility? I don't mind required that content is updated in step, but breaking character compatibility I'd prefer not to (last time that happened people were pretty mad, and with 2.0 in the horizon... no need to aggravate people too much.) If we can boil the incompatibility to only the combat rebalance, then I suppose I could write a script that fixes characters. Or we leave the rebalance to 1.13 and then include said script. 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Tue Jan 6 19:54:31 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 7 Jan 2009 01:54:31 +0000 (UTC) Subject: [crossfire] Release 1.12 References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> Message-ID: quoth Lalo Martins as of Wed, 07 Jan 2009 00:22:52 +0000: > Can you make a list, either here or the wiki, of known points where 1.12 > would break backwards compatibility? I don't mind required that content > is updated in step, but breaking character compatibility I'd prefer not > to (last time that happened people were pretty mad, and with 2.0 in the > horizon... no need to aggravate people too much.) Actually, let me rephrase that :-) Under the premise that current trunk arches and maps will be a 1.12 content release, I already expressed that I'd like those tested. I'm now saying that any changes in trunk maps or arches that make 1.11 characters unusable, with the exception of Mark's rebalance (which we don't know yet if we'll include in 1.12), are to be considered bugs and reported accordingly. (Of course, the "fix" will be simply to not merge those changes.) Anyone who knows about them can report them here, or on the tracker, or the wiki. Content changes that require trunk code are another matter. I'd like to have a list of those if someone who knows about it has the time to compile it; but it's unclear whether these are bugs, until the code leader decides about a 1.12 code release. I'll be putting a few hours this week into getting acquainted with all differences between trunk and branch content, and I'll do the work above alone if necessary, but it will be faster if people already in the know can contribute :-) 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From kbulgrien at att.net Tue Jan 6 20:04:18 2009 From: kbulgrien at att.net (Kevin Bulgrien) Date: Tue, 6 Jan 2009 20:04:18 -0600 Subject: [crossfire] GTKv2 trunk client to branches/1.x client (was Release 1.12) In-Reply-To: <4963E0BE.7060004@real-time.com> References: <4963E0BE.7060004@real-time.com> Message-ID: <20090106200418.419e2721@a850srvr.kbulgrien.att.net> > > - By January 20th I'd like to merge all trunk changes that are > > sufficiently tested into branch and cut a RC1. Since I haven't > > been following everything that happened in the last year and a > > half, I kindly ask people to tell me which changes are known > > good, which are known bad, and the rest we'll make an effort to > > test in this time window. > > In regards to the client, here's what one distro (debian) had to say.. > > >> Subj: Re: Bug#510778: Please drop crossfire-client-gtk binary package > >> > >> Package: crossfire-client-gtk > >> Severity: normal > >> > >> GTK 1.2 will be removed after Lenny release. Please drop the binary > >> crossfire-client-gtk binary package. > >> > >> Cheers, > >> Moritz > >> > >> -- System Information: > >> Debian Release: 4.0 > >> APT prefers stable > >> APT policy: (990, 'stable') > >> Architecture: i386 (i686) > >> Shell: /bin/sh linked to /bin/bash > >> Kernel: Linux 2.6.18 > >> Locale: LANG=de_DE.UTF-8 at euro, LC_CTYPE=de_DE.UTF-8 at euro (charmap=UTF-8) Why don't people get that you can build GTK-V1 with GTK2? This is the only way the Windows client is built. I don't think it should be dropped until jxclient is released. If anything, change the default build to use GTK2. > My thoughts: > > Due to the significant layout changes between the GTKv1 and GTKv2 client > and to ease the transition for players - I think the gtk-v1.glade layout > should be set as the default layout. That's ok with me, though I think I'd probably pick the V1-Redux over the straight up GTK-V1 layout. > What we have in Trunk right now should become the current branches/1.x > client that all the Linux distros would then release through their > repository. I wholeheartedly agree, but we need to be sure mwedel's changes are completed or we release prior to that change. His check in comment said that server changes need to be made to avoid horking up the display. Further, he changed only the GTK-V2 layout and not all the other layout files for the resizing thing he did. By the way, I'm also ok with thinning the number of offered layouts in a default install might be wise. Perhaps we could pack up the others by adding a package for extra layouts. If we do something like that, we probably need to try to test the water and see what people think about the various layouts, though I'd tend to package the layouts that work for lower screen resolutions with the client... which reminds me I still haven't checked in that 640x480 layout. Kevin From leaf at real-time.com Tue Jan 6 20:35:13 2009 From: leaf at real-time.com (Rick Tanner) Date: Tue, 06 Jan 2009 20:35:13 -0600 Subject: [crossfire] Release 1.12 In-Reply-To: References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> Message-ID: <496414E1.1010406@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lalo Martins wrote: > > Content changes that require trunk code are another matter. I'd like to > have a list of those if someone who knows about it has the time to > compile it; One that I am aware of, r10699 through r10701 Re-enable cfpython to change player's title Allow player dragons to pick metabolism focus in the hallofselection, also change player title As far as changes/differences from between trunk and branch from a player perspective, a list was started on the wiki: http://wiki.metalforge.net/doku.php/trunk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJZBThhHyvgBp+vH4RAn/rAKC0QC1HjtC838opw3A8VjCBpj4bhQCgh8pQ Dju7cLN3i3p6Q33kjD1V1wE= =uKdv -----END PGP SIGNATURE----- From lalo.martins at gmail.com Tue Jan 6 21:44:47 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 7 Jan 2009 03:44:47 +0000 (UTC) Subject: [crossfire] Release 1.12 References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> <496414E1.1010406@real-time.com> Message-ID: quoth Rick Tanner as of Tue, 06 Jan 2009 20:35:13 -0600: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Lalo Martins wrote: >> >> Content changes that require trunk code are another matter. I'd like >> to have a list of those if someone who knows about it has the time to >> compile it; > > One that I am aware of, r10699 through r10701 > > Re-enable cfpython to change player's title > > Allow player dragons to pick metabolism focus in the hallofselection, > also change player title LOL guilty as charged... I wrote those! I have no problem reverting them in 1.12 if there won't be an 1.12 server release. > As far as changes/differences from between trunk and branch from a > player perspective, a list was started on the wiki: > > http://wiki.metalforge.net/doku.php/trunk Cool, thanks. 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From leaf at real-time.com Wed Jan 7 00:10:13 2009 From: leaf at real-time.com (Rick Tanner) Date: Wed, 07 Jan 2009 00:10:13 -0600 Subject: [crossfire] Release 1.12 In-Reply-To: <496414E1.1010406@real-time.com> References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> <496414E1.1010406@real-time.com> Message-ID: <49644745.7030005@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lalo Martins wrote: > Content changes that require trunk code are another matter. I'd like to > have a list of those if someone who knows about it has the time to > compile it; As I (re)discover or remember the differences, here's some more. Monster generator limits (i.e., generator_limit 10) scorn/houses/resir houses/easy_house.1.c misc/beginners scorn/temples/valkyrie2 scorn/misc/beginners2 start/newbieshouse Maps where monster population and stats (lower AC, reduced Wc) are designed for the combat system in trunk: /quests/saromok/* darcap/pygmy_forest/* The Fun Zone maps, I'm not sure if there is anything with those maps; they need a closer look. darcap/darcap/circus/fz_* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklkRzoACgkQhHyvgBp+vH5tfACg9cFz+FOYO9P0RseSNKVMN5sv M0cAn2HukmcwKNhBt8iVzMdtSgToUQhH =O1w1 -----END PGP SIGNATURE----- From mwedel at sonic.net Wed Jan 7 01:05:20 2009 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 06 Jan 2009 23:05:20 -0800 Subject: [crossfire] What about a gameplay revolution? In-Reply-To: <200901070032.50650.juhaj@iki.fi> References: <200812141316.12165.nicolas.weeger@laposte.net> <200901020346.36362.juhaj@iki.fi> <495D9BD4.2010800@sonic.net> <200901070032.50650.juhaj@iki.fi> Message-ID: <49645430.3060208@sonic.net> Juha J?ykk? wrote: > > I'd prefer to find a middle ground. Something where we can let everyone be > capable of using all skills, but with some class-features still intact so > that there is no way a basher can become as good a magic-user as a wizard. > Perhpas simply requiring the "main skill", i.e. whatever is tied to the > class, to always be higher than any other skill? Or higher than all other > skills combined (this would need some adjustment on first level). There could > be a guild whose services are necessary to gain a new level (or something) > and the guild would simply kick you out if you violate the above rule. Or > something. A quick thought is that each class has some set of associated skills (wizards would have the various magic skills, fighters the combat skills, priests praying, etc). There would likely be some overlap between different classes (there is not a 1:1 relation - one handed weapons might be associated with several classes for example). Following previous discussion about highest skill level determining hit points, one could refine it further such that highest skill level of those associated skills determines hit points. So a fighter with level 10 is 1 handed weapons (and little in anything else) could decide to become a mage and use those magic skills. However, unless he improves that 1 handed weapon, he will only have hit points as a 10th level character. But I'm also sort of inclined that not all classes should necessarily have all skills available (or even most). Some skills are ones that I'd say are not as adventure related (item creation skills, etc), and so sure, everyone can have those. But for others, one could ask the question why should I play X if I can play Y and just get all those skills? Should instead of having classes, should we just let people pick what skills they want? As long as skills are available via skillscrolls, even a first level character could learn new skills as long as they have a benefactor. The other possibility which has been suggested before is quality of skills. Going for that example above, each class would have a set of skills associated with it - these are primary skills. Players can learn skills in the game through various methods, but these are secondary skills. Main difference between secondary skills gain exp at a slower rate of experience. So back to that fighter example, he could pick up magic use at first level, but if it takes double the exp to gain levels in it, probably not the best way to go. Not some of the misc skills might not have a different version - so while some classes may start with smithery, anyone could learn it later with no penalty. From mwedel at sonic.net Wed Jan 7 01:15:35 2009 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 06 Jan 2009 23:15:35 -0800 Subject: [crossfire] [Rebootworld] Priests and prayers and cults In-Reply-To: <200901070044.46076.juhaj@iki.fi> References: <200901010057.41026.juhaj@iki.fi> <495D9E09.1010309@sonic.net> <200901070044.46076.juhaj@iki.fi> Message-ID: <49645697.3010803@sonic.net> Juha J?ykk? wrote: >> If a magic user wants to get the basher reward, maybe not a problem. >> That said, just as the scorn nobility quest is a chain quest (you have to >> do them in order), same could basically be true for these class based >> quests. If you've done the first 4 as a wizard, and try to get the fighter >> reward for the fifth one, they might say 'who the hell are you?' type of >> thing. >> >> Or maybe base it on skill level. The fighter guild may not care about >> order of quests, but they are not going to give out some good item to some >> newbie fighter, even if the character has lots of exp. However, if the >> character has 10 levels of a fighter type skill, that may be considered >> good enough for them to give the reward. > > Sounds fair enough. The reward might also not be static at all, but depend on > the skill level. Or perhaps even the number of previous same-type quest > rewards given to the player. So if you suddenly decide you want the basher > reward after first getting 10 wizard rewards, you'd get the "low-level" > reward. That would work, but also have to be careful about it - you don't want some character to do a whole bunch of the basic low level quests and having done enough, now gets a really nice item. While perhaps not as interesting, I sort of like the idea of static rewards for most quests (or at least static based on quest giver - if there are several folks that want something done, they may give out different items). A few reasons for this - less reason to repeat quests if you're just going to get the same reward. Or conversely, if you get different rewards, you now get a case where you want to be able to repeat them (I did quest XYZ and got this crappy item). But I think it also allows for better tuning - you can have a better idea of character power, etc, and appropriate reward. It also perhaps doesn't make a lot of sense to get better rewards based on skill level. A level 40 fighter who goes and does a goblin quest probably should still be given the same crappy item - the person giving the quest hasn't suddenly come across a lot nicer weapon to give away - what he has is what he has. In a sense if I'm offering a reward for something, my reward isn't likely to vary based on who does it. One other note - while I mentioned idea of using same quest for different classes, they may not all be the same. For example: fighter: A->B->C->D->E wizard: A->F->G->D->E cleric: H->B->C->D->I and so on (each letter represents one quest in the chain). That example may be a bit more complicated then what would really get done, but sort of helps mix things up some. Could also have some quests with more links in the chain, or maybe for some, the order is different based on difficulty (something could be a lot harde for a fighter than for a wizard as an example) > > -Juha > > > > ------------------------------------------------------------------------ > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Wed Jan 7 01:26:53 2009 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 06 Jan 2009 23:26:53 -0800 Subject: [crossfire] GTKv2 trunk client to branches/1.x client (was Release 1.12) In-Reply-To: <20090106200418.419e2721@a850srvr.kbulgrien.att.net> References: <4963E0BE.7060004@real-time.com> <20090106200418.419e2721@a850srvr.kbulgrien.att.net> Message-ID: <4964593D.10004@sonic.net> Kevin Bulgrien wrote: >>> - By January 20th I'd like to merge all trunk changes that are > > Why don't people get that you can build GTK-V1 with GTK2? This is the only > way the Windows client is built. I don't think it should be dropped until > jxclient is released. If anything, change the default build to use GTK2. Just from a support/maintenance standpoint, I'd be in favor of getting rid of the gtk client. The main reason it has been around so long is because folks didn't really like the layout of the gtk2 client. But with the different layout options, that is really all fixed - I can't really think of a compelling reason why the gtk1 client should be retained any longer. >> What we have in Trunk right now should become the current branches/1.x >> client that all the Linux distros would then release through their >> repository. > > I wholeheartedly agree, but we need to be sure mwedel's changes are completed > or we release prior to that change. His check in comment said that server > changes need to be made to avoid horking up the display. Further, he changed > only the GTK-V2 layout and not all the other layout files for the resizing > thing he did. The other layouts should get updated - I didn't even think about that. With unmodifed layout files, things should work just as good as they did before. Which is you won't be able to resize the map window, so those changes I made just won't get used. Testing with the other layouts would likely need to get done. The reason the size for the map window was removed was that it acted as a minimum size (or so I seem to recall). That said, without a size parameter, it may default to a not very useful layout. I already have the server changes - they are fairly trivial - I'm just not sure if they will have bad effects with other clients. The change is basically that whenever the server gets a new map size, it clears all its cache and thus resends the entire map to the client. What I'm not sure is if other clients actually will change the mapsize after play starts, and if clearing that data would give a result they don't want (it sort of has a bad side effect on the client in that it will also clear all fog of war information). My belief is that the resizing of the map window is really something a player will do to get the desired layout they want, and not something will be constantly playing with. > > By the way, I'm also ok with thinning the number of offered layouts in a > default install might be wise. Perhaps we could pack up the others by > adding a package for extra layouts. If we do something like that, we > probably need to try to test the water and see what people think about > the various layouts, though I'd tend to package the layouts that work > for lower screen resolutions with the client... which reminds me I still > haven't checked in that 640x480 layout. My only issue with a bunch of different layouts is potential support issues - if one is rendered oddly and bugs are filed, if it is a standard layout, that sort of suggests it is something we should fix. I'm not sure if we could do some form of unsupported or contrib layouts - basically, we make these available, but use at your own risk and we don't offer any support for them. From kbulgrien at att.net Wed Jan 7 06:49:17 2009 From: kbulgrien at att.net (Kevin Bulgrien) Date: Wed, 7 Jan 2009 06:49:17 -0600 Subject: [crossfire] GTKv2 trunk client to branches/1.x client (was Release 1.12) In-Reply-To: <4964593D.10004@sonic.net> References: <4963E0BE.7060004@real-time.com> <20090106200418.419e2721@a850srvr.kbulgrien.att.net> <4964593D.10004@sonic.net> Message-ID: <20090107064917.5f47ef92@a850srvr.kbulgrien.att.net> > > Why don't people get that you can build GTK-V1 with GTK2? This is the only > > way the Windows client is built. I don't think it should be dropped until > > jxclient is released. If anything, change the default build to use GTK2. > > Just from a support/maintenance standpoint, I'd be in favor of getting rid of > the gtk client. > > The main reason it has been around so long is because folks didn't really like > the layout of the gtk2 client. But with the different layout options, that is > really all fixed - I can't really think of a compelling reason why the gtk1 > client should be retained any longer. All I'm saying is there is no Windows to release if GTK-V1 is gone, though I do suppose that keeping it around for Windows does not mean you have to keep it around for *nix. > > I wholeheartedly agree, but we need to be sure mwedel's changes are completed > > or we release prior to that change. His check in comment said that server > > changes need to be made to avoid horking up the display. Further, he changed > > only the GTK-V2 layout and not all the other layout files for the resizing > > thing he did. > > The other layouts should get updated - I didn't even think about that. > > With unmodifed layout files, things should work just as good as they did > before. Which is you won't be able to resize the map window, so those changes > I made just won't get used. > > Testing with the other layouts would likely need to get done. The reason the > size for the map window was removed was that it acted as a minimum size (or so > I seem to recall). That said, without a size parameter, it may default to a > not very useful layout. Yes, the whole minimum size thing has always been a beef, and I've tried a few things to fix it, but never found a solution that works straight out of the XML file. Frankly I think glade designer is somewhat broken in that it lets you lay everything out to a certain size, but then does not program the sizes in as soft defaults. This is what made the GTK-V2 client so objectionable when all I had were 17" monitors around. And yes, if you do not have a windows position file saved yet, without it, the UI is a mess. While its not an ideal solution, I did think of either hardcoding a minumum default size if a window position file doesn't exist and/or having a small data file that sets certain defaults for the window size. > I already have the server changes - they are fairly trivial - I'm just not > sure if they will have bad effects with other clients. The change is basically > that whenever the server gets a new map size, it clears all its cache and thus > resends the entire map to the client. What I'm not sure is if other clients > actually will change the mapsize after play starts, and if clearing that data > would give a result they don't want (it sort of has a bad side effect on the > client in that it will also clear all fog of war information). > > My belief is that the resizing of the map window is really something a player > will do to get the desired layout they want, and not something will be > constantly playing with. Agreed. And the initial sizing being a bit wonky at first isn't a crisis when you have no prior window position save file, but the initial sizes should be reasonable, and I do not think they are at all reasonable (at this time) with those sizes removed from the XML file. > > By the way, I'm also ok with thinning the number of offered layouts in a > > default install might be wise. Perhaps we could pack up the others by > > adding a package for extra layouts. If we do something like that, we > > probably need to try to test the water and see what people think about > > the various layouts, though I'd tend to package the layouts that work > > for lower screen resolutions with the client... which reminds me I still > > haven't checked in that 640x480 layout. > > My only issue with a bunch of different layouts is potential support issues - > if one is rendered oddly and bugs are filed, if it is a standard layout, that > sort of suggests it is something we should fix. I guess thats part of the point of suggesting a smaller layout set as a standard set, but, it does not seem unreasonable to me to have two or three alternate layouts in the standard set that aren't too similar... The one I still have not checked in is quite radically different in its control set than the others, and is probably worth considering for that very reason. There's not much point to providing multiple layouts that just change the position of stuff. There is more than one theme supported. Now granted, a theme is far smaller to package than a huge XML file, but it is probably no less, if not harder, to tweak themes, based on my five minute review of a theme file, so I guess a bit of a precedent has already been set to ship the client with more than one option. > I'm not sure if we could do some form of unsupported or contrib layouts - > basically, we make these available, but use at your own risk and we don't offer > any support for them. Maintenance on these files is hardly difficult once you get them working. Still, an alternate layouts package could certainly take a lower priority for sure, though I think "use at your own risk" and "don't offer any support for them" begs the question of why we even bother to package them then. I plan to be around a while, even if I drop out of the picture for a few months now and then. I'm perfectly fine with taking the responsibility for the XML files. I think they add something to the client that is worth keeping. Even I switch out now and then to see what "fits" me best. I don't see a compelling reason to take that away from a player at this time. Kevin From leaf at real-time.com Wed Jan 7 16:55:37 2009 From: leaf at real-time.com (Rick Tanner) Date: Wed, 07 Jan 2009 16:55:37 -0600 Subject: [crossfire] Change default perm exp values ? Message-ID: <496532E9.5000600@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The server crossfire.metalforge.net has been using 50% permanent experience for well over a year now. Players have reacted positively and prefer this (for likely obvious reasons.) ;-) What about making 50% the new default permanent experience in SVN and future releases? Index: include/config.h =================================================================== - --- include/config.h (revision 11118) +++ include/config.h (working copy) @@ -255,7 +255,7 @@ */ /* GD */ - -#define PERM_EXP_GAIN_RATIO 0.10f +#define PERM_EXP_GAIN_RATIO 0.50f #define PERM_EXP_MAX_LOSS_RATIO 0.50f /* Index: lib/settings =================================================================== - --- settings (revision 11118) +++ settings (working copy) @@ -224,7 +224,7 @@ # entirely (the same effect would be achieved by setting the two # death_penalty settings below to 0). - -permanent_experience_percentage 25 +permanent_experience_percentage 50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJZTLphHyvgBp+vH4RAoA2AKC+lA7uuT41onUmPa8BFwizXkeyHgCg0Eix lQ2I7eQkMXO2T9PsvklGzsA= =0T6T -----END PGP SIGNATURE----- From leaf at real-time.com Wed Jan 7 23:51:17 2009 From: leaf at real-time.com (Rick Tanner) Date: Wed, 07 Jan 2009 23:51:17 -0600 Subject: [crossfire] Release 1.12 In-Reply-To: References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> Message-ID: <49659455.6010502@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lalo Martins wrote: > Content changes that require trunk code are another matter. I'd like > to have a list of those if someone who knows about it has the time to > compile it; More searching and comparing. I'm not sure if this requires trunk code or not.. NPC dialog that uses @question Example map, /brest/taverns/brest.seaside.tavern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklllE0ACgkQhHyvgBp+vH49iACbBeVhZDZ48+cwBhsOZnlkkz8/ D48AoPBd6aMTApszd08tVGbzYjxuA4Aj =xskb -----END PGP SIGNATURE----- From kbulgrien at att.net Thu Jan 8 06:37:55 2009 From: kbulgrien at att.net (Kevin Bulgrien) Date: Thu, 8 Jan 2009 06:37:55 -0600 Subject: [crossfire] Release 1.12 In-Reply-To: References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> Message-ID: <20090108063755.2dafbcc0@a850srvr.kbulgrien.att.net> > > Can you make a list, either here or the wiki, of known points where 1.12 > > would break backwards compatibility? I don't mind required that content > > is updated in step, but breaking character compatibility I'd prefer not > > to (last time that happened people were pretty mad, and with 2.0 in the > > horizon... no need to aggravate people too much.) > > Actually, let me rephrase that :-) > > Under the premise that current trunk arches and maps will be a 1.12 > content release, I already expressed that I'd like those tested. > > I'm now saying that any changes in trunk maps or arches that make 1.11 > characters unusable, with the exception of Mark's rebalance (which we > don't know yet if we'll include in 1.12), are to be considered bugs and > reported accordingly. (Of course, the "fix" will be simply to not merge > those changes.) Anyone who knows about them can report them here, or on > the tracker, or the wiki. > > Content changes that require trunk code are another matter. I'd like to > have a list of those if someone who knows about it has the time to > compile it; but it's unclear whether these are bugs, until the code > leader decides about a 1.12 code release. Content changes include various maps that use cfdialog.py/npc_dialog.py. Of special note, the mork/gork quest is no longer able to be done by simply knowing the right words (the character has to perform the in-game conversation that tells them the things they need to do). Other maps would include newbiehouse, and a variety of maps associated with the witherspoon manner ghost-body hunt. I think that might be it... but I do have some content that is npc_dialog.py based that is under development, and intended for addition to trunk. Since cfdialog/npc_dialog.py make it possible for a mapmaker to create (mini) quests using stored flags in the player file. Its not particularly nice that the status of the quests is not checkable, nor that it is easy to write them stupidly, but... it was a dramatic improvement on what branch had via the match system. Kevin From lalo.martins at gmail.com Thu Jan 8 07:27:48 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 8 Jan 2009 13:27:48 +0000 (UTC) Subject: [crossfire] Release 1.12 References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> Message-ID: All right... with the help of "crossfire traffic" and svn, I compiled a list of what's in the trunk and branch. http://wiki.metalforge.net/doku.php/trunkbranchchangebreakdown Comments welcome. As far as I've seen, the only change that breaks character compatibility is the combat rebalance. So until/unless we hear from the code leadership, let's assume the rebalance won't be in the release. It seems a lot of those changes require code changes... as seen on other posts to this thread by Leaf and Kevin. So the question of whether there will be a server 1.12 release becomes somewhat important. If there won't, then it would be better to base the content release on the branch, and manually merge each set of changes that are compatible. Significantly more work... but doable. 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Fri Jan 9 00:08:38 2009 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 08 Jan 2009 22:08:38 -0800 Subject: [crossfire] Release 1.12 In-Reply-To: References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> Message-ID: <4966E9E6.3040709@sonic.net> Lalo Martins wrote: > All right... with the help of "crossfire traffic" and svn, I compiled a > list of what's in the trunk and branch. > > http://wiki.metalforge.net/doku.php/trunkbranchchangebreakdown > > Comments welcome. > > As far as I've seen, the only change that breaks character compatibility > is the combat rebalance. So until/unless we hear from the code > leadership, let's assume the rebalance won't be in the release. As far as I know, the combat rebalance does not break character compatibility - old characters can get loaded and played fine. The main issue is that the play experience is radically different, and so players not ready/aware of these changes my incur many deaths. From lalo.martins at gmail.com Fri Jan 9 00:30:51 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri, 9 Jan 2009 06:30:51 +0000 (UTC) Subject: [crossfire] Release 1.12 References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> <4966E9E6.3040709@sonic.net> Message-ID: quoth Mark Wedel as of Thu, 08 Jan 2009 22:08:38 -0800: > Lalo Martins wrote: >> >> As far as I've seen, the only change that breaks character >> compatibility is the combat rebalance. So until/unless we hear from >> the code leadership, let's assume the rebalance won't be in the >> release. > > As far as I know, the combat rebalance does not break character > compatibility - old characters can get loaded and played fine. > > The main issue is that the play experience is radically different, and > so players not ready/aware of these changes my incur many deaths. Okay... a few questions, then, as you're the one who knows those changes best :-) - Won't old characters be excessively strong (or weak) compared to rebalanced ones? Or will the differences balance out in the bottom line? - Won't old characters be excessively strong (or weak) when fighting rebalanced monsters? Or will the differences balance out in the bottom line? - Can the changes be easily calculated without human intervention? If so, I could just write a script to do that. - Do you feel it's worth shipping this in 1.12 without the magic rebalance (which, if you have the time, would follow in 1.13)? Or is it better to wait and ship both in the same release? - How well would the (archetype) rebalance work without the corresponding server changes? Would it work at all? 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From juhaj at iki.fi Fri Jan 9 01:59:29 2009 From: juhaj at iki.fi (Juha =?iso-8859-1?q?J=E4ykk=E4?=) Date: Fri, 09 Jan 2009 09:59:29 +0200 Subject: [crossfire] What about a gameplay revolution? In-Reply-To: <49645430.3060208@sonic.net> References: <200812141316.12165.nicolas.weeger@laposte.net> <200901070032.50650.juhaj@iki.fi> <49645430.3060208@sonic.net> Message-ID: <200901090959.49072.juhaj@iki.fi> > Following previous discussion about highest skill level determining hit > points, one could refine it further such that highest skill level of those > associated skills determines hit points. That sounds good. This would certainly deter too many class-defections. I still think that something else besides hit points must also be tied to this skill level, but I'm not sure what. Perhaps the types of quest rewards you're given could be one. And item_power could be checked against this level, too. > But I'm also sort of inclined that not all classes should necessarily > have all skills available (or even most). So I've noticed. =) And I disagree, but that's a matter of taste. It'll eventually be up to Lalo I think. I'm happy with both, but I'm happier with freely learnable skills. Even the system you proposed later, which dumps the classes alltogether and simply has skills. > Some skills are ones that I'd say are not as adventure related (item > creation skills, etc), and so sure, everyone can have those. Yes. And a way of getting decent xp in them too. Perhaps there could be three types of skills: primary and secondary class -based skills and a third set of general-purpose skills. The class-skills are those that gain XP by killing monsters and completing quests and they either can or cannot be learned by everyone and the third set has a different xp table and all, for creating rings, arrows, scrolls, even mining and fishing if we come to that. There are a lot of different ways to handle class-skills. At least the following come to mind: 1) Primary skills cannot be learned, secondary can 2) Both can be learned, but your class-primaries need less XP to advance 3) Your class-primary must always be at least 2x your highest secondary level (perhaps you'd change classes otherwise?), but they are both learnable 4) They are both free to learn, you just have the primary initially There are also some mixes of the four that can be quite ok, too, like take both 2) and 3) and you have pretty heavy punishment for fighting wizards. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20090109/3d0f3a00/attachment.pgp From mwedel at sonic.net Fri Jan 9 02:09:09 2009 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 09 Jan 2009 00:09:09 -0800 Subject: [crossfire] Release 1.12 In-Reply-To: References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> <4966E9E6.3040709@sonic.net> Message-ID: <49670625.6000307@sonic.net> Lalo Martins wrote: > quoth Mark Wedel as of Thu, 08 Jan 2009 22:08:38 -0800: >> Lalo Martins wrote: >>> As far as I've seen, the only change that breaks character >>> compatibility is the combat rebalance. So until/unless we hear from >>> the code leadership, let's assume the rebalance won't be in the >>> release. >> As far as I know, the combat rebalance does not break character >> compatibility - old characters can get loaded and played fine. >> >> The main issue is that the play experience is radically different, and >> so players not ready/aware of these changes my incur many deaths. > > Okay... a few questions, then, as you're the one who knows those changes > best :-) > > - Won't old characters be excessively strong (or weak) compared to > rebalanced ones? Or will the differences balance out in the bottom line? > > - Won't old characters be excessively strong (or weak) when fighting > rebalanced monsters? Or will the differences balance out in the bottom > line? Most of the rebalancing work was done by modifying archetypes, monsters, and some code. An old character that was level 100 in 1 handed weapons would still be level 100. But the meaning of being level 100 is different - before it might have meant a wc of -50, now it might be a wc -20 for example. I don't think there are many/any values stored in the player file itself. Clearly, the changes to the code will affect everyone. Changes to the archetype will affect everyone. The issue would be any custom objects on maps that were updated - old version could be better. And the other issue, as mentioned, is that the old character might log in with speed of 1.5, wc -50 and weapon_speed of 4.0, but with the rebalance, speed may be 1.0, wc -20, weapon_speed 1.5. I don't think new vs old character will have any issue - the main difference would be play experience is quite a bit different. A character may be used to hacking through monsters at a rapid pace, and not find they move much slower, and thus things could be more deadly (it may be that with the rebalance, the appropriate level to take on certain monsters is different than before) Note that part of the rebalance was a new experience table with slow advancement. If that is made active on old servers, characters may now be in a case that they do not have sufficient experience for the level they are, and thus lose several levels at login. Other changes: The stats for players is a fixed total instead of a range. IIRC, this fixed total is near the upper end of what the range was before, but not the very top. It does mean that players who were sufficient patient may have gotten higher starting stats than are achievable now. The other change is generator limits - I believe this was mentioned, but some number of maps may need to get updated, as they should have unlimited generation and break if they don't have unlimited generation. > > - Can the changes be easily calculated without human intervention? If > so, I could just write a script to do that. As said above, I don't really think there is anything to recalculate (maybe exp). > > - Do you feel it's worth shipping this in 1.12 without the magic > rebalance (which, if you have the time, would follow in 1.13)? Or is it > better to wait and ship both in the same release? I'd ship both - otherwise things are unbalanced in various ways. > > - How well would the (archetype) rebalance work without the corresponding > server changes? Would it work at all? I'm not sure. One of the server changes was changing how wc for players was calculated (it increased really fast before the change). As such, the AC of many tough monsters were made worse, to compensate for for the lower WC of the character. I'm not sure how well things would work. They would probably work in the sense that the server wouldn't crash, but you could have cases where characters are unable to hit monsters - the lower attack speeds (in server code) would mean the comparatively, monsters would be tougher than they were before (other than archetype changes, they were not weakened). I'd consider such an environment untested/unsupported. One would have to do some actual playtesting I think to see how things work out. I did a fair amount of playtesting in that rebalance - this monster seems too tough, this not enough, and made various adjustments. I suspect the biggest issue is that many of these adjustments were finely tuned - in general, I tried to target a fighter hitting a monster about 25% of the time. If due to server changes, a fighter now hits that same monster 50% of the time, he is now hitting it twice as often, and monster is that much weaker. So based on AC, WC, etc of various monsters, I'm almost say for sure that some would be considered very easy for the experience they get, and others would seem very hard because they were adjusted for the new way server calculates things, and not the old way From nicolas.weeger at laposte.net Tue Jan 13 12:17:18 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 13 Jan 2009 19:17:18 +0100 Subject: [crossfire] Platform statement In-Reply-To: References: <4952D5B4.6000508@sonic.net> Message-ID: <200901131917.22575.nicolas.weeger@laposte.net> Happy new year everyone! > Actually, I think I'm over-reaching here. All considerations of *how* to > deal with gameplay, especially game mechanics, are just IMHO and > suggestions. I'll say what I think, reply on threads when asked, but in > the end, go with whatever the coders decide :-) No. It's not up to coders/developers to decide. It's up to the gameplay leader to decide game mechanisms. And no gameplay leader is why no one decides anything on the type of game we have, why so many questions aren't replied to, so many things are left as an exercice to the first one to actually move (meaning no coherence yet again). Remember: technical stuff is there FOR THE PURPOSE OF GAMEPLAY AND CONTENTS. Not the other way around. Content and gameplay should state requirements (features, ...) and have a feedback from the technical part about feasability/delays. So to sum up: - content leader => handles the story part of the game, maps that are ok or not story wise, and such - gameplay leader => handles combat mechanisms, has a say on quest rewards and such, works on non combat stuff, ... - technical leader => ensures needs of content/gameplay leaders are met, and maybe planifies development and such (of course it's not a total division, everyone can make suggestions - but at the end of the day the leaders ACTUALLY DECIDE on their domain) And we could obviously add interface/client leader, too. Nicolas PS: to reply to someone's mail, no, I don't want to be technical leader as long as we don't have a gameplay leader - and even so, I'm not sure I'd accept. -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20090113/9157244a/attachment.pgp From leaf at real-time.com Tue Jan 13 13:55:12 2009 From: leaf at real-time.com (Rick Tanner) Date: Tue, 13 Jan 2009 13:55:12 -0600 Subject: [crossfire] Release 1.12 In-Reply-To: References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> Message-ID: <496CF1A0.2000903@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lalo Martins wrote: > All right... with the help of "crossfire traffic" and svn, I compiled a > list of what's in the trunk and branch. > > http://wiki.metalforge.net/doku.php/trunkbranchchangebreakdown I've added about 10 new points of difference to the wiki page. During the next couple of days, I will go through all the maps again and post the any more differences I find between Trunk and Branches/1.x There are some (infamous) cosmetic changes I've made and will merge back in to Branch which should not have an impact on functionality. Lalo - How do things look for the Jan-20th target date? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJbPGghHyvgBp+vH4RAhwoAKDP6AOKAonS/W7wA4fDpKzS4YhfzwCgpxOD IXUjgtK7f2FSaYRvBWM4E8U= =CQzs -----END PGP SIGNATURE----- From lalo.martins at gmail.com Tue Jan 13 16:16:46 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 13 Jan 2009 22:16:46 +0000 (UTC) Subject: [crossfire] Release 1.12 References: <200812201322.53224.nicolas.weeger@laposte.net> <200812220839.46663.nicolas.weeger@laposte.net> <4963E203.1030201@real-time.com> <496CF1A0.2000903@real-time.com> Message-ID: quoth Rick Tanner as of Tue, 13 Jan 2009 13:55:12 -0600: > Lalo Martins wrote: >> http://wiki.metalforge.net/doku.php/trunkbranchchangebreakdown > > I've added about 10 new points of difference to the wiki page. > > During the next couple of days, I will go through all the maps again and > post the any more differences I find between Trunk and Branches/1.x Thanks! > There are some (infamous) cosmetic changes I've made and will merge back > in to Branch which should not have an impact on functionality. Oakdoors? :-) > Lalo - How do things look for the Jan-20th target date? Well. Actually cutting an alpha is about one day's worth of work for me, so meeting the target date isn't hard. The reason I set the date so far was, rather, to give other people time to act on it. If anyone wanted some particular changes in the release, or out of the release, they had time to speak up. And I also was hoping to see a decision on whether there will be a corresponding code release, although the lack of any comments about it does mean there won't ;-) at least not in the same timeframe. I'm not saying the release is easy work, I'm just saying cutting the alpha is the easy part. Then the real work begins -- lots of testing and fixing for the March 1st target. 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Tue Jan 13 16:48:20 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 13 Jan 2009 22:48:20 +0000 (UTC) Subject: [crossfire] Leaderships(s?) (was Re: Platform statement) References: <4952D5B4.6000508@sonic.net> <200901131917.22575.nicolas.weeger@laposte.net> Message-ID: quoth Nicolas Weeger as of Tue, 13 Jan 2009 19:17:18 +0100: > - content leader => handles the story part of the game, maps that are ok > or not story wise, and such > - gameplay leader => handles combat mechanisms, has a say on quest > rewards and such, works on non combat stuff, ... > - technical leader => ensures needs of content/gameplay leaders are met, > and maybe planifies development and such > > PS: to reply to someone's mail, no, I don't want to be technical leader > as long as we don't have a gameplay leader - and even so, I'm not sure > I'd accept. Okay, sorry, but this is not going to work. For years, we had just one project leader. That worked in its time, then as Mark got busy with real life, things slowed down. Recently it has been proposed to have separate leaders for code and content. A volunteer appeared for code, but then the need for a content leader was played; quite reasonably, one volunteer claimed he didn't want to go far as code leader unless there was a content leader. So I volunteered to take the job. But now there's a third position that has to be filled as well? And even then we may find we still don't have a coding leader? Come on, people, we're getting nowhere this way. At this point in time, I don't think we even have enough people working on it to be talking about leadership. These are the important questions that need to be asked with regards to people resources: - Who will make content releases? (me, I guess.) - Who will make server releases? - Who will make gtk client releases? - Who will make java client releases? - Who will fix content bugs? - Who will fix server bugs? - Who will fix gtk client bugs? - Who will fix java client bugs? Only after those are answered, are we prepared to talk about adding new content, new features, or even massive rewrites. Oh sure, we could just declare 1.x abandoned; but considering all the cool stuff we have in svn, that would be a waste and a pity. All right then, to Gorokh with this. Here's my new proposal. Short term: I'm naming myself "release manager" for the 1.12 mini- project. I'll get a release out, code and content. The extra work in carrying the code release through childbirth may (probably will) mean missing the March 1st deadline, but I'll give it my best. I will *not* attempt to release clients, though. If someone wants to coordinate a client release, I'd be very happy and lend my support. (Kevin?) Medium term: I think the best thing to do, as far as separation of work is concerned, is to view this as a number of separate sub-projects: - Server (code and content) for 1.x - GTK/glade client (based on v2 I assume) - Java client - Gridarta for CF - Server (code and content) for 2.x (possibly later) Each of those should have someone taking responsibility. (Gridarta already does, and the Java client unofficially does too.) The necessity of a "master overseer" over the whole project is arguable; I think the sub-project leaders can work things out between them. But for now, let's concentrate on a release. My hope is that the work involved in doing that will wake us up, and that the right people for each position will rise up in the process. Frankly... this whole thing is silly. Free/Open Source projects aren't representative democracies; it makes no sense to be arguing about who will lead what when there's work to do and nobody to lead. Let's go get this release out. Please. 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From kbulgrien at att.net Tue Jan 13 21:56:05 2009 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Tue, 13 Jan 2009 21:56:05 -0600 Subject: [crossfire] Leaderships(s?) (was Re: Platform statement) In-Reply-To: References: <200901131917.22575.nicolas.weeger@laposte.net> Message-ID: <200901132156.05527.kbulgrien@att.net> I have not enough SVN access to do a release. It feels like after all this time waiting without help to get my client work out its only natural to not flip out over someone else' urgency of the day, but, I was ready for a release a long time ago... no point in wondering what I am willing to do. I've probably made that quite clear to anyone who felt inclined to notice. That said, I have a real life, kids, high urgency project that is running over two years old now and ready to pop in a month or so... Not a lot of leftover bandwidth for thinking CF with that going on, and I suspect I'm not alone there. I'll be glad to crank up the scripts and chunk something out. :-) Have a good day... From lalo.martins at gmail.com Tue Jan 13 22:38:02 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 14 Jan 2009 04:38:02 +0000 (UTC) Subject: [crossfire] Leaderships(s?) (was Re: Platform statement) References: <200901131917.22575.nicolas.weeger@laposte.net> <200901132156.05527.kbulgrien@att.net> Message-ID: quoth Kevin R. Bulgrien as of Tue, 13 Jan 2009 21:56:05 -0600: > I have not enough SVN access to do a release. It feels like after all > this time waiting without help to get my client work out its only > natural to not flip out over someone else' urgency of the day, but, I > was ready for a release a long time ago... no point in wondering what I > am willing to do. I've probably made that quite clear to anyone who > felt inclined to notice. That said, I have a real life, kids, high > urgency project that is running over two years old now and ready to pop > in a month or so... Not a lot of leftover bandwidth for thinking CF with > that going on, and I suspect I'm not alone there. I'll be glad to crank > up the scripts and chunk something out. You have commit access. That's enough access :-) if you want to do this, what I'd expect you to do is decide what will go in the release, and merge anything that needs to be merged. (If you just decree that your client release == trunk, then your work is done.) If you *do* have time you want to spend on it, then any amount of building, testing, and fixing bugs is welcome. If something happens to draw you away, I'll handle it, or someone else will, or we'll be late. If I feel adventurous and work allows me, I may try to set up the windows build environment, and see if I can convince gtkv2+glade to compile. But from what I heard of people who did try, probably not ;-) Of course, once the alphas/betas are out and bug reports start popping in, someone has to fix them before we dare make a "final" release. Since not many people are actively doing client development, I'd say there's about a 35% chance that someone would be you anyway; but if real life keeps you away from doing it, or even makes us miss the target date? It doesn't matter at all. What matters is that a release eventually happens, and that it's the best quality we can do. I do believe regular releases on a fixed timeline are a good thing. However, I'm not expecting *this* release to be the first of those. We have a lot of accumulated work to catch up to, and we have to figure out our own workflow, so that will take some time. Better do it well than fast. Then the next one can be on time. The other good thing about volunteering to lead the client are that, well, you get to make decisions. Want to drop the x11 client? The gtkv1 client? Go ahead. Change the whole thing to C++, or, I don't know, Erlang? It's your baby. The last few decisions you did make (glade, layouts, themes) have been successes so far, so I don't think there's any reasonable justification for objecting to you making future ones. I suppose, in the interest of fairness, I should say that I've been half- secretly writing a "libcfclient" in C++, using boost and asio. I have no intention of rewriting the desktop client using this lib, or of competing with it, though; the lib was meant for other things, including bots and maybe portable (phone/pda/pmp/ds/psp) clients. 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From kbulgrien at att.net Wed Jan 14 00:06:05 2009 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Wed, 14 Jan 2009 00:06:05 -0600 Subject: [crossfire] Leaderships(s?) (was Re: Platform statement) In-Reply-To: References: <200901132156.05527.kbulgrien@att.net> Message-ID: <200901140006.05691.kbulgrien@att.net> > > I have not enough SVN access to do a release. That would be sourceforge access. No upload, no release. Last time I commented I had taken the pain out of building the client, I was told the hassle is the SF stuff, so the neverending tale goes on. If noone will upload, all release effort is wasted. I've gone out of my way to facilitate a release and the run-around needs to stop. Every time I ask for some support, some more load of hooey pops out as yet another reason not do it. I'm not wasting my time until it looks like someone is serious and says what needs to be done for them to upload, or I get the access it takes. > You have commit access. That's enough access :-) No, its not. SVN write doesn't get the poop on the download tab. > if you want to do this, > what I'd expect you to do is decide what will go in the release, and > merge anything that needs to be merged. (If you just decree that your > client release == trunk, then your work is done.) There's already consensus on this, and as far as I know, no one has argued against. > If you *do* have time you want to spend on it, then any amount of > building, testing, and fixing bugs is welcome. If something happens to > draw you away, I'll handle it, or someone else will, or we'll be late. > > If I feel adventurous and work allows me, I may try to set up the windows > build environment, and see if I can convince gtkv2+glade to compile. But > from what I heard of people who did try, probably not ;-) > > Of course, once the alphas/betas are out and bug reports start popping > in, someone has to fix them before we dare make a "final" release. Since > not many people are actively doing client development, I'd say there's > about a 35% chance that someone would be you anyway; but if real life > keeps you away from doing it, or even makes us miss the target date? It > doesn't matter at all. What matters is that a release eventually > happens, and that it's the best quality we can do. 2.x client isn't going to start popping bugs... people are using it. If it has issues, they need not stop a release. The current releases have more/worse bugs than the trunk gtk-v2 client anyway. I am somewhat confused about the question of working on it. Most of the recent client commits in SVN are mine... I'm not promising anything, but the proof is in the pudding. I do not plan to be gone from the project anytime soon. All this worry about debugging seems kind of odd... Can anyone say double-character bug... showstopper... Can't get any worse than that. Do you know how hard I worked on that one? > I do believe regular releases on a fixed timeline are a good thing. > However, I'm not expecting *this* release to be the first of those. We > have a lot of accumulated work to catch up to, and we have to figure out > our own workflow, so that will take some time. Better do it well than > fast. Then the next one can be on time. > > The other good thing about volunteering to lead the client are that, > well, you get to make decisions. Want to drop the x11 client? The gtkv1 > client? Go ahead. Change the whole thing to C++, or, I don't know, > Erlang? It's your baby. The last few decisions you did make (glade, > layouts, themes) have been successes so far, so I don't think there's any > reasonable justification for objecting to you making future ones. I don't need a title. I have been doing it. What's the deal with "volunteering". That got done years ago. I never unvolunteered, but I also know that mwedel wrote it, and am not that interested in claiming something not offered. But the point is also I don't know enough to even write a client, so how can I commit to be "the" guy when others are changing stuff I have no clue about the server/protocol/ or the tall stuff being worked on in jxclient? I can try, but that's all I can commit to, and I guess I don't see a lot of people out there making noise about keeping the GTK clients alive, so it seems I'm kind of out there on my own. > I suppose, in the interest of fairness, I should say that I've been half- > secretly writing a "libcfclient" in C++, using boost and asio. I have no > intention of rewriting the desktop client using this lib, or of competing > with it, though; the lib was meant for other things, including bots and > maybe portable (phone/pda/pmp/ds/psp) clients. > > best, > Lalo Martins From nicolas.weeger at laposte.net Wed Jan 14 12:01:13 2009 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 14 Jan 2009 19:01:13 +0100 Subject: [crossfire] Leaderships(s?) (was Re: Platform statement) In-Reply-To: References: <200901131917.22575.nicolas.weeger@laposte.net> Message-ID: <200901141901.19259.nicolas.weeger@laposte.net> So, tell me: - what should chaos attack do? - how are wc and ac related? - what is the meaning of "speed 1"? - "I made a map with this and that reward with those statistics, can I put it into SVN?" <- who will decide? - "I made a patch to enable players to create items from other items through alchemy, is it ok to be put into SVN?" <- who will decide? - "I made a patch so poison attacks aren't a one shot, but actually poison the player for 1 to 10 seconds" <- who will decide to put that into SVN? - "here is a pickaxe to destroy walls, can I put it into SVN?" (not necessarily "what does it do right now?", but "what should it do in the ideal game we're making?") As you said, this isn't a democracy, and latest discussions (and the lack of conclusions) should show that we need someone to actually decide when needed - so a gameplay leader, and a content leader, both are needed. And I don't worry for technical leadership - there are enough people willing to code for Crossfire, besides the code is enough for now for most things planned in the next releases. Nicolas Le mardi 13 janvier 2009, Lalo Martins a ?crit?: > quoth Nicolas Weeger as of Tue, 13 Jan 2009 19:17:18 +0100: > > - content leader => handles the story part of the game, maps that are ok > > or not story wise, and such > > - gameplay leader => handles combat mechanisms, has a say on quest > > rewards and such, works on non combat stuff, ... > > - technical leader => ensures needs of content/gameplay leaders are met, > > and maybe planifies development and such > > > > PS: to reply to someone's mail, no, I don't want to be technical leader > > as long as we don't have a gameplay leader - and even so, I'm not sure > > I'd accept. > > Okay, sorry, but this is not going to work. > > For years, we had just one project leader. That worked in its time, then > as Mark got busy with real life, things slowed down. > > Recently it has been proposed to have separate leaders for code and > content. A volunteer appeared for code, but then the need for a content > leader was played; quite reasonably, one volunteer claimed he didn't want > to go far as code leader unless there was a content leader. So I > volunteered to take the job. > > But now there's a third position that has to be filled as well? And even > then we may find we still don't have a coding leader? > > Come on, people, we're getting nowhere this way. > > At this point in time, I don't think we even have enough people working > on it to be talking about leadership. These are the important questions > that need to be asked with regards to people resources: > > - Who will make content releases? (me, I guess.) > - Who will make server releases? > - Who will make gtk client releases? > - Who will make java client releases? > - Who will fix content bugs? > - Who will fix server bugs? > - Who will fix gtk client bugs? > - Who will fix java client bugs? > > Only after those are answered, are we prepared to talk about adding new > content, new features, or even massive rewrites. Oh sure, we could just > declare 1.x abandoned; but considering all the cool stuff we have in svn, > that would be a waste and a pity. > > All right then, to Gorokh with this. Here's my new proposal. > > Short term: I'm naming myself "release manager" for the 1.12 mini- > project. I'll get a release out, code and content. The extra work in > carrying the code release through childbirth may (probably will) mean > missing the March 1st deadline, but I'll give it my best. I will *not* > attempt to release clients, though. If someone wants to coordinate a > client release, I'd be very happy and lend my support. (Kevin?) > > Medium term: I think the best thing to do, as far as separation of work > is concerned, is to view this as a number of separate sub-projects: > > - Server (code and content) for 1.x > - GTK/glade client (based on v2 I assume) > - Java client > - Gridarta for CF > - Server (code and content) for 2.x (possibly later) > > Each of those should have someone taking responsibility. (Gridarta > already does, and the Java client unofficially does too.) The necessity > of a "master overseer" over the whole project is arguable; I think the > sub-project leaders can work things out between them. > > But for now, let's concentrate on a release. My hope is that the work > involved in doing that will wake us up, and that the right people for > each position will rise up in the process. > > Frankly... this whole thing is silly. Free/Open Source projects aren't > representative democracies; it makes no sense to be arguing about who > will lead what when there's work to do and nobody to lead. Let's go get > this release out. Please. > > best, > Lalo Martins -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20090114/84193a87/attachment.pgp From mwedel at sonic.net Thu Jan 15 00:53:34 2009 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 14 Jan 2009 22:53:34 -0800 Subject: [crossfire] Leaderships(s?) (was Re: Platform statement) In-Reply-To: <200901141901.19259.nicolas.weeger@laposte.net> References: <200901131917.22575.nicolas.weeger@laposte.net> <200901141901.19259.nicolas.weeger@laposte.net> Message-ID: <496EDD6E.6080709@sonic.net> Hmm - I seemed to have not received some of the messages in the thread, but my two cents (take it how you will) Most all of the leadership roles have a fair amount of overlap and cooperation needed, and all that gets tricky. If we define this as the various roles: content leader (maps, archetypes, images) server code (new features, bug fixes, improved performance) client (new features, etc) - note probably have 1 leader/client editor (new features, etc) - we really only have 1 editor, but if we had more, probably would have 1 leader per editor gameplay leader (how fast is combat, how does item X work, etc) (as a note, just because there are those different roles does not require that each one be a unique person - one person may have different roles) Pretty much all of those need to work together at some level - if the content leader decides there are some changes to the archetypes, then cooperation of the server person and the editor is likely needed. And that is true for lots of other things - we could say 'the new one to create characters is to offload a lot of work to the client' - server folks are willing to make changes to do that. But unless the client folks are also willing to do so, that perhaps doesn't go anyplace. Now one hopes that things like that don't happen. But I can certainly see many cases where one leader wants something done, but it falls into another area and that other leader doesn't see it as a priority to them (they're working on something else or maybe just don't see much value, etc). Gameplay is a vague definition in this form - there isn't any actual area (like maps, server, client) that such a person is responsible for. I'd also note that many different areas could have huge affects on gameplay without need of changes in other areas (the melee combat rebalance I did was almost all content (archetypes), and a minor amount of code). Instead of that gameplay leader role, I'd suggest that instead an overall leader role should be in place instead. This person is in charge of resolving disputes (final word) when they arise. Such a role is definitely needed, because I think disputes will arise. Now hopefully, not many disputes will arise - most folks will agree on things happen. I'd also say that most gameplay decisions would fall to the content leader - simply on the basis that the content is going to have most of the effect on gameplay - simply by adjusting attributes of archetypes has big impacts on gameplay. One advantage I see with those leadership roles is each person has an area of the SVN tree that are in charge of - to me this makes sense. You can't have 2 folks in charge of the same area - that just doesn't work. The person in charge of that area gets to make final decision on patches/changes to that area, with the exception of things that hit multiple areas. The person in charge of maps is clearly the best person to make the call on if a map is appropriate. And since that person is also in charge of archetypes, they are the best person to decide on appropriate rewards. Patches/changes that hit multiple areas are the exception. In the case that all parties involved to accept or reject the change (unanimous opinion), that is very simple. The complicated case is when one person likes it, and another person doesn't. If an agreement can't be reached, then it goes to the overall leaderd to make the call. I'm willing to continue my role as overall leader - in the model described above, such a role is more resolving dispute and not so much spending lots of time actually making changes (finding time/energy to read/respond to e-mail is often easier than time to make changes to code, archetypes, etc) From om at iki.fi Thu Jan 15 11:01:05 2009 From: om at iki.fi (Otto J. Makela) Date: Thu, 15 Jan 2009 19:01:05 +0200 Subject: [crossfire] Crash on Skud bank coin exchange Message-ID: <496F6BD1.3000401@iki.fi> I'm running the ready-rpm-packaged crossfire-1.11.0-1.fc10 (with crossfire-maps and crossfire-plugins of the same version) on a Fedora10 x86_64 system. A problem that did not occurr in the crossfire-1.11.0-1.fc9 release is that the server process suddenly crashes if one exchanges coins at the bank at Skud (other banks don't seem to do it). Nothing very useful seems to end up being written into the logs. Anyone else see anything like this, and how should I try to debug where things go wrong? -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From leaf at real-time.com Thu Jan 15 11:35:12 2009 From: leaf at real-time.com (Rick Tanner) Date: Thu, 15 Jan 2009 11:35:12 -0600 Subject: [crossfire] Crash on Skud bank coin exchange In-Reply-To: <496F6BD1.3000401@iki.fi> References: <496F6BD1.3000401@iki.fi> Message-ID: <496F73D0.7030200@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Otto J. Makela wrote: > I'm running the ready-rpm-packaged crossfire-1.11.0-1.fc10 (with > crossfire-maps and crossfire-plugins of the same version) on a Fedora10 x86_64 > system. A problem that did not occurr in the crossfire-1.11.0-1.fc9 release is > that the server process suddenly crashes if one exchanges coins at the bank at > Skud (other banks don't seem to do it). I haven't seen or encountered this. Has the issue been tested enough to say this happens with all conversion altars or just a specific one/few? If so, which conversion altars? (silver to gold, platinum to jade, etc.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJb3PQhHyvgBp+vH4RAuWFAJ92UPcuhFAOtot4dUdzpVjC2lN/mgCghtQi SNufpHKEc6/9vHcFfHznWDI= =wCy6 -----END PGP SIGNATURE----- From meflin at meflin.net Thu Jan 15 11:49:58 2009 From: meflin at meflin.net (James Lopeman) Date: Thu, 15 Jan 2009 10:49:58 -0700 Subject: [crossfire] Crash on Skud bank coin exchange Message-ID: <200901151049.58946.meflin@meflin.net> On fedora 9 & 10 32 & 64 bit crossfire servers crash in scorn after a few minuets, When trying to test your money exchange bug standing around in the bank caused a crash after 1-2 minuets . ( bug report 2008-12-23 ) http://sourceforge.net/tracker/index.php?func=detail&aid=2459929&group_id=13833&atid=113833 On CentOS 32bit/trunk ( invidious.meflin.net ) python scripts randomly crash things ( bug report 2008-06-10 ) https://sourceforge.net/tracker/index.php?func=detail&aid=1989896&group_id=13833&atid=113833 On IRC i have repeatedly offered developers ssh access to the crossfire account on invidious with no takers, and very few comments other then "use a real OS like debian" Meflin On Thursday 15 January 2009 10:01:05 Otto J. Makela wrote: > I'm running the ready-rpm-packaged crossfire-1.11.0-1.fc10 (with > crossfire-maps and crossfire-plugins of the same version) on a Fedora10 > x86_64 system. A problem that did not occurr in the crossfire-1.11.0-1.fc9 > release is that the server process suddenly crashes if one exchanges coins > at the bank at Skud (other banks don't seem to do it). > > Nothing very useful seems to end up being written into the logs. Anyone > else see anything like this, and how should I try to debug where things go > wrong? From om at iki.fi Thu Jan 15 13:16:46 2009 From: om at iki.fi (Otto J. Makela) Date: Thu, 15 Jan 2009 21:16:46 +0200 Subject: [crossfire] Crash on Skud bank coin exchange In-Reply-To: References: Message-ID: <496F8B9E.2000107@iki.fi> James Lopeman wrote: > On fedora 9 & 10 32 & 64 bit crossfire servers crash in scorn after a few > minuets, > > When trying to test your money exchange bug standing around in the bank caused > a crash after 1-2 minuets . ( bug report 2008-12-23 ) > > http://sourceforge.net/tracker/index.php?func=detail&aid=2459929&group_id=13833&atid=113833 Hadn't thought to try this. Yes, just having the bank map load crashes the server after a couple of minutes. As I said, the log file doesn't contain useful stuff: 09/01/15 21:10:26 [Debug] Trying to load map /usr/share/crossfire/maps/world/world_104_115. 09/01/15 21:10:26 [Debug] load_original_map: /world/world_104_115 (0) 09/01/15 21:10:29 [Debug] Trying to load map /usr/share/crossfire/maps/scorn/shops/bank. 09/01/15 21:10:29 [Debug] load_original_map: /scorn/shops/bank (0) 09/01/15 21:10:33 [Debug] Saving map /world/world_104_115 09/01/15 21:11:15 [Debug] make_path_tofile /var/games/crossfire/players/ExTechOp/_scorn_apartment_Apartments1...09/01/15 21:11:15 [Debug] 09/01/15 21:11:15 [Debug] Saving map /var/games/crossfire/players/ExTechOp/_scorn_apartment_Apartments1 09/01/15 21:11:17 [Debug] Resetting map /var/games/crossfire/players/ExTechOp/_scorn_apartment_Apartments1. -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From lalo.martins at gmail.com Thu Jan 15 13:37:40 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 15 Jan 2009 19:37:40 +0000 (UTC) Subject: [crossfire] Leaderships(s?) (was Re: Platform statement) References: <200901131917.22575.nicolas.weeger@laposte.net> <200901141901.19259.nicolas.weeger@laposte.net> Message-ID: quoth Nicolas Weeger as of Wed, 14 Jan 2009 19:01:13 +0100: > As you said, this isn't a democracy, and latest discussions (and the > lack of conclusions) should show that we need someone to actually decide > when needed I have never seen a Free or Open Source project that actually reaches conclusions in the mailing list on a regular basis. Still, most do get things done. Also, I haven't said it isn't a democracy. It is. What I have said is that it isn't a representative democracy. We don't elect our officials and then just sit back and expect things to work. FOSS is not driven by consensus. It's driven by "rough consensus". There is someone (and I'm saying this in agreement with you, not in disagreement) that looks at the discussion in the mailing list, IRC, etc, and makes a decision based on that. Usually, based on what he or she believes is the consensus, but sometimes, the leader decides something based on his or her own judgement, ignoring what other people said. > so a gameplay leader, and a content leader, both are needed. No, sorry, but no. A gameplay leader and a content leader, both WOULD BE NICE. They're not needed. Honestly, this would all be good if we had people to take all these roles. But do we? This leadership discussion has been going on for quite a while, and we still don't have someone firmly taking the code leadership, which was the first such position to be proposed. What do you *really* want, without fancy discourse? You want to be responsible only for technical coding decisions, and have someone else take the heat for everything else? If that's what it takes to see work start getting done, I'm fine with being that person. And we still have Mark, who volunteered to remain as a final-instance arbiter. 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From meflin at meflin.net Thu Jan 15 14:04:26 2009 From: meflin at meflin.net (James Lopeman) Date: Thu, 15 Jan 2009 13:04:26 -0700 Subject: [crossfire] Crash on Skud bank coin exchange In-Reply-To: <496F8B9E.2000107@iki.fi> References: <496F8B9E.2000107@iki.fi> Message-ID: <200901151304.26756.meflin@meflin.net> For useful information you need a core dump ulimit -c unlimited usr/bin/crossfire Running python initialize script. Updating Guilds ['GUILD_TEMPLATE', 'PoisonedDagger', 'GreenGoblin'] /start/HallsOfSelection/dwarf_player crossfire: Modules/gcmodule.c:276: visit_decref: Assertion `gc->gc.gc_refs != 0' failed. Aborted (core dumped) now lets look at the core file -> gdb /usr/bin/crossfire ./core.26508 then use -> debuginfo-install crossfire-1.11.0-1.fc10.x86_64 ( gdb will spit several of these out at your to install untill your kit is good) when gdb quits whining about missing debug packages .... type bt (gdb) bt #0 0x0000003bbd832f05 in raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x0000003bbd834a73 in abort () at abort.c:88 #2 0x0000003bbd82bef9 in __assert_fail (assertion=0x3db7b1da71 "gc- >gc.gc_refs != 0", file=0x3db7b1da4c "Modules/gcmodule.c", line=276, function=0x3db7b1df5c "visit_decref") at assert.c:78 #3 0x0000003db7ae844c in visit_decref (op=0x2f0cbb0, data=) at Modules/gcmodule.c:276 #4 0x0000003db7a6cacb in dict_traverse (op=0x2e41a10, visit=0x3db7ae83c0 , arg=0x0) at Objects/dictobject.c:1893 #5 0x0000003db7ae887f in subtract_refs () at Modules/gcmodule.c:295 #6 collect (generation=1) at Modules/gcmodule.c:790 #7 0x0000003db7ae935b in collect_generations () at Modules/gcmodule.c:897 #8 _PyObject_GC_Malloc (basicsize=) at Modules/gcmodule.c:1333 #9 0x0000003db7ae93cd in _PyObject_GC_New (tp=0x3db7d476a0) at Modules/gcmodule.c:1343 #10 0x0000003db7a5c3e6 in PyFunction_New (code=0x2fca4e0, globals=0x678c) at Objects/funcobject.c:12 #11 0x0000003db7abd072 in PyEval_EvalFrameEx (f=0x30b9600, throwflag=) at Python/ceval.c:2329 #12 0x0000003db7ac0865 in PyEval_EvalCodeEx (co=0x2fca558, globals=, locals=, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836 #13 0x0000003db7ac0aa2 in PyEval_EvalCode (co=0x678c, globals=0x678c, locals=0x6) at Python/ceval.c:494 #14 0x00000000009c972a in do_script (context=0x30b9880, silent=) at cfpython.c:798 #15 0x00000000009cacde in eventListener (type=) at cfpython.c:1500 #16 0x0000000000448998 in execute_event (op=0x37bbc80, eventcode=8, activator=0x0, third=0x0, message=0x0, fix=0) at plugins.c:284 #17 0x000000000045a324 in process_object (op=0x678c) at time.c:1274 #18 0x0000000000414dc5 in process_events (map=0x0) at server.c:1141 #19 0x000000000041545b in server_main (argc=, argv=) at server.c:1388 #20 0x0000003bbd81e576 in __libc_start_main (main=0x413c10
, argc=1, ubp_av=0x7fff9fd04378, init=0x4c6070 <__libc_csu_init>, fini=, rtld_fini=, stack_end=0x7fff9fd04368) at libc-start.c:220 #21 0x0000000000413b49 in _start () Meflin On Thursday 15 January 2009 12:16:46 Otto J. Makela wrote: > James Lopeman wrote: > > On fedora 9 & 10 32 & 64 bit crossfire servers crash in scorn after a > > few minuets, > > > > When trying to test your money exchange bug standing around in the bank > > caused a crash after 1-2 minuets . ( bug report 2008-12-23 ) > > > > http://sourceforge.net/tracker/index.php?func=detail&aid=2459929&group_id > >=13833&atid=113833 > > Hadn't thought to try this. Yes, just having the bank map load crashes > the server after a couple of minutes. > > As I said, the log file doesn't contain useful stuff: > > 09/01/15 21:10:26 [Debug] Trying to load map > /usr/share/crossfire/maps/world/world_104_115. > 09/01/15 21:10:26 [Debug] load_original_map: /world/world_104_115 (0) > 09/01/15 21:10:29 [Debug] Trying to load map > /usr/share/crossfire/maps/scorn/shops/bank. > 09/01/15 21:10:29 [Debug] load_original_map: /scorn/shops/bank (0) > 09/01/15 21:10:33 [Debug] Saving map /world/world_104_115 > 09/01/15 21:11:15 [Debug] make_path_tofile > /var/games/crossfire/players/ExTechOp/_scorn_apartment_Apartments1...09/01/ >15 21:11:15 [Debug] > 09/01/15 21:11:15 [Debug] Saving map > /var/games/crossfire/players/ExTechOp/_scorn_apartment_Apartments1 > 09/01/15 21:11:17 [Debug] Resetting map > /var/games/crossfire/players/ExTechOp/_scorn_apartment_Apartments1. From lalo.martins at gmail.com Sat Jan 17 14:24:55 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 17 Jan 2009 20:24:55 +0000 (UTC) Subject: [crossfire] 1.12 branch cut Message-ID: Okay. To reflect the new 1.x plan, and to avoid the branch problem we've had this last year, I'll go ahead and phase out the 1.x branch in favour of specific 1.11, 1.12, etc branches. An 1.12 branch was cut out from trunk a few minutes ago. I'll have to revert mwedel's rebalance from server and arch, and then it will become 1.12 alpha. From that point it's bugfixes only. At some point in late February, it will become 1.12RC, and from then on it's *critical* bugfixes only. (Even after the release; so it is also possible that an 1.12.x release happens, if we screw up too bad. Let's hope not.) Immediately after 1.12 going bugfixes only, an 1.13 branch will be added. I'd recommend/encourage new feature development to still happen on trunk and then be backported. Currently the plan for 1.13 is 1.12 + rebalance, and an August release so we can get in October Ubuntu/Fedora. (1.12 will probably be late for April distros, but we'll try.) 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From leaf at real-time.com Sun Jan 18 01:06:32 2009 From: leaf at real-time.com (Rick Tanner) Date: Sun, 18 Jan 2009 01:06:32 -0600 Subject: [crossfire] Change default perm exp values ? In-Reply-To: <496532E9.5000600@real-time.com> References: <496532E9.5000600@real-time.com> Message-ID: <4972D4F8.1030502@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rick Tanner wrote: > > The server crossfire.metalforge.net has been using 50% permanent > experience for well over a year now. Players have reacted positively > and prefer this (for likely obvious reasons.) ;-) > > What about making 50% the new default permanent experience in SVN and > future releases? No praise, criticism or discussion on this proposed suggestion? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkly1O4ACgkQhHyvgBp+vH4jfwCdENW+TeHk/hsRK0B+M40Jju56 Ik8AoNnOeoqc1neLyUutcDg2iEw3OsW1 =4rVC -----END PGP SIGNATURE----- From lalo.martins at gmail.com Mon Jan 19 00:23:25 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 19 Jan 2009 06:23:25 +0000 (UTC) Subject: [crossfire] Oh noes, my checkout disappeared! Message-ID: Leaf has pointed out to me that some people may have checkouts of an 1.x branch (eg client/branches/1.x). If you do, this message is for you. Since the branch layout has changed last weekend, doing an update in such a checkout would simply fail, with the not so helpful message: svn: Target path does not exist (Leaf actually asked me to try and find a way to keep 1.x checkouts working, but there isn't anything like a redirect or auto-switch feature in svn, and I don't want to keep a whole branch around that has no real purpose but saving one command.) So if you use a checkout like that, here's the recommended thing to do: First you should make a choice. Do you want to follow the supported, released version, and get eventual bugfixes for that? Or do you want to follow the work-in-progress for the next release? If you want to follow the supported, released version, do this: svn switch https://crossfire.svn.sourceforge.net/svnroot/crossfire/ $COMPONENT/branches/1.11 . where $COMPONENT is the thing you're following -- server, client, arch, maps. So for example: % cd server % svn switch https://crossfire.svn.sourceforge.net/svnroot/crossfire/ server/branches/1.11 . But it would probably be even better to remove your checkout, and instead create one from the "stable" export: svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/stable/ crossfire This will get all the components, on the supported version. It has the significant benefit that when 1.12 is released, you don't have to run "switch" again; you will automatically start following that one. On the other hand, if you want to follow the work-in-progress 1.x release (more or less equivalent to the old branches/1.x): svn switch https://crossfire.svn.sourceforge.net/svnroot/crossfire/ $COMPONENT/branches/1.12 . for example: % cd server % svn switch https://crossfire.svn.sourceforge.net/svnroot/crossfire/ server/branches/1.12 . But it would probably be even better to remove your checkout, and instead create one from the "next" export: svn co https://crossfire.svn.sourceforge.net/svnroot/crossfire/next/ crossfire-alpha This will get all the components, on the supported version. It has the significant benefit that when 1.12 is released, you don't have to run "switch" again; you will automatically start following 1.13 instead. Note, none of the svn commands above include a line break, but you will probably see them with line breaks because, well, it's email. If you can't figure out how to join them, look them up on the wiki instead: http://wiki.metalforge.net/doku.php/downloading 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From meflin at meflin.net Tue Jan 20 12:39:48 2009 From: meflin at meflin.net (James Lopeman) Date: Tue, 20 Jan 2009 11:39:48 -0700 Subject: [crossfire] Change default perm exp values ? In-Reply-To: <4972D4F8.1030502@real-time.com> References: <496532E9.5000600@real-time.com> <4972D4F8.1030502@real-time.com> Message-ID: <200901201139.48154.meflin@meflin.net> Any such settings Metalforge uses should become the default IM-NS-HO. In the end metaforge behaviour is the "expected behaviour" and makes less work for you. Meflin On Sunday 18 January 2009 00:06:32 Rick Tanner wrote: > Rick Tanner wrote: > > The server crossfire.metalforge.net has been using 50% permanent > > experience for well over a year now. Players have reacted positively > > and prefer this (for likely obvious reasons.) ;-) > > > > What about making 50% the new default permanent experience in SVN and > > future releases? > > No praise, criticism or discussion on this proposed suggestion? > > > > > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From lalo.martins at gmail.com Tue Jan 20 16:39:26 2009 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 20 Jan 2009 22:39:26 +0000 (UTC) Subject: [crossfire] Change default perm exp values ? References: <496532E9.5000600@real-time.com> <4972D4F8.1030502@real-time.com> <200901201139.48154.meflin@meflin.net> Message-ID: quoth James Lopeman as of Tue, 20 Jan 2009 11:39:48 -0700: > Any such settings Metalforge uses should become the default IM-NS-HO. In > the end metaforge behaviour is the "expected behaviour" and makes less > work for you. Agreed... any server admin who wants things different than MF is free to, you know, actually edit the configuration :-) 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. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From om at iki.fi Wed Jan 21 10:01:10 2009 From: om at iki.fi (Otto J. Makela) Date: Wed, 21 Jan 2009 18:01:10 +0200 Subject: [crossfire] Treasures Message-ID: <497746C6.5070700@iki.fi> Can someone tell me a couple of things that have bugged me for ages? Some treasure objects (gold nuggets, rubies, sapphires, emeralds) retrieved from randomly generated levels do not "pile up" with similar objects retrieved from normal maps. I assume this means they are in some fundamental way different (weight, value, something else?) from the "normal" treasure objects. Pearls and diamonds from random levels do seem to be "normal" in this respect. Is this intentional, or some kind of a random side-effect? And now that I've got to the random treasure objects, is it also intentional that amethysts are never generated as "random gem" on maps? Have they somehow been depreciated in the game engine, or are they significantly more valuable than other gems? Just the fact that they would need to be buyable at banks, and yet another table would be needed for this? And the same question on opals, which do not appear at all in the standard maps (only place I can find them is unlinked/kandora/elcyon/temple)? -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From fuchs.andy at gmail.com Wed Jan 21 14:27:01 2009 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Wed, 21 Jan 2009 15:27:01 -0500 Subject: [crossfire] Treasures In-Reply-To: <497746C6.5070700@iki.fi> References: <497746C6.5070700@iki.fi> Message-ID: On Wed, Jan 21, 2009 at 11:01 AM, Otto J. Makela wrote: > Can someone tell me a couple of things that have bugged me for ages? > > Some treasure objects (gold nuggets, rubies, sapphires, emeralds) retrieved > from randomly generated levels do not "pile up" with similar objects retrieved > from normal maps. I assume this means they are in some fundamental way > different (weight, value, something else?) from the "normal" treasure objects. > Pearls and diamonds from random levels do seem to be "normal" in this respect. > > Is this intentional, or some kind of a random side-effect? This has been happening the whole time I have known about Crossfire. My understanding so far has been that it is a bug that nobody has bothered to fix. If anyone knows anything to the contrary, please say so. > And now that I've got to the random treasure objects, is it also intentional > that amethysts are never generated as "random gem" on maps? Have they somehow > been depreciated in the game engine, or are they significantly more valuable > than other gems? Just the fact that they would need to be buyable at banks, > and yet another table would be needed for this? Looking at the SVN commit history for the amethyst archetype, it was added by a mapper who later had a augmentation with some of the other project members, leading to him being kicked out of the project and his server being delisted from the metaserver. He probably intended to use them with some of the maps he was making. SVN log for arch/trunk/jewel/amethyst.arc: http://crossfire.svn.sourceforge.net/viewvc/crossfire/arch/trunk/jewel/amethyst.arc?view=log#rev3714 > And the same question on opals, which do not appear at all in the standard > maps (only place I can find them is unlinked/kandora/elcyon/temple)? Looking at that map, the opals are actually pearls, renamed to "opal". I have no idea what the mapper intended them to do. -- Andrew Fuchs From leaf at real-time.com Wed Jan 21 14:46:19 2009 From: leaf at real-time.com (Rick Tanner) Date: Wed, 21 Jan 2009 14:46:19 -0600 Subject: [crossfire] Treasures In-Reply-To: References: <497746C6.5070700@iki.fi> Message-ID: <4977899B.3000709@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Fuchs wrote: > On Wed, Jan 21, 2009 at 11:01 AM, Otto J. Makela wrote: >> Can someone tell me a couple of things that have bugged me for ages? >> >> Some treasure objects (gold nuggets, rubies, sapphires, emeralds) retrieved >> from randomly generated levels do not "pile up" with similar objects retrieved >> from normal maps. I assume this means they are in some fundamental way >> different (weight, value, something else?) from the "normal" treasure objects. >> Pearls and diamonds from random levels do seem to be "normal" in this respect. >> >> Is this intentional, or some kind of a random side-effect? While in DM mode, check and see what material those items are made of. You'll likely find that some are "material: granite" or something along those lines. AFAIK, this is what keeps the items from merging. Leaving a stack of similar items in your apartment, and allowing the map to be swapped out and written to disk (again, AFAIK) will result in the entire stack being merged. For instance, 3 rubies & 5 rubies will merge in to a stack of 8 rubies. > This has been happening the whole time I have known about Crossfire. > My understanding so far has been that it is a bug that nobody has > bothered to fix. If anyone knows anything to the contrary, please say > so. Finding a way to replicate this, consistently, is the issue. Unless there is more information I am aware of. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJd4mbhHyvgBp+vH4RAm/sAJ9p2lzckDrXi/8In9ZdLU8j+qVihQCgmYjy 5U81sbcnpQG6H/10mI/1zOM= =4j9n -----END PGP SIGNATURE----- From edler at heydernet.de Wed Jan 21 16:05:02 2009 From: edler at heydernet.de (Bernd Edler) Date: Wed, 21 Jan 2009 23:05:02 +0100 Subject: [crossfire] Treasures In-Reply-To: <497746C6.5070700@iki.fi> References: <497746C6.5070700@iki.fi> Message-ID: <49779C0E.3040605@heydernet.de> Otto J. Makela wrote: > Some treasure objects (gold nuggets, rubies, sapphires, emeralds) retrieved > from randomly generated levels do not "pile up" with similar objects retrieved > from normal maps. Maybe this is outdated, (last play time is years ago) but I found out why "gems" (diamond) from vending machines did not merge with others. They are unidentified, but unlike e.g. rings this is not shown in inventory screen. I used this for bootstrapping jeweler skill : Buying a big stack - then identifying them one by one - as one does get exp. per pile - not per item. From om at iki.fi Thu Jan 22 19:28:23 2009 From: om at iki.fi (Otto J. Makela) Date: Fri, 23 Jan 2009 03:28:23 +0200 Subject: [crossfire] Treasures In-Reply-To: References: Message-ID: <49791D37.706@iki.fi> Rick Tanner wrote: > While in DM mode, check and see what material those items are made of. > You'll likely find that some are "material: granite" or something along > those lines. AFAIK, this is what keeps the items from merging. I took a look at some "random level" diamonds in a saved apartment file: material, value, weight and all that other stuff was the same. I found that they differed from "normal" diamonds only in having the flag "move_block swim" set, where "normal" ones had the flag "state 1" set. Anyone remember offhand what these flags mean when applied to objects? As someone else noted, restarting the server ended up in merging quite a lot of these "random level" objects with the "normal" ones, like several other types of gems. -- /* * * Otto J. Makela * * * * * * * * * * * * * * * */ /* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */ /* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */ From mwedel at sonic.net Fri Jan 23 00:12:13 2009 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 22 Jan 2009 22:12:13 -0800 Subject: [crossfire] Treasures In-Reply-To: <49791D37.706@iki.fi> References: <49791D37.706@iki.fi> Message-ID: <49795FBD.6030700@sonic.net> Otto J. Makela wrote: > Rick Tanner wrote: > >> While in DM mode, check and see what material those items are made of. >> You'll likely find that some are "material: granite" or something along >> those lines. AFAIK, this is what keeps the items from merging. > > I took a look at some "random level" diamonds in a saved apartment file: > material, value, weight and all that other stuff was the same. I found that > they differed from "normal" diamonds only in having the flag "move_block swim" > set, where "normal" ones had the flag "state 1" set. move_block set on items seems weird. I'd have to double check, but from memory, that has no meaning for items that can be picked up. state 1 I believe is related to animations - I could certainly see that different based on just random factors.