From wim-cf at villerius.nl Sat Jul 1 10:12:14 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Sat, 01 Jul 2006 17:12:14 +0200 Subject: [crossfire] race/class lacks distinctions In-Reply-To: <44A4BB3B.5070709@sonic.net> References: <44A4BB3B.5070709@sonic.net> Message-ID: <1151766735.10530.97.camel@localhost.localdomain> On Thu, 2006-06-29 at 22:48 -0700, Mark Wedel wrote: > It has long been discussed that with a few exception (the non humanoid races > and the classes that prohibit weapons/armors), a lot of race/classes tend to > blur together. > > There are several reasons for this: > > - There are not really any race/class restrictions for objects (or conversely, > not any objects that only clerics can use, or that only fighters can use, etc). > While there is a 'ring of the paladin', you don't need to be a paladin to use > it for example. > > - Pretty much all the skills are learnable, so what skills you start out with > are not very important - you can learn everything else later. > > - Most differences in stats can be overcome fairly easily by use of items that > improve your stats. > > In terms of these issues, I think the first could be fixed by adding new items > and a little code - use a key/value to store what class/race can use an object, > and add some code in the apply logic to check for it. I would suggest also to modify quite some existing items. Adding still more items degenerates the value of current items. Why would you search for 'special item' if the so-and-so not so special item gives almost the same benefits? Perhaps - but that's quite a different discussion - it's worth to remove a lot of (more or less) special items from the game. > For the skills, my thought would be there should be different levels (for lack > of better term) of skills. > > For example, there may be 4 different skills of sorcery - basic, expert, > advanced, mastery. However, these all tie in with the same skill. > > The sorcery class starts with the mastery skill. Some of the other classes > (if they get several casting skills) maybe get those at advanced. Skill scrolls > would give you basic skill, and perhaps quests or other harder to do things give > you expert. I'd suggest that mastery is not something you can start with. the name suggests that you need some experience in a skill to become a master of that skill. That could even make six different grades. basic and basic mastery advanced and advanced mastery expert and expert mastery Perhaps it would even be possible to completely remove skill scrolls. If your class doesn't have skill X, you can learn it at basic lvl in the elementary school. Access to a school for advanced students could be limited to certain classes and a University of X could be restricted to one class only. Every skill level should have spells in it, some restricted to masters of the skill level only. > I don't really have any good solution to the stat problem - I don't > think that is really solvable. It might not be solvable without a lot of work, but I really think adding a zero to the max stat would make a huge difference. That would as well allow a change of the effects stats have. Now the difference between 29 and 30 is incredibly big. It seems to be exponential, which doesn't make much sense IMO. I think the difference between n and n+1 should become smaller and smaller (now it's bigger and bigger) (Anyway, this is quite a distinct discussion) Another great way to eliminate the problem under discussion is to remove quite some races/classes! Simplicity is a key to success. Besides, that allows to create really different races/classes From wim-cf at villerius.nl Sat Jul 1 11:19:40 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Sat, 01 Jul 2006 18:19:40 +0200 Subject: [crossfire] race/class lacks distinctions In-Reply-To: <44A5EC04.5040507@sonic.net> References: <44A4BB3B.5070709@sonic.net> <44A53DF0.6070808@telus.net> <44A5EC04.5040507@sonic.net> Message-ID: <1151770781.10530.110.camel@localhost.localdomain> Although I fully agree that races and classes should be more important, I feel a bit concerned about the current proposals to distinguish certain classes some more. On Fri, 2006-06-30 at 20:29 -0700, Mark Wedel wrote: > Alex Schultz wrote: > > Mark Wedel wrote: > >> For example, there may be 4 different skills of sorcery - basic, expert, > >> advanced, mastery. However, these all tie in with the same skill. > >> > >> The sorcery class starts with the mastery skill. Some of the other classes > >> (if they get several casting skills) maybe get those at advanced. Skill scrolls > >> would give you basic skill, and perhaps quests or other harder to do things give > >> you expert. > yes - getting advanced skills should not really be possible. > >> What exactly these differences mean would have to be worked out. At a most > >> basic level, it could determine the rate of exp you gain in the skill (basic > >> gets 25% of normal or something). There could also be level caps - mastery caps > >> at 110, advanced 75, expert 50, basic 25 > > This seems like a good idea to me. Well, this certainly makes sense for magic skills. Restricting a warrior to lvl 25 magic skills doesn't hurt much - he wont use them often. On the other hand, restricting a mage to use at most lvl 25 one/two handed is a BIG pain and an unfair restriction. I have no clue how long ago you tried to kill certain powerfull monsters, but being a mage it is literally impossible to kill Lorkas/Gothwolthe/... Magic is fine for normal critter - even up to grand titans and cyclops - but it is simply _impossible_ to kill the bosses with that (granted, Lorkas can easily be killed with diseases, but Gothwolte cannot - he's an undead force) In summary: this proposal makes it impossible for a mage to do really interesting things for that requires weaponery at lvl 100+ (need a good wc) (note that this does not YET apply to charm monster) > >> (however, the fact there really aren't > >> many spells above level 20, this may not mean a lot). > > This I believe is a separate problem, personally I think that both more > > spells are needed, and the level on many of them needs to be increased > > very significantly (i.e. meteor swarm I would put at level 50 to 60 or > > perhaps even higher, and would put comet around 30 or 40). Also, I think > > this is a rather important problem to deal with, though being a separate > > one from the rest of this post. > > Yes, and also one that sort of breaks compatibility - you almost need to do a > fresh server start. > > However, this reshuffling is still a little tricky. IIRC, the quest for the > comet spell is a level 15 quest. If the comet becomes a level 30 spell, that is > sort annoying - you do the quest, get a new spell, but can't use it for a really > long time. That quest is ok for lvl 8-10 players. Putting Meteor Swarm at lv 60 or even higher is - from the perspective of the player - insane. It is very hard to become lvl 60 pyromancy. Using burning hands or even dragon breath just doesnt bring you at lvl 60. > > Also, I personally believe, that the skills need to be rebalanced such > > that there is not such a desire to want every skill. I believe these > > things would make classes actually matter, however I believe that too > > many maps and monsters, are vastly easier to do by spellcasting, or in > > some cases, vastly easier to do by melee. I believe there should be some > > variation, however I believe the variation currently would be too > > extreme once classes were made to matter. As I wrote above, only low lvl monsters are easily killed with magic. If someone believes that a lot of maps&monsters are much easier to do complete with magic, I'd love to suggest them to start a new character and to try it. It's just the opposite. You're always running out of mana way too fast and once all mana is used, you're an easy prey. (And I'm not even talking about treasure that's usualy destroyed by magic.) > Some of this could probably be fixed by balancing the resistances of the > monsters more - there are some monsters virtually impervious to melee because it > can only be hit by one attacktype (you may be luck to have that attacktype in a > weapon). However, spellcasters can almost have every attacktype, so it is just > a matter of choosing the right spell. Monsters should get balanced better so > sure, it may be easier to kill them via spells or weapon, but shouldn't be > impossible to do so by the other method. Au contraire! Usually the best attack types against monsters are weaponmagic, chaos and death (the last works only against low lvl monsters) Now chaos and weaponmagic are almost not available to spellcasters. Comets do weaponmagic damage, but only 5 to 10 hp each comet... Now that makes it almost inpossible to kill anything with it. A high lvl player can do 200 weaponmagic damage each hit with weaponspeed > 10 That same high lvl player will have weaponmagic, fire and electricity attack by equipent and a few others, depending on his gods blessing. Given these numbers the only reason one would use spells are diseases. They slow monsters down a several magnitudes and a combination of several diseases is almost always extremely lethal. > But a lot is also the speed of combat. IMO, combat is often so fast that it > is difficult to have much strategy. Now that is indeed a big problem. Take for example Zorn (Brest scrollshops) He can kill any player in less than a second, no matter what the player does. (he is much faster and does 5 times more damage than Gothwolte, to put him in perspective) So it's inpossible to run away once he's angry. > If we say stats go up to 100, then a couple point swing at first level isn't > likely to make much difference. > > You now need to make the differences for race/class like ?5. But even then, > presumably the bonuses tend to get flattened out, so a +5 is like a +1 right > now. It may mean a character has a 45 vs 40 strength based on race, but that > may not mean a whole much. Why can't these differences be much bigger? A trained man might even be four times stronger than me ;-) From alex_sch at telus.net Sat Jul 1 11:52:10 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 01 Jul 2006 10:52:10 -0600 Subject: [crossfire] race/class lacks distinctions In-Reply-To: <1151770781.10530.110.camel@localhost.localdomain> References: <44A4BB3B.5070709@sonic.net> <44A53DF0.6070808@telus.net> <44A5EC04.5040507@sonic.net> <1151770781.10530.110.camel@localhost.localdomain> Message-ID: <44A6A83A.1090001@telus.net> Wim Villerius wrote: > On Fri, 2006-06-30 at 20:29 -0700, Mark Wedel wrote: > >> Alex Schultz wrote: >> >>> Mark Wedel wrote: >>> >>>> For example, there may be 4 different skills of sorcery - basic, expert, >>>> advanced, mastery. However, these all tie in with the same skill. >>>> >>>> The sorcery class starts with the mastery skill. Some of the other classes >>>> (if they get several casting skills) maybe get those at advanced. Skill scrolls >>>> would give you basic skill, and perhaps quests or other harder to do things give >>>> you expert. >>>> >> yes - getting advanced skills should not really be possible. >> >>>> What exactly these differences mean would have to be worked out. At a most >>>> basic level, it could determine the rate of exp you gain in the skill (basic >>>> gets 25% of normal or something). There could also be level caps - mastery caps >>>> at 110, advanced 75, expert 50, basic 25 >>>> >>> This seems like a good idea to me. >>> > Well, this certainly makes sense for magic skills. Restricting a warrior > to lvl 25 magic skills doesn't hurt much - he wont use them often. > See below, about how the level of various spells needs adjustment. > On the other hand, restricting a mage to use at most lvl 25 one/two > handed is a BIG pain and an unfair restriction. > Again, see below, this time, about magic vs. melee balance. > I have no clue how long ago you tried to kill certain powerfull > monsters, but being a mage it is literally impossible to kill > Lorkas/Gothwolthe/... > Magic is fine for normal critter - even up to grand titans and cyclops - > but it is simply _impossible_ to kill the bosses with that (granted, > Lorkas can easily be killed with diseases, but Gothwolte cannot - he's > an undead force) > In summary: this proposal makes it impossible for a mage to do really > interesting things for that requires weaponery at lvl 100+ (need a good > wc) > (note that this does not YET apply to charm monster) > Gothwolte can be easily killed with a heavy rod of banishment of gaea currently. In my experience, I have only been able to kill the first evil master by meteor swarm. I have only been able to beat the second with earthwalling and using heavy rods. For the third I have only been able to kill it by high level banishment of gaea, and the fourth only by high level banishment of gaea. Conventional magic may not work against these things, however when one's melee is limited to acid, fire, cold, and poison (i.e. dragon), then one cannot defeat these things WITHOUT making use of arguably cheap magical tactics. That said, yes, magic can't kill high level things easily, and this I feel is an issue with, how magic scales as one gains levels, as well as the resists used in monsters, so see below about damage type balance. >>>> (however, the fact there really aren't >>>> many spells above level 20, this may not mean a lot). >>>> >>> This I believe is a separate problem, personally I think that both more >>> spells are needed, and the level on many of them needs to be increased >>> very significantly (i.e. meteor swarm I would put at level 50 to 60 or >>> perhaps even higher, and would put comet around 30 or 40). Also, I think >>> this is a rather important problem to deal with, though being a separate >>> one from the rest of this post. >>> >> Yes, and also one that sort of breaks compatibility - you almost need to do a >> fresh server start. >> >> However, this reshuffling is still a little tricky. IIRC, the quest for the >> comet spell is a level 15 quest. If the comet becomes a level 30 spell, that is >> sort annoying - you do the quest, get a new spell, but can't use it for a really >> long time. >> > That quest is ok for lvl 8-10 players. > Putting Meteor Swarm at lv 60 or even higher is - from the perspective > of the player - insane. It is very hard to become lvl 60 pyromancy. > Using burning hands or even dragon breath just doesnt bring you at lvl > 60. > Hmm, that is an understandable point. Personally I believe that either the quest for comet should be harder, or the spell less powerful. In the case of meteor swarm, I believe that perhaps make it level 30, but make it weaker at lower levels and scale up well, and I also think the problem you mention, is a problem that low level spells don't scale up with level in a useful manner. >>> Also, I personally believe, that the skills need to be rebalanced such >>> that there is not such a desire to want every skill. I believe these >>> things would make classes actually matter, however I believe that too >>> many maps and monsters, are vastly easier to do by spellcasting, or in >>> some cases, vastly easier to do by melee. I believe there should be some >>> variation, however I believe the variation currently would be too >>> extreme once classes were made to matter. >>> > As I wrote above, only low lvl monsters are easily killed with magic. If > someone believes that a lot of maps&monsters are much easier to do > complete with magic, I'd love to suggest them to start a new character > and to try it. > It's just the opposite. You're always running out of mana way too fast > and once all mana is used, you're an easy prey. > (And I'm not even talking about treasure that's usualy destroyed by > magic.) > Well, I was mainly referring to, with magic, high level rods, meteor swarm, comet, banishment, charmkilling, and earthwalling while casting numerous spells (possibly from high level heavy rods). Those ARE things that often end up being the only practical way to kill certain things. > >> Some of this could probably be fixed by balancing the resistances of the >> monsters more - there are some monsters virtually impervious to melee because it >> can only be hit by one attacktype (you may be luck to have that attacktype in a >> weapon). However, spellcasters can almost have every attacktype, so it is just >> a matter of choosing the right spell. Monsters should get balanced better so >> sure, it may be easier to kill them via spells or weapon, but shouldn't be >> impossible to do so by the other method. >> > Au contraire! Usually the best attack types against monsters are > weaponmagic, chaos and death (the last works only against low lvl > monsters) > Now chaos and weaponmagic are almost not available to spellcasters. > Comets do weaponmagic damage, but only 5 to 10 hp each comet... Now that > makes it almost inpossible to kill anything with it. > A high lvl player can do 200 weaponmagic damage each hit with > weaponspeed > 10 > That same high lvl player will have weaponmagic, fire and electricity > attack by equipent and a few others, depending on his gods blessing. > > Given these numbers the only reason one would use spells are diseases. > They slow monsters down a several magnitudes and a combination of > several diseases is almost always extremely lethal. > However there are many monsters vulnerable or non-resistant to a type of damage that can be magically delt. It is true that this does leave dragons/fireborn/monks at a disadvantage against such things that do resist their melee, and leave spellcasters at a similar disadvantage, however this is as was said above an issue of rebalancing the resists. I would agree with you though that the choice of damage types that spellcasters have is not very helpful to them against most things, and with a few swords melee can have more choice. Alex Schultz From alex_sch at telus.net Sat Jul 1 11:58:26 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 01 Jul 2006 10:58:26 -0600 Subject: [crossfire] the scale of stats (was: race/class lacks distinctions) In-Reply-To: <1151766735.10530.97.camel@localhost.localdomain> References: <44A4BB3B.5070709@sonic.net> <1151766735.10530.97.camel@localhost.localdomain> Message-ID: <44A6A9B2.90902@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> Mark Wedel wrote: >> >>> I don't really have any good solution to the stat problem - I don't think that >>> is really solvable. >>> >> Well, adjusting or removing the stat limit of 30 would allow those base >> stat differences to matter more at higher levels, however doing that may >> cause more problems than it solves. Also, something I've saw some muds >> do, that might deal with that, is when one gains a level, randomly, some >> stats will increase depending on the class. Of course, those muds did >> have their stats on a different scale (starting stats ranged from 7 to >> 30 or so depending on race and class, with stats of the very very very >> high level players getting to like 500 even). >> > > But there is always some issue. > > If we say stats go up to 100, then a couple point swing at first level isn't > likely to make much difference. > > You now need to make the differences for race/class like ?5. But even then, > presumably the bonuses tend to get flattened out, so a +5 is like a +1 right > now. It may mean a character has a 45 vs 40 strength based on race, but that > may not mean a whole much. > > However, the idea of stat increases as you gain level is interesting. If we > say stats go to 100, you could have some logic that each race has a difference > balance on what stat will increase. Eg, for a troll, might be 75% that str, > con, dex get increased (one of those), and 25% for the rest of the stats. Thus, > a high level troll would have a high natural str, dex, and con, and still pretty > crummy pow, wis, cha, int. > > If such a redoing of stats was done, would have to figure out how to deal with > stat potions (maybe make it so that drinking one only has some % of increasing > that stat or just do nothing, so same thing happy - if you play a fighter > class/race, you will have good stats). Or maybe just make generic 'improve stat > potions', which sort of act like what happens when you gain a level Wim Villerius wrote: > On Thu, 2006-06-29 at 22:48 -0700, Mark Wedel wrote: > >> I don't really have any good solution to the stat problem - I don't >> think that is really solvable. >> > It might not be solvable without a lot of work, but I really think > adding a zero to the max stat would make a huge difference. That would > as well allow a change of the effects stats have. Now the difference > between 29 and 30 is incredibly big. It seems to be exponential, which > doesn't make much sense IMO. I think the difference between n and n+1 > should become smaller and smaller (now it's bigger and bigger) > (Anyway, this is quite a distinct discussion) Well here's a new subject then :) Hmm, from what I've heard here, and from players back when I was playing more frequently, I would say that having stats go higher would be a good thing. The issue really is if it is worth the effort of rescaling all of the player stats, all of the item stats, and adjusting everything where the code looks at the stats really. I personally think it would be a good idea, however we would certainly need a detailed plan to address those sorts of issues. Alex Schultz From mwedel at sonic.net Sat Jul 1 12:27:09 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 01 Jul 2006 10:27:09 -0700 Subject: [crossfire] the scale of stats In-Reply-To: <44A6A9B2.90902@telus.net> References: <44A4BB3B.5070709@sonic.net> <1151766735.10530.97.camel@localhost.localdomain> <44A6A9B2.90902@telus.net> Message-ID: <44A6B06D.40905@sonic.net> Alex Schultz wrote: >> It might not be solvable without a lot of work, but I really think >> adding a zero to the max stat would make a huge difference. That would >> as well allow a change of the effects stats have. Now the difference >> between 29 and 30 is incredibly big. It seems to be exponential, which >> doesn't make much sense IMO. I think the difference between n and n+1 >> should become smaller and smaller (now it's bigger and bigger) >> (Anyway, this is quite a distinct discussion) > Well here's a new subject then :) > Hmm, from what I've heard here, and from players back when I was playing > more frequently, I would say that having stats go higher would be a good > thing. The issue really is if it is worth the effort of rescaling all of > the player stats, all of the item stats, and adjusting everything where > the code looks at the stats really. I personally think it would be a > good idea, however we would certainly need a detailed plan to address > those sorts of issues. Maybe for the 3.0 TODO list :) If stats are redone, the bonuses should be changed so that they are linear and not exponentional like it is now (for example, something like .25 SP/power/level or the like). Exact bonuses could be worked out later, but it shouldn't be exponential. But to my mind, there are several issues. IF we suppose the max stat is now 100, what are characters starting stats? Still in the 15?5 range? How do racial maximums come in? How can any character ever hope to get close to a 100 stat? Do items now need to be adjusted? a +3 Str item right now is pretty cool. Under a revised systems, that may not mean much. And if the end result is that everything basically just get multipled by 3 (you now get +15 stat items, etc), you then have to look and say what was the benefit of doing all of that. I think it only make sense if it is tied in with some new form of stat improvement. From mwedel at sonic.net Sat Jul 1 12:41:30 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 01 Jul 2006 10:41:30 -0700 Subject: [crossfire] Items and balance, was Re: race/class lacks distinctions In-Reply-To: <1151766735.10530.97.camel@localhost.localdomain> References: <44A4BB3B.5070709@sonic.net> <1151766735.10530.97.camel@localhost.localdomain> Message-ID: <44A6B3CA.6080401@sonic.net> Wim Villerius wrote: > On Thu, 2006-06-29 at 22:48 -0700, Mark Wedel wrote: >> It has long been discussed that with a few exception (the non humanoid races >> and the classes that prohibit weapons/armors), a lot of race/classes tend to >> blur together. >> >> There are several reasons for this: >> >> - There are not really any race/class restrictions for objects (or conversely, >> not any objects that only clerics can use, or that only fighters can use, etc). >> While there is a 'ring of the paladin', you don't need to be a paladin to use >> it for example. >> >> - Pretty much all the skills are learnable, so what skills you start out with >> are not very important - you can learn everything else later. >> >> - Most differences in stats can be overcome fairly easily by use of items that >> improve your stats. >> >> In terms of these issues, I think the first could be fixed by adding new items >> and a little code - use a key/value to store what class/race can use an object, >> and add some code in the apply logic to check for it. > I would suggest also to modify quite some existing items. Adding still > more items degenerates the value of current items. Why would you search > for 'special item' if the so-and-so not so special item gives almost the > same benefits? > Perhaps - but that's quite a different discussion - it's worth to remove > a lot of (more or less) special items from the game. Possibly. I think Raphael had got some script which showed all the items in the game. But my thought for class/race specific items also does help out balance some. For example, monks are banned from weapons and armor. Certain races are also banned from certain objects. It may be desirable to give those classes/race combinations some items to help restore their balance some. However, you don't want to make them available to everyone, as then the human fighter can use it and really get things out of whack. So such a feature can be used to further help to balance the races and classes. But the other thing, going back to the original discussion, is it starts to add some distinction. As a mage, I can were that diadam of spellcasting, which gives some cool bonus, which fighters can't. This would also likely make it so that all high level characters don't go around all wearing the same equipment, as there sort of is the 'this is the best set of stuff' thing. Another thing, long discussed, was to split attack damages based on attacktype. Right now, if a character does damage, it uses the best of any attacktypes the item(s) he has does. This means that any item that gives you an attacktype is really pretty handy. It also means that balancing some objects is harder. But if you did things like 'dam_fire 12' 'dam_weaponmagic 4', it can help to reblance things some. > > Another great way to eliminate the problem under discussion is to remove > quite some races/classes! Simplicity is a key to success. > Besides, that allows to create really different races/classes Yes - although if different skill levels are done, getting rid of some classes may not work really well. It could perhaps be interesting to have an advanced character creation method where each character is allowed X expert skills, Y basic skills, Z advanced skills, and they can choose which skill they want and customize themselves. But that starts to get really complicated. I haven't looked at all the races recently, but at one time, there were several human type races because there were not different classes, just races, and race sort of determined class. So some of the human type races could probably go away. From mwedel at sonic.net Sat Jul 1 12:57:01 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 01 Jul 2006 10:57:01 -0700 Subject: [crossfire] race/class lacks distinctions In-Reply-To: <1151770781.10530.110.camel@localhost.localdomain> References: <44A4BB3B.5070709@sonic.net> <44A53DF0.6070808@telus.net> <44A5EC04.5040507@sonic.net> <1151770781.10530.110.camel@localhost.localdomain> Message-ID: <44A6B76D.8090301@sonic.net> Wim Villerius wrote: > Well, this certainly makes sense for magic skills. Restricting a warrior > to lvl 25 magic skills doesn't hurt much - he wont use them often. > On the other hand, restricting a mage to use at most lvl 25 one/two > handed is a BIG pain and an unfair restriction. > I have no clue how long ago you tried to kill certain powerfull > monsters, but being a mage it is literally impossible to kill > Lorkas/Gothwolthe/... > Magic is fine for normal critter - even up to grand titans and cyclops - > but it is simply _impossible_ to kill the bosses with that (granted, > Lorkas can easily be killed with diseases, but Gothwolte cannot - he's > an undead force) > In summary: this proposal makes it impossible for a mage to do really > interesting things for that requires weaponery at lvl 100+ (need a good > wc) > (note that this does not YET apply to charm monster) Some of this should probably be fixed by rebalancing of monsters. While perhaps difficult, pretty much every monster should be killable by spells. Now it may be hard, may take a while, etc, but should be doable. Some of this may be left over from what back before the partial resistance code was put in - lots of creatures had immunity (100% resistance), and I don't know if those were all fixed. But also, I don't think it should be expected or be a requirement that every class can complete every dungeon in the game. The number they can't do should be pretty small, but to me, it is reasonable that some dungeons may have a monster that can only be killed by spells, or only killed by melee, etc. > > > It's just the opposite. You're always running out of mana way too fast > and once all mana is used, you're an easy prey. > (And I'm not even talking about treasure that's usualy destroyed by > magic.) OTOH, as a fighter, I often run out of HP pretty fast, and when your out of HP, your dead :( There are ways around both problems to some extent. Spell crystals can help the SP a bit, power potions to regain, etc. >> But a lot is also the speed of combat. IMO, combat is often so fast that it >> is difficult to have much strategy. > Now that is indeed a big problem. Take for example Zorn (Brest > scrollshops) He can kill any player in less than a second, no matter > what the player does. (he is much faster and does 5 times more damage > than Gothwolte, to put him in perspective) So it's inpossible to run > away once he's angry. Even at lower levels, this is a big problem - if your caught in a bolt spell, you need to get out of it pretty quickly or your dead. There is one problem which is the major difference in number of HP for players or monsters. This means other spells cast by players tend to be pretty deadly. Typically, monsters have lots of HP but are slow relative to players. Things probably need to be brought more in line - make most monsters faster than they are now, make most players slower than they are now (at least in terms of number of attacks - even first level characters probably have a 1+ weaponspeed), and give players more HP to balance out those factors (I figure it is easier to give players more HP than to reduce the damager by all the monsters & spells). From fuchs.andy at gmail.com Sat Jul 1 13:15:08 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 1 Jul 2006 14:15:08 -0400 Subject: [crossfire] Items and balance, was Re: race/class lacks distinctions In-Reply-To: <44A6B3CA.6080401@sonic.net> References: <44A4BB3B.5070709@sonic.net> <1151766735.10530.97.camel@localhost.localdomain> <44A6B3CA.6080401@sonic.net> Message-ID: On 7/1/06, Mark Wedel wrote: > Wim Villerius wrote: ... > > I would suggest also to modify quite some existing items. Adding still > > more items degenerates the value of current items. Why would you search > > for 'special item' if the so-and-so not so special item gives almost the > > same benefits? > > Perhaps - but that's quite a different discussion - it's worth to remove > > a lot of (more or less) special items from the game. > > Possibly. I think Raphael had got some script which showed all the items in > the game. > > But my thought for class/race specific items also does help out balance some. > > For example, monks are banned from weapons and armor. Certain races are also > banned from certain objects. > > It may be desirable to give those classes/race combinations some items to help > restore their balance some. However, you don't want to make them available to > everyone, as then the human fighter can use it and really get things out of whack. Anyone want to make a script to find the best set of equipment for each race/class combination? (including generated and modified in map objects) > So such a feature can be used to further help to balance the races and classes. > > But the other thing, going back to the original discussion, is it starts to > add some distinction. As a mage, I can were that diadam of spellcasting, which > gives some cool bonus, which fighters can't. This would also likely make it so > that all high level characters don't go around all wearing the same equipment, > as there sort of is the 'this is the best set of stuff' thing. > > Another thing, long discussed, was to split attack damages based on attacktype. > > Right now, if a character does damage, it uses the best of any attacktypes the > item(s) he has does. > > This means that any item that gives you an attacktype is really pretty handy. > It also means that balancing some objects is harder. > > But if you did things like 'dam_fire 12' 'dam_weaponmagic 4', it can help to > reblance things some. > > > > > > Another great way to eliminate the problem under discussion is to remove > > quite some races/classes! Simplicity is a key to success. > > Besides, that allows to create really different races/classes > > Yes - although if different skill levels are done, getting rid of some classes > may not work really well. > > It could perhaps be interesting to have an advanced character creation method > where each character is allowed X expert skills, Y basic skills, Z advanced > skills, and they can choose which skill they want and customize themselves. But > that starts to get really complicated. > > I haven't looked at all the races recently, but at one time, there were > several human type races because there were not different classes, just races, > and race sort of determined class. So some of the human type races could > probably go away. Lets see: Humans, Halflings (somewhat debatabe if human or just humanoid), Northmen, and Vikings; with Northmen and Vikings sharing the same faces. Other "Humanoids": Dwarves, Elves, Gnomes, Half Orcs (Half Human?), Serpent Men , Trolls, Wraiths What we have left: Quetzalcoatls, Dragons, Fireborns So, yes we can probably get rid of a few of the human/humanoid classes. I want to bring up that there is a patch for an experimental per-race HallOfSelection on the sf.net tracker. This could help the balance issue a little. http://sourceforge.net/tracker/index.php?func=detail&aid=1389432&group_id=13833&atid=313833 -- Andrew Fuchs From alex_sch at telus.net Sat Jul 1 13:25:23 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 01 Jul 2006 12:25:23 -0600 Subject: [crossfire] the scale of stats In-Reply-To: <44A6B06D.40905@sonic.net> References: <44A4BB3B.5070709@sonic.net> <1151766735.10530.97.camel@localhost.localdomain> <44A6A9B2.90902@telus.net> <44A6B06D.40905@sonic.net> Message-ID: <44A6BE13.3080607@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> Well here's a new subject then :) >> Hmm, from what I've heard here, and from players back when I was playing >> more frequently, I would say that having stats go higher would be a good >> thing. The issue really is if it is worth the effort of rescaling all of >> the player stats, all of the item stats, and adjusting everything where >> the code looks at the stats really. I personally think it would be a >> good idea, however we would certainly need a detailed plan to address >> those sorts of issues. >> > > Maybe for the 3.0 TODO list :) > Hmm, this tempts me to want, after 2.0 is released, to make a separate 3.0-dev branch in cvs, to allow for features on what will be the 3.0 todo list, that we don't want in 2.x, to be worked on. It might involve a little effort, syncing changes from the 2.x tree to the 3.x tree, but I don't think that would really be that bad, and is an extremely common practice in larger projects with many more commits to handle. > If stats are redone, the bonuses should be changed so that they are linear and > not exponentional like it is now (for example, something like .25 SP/power/level > or the like). Exact bonuses could be worked out later, but it shouldn't be > exponential. > I would agree with you there. > But to my mind, there are several issues. > Same :) > IF we suppose the max stat is now 100, what are characters starting stats? > Still in the 15?5 range? > Personally, I'm thinking more in the 20?14 range, including racial and class bonuses, as a base before such bonuses, I'm thinking somewhere in the 20?8 type of rage. Of course, I believe that the 15?5 as it is now could very well be made to work. > How do racial maximums come in? How can any character ever hope to get close > to a 100 stat? > Personally, I don't think there should be a 'racial max' really, but instead just have the races affect the chances of gaining stats due to levels, as I mentioned in my previous message. > Do items now need to be adjusted? a +3 Str item right now is pretty cool. > Under a revised systems, that may not mean much. And if the end result is that > everything basically just get multipled by 3 (you now get +15 stat items, etc), > you then have to look and say what was the benefit of doing all of that. > Personally, I'm thinking that multiplying existing item stats by about 3x or 4x would work decently if the max was made about 100, though perhaps certain items may merit exceptions and need a value a little different than that. Also, weapon stat enchantment scrolls would need adjustment, and personally I think the way to do that, would be by making them improve the stat by a randomized amount, something like 2?2 or so. > I think it only make sense if it is tied in with some new form of stat > improvement. Yes, such as the gaining stats with levels as I mentioned in my previous post, or something else perhaps. In any case, I do feel that a different form of stat improvement than currently is needed anyways, as currently, people just get their racial max extremely quickly with potions, and I'm not sure I like the concept of racial max in it's current form anyways. Alex Schultz From alex_sch at telus.net Sat Jul 1 13:38:51 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 01 Jul 2006 12:38:51 -0600 Subject: [crossfire] Items and balance, was Re: race/class lacks distinctions In-Reply-To: <44A6B3CA.6080401@sonic.net> References: <44A4BB3B.5070709@sonic.net> <1151766735.10530.97.camel@localhost.localdomain> <44A6B3CA.6080401@sonic.net> Message-ID: <44A6C13B.7090903@telus.net> Mark Wedel wrote: > But my thought for class/race specific items also does help out balance some. > > For example, monks are banned from weapons and armor. Certain races are also > banned from certain objects. > > It may be desirable to give those classes/race combinations some items to help > restore their balance some. However, you don't want to make them available to > everyone, as then the human fighter can use it and really get things out of whack. > > So such a feature can be used to further help to balance the races and classes. > This does remind me, one thing some players were sometimes thinking of was how it would be having things like dragon-specific weapons/armor. Those ideas never really went far, but some players occasionally were thinking about it. Mainly due to the lack of ability to get many types of attack with dragon melee (yes yes, there's the claw types, however many high level things arn't hurt by any of those), though that is perhaps more of an issue with the resists of monsters, as is being discussed in other messages. > But the other thing, going back to the original discussion, is it starts to > add some distinction. As a mage, I can were that diadam of spellcasting, which > gives some cool bonus, which fighters can't. This would also likely make it so > that all high level characters don't go around all wearing the same equipment, > as there sort of is the 'this is the best set of stuff' thing. > Well, I have found that my main high level character doesn't just use one set of stuff. He carries around a vast variety of things, to he can adjust to any situation, however, 95% of the time he is using a set that's best for spellcasting, or a set that's best for melee. > Another thing, long discussed, was to split attack damages based on attacktype. > > Right now, if a character does damage, it uses the best of any attacktypes the > item(s) he has does. > > This means that any item that gives you an attacktype is really pretty handy. > It also means that balancing some objects is harder. > > But if you did things like 'dam_fire 12' 'dam_weaponmagic 4', it can help to > reblance things some. > Personally, I think that would be a very welcome change, partially because the current system of "uses the best attacktype" does confuse new players frequently. Alex Schultz From alex_sch at telus.net Sat Jul 1 13:44:07 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 01 Jul 2006 12:44:07 -0600 Subject: [crossfire] Items and balance, was Re: race/class lacks distinctions In-Reply-To: References: <44A4BB3B.5070709@sonic.net> <1151766735.10530.97.camel@localhost.localdomain> <44A6B3CA.6080401@sonic.net> Message-ID: <44A6C277.1000403@telus.net> Andrew Fuchs wrote: > > > Anyone want to make a script to find the best set of equipment for > each race/class combination? (including generated and modified in map > objects) > I think I might want to work on making that some time soon, though one question is, best for magic damage? or best for melee damage? I think I'll start with melee, and I'll make use of the python code I already made that calculates melee damage rolls (i.e. accounts for attacktypes, resists, wc, ac, and even deals with things like the death attacktype) and graphs that. Alex Schultz From fuchs.andy at gmail.com Sat Jul 1 14:34:13 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 1 Jul 2006 15:34:13 -0400 Subject: [crossfire] on the delay of sending "on ground" list when player is moving Message-ID: Just dumping this here: On the forum, Monger has suggested that the list of items on the floor, be delayed from updating while the player is moving. http://forum.metalforge.net/viewtopic.php?t=1492 He also suggested that this could have the potential of saving resources on the server. -- Andrew Fuchs From nicolas.weeger at laposte.net Sun Jul 2 03:57:06 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 2 Jul 2006 10:57:06 +0200 Subject: [crossfire] race/class lacks distinctions In-Reply-To: <44A4BB3B.5070709@sonic.net> References: <44A4BB3B.5070709@sonic.net> Message-ID: <200607021057.06443.nicolas.weeger@laposte.net> I won't comment on everything on this thread, just give my 0.2? on some things :) > - Pretty much all the skills are learnable, so what skills you start out > with are not very important - you can learn everything else later. and > For the skills, my thought would be there should be different levels (for > lack of better term) of skills. > > For example, there may be 4 different skills of sorcery - basic, expert, > advanced, mastery. However, these all tie in with the same skill. What about limiting skills in which you can get over level 20 (or 30, or whatever)? So if you're fighter you can get one/two handed weapon and punching to 50, smithery to 40, use magic item to 30, but can't have sorcery/pyromancy over 20? Of course that's arbitrarily limiting skills one can use. But this thread is about that, I think ^_- That'd also require quite many balance changes. More global idea, limit player to having p high level skills in a group of p + n (ie: 2 of one/two handed weapon / karate / sorcery / pyromancy / evocation, 2 of smithery / alchemy / bowyer), the remaining having some cap or penalty. > In terms of these issues, I think the first could be fixed by adding new > items and a little code - use a key/value to store what class/race can use > an object, and add some code in the apply logic to check for it. For races it sure makes sense (the armor is designed for a human, how can a troll think about wearing it? size issues!). Another idea is to add a skill requirement. Using eg Chaos Sword would require level 40+ in one handed weapon. Complements item power, and if spellcasters can't reach 40 in one handed weapon, well, they can't use CS, which seems reasonable - you're a spell caster ;) > What exactly these differences mean would have to be worked out. At a > most basic level, it could determine the rate of exp you gain in the skill > (basic gets 25% of normal or something). There could also be level caps - > mastery caps at 110, advanced 75, expert 50, basic 25 (however, the fact > there really aren't many spells above level 20, this may not mean a lot). Ideally, here's how I'd see the separation. All players would have access to basic versions of healing, word of recall, town portal, some spells here and there (identify, let's say "useful non combat spells"). Higher versions would be reserved to specific classes (if you're a fighter, don't except to be able to cast "regeneration" or "party healing" or "meteor swarm", or with big disadvantages). But as Mark said, players should be able to do most of maps alone, whatever their class. Of course we can still have class-specific maps (quest to become an expert in one handed weapon), or maps requiring 2+ players. Nicolas From tchize at myrealbox.com Sun Jul 2 07:03:35 2006 From: tchize at myrealbox.com (tchize) Date: Sun, 02 Jul 2006 14:03:35 +0200 Subject: [crossfire] player character creation/login redo. In-Reply-To: <44A5F0FE.2020502@sonic.net> References: <44A5F0FE.2020502@sonic.net> Message-ID: <44A7B617.7020804@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You are still mixing at protocol level the player login and the player creation, this is wrong. If a player want to create a character, he clicks on a new character button. He doesn't have to enter user/password before. At protocol level, when player wants to create a new character, the client request from server the list if class and stats with description and modifiers. The player then selects what he wants. Also, player should not be forved to choose a class, he should be presented with the option to choose 3 skills instead. (not all game skills should be available like that!) Mark Wedel a ?crit : > Looking at the 2.0 TODO list: > http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 (as an aside, > I'd hope to make the 2.0 release by end of year, which might limit > it to the 'High' and perhaps some 'medium' items on the list) > > One of the high priority items is character creation todo. That's > been on the list for a long time, and I think is one of the best > things to change for initial player experience. > > Below is basically my general outline. It doesn't go into the > technical details much, but general flow. > > First, the client would have to negotiate that it uses the new > login method - probably via setup. > > Client would prompt player for both name and password in a nice pop > up box, which should display the motd and any other pre login > information. The client would then send this information to the > server in one packet. > > The server could then return 1 of 3 results: 1) login success, and > loads the player up, starts playing with previously saved password. > 2) invalid password - retry login. 3) no such player - go to new > password creation method (ask player if he really wants to create a > new character, confirm password). > > For new players, I see a pop up window with all the selections > (stat adjustment, race & class selection). The client could get > the available races and classes via requestinfo commands. > > For stats, I personally like the idea of giving the player X number > of points to distribute between his stats. This removes the need > to keep re-rolling until you get a good character, and after all, > the client could be hacked to basically do that - re-roll until it > gets the best character possible. The number of points would just > be an option in the settings file, so easy to tune. (alternatively, > stats could be rolled by the server, but instead of anything within > a stat total range be valid, should always return characters that > match the best). > > The player then makes his selections. When all done, they click > done, and the client sends the selection back to the server (player > is an elf fighter, stats ...). Play then begins at what is > considered the starting map. > > I think this would provide the best experience, and at least for > the gtkv2 client, wouldn't be hard to do that window in glade. I > think this is much better than having an in-game mechanism of > moving between maps, etc. > > For compatibility, the existing method can continue to be used for > a while (until at least it seems to have been long enough that > clients that support this new interface are widely used). This new > method isn't requiring any information that isn't currently asked > for - it is just providing a nicer interface (for that matter, if > using the old logic, maybe you won't have a choice but to roll > stats). > > This also has to me the following long term benefits: > > 1) the classes will need to be made fully stand along archetypes > (if not already). I'm not sure if the current hall of selection > map has customized archetypes. > > 2) All new player information is dynamically generated (stats from > settings file, race from archetypes (same as right now), class from > archetypes (not map). This means that new classes or other > customizations can be easily made without needing to update maps. > > 3) This should lead to the eventual removal of the ST_ input states > - shouldn't ever be a need for the server to have to wait for input > of a specific nature for the client - the server can know if a > player is logged in or not, but otherwise, it just gets a bulk of > data (there might need to be the addition of some new Ns_.. socket > states, but I'd rather have state data in only 1 place, not 2). > > > > _______________________________________________ crossfire mailing > list crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEp7YXHHGOa1Q2wXwRAqM8AKDCh6ZeVWRxitKAuEFd6R3UaC3YlACfcw8+ DVnUy2ctMX+oLnoL/ZN54j8= =vUJZ -----END PGP SIGNATURE----- From tchize at myrealbox.com Sun Jul 2 07:04:54 2006 From: tchize at myrealbox.com (tchize) Date: Sun, 02 Jul 2006 14:04:54 +0200 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: References: Message-ID: <44A7B666.4000707@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I do not agree on this change, those informations are not so verbose and have no reason to make users afraid of as they are not visible by default. Normal users don't start game in console and those starting in console want basic messages about what is happening. Moreover, this is pretty usefull to ask on irc a user to dump us content of help - bugreport when trying to support him. It's easier to ask player to go to a menu entry then ask him to go in consle mode, and it works crossplatform Crossfire CVS repository messages. a ?crit : > Module Name: client Committed By: mwedel Date: Sun Jul 2 03:19:43 > UTC 2006 > > Modified Files: client: ChangeLog client/common: misc.c > > Log Message: common/misc.c: Make default log level 2 when not in > debug mode. Normal users probably don't want all the INFO log > messages, and it never makes a good impression about > stability/quality if a program spews out lots of errors or other > messages. MSW 2006-07-01 > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEp7ZlHHGOa1Q2wXwRAsHYAJwNpQ3aGDts/IfYbJdPYeGvX6VFEACeJoky wxfJo+dw4uAaI3ySSS6aYYI= =fnnG -----END PGP SIGNATURE----- From alex_sch at telus.net Sun Jul 2 10:37:50 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 02 Jul 2006 09:37:50 -0600 Subject: [crossfire] race/class lacks distinctions In-Reply-To: <200607021057.06443.nicolas.weeger@laposte.net> References: <44A4BB3B.5070709@sonic.net> <200607021057.06443.nicolas.weeger@laposte.net> Message-ID: <44A7E84E.1090704@telus.net> Nicolas Weeger (Laposte) wrote: > All players would have access to basic versions of healing, word of recall, > town portal, some spells here and there (identify, let's say "useful non > combat spells"). Higher versions would be reserved to specific classes (if > you're a fighter, don't except to be able to cast "regeneration" or "party > healing" or "meteor swarm", or with big disadvantages). I personally agree with that, though IMHO that we would need rebalancing of spells, and addition of a fair number more spells would be necessary for that to work well. Alex Schultz From mwedel at sonic.net Sun Jul 2 13:41:42 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 02 Jul 2006 11:41:42 -0700 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: <44A7B666.4000707@myrealbox.com> References: <44A7B666.4000707@myrealbox.com> Message-ID: <44A81366.20802@sonic.net> tchize wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I do not agree on this change, those informations are not so verbose > and have no reason to make users afraid of as they are not visible by > default. Normal users don't start game in console and those starting > in console want basic messages about what is happening. Moreover, this > is pretty usefull to ask on irc a user to dump us content of help - > bugreport when trying to support him. It's easier to ask player to go > to a menu entry then ask him to go in consle mode, and it works > crossplatform Given (IIRC) that the client does not currently register itself with gnome of KDE, I'd expect most people to actually run from the command line. Any my experience is that very few programs will dump out all that information by default. And one problem in doing so is that it can be harder to see real error messages. Probably the correct solution is to add a -V or --version option to the clients which dump out that information - that is what most all other applications do. It hides the information people don't need by default, but still provides a way to get that information in case of bug reports, etc. > > Crossfire CVS repository messages. a ?crit : > >> Module Name: client Committed By: mwedel Date: Sun Jul 2 03:19:43 >> UTC 2006 >> >> Modified Files: client: ChangeLog client/common: misc.c >> >> Log Message: common/misc.c: Make default log level 2 when not in >> debug mode. Normal users probably don't want all the INFO log >> messages, and it never makes a good impression about >> stability/quality if a program spews out lots of errors or other >> messages. MSW 2006-07-01 >> >> >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFEp7ZlHHGOa1Q2wXwRAsHYAJwNpQ3aGDts/IfYbJdPYeGvX6VFEACeJoky > wxfJo+dw4uAaI3ySSS6aYYI= > =fnnG > -----END PGP SIGNATURE----- > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Sun Jul 2 13:51:04 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 02 Jul 2006 11:51:04 -0700 Subject: [crossfire] player character creation/login redo. In-Reply-To: <44A7B617.7020804@myrealbox.com> References: <44A5F0FE.2020502@sonic.net> <44A7B617.7020804@myrealbox.com> Message-ID: <44A81598.50505@sonic.net> tchize wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > You are still mixing at protocol level the player login and the > player creation, this is wrong. If a player want to create a > character, he clicks on a new character button. He doesn't have to > enter user/password before. At protocol level, when player wants to > create a new character, the client request from server the list if > class and stats with description and modifiers. The player then > selects what he wants. That is a good point. At login, have a few options - log in, or create new character. After creating the new character, the server can then validate if the name is in use, and if so, send an error to the client telling it to come up with a new name. > > Also, player should not be forved to choose a class, he should be > presented with the option to choose 3 skills instead. (not all game > skills should be available like that!) I'd put this in the 'advanced' character creation or something like that. I think if that is done, the skills probably need to be put in categories. And in some cases, some tied together perhaps (you should get both 1 handed and 2 handed weapons?) I'd sort of defer this until the discussion about redoing skills is done, as what should probably really happen is something like 1 or 2 skills at best level, 2 or 3 at medium level, and maybe 3-4 are low level. And there are probably some skills that everyone should get at a low level - punching, praying? Maybe some others? In any case, I still think that providing classes might still be a good idea (maybe reduce the number quite a bit) for new players as a quick creation method as well as knowing you can get a character that is playable. Otherwise, you could get new players that don't choose good skills, and have an unplayable character, and say 'this game sucks'. Also, under such a 'choose skill' method, starting items has to get redone some - if you choose pyromancy, you should get at least one pyromancy spell, right? From mwedel at sonic.net Sun Jul 2 14:11:26 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 02 Jul 2006 12:11:26 -0700 Subject: [crossfire] race/class lacks distinctions In-Reply-To: <200607021057.06443.nicolas.weeger@laposte.net> References: <44A4BB3B.5070709@sonic.net> <200607021057.06443.nicolas.weeger@laposte.net> Message-ID: <44A81A5E.10304@sonic.net> Nicolas Weeger (Laposte) wrote: > > What about limiting skills in which you can get over level 20 (or 30, or > whatever)? > So if you're fighter you can get one/two handed weapon and punching to 50, > smithery to 40, use magic item to 30, but can't have sorcery/pyromancy over > 20? > Of course that's arbitrarily limiting skills one can use. But this thread is > about that, I think ^_- > That'd also require quite many balance changes. That is sort of what I also said in the original message. However, I certainly don't want to have lines in the code of things like 'if player class if fighter and skill is pyromancy, max level is 20'. That just gets really messy, and has to be updated whenever a new class may be added. I'd much rather that all that information be stored in the skill object itself. Which then goes back to having different skill objects, and characters getting these different objects based on if they start with the skill or learn it later on. > > More global idea, limit player to having p high level skills in a group of p + > n (ie: 2 of one/two handed weapon / karate / sorcery / pyromancy / evocation, > 2 of smithery / alchemy / bowyer), the remaining having some cap or penalty. I'm not sure if that is good method, however. For one, it means some skills will always be second class skill. Granted, it is hard to get some skills pretty high, but I doubt many people would ever want a high singing skill if it now prevents them from getting a high spellcasting skill. The other problem here is just ordering. Maybe you want a high alchemy skill. But in the course of adventuring, your combat/spellcasting skills go up, and now you've reached your cap on the number of high level skills you can have, so you can never get a high alchemy skill. > >> In terms of these issues, I think the first could be fixed by adding new >> items and a little code - use a key/value to store what class/race can use >> an object, and add some code in the apply logic to check for it. > > For races it sure makes sense (the armor is designed for a human, how can a > troll think about wearing it? size issues!). That wasn't my main concern - I really don't need to see 20 different types of armor (but how that titan can wear the same plate armor as you is a little odd). But most RPG's have some items that can only be used by certain classes/races, and it adds a nice little touch IMO. It may also add some more player interaction, especially if these items are somewhat rare but still findable at low level. If you are a human but find an item that can only be used by a dwarf, it has zero use, but may have lots of use to a dwarf. > Another idea is to add a skill requirement. Using eg Chaos Sword would require > level 40+ in one handed weapon. Complements item power, and if spellcasters > can't reach 40 in one handed weapon, well, they can't use CS, which seems > reasonable - you're a spell caster ;) That's possible. I think we should be careful on the number of requirements that may be in place to use an object. but having class/race/skill level requirements could be yet another way to help balance things. > >> What exactly these differences mean would have to be worked out. At a >> most basic level, it could determine the rate of exp you gain in the skill >> (basic gets 25% of normal or something). There could also be level caps - >> mastery caps at 110, advanced 75, expert 50, basic 25 (however, the fact >> there really aren't many spells above level 20, this may not mean a lot). > > Ideally, here's how I'd see the separation. > > All players would have access to basic versions of healing, word of recall, > town portal, some spells here and there (identify, let's say "useful non > combat spells"). Higher versions would be reserved to specific classes (if > you're a fighter, don't except to be able to cast "regeneration" or "party > healing" or "meteor swarm", or with big disadvantages). It sounds like your basically trying to tie the spells to a class, and not a skill then? I'm not sure if this is the right approach. If you read tchize's method about new character creation, he is proposing the idea that there are no classes really - you just choose the skills you want. While I don't think that is necessary good for new players, I think that is a valid option fo experienced players. So under such a method, you really have to tie this to the players skill level, and not class (which actually sort of also means that item use perhaps needs to be tied to skill level also, and not class). But IMO, most of this balance should probably be driven by skills, and not classes. Really, all that classes should determine is what skill (and quality of that skill) you get, and perhaps starting equipment. So I think we have to be careful with tieing things to classes, as that is likely to not really work well. From tchize at myrealbox.com Sun Jul 2 16:21:33 2006 From: tchize at myrealbox.com (tchize) Date: Sun, 02 Jul 2006 23:21:33 +0200 Subject: [crossfire] [Crossfire-cvs] CVS commit: client - info level In-Reply-To: <44A81366.20802@sonic.net> References: <44A7B666.4000707@myrealbox.com> <44A81366.20802@sonic.net> Message-ID: <44A838DD.4080401@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Most distros provide a shortcut menu to client, moreover, windows users don't use the console and it would be very difficult to have them running a program from console to pass log argument. I ran it in info mode just to check, all i got is 30 lines of info telling user mainly about client modules version and server communication. This is not so much, i remember games like half-life or UT dump pages of messages in console and nobody is afraid of this. And i don't see where this make errors difficulut to find. By user? When user has program running like he wants, am pretty sure it doesn't read console! By developper? developper will need at least an info level to see what's wrong most of the time. Seriously, I don't want to fight on this point, this is pretty trivial and i have othere things to do. This is my last mail on this subjectn do what you like. I have never seen a player on irc being afraid of those messages and i have seen several time it proves usefull to detect version of client / detect kind of server the user is playing on. Usefull informations are provided on info level while not slowing client and not invading user. There was no point removing that behaviour. There is no gain in removal and there is informations lost. Greetings, Tchize Mark Wedel a ?crit : > tchize wrote: > > I do not agree on this change, those informations are not so > verbose and have no reason to make users afraid of as they are not > visible by default. Normal users don't start game in console and > those starting in console want basic messages about what is > happening. Moreover, this is pretty usefull to ask on irc a user to > dump us content of help - bugreport when trying to support him. > It's easier to ask player to go to a menu entry then ask him to go > in consle mode, and it works crossplatform > > >> Given (IIRC) that the client does not currently register itself > with gnome of >> KDE, I'd expect most people to actually run from the command >> line. > >> Any my experience is that very few programs will dump out all > that information >> by default. And one problem in doing so is that it can be harder >> > to see real >> error messages. > >> Probably the correct solution is to add a -V or --version option > to the >> clients which dump out that information - that is what most all >> other applications do. It hides the information people don't >> need by > default, but >> still provides a way to get that information in case of bug > reports, etc. > > > Crossfire CVS repository messages. a ?crit : > >> Module Name: client Committed By: mwedel Date: Sun Jul 2 03:19:43 >> UTC 2006 > >> Modified Files: client: ChangeLog client/common: misc.c > >> Log Message: common/misc.c: Make default log level 2 when not in >> debug mode. Normal users probably don't want all the INFO log >> messages, and it never makes a good impression about >> stability/quality if a program spews out lots of errors or other >> messages. MSW 2006-07-01 > > > _______________________________________________ crossfire mailing list crossfire at metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire > _______________________________________________ crossfire mailing > list crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEqDjdHHGOa1Q2wXwRAqCsAKC98YV4k/5tWZMbolb2E7egpZGkmACeJDh1 838DvvJQbVxXYeMf07BS13M= =ZSSC -----END PGP SIGNATURE----- From wim-cf at villerius.nl Mon Jul 3 02:09:41 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Mon, 03 Jul 2006 09:09:41 +0200 Subject: [crossfire] race/class lacks distinctions In-Reply-To: <44A6B76D.8090301@sonic.net> References: <44A4BB3B.5070709@sonic.net> <44A53DF0.6070808@telus.net> <44A5EC04.5040507@sonic.net> <1151770781.10530.110.camel@localhost.localdomain> <44A6B76D.8090301@sonic.net> Message-ID: <1151910582.17149.22.camel@localhost.localdomain> On Sat, 2006-07-01 at 10:57 -0700, Mark Wedel wrote: > Wim Villerius wrote: > > > Well, this certainly makes sense for magic skills. Restricting a warrior > > to lvl 25 magic skills doesn't hurt much - he wont use them often. > > On the other hand, restricting a mage to use at most lvl 25 one/two > > handed is a BIG pain and an unfair restriction. > > I have no clue how long ago you tried to kill certain powerfull > > monsters, but being a mage it is literally impossible to kill > > Lorkas/Gothwolthe/... > > Magic is fine for normal critter - even up to grand titans and cyclops - > > but it is simply _impossible_ to kill the bosses with that (granted, > > Lorkas can easily be killed with diseases, but Gothwolte cannot - he's > > an undead force) > > In summary: this proposal makes it impossible for a mage to do really > > interesting things for that requires weaponery at lvl 100+ (need a good > > wc) > > (note that this does not YET apply to charm monster) > > Some of this should probably be fixed by rebalancing of monsters. While > perhaps difficult, pretty much every monster should be killable by spells. Now > it may be hard, may take a while, etc, but should be doable. > > Some of this may be left over from what back before the partial resistance > code was put in - lots of creatures had immunity (100% resistance), and I don't > know if those were all fixed. Some monsters are expected to be hard to kill. Gothwolthe is one of them and IMO it is reasonable that only one attack type will kill him. On the other hand, many monsters have 30,000 hp and 95% resistance and a high regeneration rate. That combination is rather insane. It means that in the time a monster regenerates X, more than 20X damage should be done in order to kill it sometime. > >> But a lot is also the speed of combat. IMO, combat is often so fast that it > >> is difficult to have much strategy. > > Now that is indeed a big problem. Take for example Zorn (Brest > > scrollshops) He can kill any player in less than a second, no matter > > what the player does. (he is much faster and does 5 times more damage > > than Gothwolte, to put him in perspective) So it's inpossible to run > > away once he's angry. > > Even at lower levels, this is a big problem - if your caught in a bolt spell, > you need to get out of it pretty quickly or your dead. IMO it is especially a problem at high lvl. Being lvl 114, having great armour and lifesaving, you just don't expect to be killed in less than a second. That's unfair, for it means that no player ever stand a change against a creature such as Zorn. > There is one problem which is the major difference in number of HP for players > or monsters. This means other spells cast by players tend to be pretty deadly. > > Typically, monsters have lots of HP but are slow relative to players. Things > probably need to be brought more in line - make most monsters faster than they > are now, make most players slower than they are now (at least in terms of number > of attacks - even first level characters probably have a 1+ weaponspeed), and > give players more HP to balance out those factors (I figure it is easier to give > players more HP than to reduce the damager by all the monsters & spells). Having players walk slower would especially hurt low lvls. For them, walking is already tidious. But reducing weapon speed might make sense since that is effectively reducing damge by two. OTOH this might render some monsters really untouchable, namely if their regeneration&resistance is so high that a player never can do sufficient damage. Increasing monster speed might not be always a good idea. Evil masters are already lightning fast and since they run away when they're low on hp, it's fun but hard to kill them. Kind of cat and mouse. The only question that remains is what to do with players hitpoints. The main problem might be that while players hp change linear (+2 each lvl once they have max con) monster's hp go exponentially. So giving a player 4000 hp max might make sense compared to big bosses, but that factor is just too much for low lvl players facing goblins. This suggest both to increase the basic hp with a factor 3 or 4 (newbs die too fast) and increase the number of hp gained by leveling. From yann.chachkoff at myrealbox.com Mon Jul 3 05:04:51 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Mon, 3 Jul 2006 12:04:51 +0200 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: <44A81366.20802@sonic.net> References: <44A7B666.4000707@myrealbox.com> <44A81366.20802@sonic.net> Message-ID: <200607031204.56244.yann.chachkoff@myrealbox.com> > Given (IIRC) that the client does not currently register itself with > gnome of KDE, I'd expect most people to actually run from the command line. > > Any my experience is that very few programs will dump out all that > information by default. And one problem in doing so is that it can be > harder to see real error messages. > It sounds like backward thinking to me. That most people have to run the game from the command line (and thus, see all what the client can spit out) seems to be the point to solve, and not the messages provided. Moreover, if the error messages are hard to spot, then make them more obvious (add stars around them, write a couple of !!!, shift them, add blank lines before and after them, etc). I'd also underline that the error messages targetted at the player shouldn't only go to the console, but also be clearly visible from the GUI itself in the first place whenever possible. In such a case, the player would logically first report the short error message he/she saw in a dialog box. Then, if details are needed, he/she can sends the whole content of the console messages. Sounds a much better way to make at least common errors easier to spot for the player than completely hiding what's basically useful information. > Probably the correct solution is to add a -V or --version option to the > clients which dump out that information - that is what most all other > applications do. It hides the information people don't need by default, > but still provides a way to get that information in case of bug reports, > etc. > The question is: which informations are needed by default ? I think the "Info" should have an obvious meaning: provide a couple of informations that *may* be useful in several cases, debugging being one of them. If some informations are judged superlfluous at the default level of log (typically, what's required only for debugging/post-mortem analysis) then those should be put back in the "Debug" log level, which would appear only when the verbosity is explicitely increased. Finally, I don't get why this change was done in the first place - I've so far never heard anybody bothered by the amount of log messages provided in the console; besides that, there are relatively few messages displayed, even at the "Info" level. So not only does the change of the default verbosity level in the client sound detrimental to me, but it solves a problem that didn't even exist in the first place. > > > Crossfire CVS repository messages. a ?crit : > >> Module Name: client Committed By: mwedel Date: Sun Jul 2 03:19:43 > >> UTC 2006 > >> > >> Modified Files: client: ChangeLog client/common: misc.c > >> > >> Log Message: common/misc.c: Make default log level 2 when not in > >> debug mode. Normal users probably don't want all the INFO log > >> messages, and it never makes a good impression about > >> stability/quality if a program spews out lots of errors or other > >> messages. MSW 2006-07-01 > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.1 (GNU/Linux) > > > > iD8DBQFEp7ZlHHGOa1Q2wXwRAsHYAJwNpQ3aGDts/IfYbJdPYeGvX6VFEACeJoky > > wxfJo+dw4uAaI3ySSS6aYYI> > =fnnG > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > > crossfire mailing list > > crossfire at metalforge.org > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- Yann Chachkoff ----------------------- GPG Key 2006: http://keyserver.veridis.com:11371/export?id=-43113965597490782 Fingerprint : C224 F1F9 9025 4FC7 987D 05BB FF66 D413 A3B4 01A2 ----------------------- "They misunderestimated me." - George W. Bush -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060703/1ac8400e/attachment.pgp From alex_sch at telus.net Mon Jul 3 09:41:18 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 03 Jul 2006 08:41:18 -0600 Subject: [crossfire] race/class lacks distinctions In-Reply-To: <1151910582.17149.22.camel@localhost.localdomain> References: <44A4BB3B.5070709@sonic.net> <44A53DF0.6070808@telus.net> <44A5EC04.5040507@sonic.net> <1151770781.10530.110.camel@localhost.localdomain> <44A6B76D.8090301@sonic.net> <1151910582.17149.22.camel@localhost.localdomain> Message-ID: <44A92C8E.1010706@telus.net> Wim Villerius wrote: > Some monsters are expected to be hard to kill. Gothwolthe is one of them > and IMO it is reasonable that only one attack type will kill him. Note, there is a second way to kill him: banishment of gaea (particularly from a high level heavy rod). So as it stands, the few ways to kill Gothwolte, are melee with Beelzebub's sword, banishment of gaea from a rod (overpowered), natural banishment of gaea (slow), a sword of slay undead (slaying gets around resists and immunities, but difficult to find one powerful enough), animated Beelzebub's sword or sword with slay undead (near impossible), and those acid prayers of gorok (near impossible). However, if the banishment of gaea rod thing is to be fixed (which IMHO it should), it would leave dragons and fireborn (and if the skill/classes are changed, any spellcasters too) virtually unable to kill Gothwolte, and while this may fit the quest, it is very very disappointing to go all the way through such a long series of quests, only to be unable to defeat the final thing no matter how you try. I personally don't think Gothwolte's resists should be changed, but I believe that this an issue that players could get so far in a quest only to find the last bit impossible for them. Alex Schultz From nicolas.weeger at laposte.net Mon Jul 3 14:57:41 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 3 Jul 2006 21:57:41 +0200 Subject: [crossfire] [Crossfire-cvs] CVS commit: client - info level In-Reply-To: <44A838DD.4080401@myrealbox.com> References: <44A81366.20802@sonic.net> <44A838DD.4080401@myrealbox.com> Message-ID: <200607032157.41128.nicolas.weeger@laposte.net> Hello. > Most distros provide a shortcut menu to client, moreover, windows > users don't use the console and it would be very difficult to have > them running a program from console to pass log argument. I ran it in Actually, Windows client does get console. Shortcut runs app, and you see the console still. Nicolas From mwedel at sonic.net Tue Jul 4 03:23:31 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 04 Jul 2006 01:23:31 -0700 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: <200607031204.56244.yann.chachkoff@myrealbox.com> References: <44A7B666.4000707@myrealbox.com> <44A81366.20802@sonic.net> <200607031204.56244.yann.chachkoff@myrealbox.com> Message-ID: <44AA2583.8070905@sonic.net> General quick thoughts: I removed them as I believe (rightly or wrongly) that software presented for general end user consumption should not be producing debug or information messages - it should only print error messages. I'd almost be tempted to say that the default log level should even go one step higher, so that warnings should by default not be printed - only print error or above Off the top of my head, I can not think of any other unix/linux programs that produce a list of the rcsid versions of all the files when started. I'm sure there are exceptions, but I think it is better of we behave like most other programs. I'm not even sure if the reporting of rcsid information has ever proved useful - I can't recall any bug reports where that has been provided. Most useful bit of information that users can provide is the overal version number of the client they are using, not the version information of the specific files. A lot of this is also perception. While perhaps no official complaints registered, I don't think it puts a good perception on the program. All that said, thoughts on how to fix this: 1) Within the client itself, this information should be presented in the GUI. For the gtk client, I'm going to modify the bug report page to include this information. For the gtk2 client, I'll make an about page that also includes that. If in fact most people are running the client from a launcher and not seeing the messages, then they aren't doing any good (that seems like counter argument - no one will see the messages, so having them there doesn't harm anything). So having an in-client way to display them is better. 2) The log level should not be a compiled in default - one should be able to specify it via command line (-loglevel 0) or whatever. In that case, if user has a bug, we can always say 'run with -loglevel 0' and provide us the output. This is more useful in all cases, as by default, old log level was 1 so we couldn't get debug level output without requesting the user to recompile (which doesn't work when it is prebundled). This should be pretty easy to do I think. How do those remedies sound to people? From tchize at myrealbox.com Tue Jul 4 03:41:09 2006 From: tchize at myrealbox.com (Tchize) Date: Tue, 04 Jul 2006 10:41:09 +0200 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: <44AA2583.8070905@sonic.net> References: <44A7B666.4000707@myrealbox.com> <44A81366.20802@sonic.net> <200607031204.56244.yann.chachkoff@myrealbox.com> <44AA2583.8070905@sonic.net> Message-ID: <44AA29A5.2010701@myrealbox.com> Mark Wedel wrote: > General quick thoughts: > > I removed them as I believe (rightly or wrongly) that software presented for > general end user consumption should not be producing debug or information > messages - it should only print error messages. I'd almost be tempted to say > that the default log level should even go one step higher, so that warnings > should by default not be printed - only print error or above > From info to critical is everything that might concern user, every thing below is of concern to developpers. > Off the top of my head, I can not think of any other unix/linux programs that > produce a list of the rcsid versions of all the files when started. I'm sure > there are exceptions, but I think it is better of we behave like most other > programs. > This was (probably wrongly) introduced because i couldn't find a better way to identify version when it comes to cvs build clients. However, these informations can probably go in debug level. At least, the version number of client should be increased in cvs just after each release. (example: set 1.9.1, commit, tag cvs, release, set to 'post 1.9.1', commit) > > 1) Within the client itself, this information should be presented in the GUI. > For the gtk client, I'm going to modify the bug report page to include this > information. For the gtk2 client, I'll make an about page that also includes that. > > If in fact most people are running the client from a launcher and not seeing > the messages, then they aren't doing any good (that seems like counter argument > - no one will see the messages, so having them there doesn't harm anything). So > having an in-client way to display them is better. > help -> bug report, there is already everything needed there to provide information for a bug report, that is copy of log messages and a link to sourceforge tracker... btw, a 'fork at begin, watch for dying of client process, expose a bug report window' might be interresting too, but quite more cumbersome to make :) > 2) The log level should not be a compiled in default > agree, but info level should be the default. From mwedel at sonic.net Tue Jul 4 14:40:40 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 04 Jul 2006 12:40:40 -0700 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: <44AA29A5.2010701@myrealbox.com> References: <44A7B666.4000707@myrealbox.com> <44A81366.20802@sonic.net> <200607031204.56244.yann.chachkoff@myrealbox.com> <44AA2583.8070905@sonic.net> <44AA29A5.2010701@myrealbox.com> Message-ID: <44AAC438.4070502@sonic.net> One thing which may make sense is different default levels based on if it is a precompiled binary vs something checked out from CVS. I still stand by that the precompiled binaries should be less verbose on problems - we're putting this out there as this is quality software, so it should act like it. Perhaps even the official source code releases should also be more quiet. However, if running from CVS, then having all sorts of error messages is fine. I'm not sure if there is any way of automatically doing this detection logic in the build environment itself. I suppose the file can be changed just prior to release. Maybe the best method is also an ability to pass it in via command line/CFLAGS (-DLOGLEVEL=...) From tchize at myrealbox.com Wed Jul 5 02:24:10 2006 From: tchize at myrealbox.com (Tchize) Date: Wed, 05 Jul 2006 09:24:10 +0200 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: <44AAC438.4070502@sonic.net> References: <44A7B666.4000707@myrealbox.com> <44A81366.20802@sonic.net> <200607031204.56244.yann.chachkoff@myrealbox.com> <44AA2583.8070905@sonic.net> <44AA29A5.2010701@myrealbox.com> <44AAC438.4070502@sonic.net> Message-ID: <44AB691A.6000000@myrealbox.com> Maybe a ./configure --release= :) Mark Wedel wrote: > One thing which may make sense is different default levels based on if it is a > precompiled binary vs something checked out from CVS. > > I still stand by that the precompiled binaries should be less verbose on > problems - we're putting this out there as this is quality software, so it > should act like it. Perhaps even the official source code releases should also > be more quiet. > > However, if running from CVS, then having all sorts of error messages is fine. > > I'm not sure if there is any way of automatically doing this detection logic > in the build environment itself. I suppose the file can be changed just prior > to release. Maybe the best method is also an ability to pass it in via command > line/CFLAGS (-DLOGLEVEL=...) > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From alex_sch at telus.net Wed Jul 5 10:54:08 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 05 Jul 2006 09:54:08 -0600 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: <44AB691A.6000000@myrealbox.com> References: <44A7B666.4000707@myrealbox.com> <44A81366.20802@sonic.net> <200607031204.56244.yann.chachkoff@myrealbox.com> <44AA2583.8070905@sonic.net> <44AA29A5.2010701@myrealbox.com> <44AAC438.4070502@sonic.net> <44AB691A.6000000@myrealbox.com> Message-ID: <44ABE0A0.4080006@telus.net> Tchize wrote: > Maybe a ./configure --release= > :) I really like that idea, except for one issue. People compiling from source releases typically wouldn't do that, so I think that what would be better than including that in the ./configure, would be having a simple script that could be run as part of the release process. Alex Schultz From mwedel at sonic.net Thu Jul 6 00:42:16 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 05 Jul 2006 22:42:16 -0700 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: <44ABE0A0.4080006@telus.net> References: <44A7B666.4000707@myrealbox.com> <44A81366.20802@sonic.net> <200607031204.56244.yann.chachkoff@myrealbox.com> <44AA2583.8070905@sonic.net> <44AA29A5.2010701@myrealbox.com> <44AAC438.4070502@sonic.net> <44AB691A.6000000@myrealbox.com> <44ABE0A0.4080006@telus.net> Message-ID: <44ACA2B8.5070903@sonic.net> Alex Schultz wrote: > Tchize wrote: >> Maybe a ./configure --release= >> :) > I really like that idea, except for one issue. People compiling from > source releases typically wouldn't do that, so I think that what would > be better than including that in the ./configure, would be having a > simple script that could be run as part of the release process. Updating the version number requires the update of the configure.ac script (then it builds the correct package, etc). Likewise for the rpmspec file. However, doing something like ./configure --debuglevel=0 does work, because the rpmspec, which at least is used for rpm building, does have the configure line it uses, so modifying that to include the debug option works just fine and dandy. I'll look at doing that. From wim-cf at villerius.nl Wed Jul 5 12:42:42 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Wed, 05 Jul 2006 19:42:42 +0200 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: <44ABE0A0.4080006@telus.net> References: <44A7B666.4000707@myrealbox.com> <44A81366.20802@sonic.net> <200607031204.56244.yann.chachkoff@myrealbox.com> <44AA2583.8070905@sonic.net> <44AA29A5.2010701@myrealbox.com> <44AAC438.4070502@sonic.net> <44AB691A.6000000@myrealbox.com> <44ABE0A0.4080006@telus.net> Message-ID: <1152121362.25678.38.camel@localhost.localdomain> maybe add in the configure script something like (pseudo code) if -e "./CVS" then cvs-date=date_of_"./CVS" that won't give a version number, but it does include a clue about the version used. On Wed, 2006-07-05 at 09:54 -0600, Alex Schultz wrote: > Tchize wrote: > > Maybe a ./configure --release= > > :) > I really like that idea, except for one issue. People compiling from > source releases typically wouldn't do that, so I think that what would > be better than including that in the ./configure, would be having a > simple script that could be run as part of the release process. > > Alex Schultz > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From mwedel at sonic.net Thu Jul 6 01:27:47 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 05 Jul 2006 23:27:47 -0700 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: <44ACA2B8.5070903@sonic.net> References: <44A7B666.4000707@myrealbox.com> <44A81366.20802@sonic.net> <200607031204.56244.yann.chachkoff@myrealbox.com> <44AA2583.8070905@sonic.net> <44AA29A5.2010701@myrealbox.com> <44AAC438.4070502@sonic.net> <44AB691A.6000000@myrealbox.com> <44ABE0A0.4080006@telus.net> <44ACA2B8.5070903@sonic.net> Message-ID: <44ACAD63.2060007@sonic.net> Mark Wedel wrote: > Alex Schultz wrote: >> Tchize wrote: >>> Maybe a ./configure --release= >>> :) >> I really like that idea, except for one issue. People compiling from >> source releases typically wouldn't do that, so I think that what would >> be better than including that in the ./configure, would be having a >> simple script that could be run as part of the release process. > > Updating the version number requires the update of the configure.ac script > (then it builds the correct package, etc). Likewise for the rpmspec file. > > However, doing something like ./configure --debuglevel=0 does work, because > the rpmspec, which at least is used for rpm building, does have the configure > line it uses, so modifying that to include the debug option works just fine and > dandy. > > I'll look at doing that. That was easier than expected, so I put in a --with-logevel=x configure options. From wim-cf at villerius.nl Wed Jul 5 12:42:42 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Wed, 05 Jul 2006 19:42:42 +0200 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: <44ABE0A0.4080006@telus.net> References: <44A7B666.4000707@myrealbox.com> <44A81366.20802@sonic.net> <200607031204.56244.yann.chachkoff@myrealbox.com> <44AA2583.8070905@sonic.net> <44AA29A5.2010701@myrealbox.com> <44AAC438.4070502@sonic.net> <44AB691A.6000000@myrealbox.com> <44ABE0A0.4080006@telus.net> Message-ID: <1152121362.25678.38.camel@localhost.localdomain> maybe add in the configure script something like (pseudo code) if -e "./CVS" then cvs-date=date_of_"./CVS" that won't give a version number, but it does include a clue about the version used. On Wed, 2006-07-05 at 09:54 -0600, Alex Schultz wrote: > Tchize wrote: > > Maybe a ./configure --release= > > :) > I really like that idea, except for one issue. People compiling from > source releases typically wouldn't do that, so I think that what would > be better than including that in the ./configure, would be having a > simple script that could be run as part of the release process. > > Alex Schultz > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From tchize at myrealbox.com Thu Jul 6 02:25:38 2006 From: tchize at myrealbox.com (Tchize) Date: Thu, 06 Jul 2006 09:25:38 +0200 Subject: [crossfire] [Crossfire-cvs] CVS commit: client In-Reply-To: <44ACA2B8.5070903@sonic.net> References: <44A7B666.4000707@myrealbox.com> <44A81366.20802@sonic.net> <200607031204.56244.yann.chachkoff@myrealbox.com> <44AA2583.8070905@sonic.net> <44AA29A5.2010701@myrealbox.com> <44AAC438.4070502@sonic.net> <44AB691A.6000000@myrealbox.com> <44ABE0A0.4080006@telus.net> <44ACA2B8.5070903@sonic.net> Message-ID: <44ACBAF2.1020000@myrealbox.com> Let's just do what Wim Villerius suggested: if we find a .CVS, use it as version number, else use version number read from a simple VERSION file. This all can be calculated at very begining of configure script, before defining version number :) Mark Wedel wrote: > Alex Schultz wrote: > >> Tchize wrote: >> >>> Maybe a ./configure --release= >>> :) >>> >> I really like that idea, except for one issue. People compiling from >> source releases typically wouldn't do that, so I think that what would >> be better than including that in the ./configure, would be having a >> simple script that could be run as part of the release process. >> > > Updating the version number requires the update of the configure.ac script > (then it builds the correct package, etc). Likewise for the rpmspec file. > > However, doing something like ./configure --debuglevel=0 does work, because > the rpmspec, which at least is used for rpm building, does have the configure > line it uses, so modifying that to include the debug option works just fine and > dandy. > > I'll look at doing that. > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From mwedel at sonic.net Thu Jul 6 02:29:26 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 06 Jul 2006 00:29:26 -0700 Subject: [crossfire] no_pick 1 on earthwalls Message-ID: <44ACBBD6.4010605@sonic.net> anyone know of a particular reason that earthwalls have no_pick 1 set? Earthwalls are 'alive 1', so can't be picked up in any case. Where this comes up is related to stacking and the new code - the new stacking code tries to put objects of specific types on specific layers (so monsters will be on top of objects, spells on top of monsters, etc). Some maps hide things behind earthwalls, and since no pick objects are a lower layer than pickable objects, this results in objects no longer being hidden by the earthwall, and instead are now on top. I removed the 'no_pick 1' from my test server, and at a brief check, earthwalls behaved the same (had to whack them to destroy them). But before committing that change, just thought I'd ask to make sure no one is aware of any other problems. From mwedel at sonic.net Thu Jul 6 02:46:29 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 06 Jul 2006 00:46:29 -0700 Subject: [crossfire] Monster & player balance, was Re: race/class lacks distinctions In-Reply-To: <1151910582.17149.22.camel@localhost.localdomain> References: <44A4BB3B.5070709@sonic.net> <44A53DF0.6070808@telus.net> <44A5EC04.5040507@sonic.net> <1151770781.10530.110.camel@localhost.localdomain> <44A6B76D.8090301@sonic.net> <1151910582.17149.22.camel@localhost.localdomain> Message-ID: <44ACBFD5.5000601@sonic.net> Wim Villerius wrote: > On Sat, 2006-07-01 at 10:57 -0700, Mark Wedel wrote: >> Typically, monsters have lots of HP but are slow relative to players. Things >> probably need to be brought more in line - make most monsters faster than they >> are now, make most players slower than they are now (at least in terms of number >> of attacks - even first level characters probably have a 1+ weaponspeed), and >> give players more HP to balance out those factors (I figure it is easier to give >> players more HP than to reduce the damager by all the monsters & spells). > Having players walk slower would especially hurt low lvls. For them, > walking is already tidious. But reducing weapon speed might make sense > since that is effectively reducing damge by two. OTOH this might render > some monsters really untouchable, namely if their > regeneration&resistance is so high that a player never can do sufficient > damage. My thought in terms of speed is to generally reduce the range it will be 'naturally'. So if you don't have magic to boost it, the range would be 0.25 to 0.75, based on weight. In many cases, this may actually make low level players faster. Right now, min speed is 0.10 Then the various speed items act as a bonus, making you faster. My idea is more to cut down the speed of higher level players some (I believe with high dex/str, one can get a 1.20+ speed without any bonus speed objects). I think the weight encumberance is calculated should be redone - you should be able to carry some weight without it affecting movement at all, and then after that, it starts to slow you down. So in effect, you could carry 25% of your max load and still move at 0.75, but then each pound you start picking you up may slow you a little bit, like right now, down to 0.25 speed when at full carrying capacity. > > Increasing monster speed might not be always a good idea. Evil masters > are already lightning fast and since they run away when they're low on > hp, it's fun but hard to kill them. Kind of cat and mouse. Some monsters already move fast. But they are the exception - lots of monsters move pretty slowly, and those are the ones I'm thinking should be sped up some. This may make spellcasting harder, as monsters will be able to close to you faster at lower levels. > The only question that remains is what to do with players hitpoints. The > main problem might be that while players hp change linear (+2 each lvl > once they have max con) monster's hp go exponentially. So giving a > player 4000 hp max might make sense compared to big bosses, but that > factor is just too much for low lvl players facing goblins. > This suggest both to increase the basic hp with a factor 3 or 4 (newbs > die too fast) and increase the number of hp gained by leveling. It may make sense to try and work on what would be a good number of HP for a high level character to have. Taking a look right now, it seems that at level 110, HP max out at around 550. At very low levels, I'm not sure if HP is much a problem. Granted, I'm an experienced player, but if you head into the newbie dungeon, and are not completely careless, you can shouldn't have many problems, and can get to level 3 (or thereabouts) when you clear it out. In any case, rebalancing crossfire probably is a major task. What I'd really like are fewer monsters that are tougher to kill and take longer to kill. From nicolas.weeger at laposte.net Thu Jul 6 12:45:25 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Thu, 6 Jul 2006 19:45:25 +0200 Subject: [crossfire] no_pick 1 on earthwalls In-Reply-To: <44ACBBD6.4010605@sonic.net> References: <44ACBBD6.4010605@sonic.net> Message-ID: <200607061945.25190.nicolas.weeger@laposte.net> > anyone know of a particular reason that earthwalls have no_pick 1 set? Isn't it related to create earthwall not working correctly? Something to do with the wall size? Nicolas From crossfire-devel-bounces at lists.sourceforge.net Sat Jul 8 19:58:22 2006 From: crossfire-devel-bounces at lists.sourceforge.net (crossfire-devel-bounces at lists.sourceforge.net) Date: Sat, 08 Jul 2006 17:58:22 -0700 Subject: [crossfire] Forward of moderated message Message-ID: An embedded message was scrubbed... From: "Daimonin" Subject: 32000 file border for player files Date: Sat, 8 Jul 2006 16:34:45 +0200 Size: 3066 Url: http://mailman.metalforge.org/pipermail/crossfire/attachments/20060708/be9f4f1e/attachment.eml From alex_sch at telus.net Sat Jul 8 23:43:08 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 08 Jul 2006 22:43:08 -0600 Subject: [crossfire] Forward of moderated message In-Reply-To: References: Message-ID: <44B0895C.7040101@telus.net> crossfire-devel-bounces at lists.sourceforge.net wrote: > > ------------------------------------------------------------------------ > > Subject: > 32000 file border for player files > From: > "Daimonin" > Date: > Sat, 8 Jul 2006 16:34:45 +0200 > > To: > "crossfire-devel" , > "daimonin-devel" > > > Hello > > This bug (or better linux problem) comes from the daimonin server > but it will effect cf server too. > > The last 2 days i encountered strange server downs for the daimonin beta 3 > server. As i investigated, i saw that the server was not able to create > a new player dir. > > mkdir() failed with the errno EMLINK. > > Please read here: http://www.wlug.org.nz/EMLINK > > It was as described in the article. We got 32000 player dirs in the > the data/players directory. > > The bad thing: Our server runs a pre-installed Ubuntu 64bit with raid1, > pre-installed by the provider company. I am pretty sure its not easy, > not doable without problems and perhaps not possible to change the file > system. > For other servers which are perhaps guests on server boxes is a file > system change impossible too - we have to use what we find there. > > In beta 4 we fixed this some month ago by changing the /data/players > structure like sourceforge manages their user accounts: > > we take the first 2 characters of a name, and sort it in a new subfolder > structure like this.. > > the name "aab1" and "aab2" will be sorted in this: > > data/players/ > a/ > a/aa/ > a/ab/aab1 <- player folder > a/ab/aab2 <- another player > a/ac/ > a/ad/ > .. > .. > b/ > b/ba/ > b/bb/ > ... > > This works very fine and should have a good effect too under files systems > which scale up with many sub folders (in cpu time). > > Of course its not a "100%" fix. In theory, a server can have such many > players, > that even a sub folder hit the 32000 folder problem. > > Possible fixes then: > - use explicit a file system which don't use hard links. > - change to a DB storing (but there we have performance and > storing problems perhaps too under different OS?) > Another alternative fix could be doing something such as, for not just the first two characters having folders, but for each two characters, having recursive layers of folders. For example, the name "foobar" would turn to "fo/ob/ar/foobar" and "foobeer" would turn to "fo/ob/ee/r/foobeer" and "fubar" would turn to "fu/ba/r/fubar". Given the allowable characters for usernames, that will never exceed 32000 hard links, and at the same time wouldn't require a DB or a filesystem that doesn't use hard links. That said, I personally think this naming system might be a little ugly, however it would in theory work so far as I can tell. Alex Schultz From nicolas.weeger at laposte.net Sun Jul 9 04:44:21 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 9 Jul 2006 11:44:21 +0200 Subject: [crossfire] Exiting shops with unpaid items Message-ID: <200607091144.21743.nicolas.weeger@laposte.net> Hello. In relation to https://sourceforge.net/tracker/index.php?func=detail&aid=1519089&group_id=13833&atid=113833 The bug is pretty easy: server/shop.c:can_pay doesn't go into containers to check for unpaid items, whereas get_payment does - thus player doesn't pay but does exit. I see two fixes for that: * make can_pay recursively check containers * don't allow unpaid items to enter containers and stay in "main" inventory I prefer the 2nd solution, as this way it's easy to drop items you couldn't pay. Drawback is that you can't buy an item you can't carry without any container (but i don't think that happens often ^_-), and you'll need to drop/pick bought items so they enter the container. Nicolas From fuchs.andy at gmail.com Sun Jul 9 10:52:23 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun, 9 Jul 2006 11:52:23 -0400 Subject: [crossfire] Forward of moderated message In-Reply-To: References: Message-ID: On 7/8/06, crossfire-devel-bounces at lists.sourceforge.net wrote: ... > ---------- Forwarded message ---------- > From: "Daimonin" ... > In beta 4 we fixed this some month ago by changing the /data/players > structure like sourceforge manages their user accounts: > > we take the first 2 characters of a name, and sort it in a new subfolder > structure like this.. > > the name "aab1" and "aab2" will be sorted in this: > > data/players/ > a/ > a/aa/ > a/ab/aab1 <- player folder > a/ab/aab2 <- another player > a/ac/ > a/ad/ > .. > .. > b/ > b/ba/ > b/bb/ > ... > > This works very fine and should have a good effect too under files systems > which scale up with many sub folders (in cpu time). > > Of course its not a "100%" fix. In theory, a server can have such many > players, > that even a sub folder hit the 32000 folder problem. Dawn of Time (mud server) uses a similar system to store player files. It also uses it for extra security, by requiring that wizard/dungeonmaster/immortal players be in a separate directory (at least from what it seems when i was messing with it). > Possible fixes then: > - use explicit a file system which don't use hard links. > - change to a DB storing (but there we have performance and > storing problems perhaps too under different OS?) A DB is the way to go, if you expect LOTS of users, otherwise it just adds another dependency. This could be a possible argument for modularization. -- Andrew Fuchs From leaf at real-time.com Tue Jul 11 11:15:18 2006 From: leaf at real-time.com (Rick Tanner) Date: Tue, 11 Jul 2006 11:15:18 -0500 Subject: [crossfire] Metaserver reporting and accuracy Message-ID: <44B3CE96.3020605@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Per the feedback from other people on IRC and other means, I've put together a list of requirements that people want to see with the metaserver reporting. So, with this post I am asking public server admins to cooperate on the following: * All information must be as accurate as can reasonably be (IP Address, hostname, number of players, server version, etc.) * Only crossfire compatible servers can be listed. Compatible in this case means that the official crossfire clients can be used to play on that server without any issues. Servers may have enhancements the official client does not support so long as those enhancements are not needed to play the game. * If the server is only going to be available temporarily or for a limited - indicate so in the metaserver comment area. This is not a final draft or a complete list by any means, but I think it's a reasonable start. Comments? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEs86WhHyvgBp+vH4RAmNqAKD0JL0u4CK2KV7EDh6bGLqZ9uSwSgCg6ZX1 QY895/nY52/towRpKjjXIuY= =WbKL -----END PGP SIGNATURE----- From fuchs.andy at gmail.com Tue Jul 11 20:06:19 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Tue, 11 Jul 2006 21:06:19 -0400 Subject: [crossfire] Metaserver reporting and accuracy In-Reply-To: <44B3CE96.3020605@real-time.com> References: <44B3CE96.3020605@real-time.com> Message-ID: On 7/11/06, Rick Tanner wrote: > Per the feedback from other people on IRC and other means, I've put > together a list of requirements that people want to see with the > metaserver reporting. > > So, with this post I am asking public server admins to cooperate on the > following: > > * All information must be as accurate as can reasonably be (IP Address, > hostname, number of players, server version, etc.) Allow some bots to be in the player count, but within reason (drop the server if the player count is intentionally raised by the server owner; some abuse can take place, if you don't try to determine the owner of the bots). > * Only crossfire compatible servers can be listed. Compatible in this > case means that the official crossfire clients can be used to play on > that server without any issues. Servers may have enhancements the > official client does not support so long as those enhancements are not > needed to play the game. > > * If the server is only going to be available temporarily or for a > limited - indicate so in the metaserver comment area. Would be easier to manage (on both sides) by having a "permanent" flag sent to the metaserver, that has to be explicitly set in the server config. -- Andrew Fuchs From tchize at myrealbox.com Wed Jul 12 02:06:56 2006 From: tchize at myrealbox.com (Tchize) Date: Wed, 12 Jul 2006 09:06:56 +0200 Subject: [crossfire] Metaserver reporting and accuracy In-Reply-To: References: <44B3CE96.3020605@real-time.com> Message-ID: <44B49F90.6030405@myrealbox.com> Andrew Fuchs wrote: > > Would be easier to manage (on both sides) by having a "permanent" flag > sent to the metaserver, that has to be explicitly set in the server > config. Just a though: metaserver entries of 'permanent' server should, at least partially, be stored in a config file of metaserver. For example, if I create a server named "Lands of magic", i don't want someone to configure his own personal server with the same name and fool the players. Permanent servers should have reserved names in metaserver. Also, metaserver should have a way to ensure the given connection ip is the one from which the metaserver entries are sent (currently it's only a matter of sending an udp packet and so metaserver could be overflowed by fake entries with random ips) From elmex at ta-sa.org Wed Jul 12 09:45:09 2006 From: elmex at ta-sa.org (Robin Redeker) Date: Wed, 12 Jul 2006 16:45:09 +0200 Subject: [crossfire] Metaserver reporting and accuracy In-Reply-To: <44B3CE96.3020605@real-time.com> References: <44B3CE96.3020605@real-time.com> Message-ID: <20060712144508.GA8738@elmex> On Tue, Jul 11, 2006 at 11:15:18AM -0500, Rick Tanner wrote: > > Per the feedback from other people on IRC and other means, I've put > together a list of requirements that people want to see with the > metaserver reporting. > > So, with this post I am asking public server admins to cooperate on the > following: > > * All information must be as accurate as can reasonably be (IP Address, > hostname, number of players, server version, etc.) I wondered: maybe wizards and afk people should be not listed as 'number of players'? Because the number that interestes the people who look at the 'number of players' is the number of active players. A server with 10 afk users is as active and interesting as a server with 0 users. Also wizards should not be reported, because a dungeon master that is administrating the server is not an 'active' player in means of interacting with him. Robin -- elmex at ta-sa.org / robin at nethype.de / r.redeker at gmail.com Robin Redeker From alex_sch at telus.net Wed Jul 12 11:14:18 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 12 Jul 2006 10:14:18 -0600 Subject: [crossfire] Metaserver reporting and accuracy In-Reply-To: <20060712144508.GA8738@elmex> References: <44B3CE96.3020605@real-time.com> <20060712144508.GA8738@elmex> Message-ID: <44B51FDA.40505@telus.net> Robin Redeker wrote: > On Tue, Jul 11, 2006 at 11:15:18AM -0500, Rick Tanner wrote: >> Per the feedback from other people on IRC and other means, I've put >> together a list of requirements that people want to see with the >> metaserver reporting. >> >> So, with this post I am asking public server admins to cooperate on the >> following: >> >> * All information must be as accurate as can reasonably be (IP Address, >> hostname, number of players, server version, etc.) > > I wondered: maybe wizards and afk people should be not listed as 'number of players'? > > Because the number that interestes the people who look at the 'number of players' > is the number of active players. A server with 10 afk users is as active > and interesting as a server with 0 users. > > Also wizards should not be reported, because a dungeon master that is administrating > the server is not an 'active' player in means of interacting with him. I would agree with that, however in my experience, very few players actually make use of the afk flag. This may have changed since I was actively playing though, back when I was actively playing, the default who command output would not include afk status, which it now does, so perhaps players are using it more now. Either way, perhaps another thing that would be good on servers, would be automatically setting the afk flag if they are idle for more than a certain amount of time, and if they become active again, it will unset the afk flag, unless they turned it on manually. IMHO that behavior would make not including afk players in the count, much more useful. I would agree that most players won't really be caring for the player count including the number of online wizards. One interesting idea though, is perhaps in addition to a player count not counting those, perhaps the metaserver could also be sent the number of afk players, and number of wizards, as though active players is usually what most people would care about, the amount of afk players and wizards are also indicators of the level and type of activity on the server that some players might find interesting. Alex Schultz From cher at riedquat.de Fri Jul 14 16:39:11 2006 From: cher at riedquat.de (Christian Hujer) Date: Fri, 14 Jul 2006 23:39:11 +0200 Subject: [crossfire] Gridarta as Webstart application Message-ID: <200607142339.11858.cher@riedquat.de> Hello dear co-devs, I've just started experimenting a bit with Webstart. You can see my first steps on http://www.riedquat.de/gridarta/webstart To me, Webstart currently looks like the future of Gridarta. I have the following reasons for this opinion: * It's easy to use for users. ** Start the application by a click on a link on a webpage. ** On Windows it can create desktop and start menu shortcuts. * It will automatically update the application. * We can easily split the application into several jar files. * Each jar file is updated separately. * If the webpage is set up properly, it will even help users to update their JRE if it's out of date for Gridarta. (Note that gridarta webstart is not intended to replace the original standalone applications, it's intended as an alternative that should be easy to use and easy to update for users) Possible file list A: * hosted by Gridarta: ** For Crossfire: *** gridarta4crossfire.jnlp *** gridarta4crossfire.jar ** For Daimonin: *** gridarta4daimonin.jnlp *** gridarta4daimonin.jar ** For both: *** library jars (gridarta, japi, bsh-*, jlfgr-1_0) *** legacy jars (rm'ed asap): crimson, jdom, png, visualtek *** log4j.jar (Ragnor: now open for discussion again) * hosted by Crossfire: ** gridarta4crossfire-data.jar * hosted by Daimonin: ** gridarta4daimonin-data.jar Possible file list B: * hosted by Crossfire: ** gridarta4crossfire-data.jar ** gridarta4crossfire.jnlp ** gridarta4crossfire.jar * hosted by Daimonin: ** gridarta4daimonin-data.jar ** gridarta4daimonin.jnlp ** gridarta4daimonin.jar * hosted by Gridarta: ** library jars gridarta.jar, japi.jar, bsh-classgen.jar, bsh-commands.jar, bsh-core.jar, bsh-util.jar, jlfgr-1_0.jar ** legacy jars (to be removed soon): crimson.jar, jdom.jar, png.jar, visualtek.jar ** log4j.jar (now open for discussion again) The jnlp needs to be changed if a jar is added or removed. Having the jnlp with Gridarta means Gridarta has to update the JNLPs if the projects decide to change their data jar (e.g. split it into two or three separate jars). Having the jnlp with the projects means the Projects have to update the JNLPs if gridarta decides to add / remove library jars / split itself into more jars. I haven't found a way of using a split jnlp yet. (Maybe someone knows?) I think having the servers in jar archives and deploying / updating them with the editor package could also come in handy. JNLP allows specifying different jars for different operating systems, architecture and even locale. Feedback welcome, especially from crossfire and daimonin admins / developers (that's why I crossposted and cc:-ed) -- Christian Hujer Free software developer E-Mail: cher at riedquat.de WWW: http://www.riedquat.de/ From alex_sch at telus.net Mon Jul 17 14:57:16 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 17 Jul 2006 13:57:16 -0600 Subject: [crossfire] Code restructuring Message-ID: <44BBEB9C.5090901@telus.net> Currently in the crossfire code, how objects behave is intertwined all throughout the code, and this is in many ways a problem as it makes it difficult to find code related to a type of object. It's current state also makes it relatively difficult to add code for new object types. One possible solution to these issues, would be to move type-specific code, into a structure such as types/*.c, where files could be things such as types/teleporter.c or types/food.c. Also, some existing files such as swamp.c and disease.c also correspond well to this and would need little modification to be moved over. Instead of making calls to things like apply_ob(), one would call things such as ob->arch->apply(), which would be function pointers stored in the archetypes, to functions in the aforementioned type-specific files. Archetypes would have such function pointers initialized to a "nop" function as a placeholder in order to avoid needing to check if the function pointer is null or not. After the archetype list is initialized, an init_types() function will run something like type_teleporter_init() from each of the type-specific files, which would register the type and adjust the function pointers of all archetypes of that type. This design would also allow plugins to insert their own types, though the core of the crossfire should be statically linked and not use plugins for types normally. While such a change is technically manageable, it would need to be done bit by bit, and there may be issues with it breaking other code that people are working on, for this reason some people believe this restructuring should be done in a separate branch. Others are concerned about the extra effort of maintaining the branch and believe that it should not be done in a branch. There is also the possibility that the conversion may only be halfway done in a release, hence the code would be a little messy at such a release. Personally I am not sure which way is the right way to implement such a restructure in terms of those issues. Any thoughts on such restructuring? Alex Schultz From mwedel at sonic.net Tue Jul 18 00:10:23 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 17 Jul 2006 22:10:23 -0700 Subject: [crossfire] Code restructuring In-Reply-To: <44BBEB9C.5090901@telus.net> References: <44BBEB9C.5090901@telus.net> Message-ID: <44BC6D3F.5060708@sonic.net> Alex Schultz wrote: > Currently in the crossfire code, how objects behave is intertwined all > throughout the code, and this is in many ways a problem as it makes it > difficult to find code related to a type of object. It's current state > also makes it relatively difficult to add code for new object types. While the current organization isn't great, and should be redone, I'd disagree a little bit about the adding new objects - while hardly simple, I don't think any method will make it really simple - it can become simpler, but never really simple. The current code organization is based more on the function/operation of the object, and not the object itself (all the apply logic is together, all the time code is together). Given there are a lot more object types than operations, it does make sense to organize by type (but even then, I think some grouping is necessary - I'm not sure I want 80 .c files, each covering a specific type of object, when some may just be a few lines of code. A real case of this is the general armor category - right now, there are boots, gloves, armor, shields, helmets, cloaks, etc, but all behave the same way, so it doesn't make sense to have different .c files for those - just a single armor.c file would be correct (but then in that case, we start looking at whether all those should be different types, or be a single type with subtypes, and even the subtypes may be overkill with the body code, since that was the main reason for all the different types.) > > One possible solution to these issues, would be to move type-specific > code, into a structure such as types/*.c, where files could be things > such as types/teleporter.c or types/food.c. Also, some existing files > such as swamp.c and disease.c also correspond well to this and would > need little modification to be moved over. That works. > Instead of making calls to things like apply_ob(), one would call things > such as ob->arch->apply(), which would be function pointers stored in > the archetypes, to functions in the aforementioned type-specific files. > Archetypes would have such function pointers initialized to a "nop" > function as a placeholder in order to avoid needing to check if the > function pointer is null or not. After the archetype list is > initialized, an init_types() function will run something like > type_teleporter_init() from each of the type-specific files, which would > register the type and adjust the function pointers of all archetypes of > that type. Few quick thoughts: Unless we allow or plan for these callbacks to be modified on an object by object basis, I'm not sure if putting that callback in the object structure makes sense - it probably makes more sense to just have a static table, eg, apply_callbacks[]. The per type registration code could then update that. Doing that is certainly easier than going through all the archetypes updating the ones of the matching type (and if we're just doing that, what advantage do we get vs just using a table then?) This saves some amount of memory (pointer size * number of callbacks/object, eg, if we have 8 callbacks and running on a 64 bit systems, that is 64 bytes/object). That probably isn't a huge deal, but could add up. I think that may also be easier to code, or at least transition - in this case, simple 'if apply_callbacks[ob->type] apply->callbacks[ob->type]() else ..' if all that is needed. I do think it is neccessary not to set these to dummy functions - for performance, you don't want to be making function calls if it isn't do anything (no matter which implementation is chosen). This maybe isn't a big deal for apply code, since that generally has to be triggered by some player, but there could certainly be time based callbacks that you don't want to be making if they are no-ops. Last thought - the data passed to these functions has to be well thought out, as all the callbacks of the same type will be getting the same data passed in (apply_armor will get the same parameters as apply_weapon as apply_handle, etc). In some cases, these functions may not care what the extra data is, but there may be others that care what some field is. So this needs to be fairly well researched - you probably don't want to get halfway through doing the objects and get to one that needs some other parameter passed, and now have to go back through all the ones you did to update the calling structure. > This design would also allow plugins to insert their own types, though > the core of the crossfire should be statically linked and not use > plugins for types normally. Adding such functionality would have to be carefully considered - specific notes/thoughts: - If this is an object attribute, then a plugin could modify the callback structure for a specific object. Problem is how to save/load that callback information. - If this is a type attribute, some form of type reservation is needed. If a plugin (script) uses type 999, and I don't know that and also use type 999 for a new object, things now break. Or for that matter if two different script register different callbacks for the same type, problems occur. The one plus side of using a table is it can be easier to detect these duplicate entries. > > While such a change is technically manageable, it would need to be done > bit by bit, and there may be issues with it breaking other code that > people are working on, for this reason some people believe this > restructuring should be done in a separate branch. Others are concerned > about the extra effort of maintaining the branch and believe that it > should not be done in a branch. There is also the possibility that the > conversion may only be halfway done in a release, hence the code would > be a little messy at such a release. Personally I am not sure which way > is the right way to implement such a restructure in terms of those issues. I think such a restructure should wait until post 2.0 (I suppose work could start now in a branch). This endeavor may make sense to do in a branch, simply because multiple people could be working on it. The issue always with branches is how many people will use it, if not many, the benefit of branches go down. I'd almost say it is better to do an approach piece by piece in the main branch, simply because such a major reorganization is such that merging isn't a simple issue. Eg, I fix a bug in apply.c, but in the branch, it is types/weapon.c - the merge isn't going to catch it (it will catch that apply.c is different, but you'll have to manually move that change to types/weapon.c). However, if types/weapon.c is in the main branch, but there is still lots of stuff in server/apply.c, I'll fix whatever is in CVS. Some of this may depend on how long it takes to make this transition. Other thought to make this work better is to send out some type of schedule, eg, I'm going to update these objects on this date, so either make your updates now, or you'll have to merge them after the commit. From mwedel at sonic.net Tue Jul 18 00:15:51 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 17 Jul 2006 22:15:51 -0700 Subject: [crossfire] Metaserver reporting and accuracy In-Reply-To: <44B49F90.6030405@myrealbox.com> References: <44B3CE96.3020605@real-time.com> <44B49F90.6030405@myrealbox.com> Message-ID: <44BC6E87.1050101@sonic.net> Tchize wrote: > Andrew Fuchs wrote: >> Would be easier to manage (on both sides) by having a "permanent" flag >> sent to the metaserver, that has to be explicitly set in the server >> config. > Just a though: > metaserver entries of 'permanent' server should, at least partially, be > stored in a config file of metaserver. > > For example, if I create a server named "Lands of magic", i don't want > someone to configure his own personal server with the same name and fool > the players. Permanent servers should have reserved names in metaserver. > Also, metaserver should have a way to ensure the given connection ip is > the one from which the metaserver entries are sent (currently it's only > a matter of sending an udp packet and so metaserver could be overflowed > by fake entries with random ips) I'd almost say that this is more a 'trusted server' list, which is probably a good idea, but is a little different. I don't really think a permanent flag is needed - if a server hasn't provided an update in X amount of time, it probably isn't around (even if it is a trusted server), and shouldn't be shown. Not sure current setting, but initially the timeout on the metaserver to remove systems that haven't provided updates was very long (a leftover from initial testing). But before we start looking at doing too much here, this sort of goes back to the discussion several months back about a new/better metaserver design (more than one metaserver, etc). That discussion basically went away after the metaserver came back online. From mwedel at sonic.net Tue Jul 18 00:20:23 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 17 Jul 2006 22:20:23 -0700 Subject: [crossfire] Metaserver reporting and accuracy In-Reply-To: <44B51FDA.40505@telus.net> References: <44B3CE96.3020605@real-time.com> <20060712144508.GA8738@elmex> <44B51FDA.40505@telus.net> Message-ID: <44BC6F97.40504@sonic.net> Alex Schultz wrote: > Robin Redeker wrote: >> On Tue, Jul 11, 2006 at 11:15:18AM -0500, Rick Tanner wrote: >>> Per the feedback from other people on IRC and other means, I've put >>> together a list of requirements that people want to see with the >>> metaserver reporting. >>> >>> So, with this post I am asking public server admins to cooperate on the >>> following: >>> >>> * All information must be as accurate as can reasonably be (IP Address, >>> hostname, number of players, server version, etc.) >> I wondered: maybe wizards and afk people should be not listed as 'number of players'? >> >> Because the number that interestes the people who look at the 'number of players' >> is the number of active players. A server with 10 afk users is as active >> and interesting as a server with 0 users. >> >> Also wizards should not be reported, because a dungeon master that is administrating >> the server is not an 'active' player in means of interacting with him. > I would agree with that, however in my experience, very few players > actually make use of the afk flag. This may have changed since I was > actively playing though, back when I was actively playing, the default > who command output would not include afk status, which it now does, so > perhaps players are using it more now. One could take this a little further and say that these are provided to the metaserver, and the player can then decide if that other information is of interest (2 wiz's online, that's good, etc). In fact, I could imagine some players would find that useful when they need a wiz because their character is stranded, etc. > Either way, perhaps another thing that would be good on servers, would > be automatically setting the afk flag if they are idle for more than a > certain amount of time, and if they become active again, it will unset > the afk flag, unless they turned it on manually. IMHO that behavior > would make not including afk players in the count, much more useful. That would almost go into yet another category - 'idle'. I'm not sure how true it is, but I can certainly envision that there are players online who are idle - they are waiting for something interesting to happen, partake in chatting, etc. So while idle, they are effectively around. But that may be over thinking this problem here. From alex_sch at telus.net Tue Jul 18 01:35:13 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 18 Jul 2006 00:35:13 -0600 Subject: [crossfire] Code restructuring In-Reply-To: <44BC6D3F.5060708@sonic.net> References: <44BBEB9C.5090901@telus.net> <44BC6D3F.5060708@sonic.net> Message-ID: <44BC8121.40705@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> Currently in the crossfire code, how objects behave is intertwined all >> throughout the code, and this is in many ways a problem as it makes it >> difficult to find code related to a type of object. It's current state >> also makes it relatively difficult to add code for new object types. >> > > While the current organization isn't great, and should be redone, I'd > disagree a little bit about the adding new objects - while hardly simple, I > don't think any method will make it really simple - it can become simpler, but > never really simple. > Well, indeed it is never really very simple, but I believe some of the changes described below would make it simpler by a noticeable amount. > The current code organization is based more on the function/operation of the > object, and not the object itself (all the apply logic is together, all the time > code is together). Given there are a lot more object types than operations, it > does make sense to organize by type (but even then, I think some grouping is > necessary - I'm not sure I want 80 .c files, each covering a specific type of > object, when some may just be a few lines of code. > > A real case of this is the general armor category - right now, there are > boots, gloves, armor, shields, helmets, cloaks, etc, but all behave the same > way, so it doesn't make sense to have different .c files for those - just a > single armor.c file would be correct (but then in that case, we start looking at > whether all those should be different types, or be a single type with subtypes, > and even the subtypes may be overkill with the body code, since that was the > main reason for all the different types.) > And these issues are why I don't believe it should be strictly one file per type, and that given files should register to multiple types if that makes sense. (Offtopic though, it does seem to me that in the case of armor, it really should just use one type, and then use subtypes, instead of how it is currently) Also, it might be good to have a types/common directory, for store functions that are not part of the "core" but are used by multiple files in types/*.c (each of which corresponding to one or more object types, but usually as few as makes sense) >> Instead of making calls to things like apply_ob(), one would call things >> such as ob->arch->apply(), which would be function pointers stored in >> the archetypes, to functions in the aforementioned type-specific files. >> Archetypes would have such function pointers initialized to a "nop" >> function as a placeholder in order to avoid needing to check if the >> function pointer is null or not. After the archetype list is >> initialized, an init_types() function will run something like >> type_teleporter_init() from each of the type-specific files, which would >> register the type and adjust the function pointers of all archetypes of >> that type. >> > > Few quick thoughts: > > Unless we allow or plan for these callbacks to be modified on an object by > object basis, I'm not sure if putting that callback in the object structure > makes sense - it probably makes more sense to just have a static table, eg, > apply_callbacks[]. The per type registration code could then update that. > Doing that is certainly easier than going through all the archetypes updating > the ones of the matching type (and if we're just doing that, what advantage do > we get vs just using a table then?) > > This saves some amount of memory (pointer size * number of callbacks/object, > eg, if we have 8 callbacks and running on a 64 bit systems, that is 64 > bytes/object). That probably isn't a huge deal, but could add up. > Well, what I was proposing wasn't per-object, but was per-archetype, as in, one wouldn't access ob->apply, one would access ob->arch->apply, so the memory hit wouldn't be very bad. However, what you say does have a point still. > I think that may also be easier to code, or at least transition - in this > case, simple 'if apply_callbacks[ob->type] apply->callbacks[ob->type]() else ..' > if all that is needed. > > I do think it is neccessary not to set these to dummy functions - for > performance, you don't want to be making function calls if it isn't do anything > (no matter which implementation is chosen). This maybe isn't a big deal for > apply code, since that generally has to be triggered by some player, but there > could certainly be time based callbacks that you don't want to be making if they > are no-ops. > Hmm, that is true, however if we don't use no-op defaults, then checking to make sure it isn't null, should IMHO be put into a macro, to make sure nobody forgets that check. The way I see it, there are 3 ways to take it, per-object, per-archetype, and per-type (static array). In any case. I think per-type is best if we only want the callbacks defined by the core (or by plugins if an interface for plugins is made), however if we want the callbacks defined by the archetypes or maps that wouldn't work. I'm now thinking perhaps per-type would be best, but I am unsure. > Last thought - the data passed to these functions has to be well thought out, > as all the callbacks of the same type will be getting the same data passed in > (apply_armor will get the same parameters as apply_weapon as apply_handle, etc). > In some cases, these functions may not care what the extra data is, but there > may be others that care what some field is. > > So this needs to be fairly well researched - you probably don't want to get > halfway through doing the objects and get to one that needs some other parameter > passed, and now have to go back through all the ones you did to update the > calling structure. > Yes, that certainly does need to be kept in mind, however could be easy to deal with it in many cases where there is currently a unifies function for things like applying, because in those cases we shouldn't need anything passed other than what the current function passes. >> While such a change is technically manageable, it would need to be done >> bit by bit, and there may be issues with it breaking other code that >> people are working on, for this reason some people believe this >> restructuring should be done in a separate branch. Others are concerned >> about the extra effort of maintaining the branch and believe that it >> should not be done in a branch. There is also the possibility that the >> conversion may only be halfway done in a release, hence the code would >> be a little messy at such a release. Personally I am not sure which way >> is the right way to implement such a restructure in terms of those issues. >> > > I think such a restructure should wait until post 2.0 (I suppose work could > start now in a branch). > Assuming 2.0 will be release some time in the next 4 months or so, that makes sense. I wouldn't want to start now in a branch though due to effort of keeping in sync. > This endeavor may make sense to do in a branch, simply because multiple people > could be working on it. The issue always with branches is how many people will > use it, if not many, the benefit of branches go down. > > I'd almost say it is better to do an approach piece by piece in the main > branch, simply because such a major reorganization is such that merging isn't a > simple issue. Eg, I fix a bug in apply.c, but in the branch, it is > types/weapon.c - the merge isn't going to catch it (it will catch that apply.c > is different, but you'll have to manually move that change to types/weapon.c). I'm currently estimating the break-even point, in terms the overhead vs. benefit of branches, would be somewhere around 3-6 people depending on how actively they would use it, so that said, I'm currently thinking it might not be work it to do in a branch, however that is a very rough estimate and difficult to really gage. > Other thought to make this work better is to send out some type of schedule, > eg, I'm going to update these objects on this date, so either make your updates > now, or you'll have to merge them after the commit. That would make sense, though it may be difficult for people working on such may find it difficult to know when they would have a chance to finish updating objects. I'm thinking something that might Alex Schultz From yann.chachkoff at myrealbox.com Tue Jul 18 02:18:17 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Tue, 18 Jul 2006 09:18:17 +0200 Subject: [crossfire] Code restructuring In-Reply-To: <44BC6D3F.5060708@sonic.net> References: <44BBEB9C.5090901@telus.net> <44BC6D3F.5060708@sonic.net> Message-ID: <200607180918.22295.yann.chachkoff@myrealbox.com> Le mardi 18 juillet 2006 07:10, Mark Wedel a ?crit : > Alex Schultz wrote: > > Currently in the crossfire code, how objects behave is intertwined all > > throughout the code, and this is in many ways a problem as it makes it > > difficult to find code related to a type of object. It's current state > > also makes it relatively difficult to add code for new object types. > > While the current organization isn't great, and should be redone, I'd > disagree a little bit about the adding new objects - while hardly simple, I > don't think any method will make it really simple - it can become simpler, > but never really simple. > Well, currently, adding a new object type involves adding small bits of code everywhere. It seems much easier to me to regroup all the functionality specific to an object type in a central place, so adding a new object would basically be as simple as filling a unique source file template. > The current code organization is based more on the function/operation of > the object, and not the object itself (all the apply logic is together, all > the time code is together). Given there are a lot more object types than > operations, it does make sense to organize by type (but even then, I think > some grouping is necessary - I'm not sure I want 80 .c files, each covering > a specific type of object, when some may just be a few lines of code. > > A real case of this is the general armor category - right now, there are > boots, gloves, armor, shields, helmets, cloaks, etc, but all behave the > same way, so it doesn't make sense to have different .c files for those - > just a single armor.c file would be correct (but then in that case, we > start looking at whether all those should be different types, or be a > single type with subtypes, and even the subtypes may be overkill with the > body code, since that was the main reason for all the different types.) > I agree with this - if several types behave the same, there is no need to duplicate code. > Few quick thoughts: > > Unless we allow or plan for these callbacks to be modified on an object > by object basis, I'm not sure if putting that callback in the object > structure makes sense - it probably makes more sense to just have a static > table, eg, apply_callbacks[]. > You misread the proposal, I think. As I understood it, callbacks were to be bound with archetypes, not on a per-object basis. It sounds logical, as the archetype is supposed to be the "model" a given object is based on. > The per type registration code could then > update that. Doing that is certainly easier than going through all the > archetypes updating the ones of the matching type (and if we're just doing > that, what advantage do we get vs just using a table then?) > Updating the callbacks is something you'd do exceptionally - it should normally occur only when the archetypes are initially loaded; so that point really sounds like a non-issue. > This saves some amount of memory (pointer size * number of > callbacks/object, eg, if we have 8 callbacks and running on a 64 bit > systems, that is 64 bytes/object). That probably isn't a huge deal, but > could add up. > No, it would be 64bytes/archetype. 10,000 archetypes would thus give a little less than 640KB - I doubt such an amount can be considered as a problem, knowing the amount of memory most computers now have. > I think that may also be easier to code, or at least transition - in this > case, simple 'if apply_callbacks[ob->type] apply->callbacks[ob->type]() > else ..' if all that is needed. > I don't see how this is "easier" - both solutions look equally understandable to me. > Last thought - the data passed to these functions has to be well thought > out, as all the callbacks of the same type will be getting the same data > passed in (apply_armor will get the same parameters as apply_weapon as > apply_handle, etc). In some cases, these functions may not care what the > extra data is, but there may be others that care what some field is. > Definitely. > Adding such functionality would have to be carefully considered - > specific notes/thoughts: > - If this is an object attribute, then a plugin could modify the callback > structure for a specific object. Problem is how to save/load that callback > information. > Indeed, it is a possible issue. My guess is that we shouldn't allow a plugin to change callbacks "on the fly", to keep things simple. My guess is that either an archetype mentions no plugin (and in that case, the default callbacks are bound to it), or it does (and in that case, the specified plugin is responsible for all callbacks of that archetype, eventually delegating some to the server default ones). Such a system means that you cannot manage an archetype by more than a single plugin - but I hardly see this as a big drawback. > - If this is a type attribute, some form of type reservation is needed. If > a plugin (script) uses type 999, and I don't know that and also use type > 999 for a new object, things now break. Or for that matter if two > different script register different callbacks for the same type, problems > occur. The one plus side of using a table is it can be easier to detect > these duplicate entries. > I don't like the idea of using a numerical type identification - this is running the risk of type id clash. > I think such a restructure should wait until post 2.0 (I suppose work > could start now in a branch). > Given that this is obviously an important change, I don't see why it should wait post-2.0. Quite the contrary, I think that an improved code structure is a primary goal that the next major CF version should take into account. > This endeavor may make sense to do in a branch, simply because multiple > people could be working on it. The issue always with branches is how many > people will use it, if not many, the benefit of branches go down. > > I'd almost say it is better to do an approach piece by piece in the main > branch, simply because such a major reorganization is such that merging > isn't a simple issue. Eg, I fix a bug in apply.c, but in the branch, it is > types/weapon.c - the merge isn't going to catch it (it will catch that > apply.c is different, but you'll have to manually move that change to > types/weapon.c). > The drawback being that this is a rather important change of the code; I think that doing it in the main branch is a bad idea, as it will probably make other changes harder to achieve. If this is going to be done, I'd suggest to make a "stable" branch, which can be maintained for the duration of the transition as a "bugfixes-only" code base (so basically, the main branch would be "Crossfire 2.0 code", while the "stable" one would be "1.9.x", and would get deprecated once the goals defined for "2.0" are met. -- Yann Chachkoff ----------------------- GPG Key 2006: http://keyserver.veridis.com:11371/export?id=-43113965597490782 Fingerprint : C224 F1F9 9025 4FC7 987D 05BB FF66 D413 A3B4 01A2 ----------------------- Reality is a nice place, but I wouldn't want to live there. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060718/787af040/attachment.pgp From nicolas.weeger at laposte.net Tue Jul 18 12:43:34 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 18 Jul 2006 19:43:34 +0200 Subject: [crossfire] Code restructuring In-Reply-To: <44BBEB9C.5090901@telus.net> References: <44BBEB9C.5090901@telus.net> Message-ID: <200607181943.34223.nicolas.weeger@laposte.net> Hello, here are my 2 cents of ?. I'll agree to some points made here and there :) Such a restructuration is a good idea, and will hopefully enable to clean some code. It should take advantage of unit tests currently being added. IMO this should be done in current HEAD branch, having a "stable" branch per Yann's suggestion - after all HEAD is supposed to be unstable ^_- Yes it'll be a non-trivial task, but worth it, for a 2.0 release (which is after all a big symbolic number!). I'd say to put the callback in the archetype itself. But I'd enable a plugin to override such callbacks, to change some behaviours. Nicolas From mwedel at sonic.net Tue Jul 18 23:50:25 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 18 Jul 2006 21:50:25 -0700 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <200607181943.34223.nicolas.weeger@laposte.net> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> Message-ID: <44BDBA11.1030500@sonic.net> To me, the issue for targetting this for a 2.0 release is timing. We can come up with a huge list of things that should be done before a 2.0 list. And we could attempt to do them all, but then 2.0 probably won't be released for 5 years or the like. The discussion for a 2.0 release probably needs to be done. Several questions need to be asked & answered: 1) What is the target date for a 2.0 release? It can't be 'when all the cool stuff is done', as then it never happens - always something new to add, etc - some general date has to targeted. I had previously mentioned shooting for end of this calendar year. 2) What are the 'must have', 'nice to have', and 'not really important' features to target for that release? The wiki - http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 - sort of covers that by high/medium/low priorities. Does code restructuring fall into high category? There is a code cleanup which is high, but I had envisioned that to be a bit more modest than what is being talked about now. Depending on the timeframe would determine how many can really be done in the targeted time. Bugs, both new and current, also need to be similarly prioritized - fixing bugs is great to do, but can also be a big time sink. 3) Who commits to working on these changes? The wiki above has lots of things to do, but very people signed up to do them. If there are only a few people actively working on making code changes, that certainly limits number of changes that can be done for a release. So all that said, if we think end of the year is a reasonable target date, I think that limits us to trying to take on somewhere between 2-4 decent sized projects. If we look at the wiki, taking things currently marked as high, that would be: Character creation - new character creation method Game balance - fix various balance issues improve client ui code cleanup (but have to be careful this doesn't lead to rewriting huge sections of code) change password command Of which, none of those currently has anyone signed up to do them (I was personally planning to look at the character creation sometime soon) I'd also say that generally speaking, any of these big changes needs to be completed at least a month before the targeted release date, simply so there is sufficient time to find bugs, make fixes, then run the fixed code to see if it works, etc. The end of the year date for next release was somewhat arbitrarily chosen, but some date is needed. From yann.chachkoff at myrealbox.com Wed Jul 19 01:01:38 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Wed, 19 Jul 2006 08:01:38 +0200 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44BDBA11.1030500@sonic.net> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> Message-ID: <200607190801.38345.yann.chachkoff@myrealbox.com> Le mercredi 19 juillet 2006 06:50, Mark Wedel a ?crit?: > To me, the issue for targetting this for a 2.0 release is timing. > > We can come up with a huge list of things that should be done before a > 2.0 list. And we could attempt to do them all, but then 2.0 probably won't > be released for 5 years or the like. > Although I do agree that delaying 2.0 too far away would be a bad thing, I also think that releasing a 2.0 that would basically be a "1.9 with some fixes" would make little sense. > The discussion for a 2.0 release probably needs to be done. Several > questions need to be asked & answered: > > 1) What is the target date for a 2.0 release? It can't be 'when all the > cool stuff is done', as then it never happens - always something new to > add, etc - some general date has to targeted. I had previously mentioned > shooting for end of this calendar year. > That's a question that can only be answered once goals to reach for 2.0 are cleared. > 2) What are the 'must have', 'nice to have', and 'not really important' > features to target for that release? The wiki - > http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 - sort of covers that by > high/medium/low priorities. Does code restructuring fall into high > category? There is a code cleanup which is high, but I had envisioned that > to be a bit more modest than what is being talked about now. > I'd say that there are basically two types of changes to be done: (a) Fixes to problems currently encountered in the 1.9.x version of Crossfire. Typically, this is the case for "Game balance" or "Fix weather". Those do not involve creating new systems, but rather work so that the current stuff does its job as expected; (b) Additions to the existing functionality. Two subtypes here: (1)minor changes, that are relatively easy to code, or that are mostly not necessary and (2)major changes, that will require some time to complete, or that change the game experience in a significant way. I'd say that everything that is (a) should be done and integrated as a release of the 1.x series - there is no reason to change the major version number for bugfixes. Similarly, (b.2) would have to go into the 2.x side of things - major changes is what one expects to have when the major version number itself changes. Finally, for stuff belonging to (b.1), I'd say that it depends on the priority we put on it: if it is desperately wanted, then integrate into the 1.x series; if that's just a nice idea but not really top-priority, then push to 2.x. > Depending on the timeframe would determine how many can really be done in > the targeted time. > I think that's a bit backward-thinking: the number of tasks should define the timeframe, not the opposite. > Bugs, both new and current, also need to be similarly prioritized - > fixing bugs is great to do, but can also be a big time sink. > That's true, but I don't think it is realistic to start working on 2.0 when 1.x isn't even mostly bug-free. > 3) Who commits to working on these changes? The wiki above has lots of > things to do, but very people signed up to do them. If there are only a > few people actively working on making code changes, that certainly limits > number of changes that can be done for a release. > > So all that said, if we think end of the year is a reasonable target > date, I think that limits us to trying to take on somewhere between 2-4 > decent sized projects. If we look at the wiki, taking things currently > marked as high, that would be: > > Character creation - new character creation method > Sounds good for inclusion in 2.0 - new feature that's radically different from what we have. > Game balance - fix various balance issues > Looks like a bugfix to me rather than a new feature - so that's 1.x work, IMHO. > improve client ui > Depends on the level of improvements. If that's just fixing/completing the current client, mark that 1.x (that's basically nothing more than minor tweaks); if that involves rethinking the client UI, then mark that 2.0. > code cleanup (but have to be careful this doesn't lead to rewriting huge > sections of code) > If that's only "cleanup" without any fundamental change in the way it works, then that's definitely an 1.x task. > change password command > Agree, although it looks like a rather minor point to me compared to others. > Of which, none of those currently has anyone signed up to do them (I was > personally planning to look at the character creation sometime soon) > I'm not even sure there is a clear document for each of those tasks describing what we are supposed to add/do/design. I mean, everybody understands what "new character creation method"; but there is nothing documenting what has been decided about it, what it should/shouldn't contain, etc. That's basically a "free for all": the first one that assigns itself to the task and submit it to the CVS will get its concept becoming the de-facto choice. I think that before starting to blindly code, we need to clearly define how each point will solve current problems. Then we need to define working groups, and only then shall we be able to get a realistic deadline. Currently, we only have a list of proposals - that's a good start, but I think that a clear organization of the work is required if we want to get things done in a timely fashion. > I'd also say that generally speaking, any of these big changes needs to > be completed at least a month before the targeted release date, simply so > there is sufficient time to find bugs, make fixes, then run the fixed code > to see if it works, etc. > > The end of the year date for next release was somewhat arbitrarily > chosen, but some date is needed. > Again, I think that we cannot define a date before having clearly defined and organized the work - and there's still a lot to do in that respect, IMHO. From alex_sch at telus.net Wed Jul 19 01:22:12 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 19 Jul 2006 00:22:12 -0600 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44BDBA11.1030500@sonic.net> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> Message-ID: <44BDCF94.9080400@telus.net> Mark Wedel wrote: > 1) What is the target date for a 2.0 release? It can't be 'when all the cool > stuff is done', as then it never happens - always something new to add, etc - > some general date has to targeted. I had previously mentioned shooting for end > of this calendar year. > Well, I think that targeting a general date may not be the best solution, and a better one would be having a feature-based target. Essentially based upon the sort of things you talk about below. We just need to limit the number of "must have" things to be reasonable and wait till we have those, and a few "nice to have" things. > 2) What are the 'must have', 'nice to have', and 'not really important' features > to target for that release? The wiki - > http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 - sort of covers that by > high/medium/low priorities. Does code restructuring fall into high category? > There is a code cleanup which is high, but I had envisioned that to be a bit > more modest than what is being talked about now. > > Depending on the timeframe would determine how many can really be done in the > targeted time. > I think the real question is, how 'big' do we want 2.0 to be? How much justifies a major version number? The answer to that, affects what features we should target to have in 2.0, and that dictates the timeframe. At the same time though, the timeframe does affect the other parts, it isn't just a one way chain, as we have to also make sure the features are reasonable to complete within a "reasonable" timeframe. What it really is, is not a question of how much can be done in a timeframe, or how 'big' we want it. It is a matter of weighing how 'big' we want it, against what timeframe is "reasonable". Balances are always so much harder to weigh than simple one way relationships ;) Another issue though, is due to the way that crossfire has released in the past, releases with minor version number increments are a mixture of bugfixes, minor features, and major features. One question is, what will make the difference between 1.9 and 2.0 so different from 1.7 and 1.8? Really, I don't see how anything that has happened or is planned for 2.0, will really make the change so much bigger than the difference between 1.7 and 1.8. For an even better example, the difference between the releases where the skills system changed a bunch, is probably much more worthy of a major version change, than what is currently planned for 2.0 IMHO. Personally, the only way I can see things changing enough in a single release to in my opinion warrant a 2.0, is if we start keeping a "stable" branch in CVS and have that used for minor releases, or if something either in code and/or gameplay undergoes a major (in a loose sense) restructure. Alex Schultz From mwedel at sonic.net Wed Jul 19 23:47:00 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 19 Jul 2006 21:47:00 -0700 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <200607190801.38345.yann.chachkoff@myrealbox.com> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> <200607190801.38345.yann.chachkoff@myrealbox.com> Message-ID: <44BF0AC4.1040004@sonic.net> Yann Chachkoff wrote: > Le mercredi 19 juillet 2006 06:50, Mark Wedel a ?crit : >> To me, the issue for targetting this for a 2.0 release is timing. >> >> We can come up with a huge list of things that should be done before a >> 2.0 list. And we could attempt to do them all, but then 2.0 probably won't >> be released for 5 years or the like. >> > Although I do agree that delaying 2.0 too far away would be a bad thing, I > also think that releasing a 2.0 that would basically be a "1.9 with some > fixes" would make little sense. At some level, all version numbers are arbitrary and can mean whatever. In my thinking, the differences of any major release should be seen from the previous major release (1.0 -> 2.0, 2.0 -> 3.0), not the previous minor release. In which case a lot has changed from 1.0. Maybe that isn't great, but as I think was discussed elsewhere, if there is a separate branch for 2.0 (or 3.0 thinking after that), it probably won't get used much, and before you can really release it to the general public, you have to make sure it is in fact used. So this means that a lot of those features have to put in to the previous version. Maybe going forward, there should be a pre-2.0 (or pre-3.0) branch, and all significant changes have to be put in that branch, so that current branch only contains bug fixes. But this still goes back to what do the numbers really need - if most people are running pre 2.0 (pre-2.0-1.9?), then there are not lots of changes when that is decided to stop calling it pre 2.0 and make it as a real release. > I'd say that there are basically two types of changes to be done: > > (a) Fixes to problems currently encountered in the 1.9.x version of Crossfire. > Typically, this is the case for "Game balance" or "Fix weather". Those do not > involve creating new systems, but rather work so that the current stuff does > its job as expected; > > (b) Additions to the existing functionality. Two subtypes here: (1)minor > changes, that are relatively easy to code, or that are mostly not necessary > and (2)major changes, that will require some time to complete, or that change > the game experience in a significant way. > > I'd say that everything that is (a) should be done and integrated as a release > of the 1.x series - there is no reason to change the major version number for > bugfixes. Similarly, (b.2) would have to go into the 2.x side of things - > major changes is what one expects to have when the major version number > itself changes. Finally, for stuff belonging to (b.1), I'd say that it > depends on the priority we put on it: if it is desperately wanted, then > integrate into the 1.x series; if that's just a nice idea but not really > top-priority, then push to 2.x. That is a reasonable model - the official version is bug fix only, and all new features go into what will become the next major version. But as said above, snap shots/pre releases of the next major version still need to be done at some point, and what do we call those? Sort of goes back to whatever arbitrary numbering scheme we choose. > >> Depending on the timeframe would determine how many can really be done in >> the targeted time. >> > I think that's a bit backward-thinking: the number of tasks should define the > timeframe, not the opposite. Problem is that then we will never make another major release, as the list of things to do will continue to grow. And there is certainly the case of things that get deferred to the next release. That happens all the time in all sorts of software - it would be nice to have feature X, but doing that means that things won't be completed for another 12 months, so will put feature X into the next version. > >> Bugs, both new and current, also need to be similarly prioritized - >> fixing bugs is great to do, but can also be a big time sink. >> > That's true, but I don't think it is realistic to start working on 2.0 when > 1.x isn't even mostly bug-free. But there are many different types/layers of bugs. Many bugs may fall more into the RFE category or nice to have feature type of thing. And there may be many other bugs that fall more into the inconvenience of slightly annoying. Saying it should be 100% bug free is also one of those things that is likely to never happen (as you fix ones, new ones will always get filed). Pretty much all software ships with some number of bugs. > I'm not even sure there is a clear document for each of those tasks describing > what we are supposed to add/do/design. I mean, everybody understands > what "new character creation method"; but there is nothing documenting what > has been decided about it, what it should/shouldn't contain, etc. That's > basically a "free for all": the first one that assigns itself to the task and > submit it to the CVS will get its concept becoming the de-facto choice. I'd say that the first person that steps in to the task then writes up what they think should be done, send it out, get comments, revise, repeat, then code when decided. > I think that before starting to blindly code, we need to clearly define how > each point will solve current problems. Then we need to define working > groups, and only then shall we be able to get a realistic deadline. I think that is a much better solution than some committee deciding what should be done and then expect someone else to write that code. As in a volunteer project, I think we'd see a lot of specs and not a lot of code. And I think we have to be careful about making things too complicated. Crossfire doesn't have a huge developer base - the need for high degree of coordination, isn't as great as if there were 100 developers with many different major projects going on at once. In fact, I just looked over the server changelog - I may have miscounted, but I only counted 6 different people committing code (or at least code reflected in the changelog) since the start of the year. > Currently, we only have a list of proposals - that's a good start, but I think > that a clear organization of the work is required if we want to get things > done in a timely fashion. So saying that, what I'd be tempted to say is the next process in this: People have to take claim of these various big changes. What this means is they are the main person responsible - they write up what will be done, get comments, figure out how long it will take, and then see through the process of making the changes (this doesn't necessarily mean doing all the work themselves if they can recruit other people to help out, but such a person is really the lead on that aspect) Things that don't get claimed get scratched off the list. Lets face it - there are lots of things that would be nice to do. However, if it is a feature that no one wants to do, it won't get done. From mwedel at sonic.net Thu Jul 20 00:29:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 19 Jul 2006 22:29:52 -0700 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44BDCF94.9080400@telus.net> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> <44BDCF94.9080400@telus.net> Message-ID: <44BF14D0.3060901@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> 1) What is the target date for a 2.0 release? It can't be 'when all the cool >> stuff is done', as then it never happens - always something new to add, etc - >> some general date has to targeted. I had previously mentioned shooting for end >> of this calendar year. >> > Well, I think that targeting a general date may not be the best > solution, and a better one would be having a feature-based target. > Essentially based upon the sort of things you talk about below. We just > need to limit the number of "must have" things to be reasonable and wait > till we have those, and a few "nice to have" things. Have to be careful and limit the feature so that you don't keep adding more things to be done, to the point where nothing ever gets done. Whatever is targeted for 2.0, there will be things that should be done for 3.0, 4.0, etc. The next version can't hope to cover everything that should be done. > Another issue though, is due to the way that crossfire has released in > the past, releases with minor version number increments are a mixture of > bugfixes, minor features, and major features. One question is, what will > make the difference between 1.9 and 2.0 so different from 1.7 and 1.8? > Really, I don't see how anything that has happened or is planned for > 2.0, will really make the change so much bigger than the difference > between 1.7 and 1.8. For an even better example, the difference between > the releases where the skills system changed a bunch, is probably much > more worthy of a major version change, than what is currently planned > for 2.0 IMHO. Personally, the only way I can see things changing enough > in a single release to in my opinion warrant a 2.0, is if we start > keeping a "stable" branch in CVS and have that used for minor releases, > or if something either in code and/or gameplay undergoes a major (in a > loose sense) restructure. One thought is to define major.minor.micro releases like this: major release: Changes that break compatiblity (need to start with a clean server as player files are not compatible, server/client compatibility may be an issue, and/or programs removed (x11 client goes away for example). minor release: feature enhancements and bug fixes. micro release: only bug fixes. In terms of CVS, that could work out like: head branch: Contains major release - all changes (unless not applicable due to other changes) go in the head. stable branch: This is where minor/micro releases come from. When a new major release is done, a new stable (stable-2-0-0, stable-3-0-0) is done. I really only see one stable branch per major release - the determination of micro/minor is a call of the RE at time of release based on what changes. I think in this model, releases done on a fairly regular schedule (quarterly? Every 6 months) since the number of changes probably won't be that big. The question is then who is responsible for updating the stable branch. IS the developer who commits the change responsible? Do we have some people responsible for maintaining the stable branch and they make the call on what changes to pull out of the main? And you get that thorny issue - what level of enhancements from the main branch get put into the stable branch. While some may be obviously incompatible, there could be other ones which are pretty significant changes. Under this model, I don't think you want to go too long between making major releases - simply because as more time passes, the code from major and stable will drift farther and farther apart, making it harder and harder to take any fixes from the main branch to the stable branch - this then basically amounts to having two different programs to maintain (and/or the stable branch stops getting change as if I fix a bug in the head branch and can't easily see in the code where that belongs in the stable branch, I may not be inclined to get the stable branch, compile, spend the time to debug, etc to try and fix that problem). IMO, this CVS/release model actually is pretty good. The problem is how to handle the head/main CVS branch. It would seem that official releases are never made from it until the target for what constitutes the release is made. That may work if there are people running these CVS servers and clients. But the danger there is it can be hard to run a CVS server when a commit at any time could result in the entire server being reset - I think you almost need to set up various snapshots where you can say 'the code will be stable enough for at least some number of months' so people can feel somewhat comfortable playing on the server, etc. I think then also some form of filtering or a separate metaserver is needed so players do play on the appropriate server. From yann.chachkoff at myrealbox.com Thu Jul 20 02:02:27 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Thu, 20 Jul 2006 09:02:27 +0200 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44BF14D0.3060901@sonic.net> References: <44BBEB9C.5090901@telus.net> <44BDCF94.9080400@telus.net> <44BF14D0.3060901@sonic.net> Message-ID: <200607200902.27489.yann.chachkoff@myrealbox.com> (I fear I'll be overly long again, so fasten your seatbelts :)) Le jeudi 20 juillet 2006 07:29, Mark Wedel a ?crit?: > > Although I do agree that delaying 2.0 too far away would be a bad thing, > > I also think that releasing a 2.0 that would basically be a "1.9 with > > some fixes" would make little sense. > > At some level, all version numbers are arbitrary and can mean whatever. > Sure - yet there are some commonly admitted "values" behind version numbers. Basically, an increase in the major number means a noticeable, significant break from the previous series; a minor usually indicates a "natural" evolution of a given codebase. > In my thinking, the differences of any major release should be seen from > the previous major release (1.0 -> 2.0, 2.0 -> 3.0), not the previous minor > release. In which case a lot has changed from 1.0. > That's a rather strange way of seeing things. The last iteration of the 1.x codebase is 1.9.1, not 1.0. There is no reason to evaluate a new release with one that was made several years ago, and long outdated by an extended evolution process. To put it in another way, do you think players will compare 2.0 against the last known stable version (currently 1.9) or with the 1.0 that's five years old ? > Maybe that isn't great, but as I think was discussed elsewhere, > I wasn't aware of this. > if there is a separate branch for 2.0 (or 3.0 thinking after that), it > probably won't get used much, and before you can really release it to the > general public, you have to make sure it is in fact used. > Sounds a somewhat flawed way of thinking. If you develop a new version of a software - whatever the software is - you cannot expect it to be widely used before it is released. > So this means > that a lot of those features have to put in to the previous version. > No, I don't think so. You can backport *some* features if the new version takes too long to develop, but why would you want to do the work twice ? I see little interest in this. I have the feeling that you consider that leaving the 1.x server for a possibly long period of time without adding more than bugfixes to it is not acceptable - but I personally don't get why this would be a problem; that's a common development cycle and, unless 2.x takes years to be finished, it is hardly an issue for players. > Maybe going forward, there should be a pre-2.0 (or pre-3.0) branch, and > all significant changes have to be put in that branch, so that current > branch only contains bug fixes. But this still goes back to what do the > numbers really need - if most people are running pre 2.0 (pre-2.0-1.9?), > then there are not lots of changes when that is decided to stop calling it > pre 2.0 and make it as a real release. > I don't get why you would need to play with "pre-x" labels - that only adds useless complexity. Let's not forget that the CVS is essentially a developer's tool. Its content is by definition "unreleased code". So I'd suggest to branch whenever we make a new stable release, whatever its version number. The "main" CVS should contain the latest, work-in-progress stuff. The various branches (1.9, 1.10, 2.0) get only bugfixes and can be used to create package revisions (1.9.1, 1.9.2, etc). I think the confusion comes from that currently, a lot of people are using the CVS directly and don't care about the file releases. I don't think it is the best way to ensure a smooth transition process between version, and pertly explains why some important projects get delayed or lack coordination (because the current general assumption is that "the CVS must always work"). > That is a reasonable model - the official version is bug fix only, and > all new features go into what will become the next major version. > > But as said above, snap shots/pre releases of the next major version > still need to be done at some point, and what do we call those? > No, I don't think they need to. But if the goal of such snapshots is to provide some food to the beta-testers, then that's simple: whenever an important development step is done, create an archive of the CVS content, name it with a -bXX suffix and continue to code afterwards. I don't get where this would be a problem. > Sort of goes back to whatever arbitrary numbering scheme we choose. > Yes, but the scheme would be a logical one, and not one that would be based on a rather vague "I think it is time to change the number" feeling. > Problem is that then we will never make another major release, as the > list of things to do will continue to grow. > No, because you can impose a time limit to submit new ideas that needs to be incorporated to the 2.x line. Say for example that "we end discussion on August 31th", have a debate during the first week of September about the submitted ideas, who will do what and what can be dropped because of being too ambitious/irrealistic/whatever else. Currently, there is no such team planning - it is basically "free for all"; it has its advantages of course, but also major drawbacks, like the inhability to planify what the next major release will contain. > And there is certainly the case of things that get deferred to the next > release. That happens all the time in all sorts of software - it would be > nice to have feature X, but doing that means that things won't be completed > for another 12 months, so will put feature X into the next version. > Yes, but I don't get the relationship between that problem and the current discussion. > But there are many different types/layers of bugs. Many bugs may fall > more into the RFE category or nice to have feature type of thing. > I was speaking about functional bugs ("Things don't work as expected"), not RFEs/whishlist (those I don't really consider as bugs, as they don't describe functional errors). > And > there may be many other bugs that fall more into the inconvenience of > slightly annoying. > Again, evaluate the bug against the "Does that work as expected ?" question. If the answer is "no", then that's indeed something that needs to be corrected as a revision of the current version. If that's a "yes", then it will get into the next (minor or major) release. > Saying it should be 100% bug free is also one of those > things that is likely to never happen (as you fix ones, new ones will > always get filed). Pretty much all software ships with some number of > bugs. > Sure - but expecting that most bugs - the most visible ones, the most annoying ones - to be corrected is a very realistic goal. > I'd say that the first person that steps in to the task then writes up > what they think should be done, send it out, get comments, revise, repeat, > then code when decided. > Agree - the problem is that at the end of the process, we should get a clear document (probably in the Wiki itself) precisely describing the final model. That's currently not the case for most of the proposals. > I think that is a much better solution than some committee deciding what > should be done and then expect someone else to write that code. > I wasn't suggesting that a "committee" decide what others should code. But I think it is not too constraining to say: "let's discuss about what we want to do about the X improvement, and get a clear consensus about it". > As in a volunteer project, I think we'd see a lot of specs and not a lot of > code. > Volunteer doesn't necessarily imply that we should have no group organization - let's not confuse "volunteer" and "individualism". Currently, what we see is a lot of code, but not a lot of specs. I'm not convinced it is a better scheme, because it basically makes cooperation on a large scale very difficult; it also makes retaking an older piece of code more difficult, because you have to guess the initial intend of the original coder. > And I think we have to be careful about making things too complicated. > Crossfire doesn't have a huge developer base - the need for high degree of > coordination, isn't as great as if there were 100 developers with many > different major projects going on at once. > Well, although I agree with the principle, I think you are completely misrepresenting what I described. I wasn't suggesting the complex creation of many internal hierarchical structures that would work like a men-in-black administration ! What I said is just that for anything larger than bugfixes or minor improvements, we need a document describing (1)the goal to achieve and (2)how to do it; something that would define the work in a clear and unambiguous way. I also suggested that for major changes, such a document should be the result of a consensus, and not a one-man decision. Regardless of the size of the developers base, I hardly see how something as simple as that would suffocate the devs and "make things too complicated". > In terms of CVS, that could work out like: > > head branch: Contains major release - all changes (unless not applicable > due to other changes) go in the head. > Agree. The head should be the main point of introduction of new code. > stable branch: This is where minor/micro releases come from. When a new > major release is done, a new stable (stable-2-0-0, stable-3-0-0) is done. > I really only see one stable branch per major release - the determination > of micro/minor is a call of the RE at time of release based on what > changes. I think in this model, releases done on a fairly regular schedule > (quarterly? Every 6 months) since the number of changes probably won't be > that big. > I don't understand why we'd have a single stable branch for each major version. I think we'd need to create a branch for every stable release made on the basis of a major release. I think this is justified by the fact that we're much more likely to get revisions of a given major release than a major release. > The question is then who is responsible for updating the stable branch. > IS the developer who commits the change responsible? Do we have some > people responsible for maintaining the stable branch and they make the call > on what changes to pull out of the main? And you get that thorny issue - > what level of enhancements from the main branch get put into the stable > branch. While some may be obviously incompatible, there could be other > ones which are pretty significant changes. > That's why I don't think branching on the sole basis of the "major release number" is a flawed idea. I think that saying "the next schedule for a release is next month, so let's branch the code now that it is more or less working, only fix bugs, and continue to put the new stuff in head. In such a scheme, there is no need for specific responsability over the stable branches - when a bug is submitted, first correct it in the stable branch, and then port it in the head, unless it has already been eliminated there. > Under this model, I don't think you want to go too long between making > major releases - simply because as more time passes, the code from major > and stable will drift farther and farther apart > That's why I think branching on releases of a single major is a better idea, as they would be done on a shorter cycle (in the range of 3 to 6 months at most). > IMO, this CVS/release model actually is pretty good. The problem is how > to handle the head/main CVS branch. It would seem that official releases > are never made from it until the target for what constitutes the release is > made. > It doesn't seem to be a problem, provided that the release cycle is short (which I expect it wouldn't basing it on the major version changes rather than the revisions in a given version). > That may work if there are people running these CVS servers and clients. > But the danger there is it can be hard to run a CVS server when a commit at > any time could result in the entire server being reset - I think you almost > need to set up various snapshots where you can say 'the code will be stable > enough for at least some number of months' so people can feel somewhat > comfortable playing on the server, etc. > That's exactly why I suggested the creation of a branch at each revision step - those would be a close match to the "snapshots" you are describing, except that we ensure to fix its bugs for its life duration (that is, until a new revision is released). > I think then also some form of filtering or a separate metaserver is > needed so players do play on the appropriate server. > We already have the "version" field in the metaserver to identify the server-side of the versioning problem. As for the client, I'd say that: - A client should always work with servers with version numbers lower or equal than its own (ex: a 2.4 client would work with 2.0->2.4 servers, but not with 2.5 ones); - A client has no guaranteed compatibility across major revisions (So a 2.x client will likely not work on 1.x servers). From alex_sch at telus.net Thu Jul 20 02:04:16 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 20 Jul 2006 01:04:16 -0600 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44BF14D0.3060901@sonic.net> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> <44BDCF94.9080400@telus.net> <44BF14D0.3060901@sonic.net> Message-ID: <44BF2AF0.4070403@telus.net> Mark Wedel wrote: > One thought is to define major.minor.micro releases like this: > > major release: Changes that break compatiblity (need to start with a clean > server as player files are not compatible, server/client compatibility may be an > issue, and/or programs removed (x11 client goes away for example). > I feel that changes that break compatibility should not be required in order for there to be a major version change, I believe that a major change from the gameplay point of view, would also go to major releases. Also, variability of automated conversion utilities should not disqualify map/arch/playerfile/etc. format changes from going towards a major release. Essentially, what I think should be put into major releases instead of minor, are things that are either, large projects in addition to things that break things. > minor release: feature enhancements and bug fixes. > micro release: only bug fixes. > These definitions work for me, though as noted above, some non-breaking feature enhancements should go to major instead if they truly are a large change (i.e. major code restructuring for example, or things very major from player perspective, should be saved for major releases) > In terms of CVS, that could work out like: > > head branch: Contains major release - all changes (unless not applicable due to > other changes) go in the head. > > stable branch: This is where minor/micro releases come from. When a new major > release is done, a new stable (stable-2-0-0, stable-3-0-0) is done. I really > only see one stable branch per major release - the determination of micro/minor > is a call of the RE at time of release based on what changes. I think in this > model, releases done on a fairly regular schedule (quarterly? Every 6 months) > since the number of changes probably won't be that big. > This makes sense, except for one thing. Unless we set up hard cycles of development, or make micro releases for even fixes of things as small as two non-critical bugs, we will have almost no micro releases ever, because every time time there are enough bugfixes to be worth making a micro release, we most likely would also have a couple feature enhancements which would force it to be a minor release instead of micro. One option if we want micro releases to be meaningful, is on a frequent regular basis, check if there are a couple or more bugs that were fixed in the cvs stable branch, and if there were no feature enhancements in that same timeframe, then make a micro release. > The question is then who is responsible for updating the stable branch. IS > the developer who commits the change responsible? Do we have some people > responsible for maintaining the stable branch and they make the call on what > changes to pull out of the main? And you get that thorny issue - what level of > enhancements from the main branch get put into the stable branch. While some > may be obviously incompatible, there could be other ones which are pretty > significant changes. > Well, I think that we don't have the manpower to maintain a stable branch separately like some larger projects may be able do, hence I think it should be the responsibility of the developer who commits. One other note you didn't really say anything about, is once a major release is released, the only stable branch that should be maintained should be the one for that major release number. What I mean is, when 3.0.0 is released, we should no longer bother with the 2.x.x branch, and the stable branch for 3.x.x will be made, and then the head branch will represent things for 4.0.0. > Under this model, I don't think you want to go too long between making major > releases - simply because as more time passes, the code from major and stable > will drift farther and farther apart, making it harder and harder to take any > fixes from the main branch to the stable branch - this then basically amounts to > having two different programs to maintain (and/or the stable branch stops > getting change as if I fix a bug in the head branch and can't easily see in the > code where that belongs in the stable branch, I may not be inclined to get the > stable branch, compile, spend the time to debug, etc to try and fix that problem). > Agreed. For that reason, I also believe that a major code restructure should be done in a major release, and the major release should happen immediately after the restructure is done in order to minimize headaches. > That may work if there are people running these CVS servers and clients. But > the danger there is it can be hard to run a CVS server when a commit at any time > could result in the entire server being reset - I think you almost need to set > up various snapshots where you can say 'the code will be stable enough for at > least some number of months' so people can feel somewhat comfortable playing on > the server, etc. > Well, several things. For one, more frequent releases would make people less inclined to run CVS servers and clients as opposed to releases. Also, not all major releases need to break compatibility and when compatibility, it should be strongly recommended that developers make conversion utilities if it is practical for map/playerfile compatibility breaks. As it stands now, there is just as much danger running a CVS server, except that nobody makes compatibility breaks even when there may be a good reason, hence I think so long as conversion utilities are made and the protocol stays reasonably stable, it should be just fine. > I think then also some form of filtering or a separate metaserver is needed so > players do play on the appropriate server. Well, I think the best way to do that, would be having servers sent the protocol version that they send in the protocol already, do the metaserver, and we can have clients check against their own protocol version number. In theory that should be very simple to do just so long as people remember to increment that if they need to break protocol compatibility. Alex Schultz From yann.chachkoff at myrealbox.com Thu Jul 20 05:42:29 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Thu, 20 Jul 2006 12:42:29 +0200 Subject: [crossfire] Server console output Message-ID: <1153392149.c7d5431cyann.chachkoff@myrealbox.com> Yesterday, I made some tests with the recent CF server (the CVS one). As I wanted to get maximum verbosity, I checked the help, which contains the following: Flags: (...) -d Turns on some debugging. +d Turns off debugging (useful if server compiled with debugging as default). (...) -log Specifies which file to send output to. Only has meaning if -detach is specified. First, I find rather strange that "+d" turns debugging *off* - that's rather counter-intuitive, given that "+" is traditionally attached to the idea of "adding", not "removing". But that's only a minor quibble. On the other hand, the "log" option says that it only has meaning if -detach is specified, but that's not true - it seems that the -log option works in all cases. Second, why is that the output is by default not stdout ? If I launch crossfire without any option from the command line, I'd expect it to give me some output on the console, but it doesn't appear to be the case. I don't even get the confirmation that the server is up and running. There is no obvious indication that the server output goes anywhere, and where. So my question/issue here is twofold: - Shouldn't either the -log option description be corrected or its behavior be changed (I'm not sure which one is "correct") ? - Shouldn't the server launched from the command line send its output by default on stdout ? If not, what's the recommended way to achieve such a result ? From tchize at myrealbox.com Wed Jul 19 04:51:38 2006 From: tchize at myrealbox.com (Tchize) Date: Wed, 19 Jul 2006 11:51:38 +0200 Subject: [crossfire] Gridarta as Webstart application In-Reply-To: <200607142339.11858.cher@riedquat.de> References: <200607142339.11858.cher@riedquat.de> Message-ID: <44BE00AA.9000505@myrealbox.com> Hi, I have quite a good amount of experience with webstart. One of the main drawback of webstart is that it comes from a web environment, that mean the running application will be in a sandbox, limiting it's possibilities. It can't access disk space, it can't store datas in user directory, it can't open network connection. Unless you explicitly put it as a trusted application, that mean you then need to sign it with a certificate, and such certificate cost money. You could use a selfsigned certificate, but then you remove all security, which is a problem in a web environment where you can't trust. Christian Hujer wrote: > Hello dear co-devs, > > > I've just started experimenting a bit with Webstart. You can see my first > steps on http://www.riedquat.de/gridarta/webstart > > To me, Webstart currently looks like the future of Gridarta. > I have the following reasons for this opinion: > * It's easy to use for users. > yes > ** Start the application by a click on a link on a webpage. > yes, main point of 'webstart' > ** On Windows it can create desktop and start menu shortcuts. > standalone installers can too > * It will automatically update the application. > can be a problem if one version appear to be bugged and user wants to keep previous :) > * We can easily split the application into several jar files. > standalone can too > * Each jar file is updated separately. > * If the webpage is set up properly, it will even help users to update their > JRE if it's out of date for Gridarta. > > (Note that gridarta webstart is not intended to replace the original > standalone applications, it's intended as an alternative that should be easy > to use and easy to update for users) > > Possible file list A: > * hosted by Gridarta: > ** For Crossfire: > *** gridarta4crossfire.jnlp > *** gridarta4crossfire.jar > ** For Daimonin: > *** gridarta4daimonin.jnlp > *** gridarta4daimonin.jar > ** For both: > *** library jars (gridarta, japi, bsh-*, jlfgr-1_0) > *** legacy jars (rm'ed asap): crimson, jdom, png, visualtek > *** log4j.jar (Ragnor: now open for discussion again) > * hosted by Crossfire: > ** gridarta4crossfire-data.jar > * hosted by Daimonin: > ** gridarta4daimonin-data.jar > > Possible file list B: > * hosted by Crossfire: > ** gridarta4crossfire-data.jar > ** gridarta4crossfire.jnlp > ** gridarta4crossfire.jar > * hosted by Daimonin: > ** gridarta4daimonin-data.jar > ** gridarta4daimonin.jnlp > ** gridarta4daimonin.jar > * hosted by Gridarta: > ** library jars gridarta.jar, japi.jar, bsh-classgen.jar, bsh-commands.jar, > bsh-core.jar, bsh-util.jar, jlfgr-1_0.jar > ** legacy jars (to be removed soon): crimson.jar, jdom.jar, png.jar, > visualtek.jar > ** log4j.jar (now open for discussion again) > > The jnlp needs to be changed if a jar is added or removed. > Having the jnlp with Gridarta means Gridarta has to update the JNLPs if the > projects decide to change their data jar (e.g. split it into two or three > separate jars). > Having the jnlp with the projects means the Projects have to update the JNLPs > if gridarta decides to add / remove library jars / split itself into more > jars. > I haven't found a way of using a split jnlp yet. (Maybe someone knows?) > add a 'ant jnlp -Djnlp.template=....' to generate jnlp a common way for all project while letting distributors customize parts of it (like base url)? :D or of course define a few properties in the build.properties :) > I think having the servers in jar archives and deploying / updating them with > the editor package could also come in handy. JNLP allows specifying different > jars for different operating systems, architecture and even locale. > Though it is indeed possible to encapsulate server in the jnlp, take care that the only file extension allowed by webstart is .jar (that's why native libs must be encapsulated in .jars too) and you will have in gridarta to do manual operations to deploy this test server (same apply for maps ^^) > > Feedback welcome, especially from crossfire and daimonin admins / developers > (that's why I crossposted and cc:-ed) > From cher at riedquat.de Wed Jul 19 16:36:32 2006 From: cher at riedquat.de (Christian Hujer) Date: Wed, 19 Jul 2006 23:36:32 +0200 Subject: [crossfire] [Gridarta-devel] Gridarta as Webstart application In-Reply-To: <44BE00AA.9000505@myrealbox.com> References: <200607142339.11858.cher@riedquat.de> <44BE00AA.9000505@myrealbox.com> Message-ID: <200607192336.32703.cher@riedquat.de> Hi all, Hi tchize, Am Mittwoch, 19. Juli 2006 11:51 schrieb Tchize: > Hi, > > I have quite a good amount of experience with webstart. One of the main > drawback of webstart is that it comes from a web environment, that mean > the running application will be in a sandbox, limiting it's > possibilities. It can't access disk space, it can't store datas in user > directory, it can't open network connection. Unless you explicitly put > it as a trusted application, that mean you then need to sign it with a > certificate, and such certificate cost money. You could use a selfsigned > certificate, but then you remove all security, which is a problem in a > web environment where you can't trust. The experimental versions already are with self-signed certificates and request all-permission. I do not see any difference in trust between the completely unsigned Gridarta downloaded from the web and Gridarta signed with a self-signed certificate. Maybe I'd even invest these 30 EUR or whatsoever for a properly signed certificate. Cu :) -- Christian Hujer Free software developer E-Mail: cher at riedquat.de WWW: http://www.riedquat.de/ From mwedel at sonic.net Fri Jul 21 00:37:19 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 20 Jul 2006 22:37:19 -0700 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <200607200902.27489.yann.chachkoff@myrealbox.com> References: <44BBEB9C.5090901@telus.net> <44BDCF94.9080400@telus.net> <44BF14D0.3060901@sonic.net> <200607200902.27489.yann.chachkoff@myrealbox.com> Message-ID: <44C0680F.7080703@sonic.net> Yann Chachkoff wrote: >> if there is a separate branch for 2.0 (or 3.0 thinking after that), it >> probably won't get used much, and before you can really release it to the >> general public, you have to make sure it is in fact used. >> > Sounds a somewhat flawed way of thinking. If you develop a new version of a > software - whatever the software is - you cannot expect it to be widely used > before it is released. The biggest danger is that given there are only a handful of servers, if the first release of 2.0 (or whatever major version) has serious problems, it might be hard convincing people to try 2.1, etc And if the changes break compatibility, that makes it even less likely for servers to switch over. > I have the feeling that you consider that leaving the 1.x server for a > possibly long period of time without adding more than bugfixes to it is not > acceptable - but I personally don't get why this would be a problem; that's a > common development cycle and, unless 2.x takes years to be finished, it is > hardly an issue for players. I suppose it depends on how often we plan to do major releases. If only every couple years, this can lead to other problems: 1) To players/users, the project may appear dead (nothing new in the past 12 months) 2) To developers, less satisfaction making changes if no one (outside perhaps a very limited set of developers) will see it for 12 months This can be solved by doing major releases every 6 months (or a year at max) - but that then limits number of changes that can be done in each for each major release. Which may not be a bad thing, but just a note. But last point is scope of changes - if major changes break compatibility, you probably don't want to do them too often - players (and server admins) probably don't want to have to start from scratch every 6 months. > So I'd suggest to branch whenever we make a new stable release, whatever its > version number. The "main" CVS should contain the latest, work-in-progress > stuff. The various branches (1.9, 1.10, 2.0) get only bugfixes and can be > used to create package revisions (1.9.1, 1.9.2, etc). That more or less matches what I said for the CVS branch. I guess if we're not really concerned about stability of major releases, doing pre-releases isn't necessary. But given that major releases will have much larger scale changes, I'd see that number of severity of bugs to potentially be larger. Likewise, if the code isn't being used very much until it is released, it means that a bug for a big change may not be discovered until a year after that change is made. I know from my own developing perspective, I'd much rather find bugs for code I do relatively shortly after I do the code, because the code will be fresher in my mind than if I have to look back at something I did 6 months ago. I suppose in short what I'm saying is it is really nice to have all code actually exercised/used somewhat shortly after the code is written. > I think the confusion comes from that currently, a lot of people are using the > CVS directly and don't care about the file releases. I don't think it is the > best way to ensure a smooth transition process between version, and pertly > explains why some important projects get delayed or lack coordination > (because the current general assumption is that "the CVS must always work"). yes - that probably isn't a good approach - I think under a new system, servers will need to keep to the stable branch. At the same time, the number of changes in the stable branch will probably be a lot less, so perhaps not as much an issue for servers to keep up to date on that. > >> Problem is that then we will never make another major release, as the >> list of things to do will continue to grow. >> > No, because you can impose a time limit to submit new ideas that needs to be > incorporated to the 2.x line. Say for example that "we end discussion on > August 31th", have a debate during the first week of September about the > submitted ideas, who will do what and what can be dropped because of being > too ambitious/irrealistic/whatever else. > Currently, there is no such team planning - it is basically "free for all"; it > has its advantages of course, but also major drawbacks, like the inhability > to planify what the next major release will contain. Fair enough. But that model sounds more like 'everyone say what you plan to do for the next major release by august 31st'. Everyone discussing what to do is also good. People saying what they will do is needed. Yet at the same time, I think some rough date has to be put out on when those changes will be completed by. If changes are not done by the date, they get pushed off to next major version (there is of course some wiggle room here, but it isn't uncommon for other various things to happen in ones life which limits the ability to do the work. If a month before the release the person responsible for it says 'I haven't done much work, and I can't continue', do we really put off the release for someone else to take over, or just put it off? If you put it off, then the danger comes that someone takes it over, and other developers, having completed there stuff, don't have anything to do, so start the process for some other big changes. I suppose it can just be a simple case of 'well, even though 2.0 isn't out yet, your change has to wait to 3.0'. Dunno what is really the right answer for this. > I was speaking about functional bugs ("Things don't work as expected"), not > RFEs/whishlist (those I don't really consider as bugs, as they don't describe > functional errors). but that can be a question that is also hard to answer. Looking at the bug list on sourceforge, I would say that perhaps a third to a half of those could be put in the not real bugs (enhancement requests). But other people could say that they are bugs that really should be fixed. At some level, it becomes a matter of of opinion. >> I'd say that the first person that steps in to the task then writes up >> what they think should be done, send it out, get comments, revise, repeat, >> then code when decided. >> > Agree - the problem is that at the end of the process, we should get a clear > document (probably in the Wiki itself) precisely describing the final model. > That's currently not the case for most of the proposals. True - but at least for significant projects, proposals are supposed to be sent to the mailing list. They are not necessarily copied to the wiki. I at least have tried for the most part to send out proposals of what I plan to do. > >> I think that is a much better solution than some committee deciding what >> should be done and then expect someone else to write that code. >> > I wasn't suggesting that a "committee" decide what others should code. But I > think it is not too constraining to say: "let's discuss about what we want to > do about the X improvement, and get a clear consensus about it". I agree. > What I said is just that for anything larger than bugfixes or minor > improvements, we need a document describing (1)the goal to achieve and (2)how > to do it; something that would define the work in a clear and unambiguous > way. I also suggested that for major changes, such a document should be the > result of a consensus, and not a one-man decision. > > Regardless of the size of the developers base, I hardly see how something as > simple as that would suffocate the devs and "make things too complicated". Perhaps you could provide an example of such a document? From your description, I have no real idea how detailed or not detailed you are expecting it to be. But as a person who often has sent out e-mail describing changes I'm planning on doing, it is often not uncommon to spend a lot more time describing that, responding to e-mails, followups, etc, than doing that actual work. Maybe that is to be expected, but at some level, not something I want to spend a lot of time doing. The flip side, and perhaps not really related, is need for people that are sending out proposals to follow through and do the code, or at least let us know that it isn't happening. But more than once, there have been discussions about some new feature I think would be cool, and I take part in those, and then never hear anything about it again. Certainly, someone else could pick up those pieces and do that feature, but then you don't necessarily know current status. Maybe as part of this, there needs to be regular updates from the developers about progress, just so it is known if someone disappears and thus we need to find someone else to do it, or that project should be written off, etc. >> stable branch: This is where minor/micro releases come from. When a new >> major release is done, a new stable (stable-2-0-0, stable-3-0-0) is done. >> I really only see one stable branch per major release - the determination >> of micro/minor is a call of the RE at time of release based on what >> changes. I think in this model, releases done on a fairly regular schedule >> (quarterly? Every 6 months) since the number of changes probably won't be >> that big. >> > I don't understand why we'd have a single stable branch for each major > version. I think we'd need to create a branch for every stable release made > on the basis of a major release. I think this is justified by the fact that > we're much more likely to get revisions of a given major release than a major > release. Are you then saying there should be a stable 2-0-0, stable 2-1-0, etc? The only reason I can see of doing that is if there are going to be micro releases as well as minor releases (2.1.1 released after 2.2.0). Given that I'd expect mostly bugfixes in this stable branch, I don't see that this is a very likely scenario (any bug fixed in 2.1.1 should also be in the main stable branch - if there is need to get that fix out right away, why not do a 2.2.1 then?) If there were significant changes in the minor releases, such that running 2.2.0 might be considered risky, which is why you want a 2.1.1 since it is in a better known state. But since I'm not expecting lots of changes in this stable branch, that doesn't seem really likely. > >> The question is then who is responsible for updating the stable branch. >> IS the developer who commits the change responsible? Do we have some >> people responsible for maintaining the stable branch and they make the call >> on what changes to pull out of the main? And you get that thorny issue - >> what level of enhancements from the main branch get put into the stable >> branch. While some may be obviously incompatible, there could be other >> ones which are pretty significant changes. >> > That's why I don't think branching on the sole basis of the "major release > number" is a flawed idea. I think that saying "the next schedule for a > release is next month, so let's branch the code now that it is more or less > working, only fix bugs, and continue to put the new stuff in head. But this starts making things even more work intensive - if I make a change to the main head branch for a bug fix, now there is the potential I have to update the main stable branch as well as the micro branch for a potential upcoming release? Before going on that approach, I'd wait and see how much activity the stable branch is really getting, and if in fact it is getting any signficant changes other than bug fixes or other minor things. >> Under this model, I don't think you want to go too long between making >> major releases - simply because as more time passes, the code from major >> and stable will drift farther and farther apart >> > That's why I think branching on releases of a single major is a better idea, > as they would be done on a shorter cycle (in the range of 3 to 6 months at > most). Is that then saying a major release every 6 months or so? >> That may work if there are people running these CVS servers and clients. >> But the danger there is it can be hard to run a CVS server when a commit at >> any time could result in the entire server being reset - I think you almost >> need to set up various snapshots where you can say 'the code will be stable >> enough for at least some number of months' so people can feel somewhat >> comfortable playing on the server, etc. >> > That's exactly why I suggested the creation of a branch at each revision > step - those would be a close match to the "snapshots" you are describing, > except that we ensure to fix its bugs for its life duration (that is, until a > new revision is released). But I personally don't want to have to main several different branches and have to do updates to them whenever I make a change. > >> I think then also some form of filtering or a separate metaserver is >> needed so players do play on the appropriate server. >> > We already have the "version" field in the metaserver to identify the > server-side of the versioning problem. As for the client, I'd say that: > - A client should always work with servers with version numbers lower or equal > than its own (ex: a 2.4 client would work with 2.0->2.4 servers, but not with > 2.5 ones); > - A client has no guaranteed compatibility across major revisions (So a 2.x > client will likely not work on 1.x servers). Yes - that is a reasonable model. But I think the client needs to hide/filter that. If I'm running client 2.5, it shouldn't show me server version 1.9 when I can't play on it. Or likewise, it should show me server version 2.7 when I may not be able to play on that also (but in that case, it should perhaps print message saying it isn't the latest client and go update) From mwedel at sonic.net Fri Jul 21 00:59:54 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 20 Jul 2006 22:59:54 -0700 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44BF2AF0.4070403@telus.net> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> <44BDCF94.9080400@telus.net> <44BF14D0.3060901@sonic.net> <44BF2AF0.4070403@telus.net> Message-ID: <44C06D5A.9010708@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> One thought is to define major.minor.micro releases like this: >> >> major release: Changes that break compatiblity (need to start with a clean >> server as player files are not compatible, server/client compatibility may be an >> issue, and/or programs removed (x11 client goes away for example). >> > I feel that changes that break compatibility should not be required in > order for there to be a major version change, I believe that a major > change from the gameplay point of view, would also go to major releases. I didn't mean to imply that is the only justification for a major release. Just if such a change is made, no matter how minor otherwise, that should warrant an increase in the major release numbering. > Also, variability of automated conversion utilities should not > disqualify map/arch/playerfile/etc. format changes from going towards a > major release. But those can't always work and/or creates other problems. In the past there have been changes that change things in various ways that would be hard to automate, and/or would make changes to characters that would be unexpected to players (try to explain to players why their stats are different now than last night, or why their item isn't as powerful) - you'll get a lot of upset players in such cases if a player who used to have no problem killing monster X is now killed by it because of changes made to the character. There is also the issue of fairness (character X created before change is made and is thus more powerful than new character Y can be under revised rules). And there is some cost in time, testing, resources of writing such conversion tools. At some level, you just have to say 'hey, the game has changed, start over'. We just have to be careful that doesn't happen too often. >> stable branch: This is where minor/micro releases come from. When a new major >> release is done, a new stable (stable-2-0-0, stable-3-0-0) is done. I really >> only see one stable branch per major release - the determination of micro/minor >> is a call of the RE at time of release based on what changes. I think in this >> model, releases done on a fairly regular schedule (quarterly? Every 6 months) >> since the number of changes probably won't be that big. >> > This makes sense, except for one thing. Unless we set up hard cycles of > development, or make micro releases for even fixes of things as small as > two non-critical bugs, we will have almost no micro releases ever, > because every time time there are enough bugfixes to be worth making a > micro release, we most likely would also have a couple feature > enhancements which would force it to be a minor release instead of > micro. One option if we want micro releases to be meaningful, is on a > frequent regular basis, check if there are a couple or more bugs that > were fixed in the cvs stable branch, and if there were no feature > enhancements in that same timeframe, then make a micro release. If there are never any micro releases, that is fine IMO. In fact, I'd generally not expect there to be many micro releases, but I could see see a minor release made, a critical bug found a few days later, and can't really justify a minor release, but you need to get a new version out, so do a micro. >> The question is then who is responsible for updating the stable branch. IS >> the developer who commits the change responsible? Do we have some people >> responsible for maintaining the stable branch and they make the call on what >> changes to pull out of the main? And you get that thorny issue - what level of >> enhancements from the main branch get put into the stable branch. While some >> may be obviously incompatible, there could be other ones which are pretty >> significant changes. >> > Well, I think that we don't have the manpower to maintain a stable > branch separately like some larger projects may be able do, hence I > think it should be the responsibility of the developer who commits. > One other note you didn't really say anything about, is once a major > release is released, the only stable branch that should be maintained > should be the one for that major release number. What I mean is, when > 3.0.0 is released, we should no longer bother with the 2.x.x branch, and > the stable branch for 3.x.x will be made, and then the head branch will > represent things for 4.0.0. Yes - I didn't say that in terms of major/stable, but that is how I expect it. It may be reasonable that right after a major release, the stable branch for the previous gets updated for some limited time - sort of same above - if 3.0.0 is released, and the next day, a major bug is discovered that affects the 2.0.0 stable branch, may want to still update that 2.0.0 stable and make a release simply because it may be unreasonable for everyone to switch over to the next major release in a few days (I'd say this overlap time would be 1 month at most, but then this also sort of depends on how often major releases are done - if major releases are done every 6 months, then updating to major releases shouldn't be seen as such a big deal). >> Under this model, I don't think you want to go too long between making major >> releases - simply because as more time passes, the code from major and stable >> will drift farther and farther apart, making it harder and harder to take any >> fixes from the main branch to the stable branch - this then basically amounts to >> having two different programs to maintain (and/or the stable branch stops >> getting change as if I fix a bug in the head branch and can't easily see in the >> code where that belongs in the stable branch, I may not be inclined to get the >> stable branch, compile, spend the time to debug, etc to try and fix that problem). >> > Agreed. For that reason, I also believe that a major code restructure > should be done in a major release, and the major release should happen > immediately after the restructure is done in order to minimize headaches. But that can then lead to rapid turnover of major releases. Eg, I do major code restructure, make 3.0.0 release. Then some other change is made (maybe compatibility breakage, maybe some other code restructure) - do you make a 4.0.0 release 3 months later then? I think there needs to be some minimum/maximum gap between major releases. > As it stands now, there is just as much danger running a CVS server, > except that nobody makes compatibility breaks even when there may be a > good reason, hence I think so long as conversion utilities are made and > the protocol stays reasonably stable, it should be just fine. but IMO, allowing breakage is one of the advantages of major cycles. There is lots of old code related to protocol handling to support old clients. That should get pulled, but may break some number of clients. And conversion routines, as mentioned above, can still be problematic. Now there is no technical reason multiple servers can't be run on the same physical box (don't even need virtual hosts, but that could be one of the easier ways - another would be to use different port numbers) - that could help server admins - they could set up the new server on some new port, and use different set of player files, etc. but I think it is desirable to periodically start with a clean slate. While conversion scripts are nice, if the changes are significant, we shouldn't be afraid to force a restart. We should limit how often we do this (and/or try to consolidate as many of those changes into one major release vs stringing it out accross several major releases). From alex_sch at telus.net Fri Jul 21 02:15:36 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 21 Jul 2006 01:15:36 -0600 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44C06D5A.9010708@sonic.net> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> <44BDCF94.9080400@telus.net> <44BF14D0.3060901@sonic.net> <44BF2AF0.4070403@telus.net> <44C06D5A.9010708@sonic.net> Message-ID: <44C07F18.2010706@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> Mark Wedel wrote: >> >>> One thought is to define major.minor.micro releases like this: >>> >>> major release: Changes that break compatiblity (need to start with a clean >>> server as player files are not compatible, server/client compatibility may be an >>> issue, and/or programs removed (x11 client goes away for example). >>> >> I feel that changes that break compatibility should not be required in >> order for there to be a major version change, I believe that a major >> change from the gameplay point of view, would also go to major releases. >> > I didn't mean to imply that is the only justification for a major release. > Just if such a change is made, no matter how minor otherwise, that should > warrant an increase in the major release numbering. > Agreed. >> Also, variability of automated conversion utilities should not >> disqualify map/arch/playerfile/etc. format changes from going towards a >> major release. >> > > But those can't always work and/or creates other problems. In the past there > have been changes that change things in various ways that would be hard to > automate, and/or would make changes to characters that would be unexpected to > players (try to explain to players why their stats are different now than last > night, or why their item isn't as powerful) - you'll get a lot of upset players > in such cases if a player who used to have no problem killing monster X is now > killed by it because of changes made to the character. > > There is also the issue of fairness (character X created before change is made > and is thus more powerful than new character Y can be under revised rules). > > And there is some cost in time, testing, resources of writing such conversion > tools. At some level, you just have to say 'hey, the game has changed, start > over'. We just have to be careful that doesn't happen too often. > Yes, agreed. Not all breakage can be dealt with by conversion scripts in a "proper" manner, however my point was that where conversion IS possible in a safe and "proper" manner we should make converters. (Things like, splitting of multi-meanings for attributes, comes to mind, with regards to converting map data). >>> The question is then who is responsible for updating the stable branch. IS >>> the developer who commits the change responsible? Do we have some people >>> responsible for maintaining the stable branch and they make the call on what >>> changes to pull out of the main? And you get that thorny issue - what level of >>> enhancements from the main branch get put into the stable branch. While some >>> may be obviously incompatible, there could be other ones which are pretty >>> significant changes. >>> >>> >> Well, I think that we don't have the manpower to maintain a stable >> branch separately like some larger projects may be able do, hence I >> think it should be the responsibility of the developer who commits. >> One other note you didn't really say anything about, is once a major >> release is released, the only stable branch that should be maintained >> should be the one for that major release number. What I mean is, when >> 3.0.0 is released, we should no longer bother with the 2.x.x branch, and >> the stable branch for 3.x.x will be made, and then the head branch will >> represent things for 4.0.0. >> > Yes - I didn't say that in terms of major/stable, but that is how I expect it. > I thought you would expect it as such but thought I would bring it up. :-) > It may be reasonable that right after a major release, the stable branch for > the previous gets updated for some limited time - sort of same above - if 3.0.0 > is released, and the next day, a major bug is discovered that affects the 2.0.0 > stable branch, may want to still update that 2.0.0 stable and make a release > simply because it may be unreasonable for everyone to switch over to the next > major release in a few days (I'd say this overlap time would be 1 month at most, > but then this also sort of depends on how often major releases are done - if > major releases are done every 6 months, then updating to major releases > shouldn't be seen as such a big deal). > That makes sense if there is a demand of it, but I'm not sure if there is, or even if there isn't much of a demand, makes sense for more critical bugs shortly after a release anyways. >>> Under this model, I don't think you want to go too long between making major >>> releases - simply because as more time passes, the code from major and stable >>> will drift farther and farther apart, making it harder and harder to take any >>> fixes from the main branch to the stable branch - this then basically amounts to >>> having two different programs to maintain (and/or the stable branch stops >>> getting change as if I fix a bug in the head branch and can't easily see in the >>> code where that belongs in the stable branch, I may not be inclined to get the >>> stable branch, compile, spend the time to debug, etc to try and fix that problem). >>> >>> >> Agreed. For that reason, I also believe that a major code restructure >> should be done in a major release, and the major release should happen >> immediately after the restructure is done in order to minimize headaches. >> > > But that can then lead to rapid turnover of major releases. Eg, I do major > code restructure, make 3.0.0 release. Then some other change is made (maybe > compatibility breakage, maybe some other code restructure) - do you make a 4.0.0 > release 3 months later then? I think there needs to be some minimum/maximum gap > between major releases. > This is true, however I can't see major code restructures working well as part of a minor release. What I see as ideal though, is if the trunk gets a few major features almost worthy of a major release, then a code restructure happens, and a release happens afterwards. Of course, timing may not work out so ideally, but perhaps it might be good for people to try to time their major code restructures to finish about just before when a major release is anticipated. >> As it stands now, there is just as much danger running a CVS server, >> except that nobody makes compatibility breaks even when there may be a >> good reason, hence I think so long as conversion utilities are made and >> the protocol stays reasonably stable, it should be just fine. >> > but IMO, allowing breakage is one of the advantages of major cycles. > > There is lots of old code related to protocol handling to support old clients. > That should get pulled, but may break some number of clients. > Yes, this is true, however despite that, not all major releases need break things, and no sense breaking things unless there is a logical reason to. (random thought about old clients: There are a good number of people who still use the plain X client, the gnome client though, I don't think is in usage though I may be mistaken) > And conversion routines, as mentioned above, can still be problematic. > Conversion routines as I noted above are not a catch-all, but are something that should be done where reasonable, safe, and "proper". For one, in the case of changes in map file format, conversion scripts should typically make sense. However if the breaks are due to behavior changes, it usually wouldn't make sense to do a conversion script. Alex Schultz From fuchs.andy at gmail.com Fri Jul 21 10:24:41 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri, 21 Jul 2006 11:24:41 -0400 Subject: [crossfire] Metaserver reporting and accuracy In-Reply-To: <44BC6F97.40504@sonic.net> References: <44B3CE96.3020605@real-time.com> <20060712144508.GA8738@elmex> <44B51FDA.40505@telus.net> <44BC6F97.40504@sonic.net> Message-ID: On 7/18/06, Mark Wedel wrote: > Alex Schultz wrote: > > Either way, perhaps another thing that would be good on servers, would > > be automatically setting the afk flag if they are idle for more than a > > certain amount of time, and if they become active again, it will unset > > the afk flag, unless they turned it on manually. IMHO that behavior > > would make not including afk players in the count, much more useful. > > That would almost go into yet another category - 'idle'. > > I'm not sure how true it is, but I can certainly envision that there are > players online who are idle - they are waiting for something interesting to > happen, partake in chatting, etc. So while idle, they are effectively around. > But that may be over thinking this problem here. IMO, a timer for AFK status is probably the only way that the whole afk thing will get used by most people. Another thing is, should an other status be implemented to tell if the player is actually playing, or just logged in to chat. This could be taken farther to add commands to the protocol so connections to the server can be set so the player can't do anything but chat and check other player's statuses, since oldsocketmode uses food iirc. The result of this may be a larger player community, but it could eventualy turn crossfire into more of a chat protocol than a game. -- Andrew Fuchs From wim-cf at villerius.nl Fri Jul 21 11:40:18 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Fri, 21 Jul 2006 18:40:18 +0200 Subject: [crossfire] Metaserver reporting and accuracy In-Reply-To: <44B3CE96.3020605@real-time.com> References: <44B3CE96.3020605@real-time.com> Message-ID: <1153500019.21673.9.camel@localhost.localdomain> perhaps add a note in the metaserver whether or not the server does actually reports bots, afk, wiz etc. And perhaps manually remove servers that are known to report incorrect numbers and refuse to change that behaviour. On Tue, 2006-07-11 at 11:15 -0500, Rick Tanner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Per the feedback from other people on IRC and other means, I've put > together a list of requirements that people want to see with the > metaserver reporting. > > So, with this post I am asking public server admins to cooperate on the > following: > > * All information must be as accurate as can reasonably be (IP Address, > hostname, number of players, server version, etc.) > > * Only crossfire compatible servers can be listed. Compatible in this > case means that the official crossfire clients can be used to play on > that server without any issues. Servers may have enhancements the > official client does not support so long as those enhancements are not > needed to play the game. > > * If the server is only going to be available temporarily or for a > limited - indicate so in the metaserver comment area. > > This is not a final draft or a complete list by any means, but I think > it's a reasonable start. > > Comments? > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFEs86WhHyvgBp+vH4RAmNqAKD0JL0u4CK2KV7EDh6bGLqZ9uSwSgCg6ZX1 > QY895/nY52/towRpKjjXIuY= > =WbKL > -----END PGP SIGNATURE----- > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From fuchs.andy at gmail.com Fri Jul 21 13:15:21 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri, 21 Jul 2006 14:15:21 -0400 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44C07F18.2010706@telus.net> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> <44BDCF94.9080400@telus.net> <44BF14D0.3060901@sonic.net> <44BF2AF0.4070403@telus.net> <44C06D5A.9010708@sonic.net> <44C07F18.2010706@telus.net> Message-ID: What I'm inferring, and my op pinions: Summary: While 2.0 should be a significant release, the majority opinion is that it should not take years. This makes it difficult to implement what everyone wants, etc. I think 2.0 should be the point at which most issues that we have known about, but haven't fixed, should be fixed. Additionally, the game should be made easier to use (more graphical interfaces on the client side instead of typing in commands constantly), and have a significant amount of balance issues fixed IMO. Another thing is that, I think we should do something to encourage developers to join the project. Finally, a stronger community of players could help this game gain popularity, which would result in more developers. Gaining developers: To get new developers, we first have to have them gain interest in the game, this would fall under building a stronger community. Second, I think reorganizing/restructuring the code into a more logical form, as it is been discussed, and revising/creating more documentation will make it easier for anyone interested in contributing to the project to contribute. Strengthening the community: On the community side, we need to encourage player interaction, both in and out of the game. One way to boost in game interaction would be bolstering the player economy. However, that will probably not be done in time for cf2.0. For the community out of game, make it easier to find resources like the forums, and the wiki. Additionally, make it easier to join irc channels, possibly by putting a java applet somewhere. Another thing that could be done to aid the community, both in-game and outside of the game, would be to setup a method to connect to servers, just for the purpose of chatting with people who are playing (oldsocketmode uses food iirc). Another topic of communication between players, would be the inter-server chat discussed a while ago. My opinion on release numbers: Once we have more developers and enough are willing to volunteer, it may be a good idea to appoint some people to maintain the stable branches. Micro releases: bug fixes, and addition of small features Minor releases: Features involving significant changes Major releases: Huge changes in game play, major overhauls, milestones in development Finally, i just want to note that our next release could be 1.10.0 instead of 2.0 if we need more time for cf2.0. -- Andrew Fuchs From mwedel at sonic.net Sat Jul 22 03:01:02 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 22 Jul 2006 01:01:02 -0700 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44C07F18.2010706@telus.net> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> <44BDCF94.9080400@telus.net> <44BF14D0.3060901@sonic.net> <44BF2AF0.4070403@telus.net> <44C06D5A.9010708@sonic.net> <44C07F18.2010706@telus.net> Message-ID: <44C1DB3E.5090305@sonic.net> Alex Schultz wrote: > >> But that can then lead to rapid turnover of major releases. Eg, I do major >> code restructure, make 3.0.0 release. Then some other change is made (maybe >> compatibility breakage, maybe some other code restructure) - do you make a 4.0.0 >> release 3 months later then? I think there needs to be some minimum/maximum gap >> between major releases. >> > This is true, however I can't see major code restructures working well > as part of a minor release. What I see as ideal though, is if the trunk > gets a few major features almost worthy of a major release, then a code > restructure happens, and a release happens afterwards. Of course, timing > may not work out so ideally, but perhaps it might be good for people to > try to time their major code restructures to finish about just before > when a major release is anticipated. Well, a major code restructure can't go into a minor release. Under the proposed model, the only thing that comes from the main branch is major releases - when a major release is done, then a new stable branch is set up where the minor releases come from. Going back to the original issue is code drifting apart - if a major restructure is done in the main branch, it makes fixing any bugs in both the main and stable branch more difficult. It could just be we live with that difficulty. Or if a major restructure is done shortly after a major release, still have to wait for the 6 months or whatever. I don't really want to try to say 'major code restructures happen near the end of the cycle' - I think if someone has the code ready and it is on the list of things to do, it should be committed. > Yes, this is true, however despite that, not all major releases need > break things, and no sense breaking things unless there is a logical > reason to. > (random thought about old clients: There are a good number of people who > still use the plain X client, the gnome client though, I don't think is > in usage though I may be mistaken) However, as per gros's comment, there needs to be sufficient changes between the releases to warrant a major release. We probably don't want to do a new major release if there are not any signficant changes - I suppose this may be a matter of opinion, but if we go in this model, I think that sort of needs to be the case, as otherwise we get into confusion at what each branch/release means. There can still certainly be major releases which don't break compatiblity in any way but still hold other significant changes (new features, or changing of existing features/expanding them). From yann.chachkoff at myrealbox.com Sat Jul 22 03:17:02 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat, 22 Jul 2006 10:17:02 +0200 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44C0680F.7080703@sonic.net> References: <44BBEB9C.5090901@telus.net> <200607200902.27489.yann.chachkoff@myrealbox.com> <44C0680F.7080703@sonic.net> Message-ID: <200607221017.02921.yann.chachkoff@myrealbox.com> Le vendredi 21 juillet 2006 07:37, Mark Wedel a ?crit?: > Yann Chachkoff wrote: > The biggest danger is that given there are only a handful of servers, if > the first release of 2.0 (or whatever major version) has serious problems, > it might be hard convincing people to try 2.1, etc > Well, at least for the code side of things, it seems to me that a software that shows "serious problems" should not get released. Now, you could say that "there is no way to be sure that the server works before trying it"; I'd answer to this that (1) we developers are supposed to do at least some rough beta testing and (2) nothing prevents us to set a single beta-testing server clearly flagged as such to get player's feedback and spot what could have been missed during development. I'd also like to underline that other games suffered serious problems at times, but it wasn't hard to convince people to try the next step, provided that they initially found the game promising/fun/interesting enough. If we are not sure of this, then we may have a content problem that needs to be put on the table. > And if the changes break compatibility, that makes it even less likely > for servers to switch over. > As long as an old version will only get bugfixes, servers will switch over anyway, to have access to the new cool and shiny features. But again, the interest of the new stuff should be strong enough and, if we believe it may not, then we have a problem regarding the content of the game and our relationship towards the player side of the community: it would basically mean that we work without understanding what players need/want/await for. > I suppose it depends on how often we plan to do major releases. If only > every couple years, this can lead to other problems: > 1) To players/users, the project may appear dead (nothing new in the past > 12 months) > Sorry if I sound rude by saying this, but that's ridiculous. Since when a project that mostly releases revisions of a given version is considered 'dead' ? To take a simple example, PHP 4.0 was released in 2000, and PHP 5.0 'only' in 2004 - did people consider it a 'dead project' in the meantime ? Again, I am not saying we should provide "nothing new" - but simply not include "major changes". And I think there are plenty of smaller-scale stuff to keep us busy to provide minor releases anyway. > 2) To developers, less satisfaction making changes if no one > (outside perhaps a very limited set of developers) will see it for 12 > months > First, there are changes that can be introduced by each minor release. Second, major changes worth an upgrade of the major version number are likely to take a long time to complete, maybe months, so the "waiting time" is unlikely to be a problem - you cannot be upset that your code isn't used if you haven't even got enough time to finish it. > This can be solved by doing major releases every 6 months (or a year at > max) - but that then limits number of changes that can be done in each for > each major release. Which may not be a bad thing, but just a note. > Why would we ever need to base major releases on arbitrary dates ? That's a terrible idea, IMHO. Such changes should be based on the features first, and *then* on some kind of deadline to complete the work, not the reverse. > But last point is scope of changes - if major changes break > compatibility, you probably don't want to do them too often - players (and > server admins) probably don't want to have to start from scratch every 6 > months. > Sure. I was more thinking about a rather long cycle for majors - one every two years or so, possibly even longer. > That more or less matches what I said for the CVS branch. > > I guess if we're not really concerned about stability of major releases, > doing pre-releases isn't necessary. But given that major releases will > have much larger scale changes, I'd see that number of severity of bugs to > potentially be larger. > > Likewise, if the code isn't being used very much until it is released, it > means that a bug for a big change may not be discovered until a year after > that change is made. I know from my own developing perspective, I'd much > rather find bugs for code I do relatively shortly after I do the code, > because the code will be fresher in my mind than if I have to look back at > something I did 6 months ago. > Then simply open a public beta server using the last usable CVS code. There's no need to play with "pre-xxx" labels of any kind for that. > I suppose in short what I'm saying is it is really nice to have all code > actually exercised/used somewhat shortly after the code is written. > Yes, indeed. But that would also include some testing made by the developer(s) it(them)selves. Often, changes made in the CVS currently result in an unusable code because of gross errors that could have been avoided if the coder had spent ten more minutes to build, install and test his/her new addition. > At the same time, the number of changes in the stable branch will > probably be a lot less, so perhaps not as much an issue for servers to keep > up to date on that. > Not really - there could be several minor releases, each made with a relatively short lifecycle (in the order of two-three months, maybe) that could potentially include a lot of new stuff; the point is that during each major, no huge, breaking change could occur, so the evolution would be rather smooth for the server maintainers. They'd also benefit from having releases that would be more solid than they're now - we currently make no bugfixes outisde of the CVS itself, forcing them to use the potentially unstable CVS content to get the fixes. > Fair enough. But that model sounds more like 'everyone say what you plan > to do for the next major release by august 31st'. Everyone discussing > what to do is also good. People saying what they will do is needed. Yet > at the same time, I think some rough date has to be put out on when those > changes will be completed by. > Yes, but you cannot define the deadline for implementation before having a list of all changes to be done. > If changes are not done by the date, they > get pushed off to next major version (there is of course some wiggle room > here, but it isn't uncommon for other various things to happen in ones life > which limits the ability to do the work. If a month before the release the > person responsible for it says 'I haven't done much work, and I can't > continue', do we really put off the release for someone else to take over, > or just put it off? > It depends on the importance of the missing piece, and should be discussed on a case-by-case basis. It also depends on what's already done - if 50% of the work is complete, then it may worth delaying the release a little to complete it; if it is still at the design stage, then it may get dropped until the next major. > If you put it off, then the danger comes that someone takes it over, and > other developers, having completed there stuff, don't have anything to do, > so start the process for some other big changes. I suppose it can just be > a simple case of 'well, even though 2.0 isn't out yet, your change has to > wait to 3.0'. Dunno what is really the right answer for this. > Well, that's a teamwork/cooperation problem. I never suggested that each specific person should code one and only one part. If some developers have finished what they wanted to work on while others haven't, of course the free ones can jump and help on the remaining things. Having a clear definition of the tasks doesn't prevent one to have some flexibility. > > I was speaking about functional bugs ("Things don't work as expected"), > > not RFEs/whishlist (those I don't really consider as bugs, as they don't > > describe functional errors). > > but that can be a question that is also hard to answer. Looking at the > bug list on sourceforge, I would say that perhaps a third to a half of > those could be put in the not real bugs (enhancement requests). But other > people could say that they are bugs that really should be fixed. At some > level, it becomes a matter of of opinion. > At which level ? My definition is pretty clear: do the rules 'claim' that it should work like X, but in fact that works like Y ? Although there is of course a "gray zone", I think that it is pretty clear in most cases. In the case a controversy arises about a specific point, then we still have a mailing list to sort it out and, if necessary, a project leader that can ultimately take the decision if no concensus arises. > True - but at least for significant projects, proposals are supposed to > be sent to the mailing list. They are not necessarily copied to the wiki. > Sure. > Perhaps you could provide an example of such a document? From your > description, I have no real idea how detailed or not detailed you are > expecting it to be. > > But as a person who often has sent out e-mail describing changes I'm > planning on doing, it is often not uncommon to spend a lot more time > describing that, responding to e-mails, followups, etc, than doing that > actual work. Maybe that is to be expected, but at some level, not > something I want to spend a lot of time doing. > Well, that's part of teamworking. Coding is just the last part of the process - the design phase, which includes the various discussions, seems at least as important to me, if not more. > The flip side, and perhaps not really related, is need for people that > are sending out proposals to follow through and do the code, or at least > let us know that it isn't happening. But more than once, there have been > discussions about some new feature I think would be cool, and I take part > in those, and then never hear anything about it again. Certainly, someone > else could pick up those pieces and do that feature, but then you don't > necessarily know current status. > Yep - that's why I was suggesting that some document summarizing the project to be done on the basis of the discussion (probably as the discussion itself develops), so that somebody could quickly get all the infos needed on it without having to browse mailing list archives to pick up the pieces. It would also help gathering who is working on what, and thus monitor the status. > Maybe as part of this, there needs to be regular updates from the > developers about progress, just so it is known if someone disappears and > thus we need to find someone else to do it, or that project should be > written off, etc. > Yep. > Are you then saying there should be a stable 2-0-0, stable 2-1-0, etc? > Yes. I'm saying that we should have such minor stable releases, just as we currently do with 1.x. > The only reason I can see of doing that is if there are going to be micro > releases as well as minor releases (2.1.1 released after 2.2.0). > There would be. Suppose that we release a 'stable' 2.1.0 version, put into its own CVS branch. Now, somebody finds a couple bugs that we correct. We'd then update the released package, numbering it 2.1.1, so that people understand this is a fix of 2.1 rather than a version with new features. Note that CVS-wise, I do not suggest sub-branching 2.1 into 2.1.0, 2.1.1, etc; that's unnecessary overkill. > Given > that I'd expect mostly bugfixes in this stable branch, I don't see that > this is a very likely scenario (any bug fixed in 2.1.1 should also be in > the main stable branch - if there is need to get that fix out right away, > why not do a 2.2.1 then?) > First, of course a bug should get both in the stable branch it was first discovered and in the CVS head; second, why not do a 2.2 instead of releasing a "fixed 2.1" ? Well, precisely because it is just a fix, and not a new revision with new stuff in it, game enhancements, new maps, etc. > If there were significant changes in the minor releases, such that > running 2.2.0 might be considered risky, which is why you want a 2.1.1 > since it is in a better known state. But since I'm not expecting lots of > changes in this stable branch, that doesn't seem really likely. > I don't see why you wouldn't see "lots of changes" - You wouldn't see lots in each minor release branch for sure (only bugfixes); but you'd do in the main trunk, which is where all 2.x-related development would take place. > But this starts making things even more work intensive - if I make a > change to the main head branch for a bug fix, now there is the potential I > have to update the main stable branch as well as the micro branch for a > potential upcoming release? > As I said, I am not suggesting to do such micro-branches. Why would you need to ? Just put the bugfix both in the head and in the last minor revision branch (2.1, 2.2, etc). Then repackage the latest minor branch CVS and mark it with an increased revision number (I suppose that practically, we'd not want to repackage each time a bug is fixed - this could be done each time a critical bug has been fixed, or on a weekly basis, provided that stuff got fixed during the week). So in my proposal, you only have to fix things at two places: the last minor revision branch, and the head. I can see two likely cases that can happen: - Either a player finds a bug; then, the bug is first spotted in the last minor branch, and that's where the developer will fix it. Then, it will get fixed in the head, provided that it is still relevant; - Either the dev working on the head spots a bug there. Then, it is his/her responsability to immediately check if the bug exists in the latest stable release as well; then, fix in both. Note that in most cases, it shouldn't be a big overload of work, as the latest stable branch wouldn't be very far away from the head content. > Before going on that approach, I'd wait and see how much activity the > stable branch is really getting, and if in fact it is getting any > signficant changes other than bug fixes or other minor things. > Let's be clear: I'm not suggesting to create a "stable branch" opposed to an "unstable" one. I'm suggesting that the head is to be used as the basis of a regular branching to stable code (thus, if head contains 2.x code, it will produce 2.1, 2.2, etc stable branches). > > That's why I think branching on releases of a single major is a better > > idea, as they would be done on a shorter cycle (in the range of 3 to 6 > > months at most). > > Is that then saying a major release every 6 months or so? > No. As I said, major releases shouldn't happen often. On the other hand, minor releases should. 6 months seems way too short a cycle for majors IMHO. > But I personally don't want to have to main several different branches > and have to do updates to them whenever I make a change. > In my model, you'd only have to care about two: the head (of course), and the last stable branch for bugfixes. That's basically not asking more than "following" the last version released and support it - and I don't think supporting what we release during its life duration is too much asking (yes, I know, bug fixing is less fun than introducing new stuff - but that's part of the things that need to be done regardless if we like them or not). > Yes - that is a reasonable model. But I think the client needs to > hide/filter that. If I'm running client 2.5, it shouldn't show me server > version 1.9 when I can't play on it. Or likewise, it should show me server > version 2.7 when I may not be able to play on that also (but in that case, > it should perhaps print message saying it isn't the latest client and go > update) > I think that at first, we could simply show a warning dialog when the version doesn't match the accepted range. From mwedel at sonic.net Sat Jul 22 03:19:10 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 22 Jul 2006 01:19:10 -0700 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> <44BDCF94.9080400@telus.net> <44BF14D0.3060901@sonic.net> <44BF2AF0.4070403@telus.net> <44C06D5A.9010708@sonic.net> <44C07F18.2010706@telus.net> Message-ID: <44C1DF7E.6070206@sonic.net> Andrew Fuchs wrote: > On the community side, we need to encourage player interaction, both > in and out of the game. One way to boost in game interaction would be > bolstering the player economy. However, that will probably not be > done in time for cf2.0. For the community out of game, make it easier > to find resources like the forums, and the wiki. Some of this could be done by including notes/links to that in the client itself (perhaps in the about tab). I think most servers may report that info in the motd, but a lot of other info is also displayed at login time, so may not be obvious to everyone (one of those things that when you get shown a bunch of info at one time, becomes more common to just ignore it.) There is also nothing preventing server admins from changing the motd so that it doesn't contain that information. > Additionally, make > it easier to join irc channels, possibly by putting a java applet > somewhere. Not 100% sure about that - presumably most everyone playing will have some irc client available - we should probably make it more obvious (again) on pointing out that the irc channel exists. I personally don't think we want to write/maintain our own irc interface. There might be libraries to make it pretty easy, in which case doing it may not be that hard. But in that case, it should be a pretty specific interface (only connect to the crossfire channel, etc - don't get things too complicated by implementing a complete irc client). If a person is serious about using irc, they should be able (or probably already have) a fully featured irc client. > Another thing that could be done to aid the community, > both in-game and outside of the game, would be to setup a method to > connect to servers, just for the purpose of chatting with people who > are playing (oldsocketmode uses food iirc). IMO, oldsocketmode should just go away - part of the code cleanup. But a simple change for this would be if your on a savebed and not regaining sp/grace/hp, you don't use food. I don't think that would hurt balance and people could be logged in and never eat a bite but still take in conversations, etc. If you want to go out and trade items, whatever, then you would use some food. > Another topic of > communication between players, would be the inter-server chat > discussed a while ago. I think that falls into a major project - not as simple as one might thing - this needs to be properly thought out in many ways. > > From yann.chachkoff at myrealbox.com Sat Jul 22 03:37:42 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat, 22 Jul 2006 10:37:42 +0200 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: References: <44BBEB9C.5090901@telus.net> <44C07F18.2010706@telus.net> Message-ID: <200607221037.42791.yann.chachkoff@myrealbox.com> Le vendredi 21 juillet 2006 20:15, Andrew Fuchs a ?crit?: > What I'm inferring, and my op pinions: > > Summary: > > While 2.0 should be a significant release, the majority opinion is > that it should not take years. This makes it difficult to implement > what everyone wants, etc. > True. > I think 2.0 should be the point at which most issues that we have > known about, but haven't fixed, should be fixed. I'd get furthermore by saying that the last 1.x should be the point where most issues should be solved. And then, we can start making massive changes leading to the 2.0 version. > Additionally, the > game should be made easier to use (more graphical interfaces on the > client side instead of typing in commands constantly), > Yep - some proposals for the ergonomy of the client would be more than welcome. > Gaining developers: > Agree on all this, although gathering more devs is probably not the most important point ATM. > > Strengthening the community: > > On the community side, we need to encourage player interaction, both > in and out of the game. One way to boost in game interaction would be > bolstering the player economy. > I think that, before entering into such details, we should ask ourselves what is fun in the game and what isn't. And more important, as players what they find fun, and what they don't. I am also doubtful that changing game mechanisms is the top issue for a stronger community - rather, that's making the game attractive and fun, by proposing events in and around them. Many MMORPGs feature special events around their games (contests, one-time special quests, etc). I think that should be investigated for Crossfire. > However, that will probably not be done in time for cf2.0. > Indeed. But that's probably a good time to start thinking about that part, and try to produce a list of what should be done. > For the community out of game, make it easier to find resources like the > forums, and the wiki. Additionally, make > it easier to join irc channels, possibly by putting a java applet > somewhere. > Good idea. Probably make the Forum and Wiki more visible on the front page would also help. > Another thing that could be done to aid the community, > both in-game and outside of the game, would be to setup a method to > connect to servers, just for the purpose of chatting with people who > are playing (oldsocketmode uses food iirc). > Agree. > Another topic of communication between players, would be the inter-server > chat discussed a while ago. > Yep, although that's a little more complex issue to solve. Maybe bridges with the IRC could solve the issue. > My opinion on release numbers: > > Once we have more developers and enough are willing to volunteer, it > may be a good idea to appoint some people to maintain the stable > branches. > Maybe. Note that I don't think we should maintain several stable branches concurrently - only the last release made. I doubt we'd really need specific maintainers in such a scheme. > Micro releases: bug fixes, and addition of small features > Minor releases: Features involving significant changes > Major releases: Huge changes in game play, major overhauls, milestones > in development > I mostly agree with this. Just for the record, I think micro releases probably wont require any CVS branching. I'd put "small features" as "minor release" ones, though - else, we're taking the risk of a slide where most changes become considered as "micro release" ones to make them happen faster. > Finally, i just want to note that our next release could be 1.10.0 > instead of 2.0 if we need more time for cf2.0. > Quite probably. I think we should first fix all the remaining problems, release that as 1.10, and then work on that strong code basis to get a 2.0. From alex_sch at telus.net Sat Jul 22 11:10:56 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 22 Jul 2006 10:10:56 -0600 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44C1DB3E.5090305@sonic.net> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> <44BDCF94.9080400@telus.net> <44BF14D0.3060901@sonic.net> <44BF2AF0.4070403@telus.net> <44C06D5A.9010708@sonic.net> <44C07F18.2010706@telus.net> <44C1DB3E.5090305@sonic.net> Message-ID: <44C24E10.7040300@telus.net> Mark Wedel wrote: > Well, a major code restructure can't go into a minor release. Under the > proposed model, the only thing that comes from the main branch is major releases > - when a major release is done, then a new stable branch is set up where the > minor releases come from. > > Going back to the original issue is code drifting apart - if a major > restructure is done in the main branch, it makes fixing any bugs in both the > main and stable branch more difficult. > > It could just be we live with that difficulty. Or if a major restructure is > done shortly after a major release, still have to wait for the 6 months or > whatever. I don't really want to try to say 'major code restructures happen > near the end of the cycle' - I think if someone has the code ready and it is on > the list of things to do, it should be committed. > Agreed, I was just nitpicking about what would be the ideal circumstances, and if someone does have code ready right after a major release, it should indeed still be committed. Personally I think this difficulty would be perfectly fine to live with, provided that those who do the restructuring make sure they keep detailed logs of what functionality of the code moved where in the changelog (i.e. along the lines of "Moved weapon behavior from apply_ob() in item.c to type_weapon_apply() in types/weapons.c"), to make it easier to people to deal with. > > However, as per gros's comment, there needs to be sufficient changes between > the releases to warrant a major release. We probably don't want to do a new > major release if there are not any signficant changes - I suppose this may be a > matter of opinion, but if we go in this model, I think that sort of needs to be > the case, as otherwise we get into confusion at what each branch/release means. > > There can still certainly be major releases which don't break compatiblity in > any way but still hold other significant changes (new features, or changing of > existing features/expanding them). Agreed, I was just pointing out that even with major releases, we should think before breaking things, and if there is a reasonable way to get things done, without breaking, or without making the code messy, etc. then it should be considered. Alex Schultz From alex_sch at telus.net Sat Jul 22 11:28:19 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 22 Jul 2006 10:28:19 -0600 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> <44BDCF94.9080400@telus.net> <44BF14D0.3060901@sonic.net> <44BF2AF0.4070403@telus.net> <44C06D5A.9010708@sonic.net> <44C07F18.2010706@telus.net> Message-ID: <44C25223.7090506@telus.net> Andrew Fuchs wrote: > Finally, i just want to note that our next release could be 1.10.0 > instead of 2.0 if we need more time for cf2.0. And that is something I strongly believe should be the case. I personally do not believe that we are ready for 2.0 for a while (I'm thinking about 6 months or so if not a little more), and I believe in the meantime that we should do at least one release such as 1.10.0. However I believe the point of another release between 2.0 and now to gain more time, is fairly moot unless people can work on 2.0 in cvs starting fairly soon, hence, I believe that the best solution would be to create create a new cvs branch for working on 1.10.0, and then work on 2.0 things in the main branch. In terms of debate between making a branch for each major version, or each minor version, I personally don't have much preference on, but I feel that a branch of some sort is needed. Also, I believe the type of code restructure I mentioned a little earlier on the mailing list, should be something to target for 2.0, though I personally wait about a month to start work on it to allow people to get used to usage of the branches and possibly to apply pending patches that have been lying around for a while already. Alex Schultz From nicolas.weeger at laposte.net Sat Jul 22 13:25:14 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 22 Jul 2006 20:25:14 +0200 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <200607221037.42791.yann.chachkoff@myrealbox.com> References: <44BBEB9C.5090901@telus.net> <200607221037.42791.yann.chachkoff@myrealbox.com> Message-ID: <200607222025.14610.nicolas.weeger@laposte.net> > I am also doubtful that changing game mechanisms is the top issue for a > stronger community - rather, that's making the game attractive and fun, by > proposing events in and around them. Many MMORPGs feature special events > around their games (contests, one-time special quests, etc). I think that > should be investigated for Crossfire. We did that on Metalforge a few times, a few DMs. Drawbacks: * it takes time to plan * it takes time to actually eg put items, create stuff, and so on * it takes time to run, because people will connect to the game and want to play * it takes many people to handle everything * also note time zone issue, too But i'd be ready (and eager!) to help do some events from time to time. Just my 0.2? :) Nicolas From penbrock at penbrock.com Sat Jul 22 14:36:07 2006 From: penbrock at penbrock.com (Penbrock) Date: Sat, 22 Jul 2006 11:36:07 -0800 Subject: [crossfire] Server setup an Debian - newbie Message-ID: <44C27E27.7080603@penbrock.com> Good morning all. I have installed the server from the Debian apt-get and it installed fine, or so I thought. It seems that the .deb package does not install the plugins. Where can I find the doc's for an old fart just learning Linux to get the plugins compiled? From fuchs.andy at gmail.com Sat Jul 22 21:12:35 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 22 Jul 2006 22:12:35 -0400 Subject: [crossfire] Ideas to make DM quests easier to manage and setup, was Re: 2.0 release Message-ID: On 7/22/06, Nicolas Weeger (Laposte) wrote: > > I am also doubtful that changing game mechanisms is the top issue for a > > stronger community - rather, that's making the game attractive and fun, by > > proposing events in and around them. Many MMORPGs feature special events > > around their games (contests, one-time special quests, etc). I think that > > should be investigated for Crossfire. IMO, we need more of these. Adding some way for mappers to use the date to control events on their maps could have a somewhat similar effect, but would be less interesting to players. > We did that on Metalforge a few times, a few DMs. > > Drawbacks: > * it takes time to plan > * it takes time to actually eg put items, create stuff, and so on I don't have the time to do this, but would some semi-standardized quest types, and premade maps (containing objects requiring minimum modification, and/or a script to check player's status) to aid with those quests help? > * it takes time to run, because people will connect to the game and want to > play Possibly make the event last for a day or two, but that would make things harder to plan. > * it takes many people to handle everything Would some premade scripts to manage dm quests help? > * also note time zone issue, too Another reason to make events that last a few days. > But i'd be ready (and eager!) to help do some events from time to time. -- Andrew Fuchs From fuchs.andy at gmail.com Sat Jul 22 21:44:58 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 22 Jul 2006 22:44:58 -0400 Subject: [crossfire] Server setup an Debian - newbie In-Reply-To: <44C27E27.7080603@penbrock.com> References: <44C27E27.7080603@penbrock.com> Message-ID: On 7/22/06, Penbrock wrote: > Good morning all. I have installed the server from the Debian apt-get > and it installed fine, or so I thought. It seems that the .deb package > does not install the plugins. Weird, usually the plugins are includes with the server, and run by default. It could be that they where placed in another package, but I doubt that (only packages that look like they would logically include them are "crossfire-server" and "crossfire-common"). > Where can I find the doc's for an old fart just learning Linux to get > the plugins compiled? No such documentation exists AFAIK (plugins are application specific most of the time). Also I don't know of anywhere to get a individual plugin, except for the source code. So ultimately the easiest solution (for those who know how to) would probably be to compile the server from source. P.S.: Anyone want to get hold of the maintainer of the crossfire Debian packages, and see what he knows? -- Andrew Fuchs From fuchs.andy at gmail.com Sat Jul 22 22:13:56 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 22 Jul 2006 23:13:56 -0400 Subject: [crossfire] Server setup an Debian - newbie In-Reply-To: References: <44C27E27.7080603@penbrock.com> Message-ID: Ok, it seems like the package has been fixed, and is waiting to be uploaded to the debain servers/mirrors. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379348 -- Andrew Fuchs From penbrock at penbrock.com Sat Jul 22 23:32:23 2006 From: penbrock at penbrock.com (Penbrock) Date: Sat, 22 Jul 2006 20:32:23 -0800 Subject: [crossfire] Server setup an Debian - newbie In-Reply-To: References: <44C27E27.7080603@penbrock.com> Message-ID: <44C2FBD7.2000400@penbrock.com> Andrew Fuchs wrote: > Ok, it seems like the package has been fixed, and is waiting to be > uploaded to the debain servers/mirrors. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379348 > > I found the maintainer on IRC and he is fixing it. Thanks From mwedel at sonic.net Sun Jul 23 01:27:16 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 22 Jul 2006 23:27:16 -0700 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <200607221017.02921.yann.chachkoff@myrealbox.com> References: <44BBEB9C.5090901@telus.net> <200607200902.27489.yann.chachkoff@myrealbox.com> <44C0680F.7080703@sonic.net> <200607221017.02921.yann.chachkoff@myrealbox.com> Message-ID: <44C316C4.9050801@sonic.net> Yann Chachkoff wrote: > Le vendredi 21 juillet 2006 07:37, Mark Wedel a ?crit : > Now, you could say that "there is no way to be sure that the server works > before trying it"; I'd answer to this that (1) we developers are supposed to > do at least some rough beta testing and (2) nothing prevents us to set a > single beta-testing server clearly flagged as such to get player's feedback > and spot what could have been missed during development. I don't think any developers writes code with known bugs (at least I hope not). while some bugs are pretty obvious if good testing was done, some are less obvious (occur on specific map due to specific setting of flags on objects, etc), but can still be very severe. So I think it is fairly likely that with major changes being made, there will be some number of bugs. A beta server fixes this, presuming you can get enough players on the beta to test it. That's a big unknown at this point. >> At the same time, the number of changes in the stable branch will >> probably be a lot less, so perhaps not as much an issue for servers to keep >> up to date on that. >> > Not really - there could be several minor releases, each made with a > relatively short lifecycle (in the order of two-three months, maybe) that > could potentially include a lot of new stuff; the point is that during each > major, no huge, breaking change could occur, so the evolution would be rather > smooth for the server maintainers. They'd also benefit from having releases > that would be more solid than they're now - we currently make no bugfixes > outisde of the CVS itself, forcing them to use the potentially unstable CVS > content to get the fixes. Right - I don't think anyone right now is arguably against having the head be bleeding edge and aimed for the next major release and another (or multiple) stable branches. The question is what goes into the stable branch. By its nature, everything has to go into the head branch (presuming the change is still applicable). But the scope of changes for the minor releases in the stable branch probably shouldn't be too big. > Well, that's part of teamworking. Coding is just the last part of the > process - the design phase, which includes the various discussions, seems at > least as important to me, if not more. There have certainly been cases where things were put in without any such discussion, and I would have liked to have seen some. And the question also becomes what level of changes require design documents? Just the major feature? Any feature beyond some scope (which would need to be defined?) The danger can become that code is submitted/committed that should perhaps have a design document but there wasn't one. Suppose a patch is submitted without a design document? Do we just say 'no design document, do commit?' That may be the right thing to say, but also probably isn't going to make developers very happy. I do think design discussions should be done. But in doing so, I think some rules need to be formulated for when a document is or is not needed (and we have to be careful about code submissions - we don't necessarily want to reject them out of hand, but at the same time, we don't want to accept code that doesn't meet standards). I think also it may be best if all the major features go through design discussions even if there isn't anyone that is necessarily going to work on them. I know that for me personally, there are times when I am unexpectedly ready to do some coding. However, if it is going to take 2 weeks to get input from a design document I write tonight, then 2 weeks from I may not have the time or inclination. So there needs to be something that people can just pick up when ready. I usually try to get around this by putting things out for discussion even when I know I don't have time right now to work on them, on the basis that when I do have time, all discussion is done. Problem then is it can be a very long time before I ever get to it, and if enough time passes, original discussion may not be relevant. >> The only reason I can see of doing that is if there are going to be micro >> releases as well as minor releases (2.1.1 released after 2.2.0). >> > There would be. Suppose that we release a 'stable' 2.1.0 version, put into its > own CVS branch. Now, somebody finds a couple bugs that we correct. We'd then > update the released package, numbering it 2.1.1, so that people understand > this is a fix of 2.1 rather than a version with new features. > Note that CVS-wise, I do not suggest sub-branching 2.1 into 2.1.0, 2.1.1, etc; > that's unnecessary overkill. But then how do you cover the case like this: 2.1.0 released. someone puts back some signficant change to stable branch. critical bug is discovered, fix is made, but a 2.1.1 release is needed a week after 2.1.0 One can release 2.1.1 from the stable branch (just like I do now), but that would also include the significant change, which then confuses the numbering scheme (suppose that change is signficant enough that it would be enough by itself to bump the number up to 2.2.0) Do we just release 2.2.0? I suppose that is fine, but then maybe gets confusing if you release 2.2.0 a week after 2.1.0? > As I said, I am not suggesting to do such micro-branches. Why would you need > to ? Just put the bugfix both in the head and in the last minor revision > branch (2.1, 2.2, etc). Then repackage the latest minor branch CVS and mark > it with an increased revision number (I suppose that practically, we'd not > want to repackage each time a bug is fixed - this could be done each time a > critical bug has been fixed, or on a weekly basis, provided that stuff got > fixed during the week). > So in my proposal, you only have to fix things at two places: the last minor > revision branch, and the head. So it sounds like you have a branch for each minor release then? Where do those branches come from? I think that all the 2.x minor releases have to start from the same main head - 2.0.0. But I'm not sure that makes things easier - it seems then you get this situation: 2.0 release. branch for 2.1 is made based on 2.0 2.1 is released, branch for 2.2 made based on 2.0 This new branch now needs to be synchronized up for all the 2.1 changes. And changes for 2.1.1 will also need to be synced up. And so on for 2.3, 2.4, etc. That seems to make it more complicated than having a stable-2-x branch and then if necessary making a new branch for micro releases. I think also with what you suggest, the version numbering of files could get really confusing (and/or because of the merging, being able to do diffs and see what was specifically changed in a release becomes more difficult. I really don't want to have to have 3-4 different CVS trees around to be able to figure out exactly when something changed and what the code looked like before then. Maybe that isn't what you are suggesting, but from reading your e-mail, that seems to suggest how you are suggesting to do revisions. > I can see two likely cases that can happen: > - Either a player finds a bug; then, the bug is first spotted in the last > minor branch, and that's where the developer will fix it. Then, it will get > fixed in the head, provided that it is still relevant; > - Either the dev working on the head spots a bug there. Then, it is his/her > responsability to immediately check if the bug exists in the latest stable > release as well; then, fix in both. Yes - I agree that is the correct process. > Note that in most cases, it shouldn't be a big overload of work, as the latest > stable branch wouldn't be very far away from the head content. I don't see that being the case - if the head branch has been worked on for 1 year with numberous code re-orgs, I'd expect the stable branch (for say 2.5) to look quite different. Unless you are suggesting that minor releases are branched from the current head code, eg: 2.0 release. branch for 2.1 is made based on 2.0 2.1 is released, branch for 2.2 made based on current head code 2.2 is released, branch for 2.3 made based on current head code If that is the model, then that really isn't any different than what we do right now, which means by the time 3.0 is really released, it won't look that much different than the last previous minor release, since the code for that previous minor released was based on code pretty close to the 3.0 release code. I guess I'm just confused on what you are suggesting for how the minor releases are made/branched from. From mwedel at sonic.net Sun Jul 23 01:33:01 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 22 Jul 2006 23:33:01 -0700 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44C25223.7090506@telus.net> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> <44BDCF94.9080400@telus.net> <44BF14D0.3060901@sonic.net> <44BF2AF0.4070403@telus.net> <44C06D5A.9010708@sonic.net> <44C07F18.2010706@telus.net> <44C25223.7090506@telus.net> Message-ID: <44C3181D.4020509@sonic.net> Alex Schultz wrote: > Andrew Fuchs wrote: >> Finally, i just want to note that our next release could be 1.10.0 >> instead of 2.0 if we need more time for cf2.0. > And that is something I strongly believe should be the case. I > personally do not believe that we are ready for 2.0 for a while (I'm > thinking about 6 months or so if not a little more), and I believe in > the meantime that we should do at least one release such as 1.10.0. > However I believe the point of another release between 2.0 and now to > gain more time, is fairly moot unless people can work on 2.0 in cvs > starting fairly soon, hence, I believe that the best solution would be > to create create a new cvs branch for working on 1.10.0, and then work > on 2.0 things in the main branch. In terms of debate between making a > branch for each major version, or each minor version, I personally don't > have much preference on, but I feel that a branch of some sort is > needed. Also, I believe the type of code restructure I mentioned a > little earlier on the mailing list, should be something to target for > 2.0, though I personally wait about a month to start work on it to allow > people to get used to usage of the branches and possibly to apply > pending patches that have been lying around for a while already. Yes - a stable-1-x branch is needed. One question not directly addressed on all of this are the different cvs trees. server: pretty clear on major/stable branching client: probably same thing (should the model be followed with client release matching server release number? arch: Does this model make sense? I suppose in some sense because as changes are made, that may enable or change behaviour of archetypes. What about new archetypes that are release independent? maps: Basically same question applies are for arch. However, maps could be more a problem because patching/fixing maps could become very tedious. From alex_sch at telus.net Sun Jul 23 02:05:14 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 23 Jul 2006 01:05:14 -0600 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44C316C4.9050801@sonic.net> References: <44BBEB9C.5090901@telus.net> <200607200902.27489.yann.chachkoff@myrealbox.com> <44C0680F.7080703@sonic.net> <200607221017.02921.yann.chachkoff@myrealbox.com> <44C316C4.9050801@sonic.net> Message-ID: <44C31FAA.40701@telus.net> Mark Wedel wrote: > Right - I don't think anyone right now is arguably against having the head be > bleeding edge and aimed for the next major release and another (or multiple) > stable branches. > Agreed. > The question is what goes into the stable branch. By its nature, everything > has to go into the head branch (presuming the change is still applicable). But > the scope of changes for the minor releases in the stable branch probably > shouldn't be too big. > Personally, I think things to go into the stable branch, are of course things we want in minor releases, and in my opinion, that should be bugfixes, and features that are not large/extensive. Of course, then the difficulty is in defining how large or extensive makes it worth putting in for the next major release, and that I believe needs to be decided in a case-by-case basis. > I think also it may be best if all the major features go through design > discussions even if there isn't anyone that is necessarily going to work on them. > > I know that for me personally, there are times when I am unexpectedly ready to > do some coding. However, if it is going to take 2 weeks to get input from a > design document I write tonight, then 2 weeks from I may not have the time or > inclination. So there needs to be something that people can just pick up when > ready. > Many discussions on the mailing list are already ones where there isn't necessarily anyone going to work on them :P > 2.0 release. > branch for 2.1 is made based on 2.0 > 2.1 is released, branch for 2.2 made based on current head code > 2.2 is released, branch for 2.3 made based on current head code > > If that is the model, then that really isn't any different than what we do > right now, which means by the time 3.0 is really released, it won't look that > much different than the last previous minor release, since the code for that > previous minor released was based on code pretty close to the 3.0 release code. > Personally I would rather dislike that setup, though I don't believe that is what he is trying to say. What I think he is trying to say is more like: 2.0 release. branch for 2.1 is made based on 2.0 2.1 is release, branch for 2.2 made based on 2.1 2.2 is release, branch for 2.3 made based on 2.2 That said, I don't see how that would end up much different from just a branch for each major release, unless we plan on providing bugfix releases for older releases, which I personally don't see a need to do. Alex Schultz From alex_sch at telus.net Sun Jul 23 02:15:02 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 23 Jul 2006 01:15:02 -0600 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44C3181D.4020509@sonic.net> References: <44BBEB9C.5090901@telus.net> <200607181943.34223.nicolas.weeger@laposte.net> <44BDBA11.1030500@sonic.net> <44BDCF94.9080400@telus.net> <44BF14D0.3060901@sonic.net> <44BF2AF0.4070403@telus.net> <44C06D5A.9010708@sonic.net> <44C07F18.2010706@telus.net> <44C25223.7090506@telus.net> <44C3181D.4020509@sonic.net> Message-ID: <44C321F6.9060301@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> Andrew Fuchs wrote: >> >>> Finally, i just want to note that our next release could be 1.10.0 >>> instead of 2.0 if we need more time for cf2.0. >>> >> And that is something I strongly believe should be the case. I >> personally do not believe that we are ready for 2.0 for a while (I'm >> thinking about 6 months or so if not a little more), and I believe in >> the meantime that we should do at least one release such as 1.10.0. >> However I believe the point of another release between 2.0 and now to >> gain more time, is fairly moot unless people can work on 2.0 in cvs >> starting fairly soon, hence, I believe that the best solution would be >> to create create a new cvs branch for working on 1.10.0, and then work >> on 2.0 things in the main branch. In terms of debate between making a >> branch for each major version, or each minor version, I personally don't >> have much preference on, but I feel that a branch of some sort is >> needed. Also, I believe the type of code restructure I mentioned a >> little earlier on the mailing list, should be something to target for >> 2.0, though I personally wait about a month to start work on it to allow >> people to get used to usage of the branches and possibly to apply >> pending patches that have been lying around for a while already. >> > > Yes - a stable-1-x branch is needed. > > One question not directly addressed on all of this are the different cvs trees. > > server: pretty clear on major/stable branching > > client: probably same thing (should the model be followed with client release > matching server release number? > Personally, I think the major and minor version numbers should match, but the micro should be independent, so long as we are releasing the server and client at the same time still, and personally I think we should continue doing that unless someone has a reason that separate releases would be worthwhile. > arch: Does this model make sense? I suppose in some sense because as changes > are made, that may enable or change behaviour of archetypes. What about new > archetypes that are release independent? > > maps: Basically same question applies are for arch. However, maps could be more > a problem because patching/fixing maps could become very tedious. Well, one issue is that changes in the server that might break the arch format (i.e. separation of multi-meaning attributes), which could cause problems unless we also create arch branches. The same also goes for maps, despite the difficulties in patching/fixing maps. The alternative though to separate branches, would be providing a conversion utility for maps and arches, as map/arch breakage is often easily convertible, with the server. Then apply that to cvs only when the major release making that breakage, is released. I'm not sure which of the options of branches, and conversion utilities, I prefer, however I believe that one of the two would be needed. Alex Schultz From rbrockway at opentrend.net Sun Jul 23 06:15:11 2006 From: rbrockway at opentrend.net (Robert Brockway) Date: Sun, 23 Jul 2006 07:15:11 -0400 (EDT) Subject: [crossfire] Server setup an Debian - newbie In-Reply-To: <44C27E27.7080603@penbrock.com> References: <44C27E27.7080603@penbrock.com> Message-ID: On Sat, 22 Jul 2006, Penbrock wrote: > Good morning all. I have installed the server from the Debian apt-get > and it installed fine, or so I thought. It seems that the .deb package > does not install the plugins. > Where can I find the doc's for an old fart just learning Linux to get > the plugins compiled? Hi Penbrock, I'm a Debian user/admin from way back. Debian is known for stability and robustness but not for having the latest packages. The Crossfire server in Debian is way behind the current stable release. As much as I think Debian rocks I've never used the Crossfire server built into Debian. I always compile from source. I think the Crossfire package in Debian would be fine for someone seeing if they like the game but once you get into it I highly recommend building from the latest stable source tree. Cheers, Rob -- Robert Brockway B.Sc. Phone: +1-905-821-2327 Senior Technical Consultant Urgent Support: +1-416-669-3073 OpenTrend Solutions Ltd Email: support at opentrend.net Web: www.opentrend.net We are open 24x365 for technical support. Call us in a crisis. If you are emailing regarding an open ticket please consider mentioning the ticket ID as this will assist us in responding as quickly as possible. From yann.chachkoff at myrealbox.com Sun Jul 23 10:03:24 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun, 23 Jul 2006 17:03:24 +0200 Subject: [crossfire] Server setup an Debian - newbie Message-ID: <1153667004.c7d7c33cyann.chachkoff@myrealbox.com> > I'm a Debian user/admin from way back. Debian is known for stability and robustness but not for having the latest packages. The Crossfire server in Debian is way behind the current stable release. You must be joking, I suppose ? Although Debian Sarge - the "stable" branch of the Debian distribution - is indeed out of date (which is somewhat logical), Debian testing and unstable both have Crossfire 1.9.1, which is the latest release of it. Answer to the initial question: The lack of plugins in the Debian package of Crossfire is documented as bug #379348, and has been solved by the package manager (just give it a couple of days for the new package to spread and become available in the repositories). Unless you are (1) using Debian Stable or (2) cannot wait a couple days more, you wouldn't need to worry about compiling stuff yourself. In case you really want to compile it yourself anyway, note that building the Python plugin will require the python-dev package to be installed before you use the configure script shipped with the Crossfire sources. To get the sources, you can do an "apt-get source crossfire-server", then cd into the directory created and do a "./configure; make; make install". I also suggest first removing the installed Debian package, to avoid clashes between both. From alex_sch at telus.net Sun Jul 23 10:23:48 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 23 Jul 2006 09:23:48 -0600 Subject: [crossfire] Server setup an Debian - newbie In-Reply-To: References: <44C27E27.7080603@penbrock.com> Message-ID: <44C39484.1050202@telus.net> Robert Brockway wrote: > I'm a Debian user/admin from way back. Debian is known for stability and > robustness but not for having the latest packages. The Crossfire server > in Debian is way behind the current stable release. > > As much as I think Debian rocks I've never used the Crossfire server built > into Debian. I always compile from source. I think the Crossfire package > in Debian would be fine for someone seeing if they like the game but once > you get into it I highly recommend building from the latest stable source > tree. > Actually, debian testing currently has the latest crossfire release (though at the second the package is broken due to a mistake by the package maintainer). Alex Schultz From penbrock at penbrock.com Sun Jul 23 13:57:53 2006 From: penbrock at penbrock.com (Penbrock) Date: Sun, 23 Jul 2006 10:57:53 -0800 Subject: [crossfire] Server setup an Debian - newbie In-Reply-To: <1153667004.c7d7c33cyann.chachkoff@myrealbox.com> References: <1153667004.c7d7c33cyann.chachkoff@myrealbox.com> Message-ID: <44C3C6B1.3020100@penbrock.com> Yann Chachkoff wrote: > You must be joking, I suppose ? Although Debian Sarge - the "stable" branch of the Debian distribution - is indeed out of date (which is somewhat logical), Debian testing and unstable both have Crossfire 1.9.1, which is the latest release of it. > > Answer to the initial question: > > The lack of plugins in the Debian package of Crossfire is documented as bug #379348, and has been solved by the package manager (just give it a couple of days for the new package to spread and become available in the repositories). > > Unless you are (1) using Debian Stable or (2) cannot wait a couple days more, you wouldn't need to worry about compiling stuff yourself. > > In case you really want to compile it yourself anyway, note that building the Python plugin will require the python-dev package to be installed before you use the configure script shipped with the Crossfire sources. To get the sources, you can do an "apt-get source crossfire-server", then cd into the directory created and do a "./configure; make; make install". I also suggest first removing the installed Debian package, to avoid clashes between both. > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > I can wait, I did find the the person who maintains the package when I was asking in the IRC room and he said he would have it fixed. He also told me about sending the reportbug. I was thinking that "plugins" where extras . I sure am happy to find out that the debian package will install everything. That is why I picked Debian for my first venture in to Linux, it sure makes it easy in add/update programs. I do have one other issue now. I have one player I use just for DM. How ever when I log him off the server crashes every time and I have to go restart it. Is there an easy was to delete that one? I tried to just quit the player but it does not delete it. From fuchs.andy at gmail.com Sun Jul 23 14:25:35 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun, 23 Jul 2006 15:25:35 -0400 Subject: [crossfire] Deleting DM players, wasRe: Server setup an Debian - newbie Message-ID: On 7/23/06, Penbrock wrote: ... > I do have one other issue now. I have one player I use just for DM. How > ever when I log him off the server crashes every time and I have to go > restart it. Is there an easy was to delete that one? I tried to just > quit the player but it does not delete it. This is how I would normaly do it on my machine: Erase the player's name off of the dm list if it is on there (should be somewhere in /etc/crossfire/ or /etc/games/crossfire or something like that). Then delete the player's directory (should be in /var/crossfire/players/ or /var/games/crossfire/players, etc). I have no idea why its crashing, exept possibly some library or something that wasn't installed just like the plugins. Also I want to note that there are some scripts included with the source code that automaticly restart the server after it crashes (along with dumping it's core, and doing a traceback). -- Andrew Fuchs From rbrockway at opentrend.net Sun Jul 23 15:09:39 2006 From: rbrockway at opentrend.net (Robert Brockway) Date: Sun, 23 Jul 2006 16:09:39 -0400 (EDT) Subject: [crossfire] Server setup an Debian - newbie In-Reply-To: <44C39484.1050202@telus.net> References: <44C27E27.7080603@penbrock.com> <44C39484.1050202@telus.net> Message-ID: On Sun, 23 Jul 2006, Alex Schultz wrote: > Actually, debian testing currently has the latest crossfire release > (though at the second the package is broken due to a mistake by the > package maintainer). Hi Alex. I was referring to Debian Stable, which is what I always mean when I say Debian without further qualification. I avoid relying on any pre-production distro, even for getting a games fix. Cheers, Rob -- Robert Brockway B.Sc. Phone: +1-905-821-2327 Senior Technical Consultant Urgent Support: +1-416-669-3073 OpenTrend Solutions Ltd Email: support at opentrend.net Web: www.opentrend.net We are open 24x365 for technical support. Call us in a crisis. If you are emailing regarding an open ticket please consider mentioning the ticket ID as this will assist us in responding as quickly as possible. From rbrockway at opentrend.net Sun Jul 23 15:12:14 2006 From: rbrockway at opentrend.net (Robert Brockway) Date: Sun, 23 Jul 2006 16:12:14 -0400 (EDT) Subject: [crossfire] Server setup an Debian - newbie In-Reply-To: <1153667004.c7d7c33cyann.chachkoff@myrealbox.com> References: <1153667004.c7d7c33cyann.chachkoff@myrealbox.com> Message-ID: On Sun, 23 Jul 2006, Yann Chachkoff wrote: >> I'm a Debian user/admin from way back. Debian is known for stability >> and robustness but not for having the latest packages. The Crossfire >> server in Debian is way behind the current stable release. > > You must be joking, I suppose ? Although Debian Sarge - the "stable" > branch of the Debian distribution - is indeed out of date (which is > somewhat logical), Debian testing and unstable both have Crossfire > 1.9.1, which is the latest release of it. No not joking. The fact I mentioned "stability" and "robustness" should give a clue I was talking about the Stable branch rather than the Testing or Unstable branch :) It does seem that while I interpret the term "Debian" to refer to "Debian Stable" a lot of others do not, so I'll certainly be qualifying this from now on. Rob -- Robert Brockway B.Sc. Phone: +1-905-821-2327 Senior Technical Consultant Urgent Support: +1-416-669-3073 OpenTrend Solutions Ltd Email: support at opentrend.net Web: www.opentrend.net We are open 24x365 for technical support. Call us in a crisis. If you are emailing regarding an open ticket please consider mentioning the ticket ID as this will assist us in responding as quickly as possible. From mwedel at sonic.net Sun Jul 23 22:07:13 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 23 Jul 2006 20:07:13 -0700 Subject: [crossfire] 2.0 release, was Re: Code restructuring In-Reply-To: <44C31FAA.40701@telus.net> References: <44BBEB9C.5090901@telus.net> <200607200902.27489.yann.chachkoff@myrealbox.com> <44C0680F.7080703@sonic.net> <200607221017.02921.yann.chachkoff@myrealbox.com> <44C316C4.9050801@sonic.net> <44C31FAA.40701@telus.net> Message-ID: <44C43961.604@sonic.net> Alex Schultz wrote: >> The question is what goes into the stable branch. By its nature, everything >> has to go into the head branch (presuming the change is still applicable). But >> the scope of changes for the minor releases in the stable branch probably >> shouldn't be too big. >> > Personally, I think things to go into the stable branch, are of course > things we want in minor releases, and in my opinion, that should be > bugfixes, and features that are not large/extensive. Of course, then the > difficulty is in defining how large or extensive makes it worth putting > in for the next major release, and that I believe needs to be decided in > a case-by-case basis. And trying to define what large of extensive may need some clarification. Some of it may just really boil down to what the developer doing the fix in the head wants to do, unless we put requirements that features within some scope must also be in the stable release. For example, I go off and add some new feature to the head branch, but because I'm lazy, don't put it in the stable branch. Thus that feature is only in the head. someone else could port over that change to the stable release if they really want it. However, as I think about, you probably want these features in the stable branch just so they get more use (and thus may find the bugs that can then be fixed in the head branch). But even that can be error prone - I make some minor enhancement which seems like it would be fine for the stable release, but it actually makes use of some new feature not found in the stable release, so that feature then also has to get ported over, etc. This probably isn't an issue, but when we are talking about doing major things to the head release, may not be as uncommon (looking back at the 1.x releases, think about things like the skill/spell redo and key/value lists - there are many minor changes that have been made since that code was committed that requires it). > Personally I would rather dislike that setup, though I don't believe > that is what he is trying to say. What I think he is trying to say is > more like: > > 2.0 release. > branch for 2.1 is made based on 2.0 > 2.1 is release, branch for 2.2 made based on 2.1 > 2.2 is release, branch for 2.3 made based on 2.2 > > That said, I don't see how that would end up much different from just a > branch for each major release, unless we plan on providing bugfix > releases for older releases, which I personally don't see a need to do. Even if we are providing bug fixes, I think it would still be better to branch the stable release for those micro releases then branch the stable for each minor. The other problem with the above scheme is you start getting crazy version numbers in files, as each time you do a branch, if you commit/change a file, you get a couple more decimals placed. So under that scheme, by the time you get to 2.9, you could have files with versions like '1.9.2.5.2.7.1.12.2.23.1.6.2'. I think it is much better, and much more common practice for branches to be based on the smaller pieces, and the main branch/head to be where most of the changes are being made. From penbrock at penbrock.com Fri Jul 28 17:55:14 2006 From: penbrock at penbrock.com (Penbrock) Date: Fri, 28 Jul 2006 14:55:14 -0800 Subject: [crossfire] Server crash issue Message-ID: <44CA95D2.2050400@penbrock.com> I have found an issue with the server and jcrossclient-1.0alpha4.jar. If someone runs the JAR, selects a server and connects but close out without entering a login name the server crashes. Is this just me? From nicolas.weeger at laposte.net Sat Jul 29 05:32:15 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 29 Jul 2006 12:32:15 +0200 Subject: [crossfire] Some pending patches on tracker Message-ID: <200607291232.15517.nicolas.weeger@laposte.net> Hello. Here are some patches i'd like opinions on: ------------------------------------- https://sourceforge.net/tracker/index.php?func=detail&aid=1389033&group_id=13833&atid=313833 New coins. I see no reason to not commit'em, it makes it easier to carry money :) ------------------------------------ https://sourceforge.net/tracker/index.php?func=detail&aid=1428566&group_id=13833&atid=313833 new face for booze. Looks ok to me, though maybe we want items to be seen from left/horizontally, instead of top-down like monsters? ------------------------------------ https://sourceforge.net/tracker/index.php?func=detail&aid=1389432&group_id=13833&atid=313833 per-race hall of selection I like the idea, and think it should be committed (note that patch doesn't work, conflict in main.c, but shouldn't be hard to fix) ----------------------------------- https://sourceforge.net/tracker/index.php?func=detail&aid=1497089&group_id=13833&atid=313833 fix for some random items Indeed a weapon from Gaea is kind of weird :) ---------------------------------- https://sourceforge.net/tracker/index.php?func=detail&aid=1526745&group_id=13833&atid=313833 new serpentman images They look much better than the ones we got, i'm for'em!! ---------------------------------- https://sourceforge.net/tracker/index.php?func=detail&aid=1073461&group_id=13833&atid=313833 pshop floor2 Now that's an old one, but should be committed imo ----------------------------------- https://sourceforge.net/tracker/index.php?func=detail&aid=1216811&group_id=13833&atid=313833 send more detailed information to client It's broken apparently Also there was no consensus on whether we do want to send more information to client or not --------------------------------- https://sourceforge.net/tracker/index.php?func=detail&aid=1382884&group_id=13833&atid=313833 changes to wraith race Anyone tried it, and noticed any unwanted effect? --------------------------------- https://sourceforge.net/tracker/index.php?func=detail&aid=1424583&group_id=13833&atid=313833 ipv6 support Anyone have issues with that still? Nicolas From wim-cf at villerius.nl Sat Jul 29 07:51:18 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Sat, 29 Jul 2006 14:51:18 +0200 Subject: [crossfire] blasphemy, vulgarities etc. Message-ID: <1154177478.14625.8.camel@localhost.localdomain> Just a simple question. What's the 'official' standpoint of the game (or rather: the devs) on blasphemy, vulgarities etc. in the game (especially maps - I'm not much concerned about code documentation, since users usually don't interact with that, though I think code should be subjected to the same guidelines) From wim-cf at villerius.nl Sat Jul 29 07:49:35 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Sat, 29 Jul 2006 14:49:35 +0200 Subject: [crossfire] Some pending patches on tracker In-Reply-To: <200607291232.15517.nicolas.weeger@laposte.net> References: <200607291232.15517.nicolas.weeger@laposte.net> Message-ID: <1154177375.14625.7.camel@localhost.localdomain> > Here are some patches i'd like opinions on: > ----------------------------------- > https://sourceforge.net/tracker/index.php?func=detail&aid=1497089&group_id=13833&atid=313833 > fix for some random items > > Indeed a weapon from Gaea is kind of weird :) Well, some comment (as I wrote on SF as well) Removing of these items will break some alchemy recipes (namely scale mail and dragon scale mail of Ruggilli) Simply removing these items will introduce new bugs - the object definitions are needed for some alchemy formulae. (I wonder what would happen if the objects are removed but not the formulae...) So either both formulae and random items should be removed, or they should both be renamed. Suggestion: Weapon of Gaea --> Weapon of Vitality Armour of Ruggilli --> Armour of Heat Resistance From fuchs.andy at gmail.com Sat Jul 29 16:28:11 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 29 Jul 2006 17:28:11 -0400 Subject: [crossfire] blasphemy, vulgarities etc. In-Reply-To: <1154177478.14625.8.camel@localhost.localdomain> References: <1154177478.14625.8.camel@localhost.localdomain> Message-ID: On 7/29/06, Wim Villerius wrote: > Just a simple question. What's the 'official' standpoint of the game (or > rather: the devs) on blasphemy, vulgarities etc. in the game > (especially maps - I'm not much concerned about code documentation, > since users usually don't interact with that, though I think code should > be subjected to the same guidelines) AFAIK, there is no known standpoint here, except a low tolerance of trolls, and a low tolerance of other's political agendas that most developers oppose (in the case of mikeeusa). So to come to a conclusion, this has to be discussed, and/or previous cases investigated. Stuff most devs seem to agree with: - kids play the game - no/minimal anti women's rights material allowed in the game (see mikeeusa) - the "14 year old wife" in mlab was questionably offensive, inappropriate for the game - this game is international (a few people in china play it) -- Andrew Fuchs From alex_sch at telus.net Sat Jul 29 16:54:37 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 29 Jul 2006 15:54:37 -0600 Subject: [crossfire] blasphemy, vulgarities etc. In-Reply-To: References: <1154177478.14625.8.camel@localhost.localdomain> Message-ID: <44CBD91D.60108@telus.net> Andrew Fuchs wrote: > - no/minimal anti women's rights material allowed in the game (see mikeeusa) > - the "14 year old wife" in mlab was questionably offensive, > inappropriate for the game One note on that, not just anti-woman's-rights content, but things likely to offend a group in general. Also, IMHO there should be a bit of leeway for cultures in the crossfire world to have customs that wouldn't be considered acceptable in the real world. I would personally consider it fine for a culture in the crossfire world to use slave labor, however I would not consider it fine if map content tried to tell the player that slave labor is morally right. That said, that is just my opinion on the topic. Alex Schultz From mwedel at sonic.net Sun Jul 30 00:44:33 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 29 Jul 2006 22:44:33 -0700 Subject: [crossfire] Some pending patches on tracker In-Reply-To: <200607291232.15517.nicolas.weeger@laposte.net> References: <200607291232.15517.nicolas.weeger@laposte.net> Message-ID: <44CC4741.9080800@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > https://sourceforge.net/tracker/index.php?func=detail&aid=1428566&group_id=13833&atid=313833 > new face for booze. > > Looks ok to me, though maybe we want items to be seen from left/horizontally, > instead of top-down like monsters? Like most things, this can be a matter of opinion. I do think that generally objects that players pick up should be given more a left/direct on view (not slanted). I think that matches how most other pickable objects are done (armor, potions, etc). > https://sourceforge.net/tracker/index.php?func=detail&aid=1526745&group_id=13833&atid=313833 > new serpentman images > > They look much better than the ones we got, i'm for'em!! Looks fine to me. > https://sourceforge.net/tracker/index.php?func=detail&aid=1216811&group_id=13833&atid=313833 > send more detailed information to client > > It's broken apparently > Also there was no consensus on whether we do want to send more information to > client or not Given it is broken and unclear if such a change is a good thing, I'd be inclined to just close it out. > > --------------------------------- > https://sourceforge.net/tracker/index.php?func=detail&aid=1382884&group_id=13833&atid=313833 > changes to wraith race > > Anyone tried it, and noticed any unwanted effect? Wonder if anyone tried it out. Given it changes existing wraith players to some extent (although it appears not really in an incompatible way) change should be carefully considered (and/or going with the recent discussion on different trees, only go in the tree for next major release, once that is set up.) > > --------------------------------- > https://sourceforge.net/tracker/index.php?func=detail&aid=1424583&group_id=13833&atid=313833 > ipv6 support > > Anyone have issues with that still? I wonder how many people are using ipv6 so this may not be something that is tested/used a lot? Still good to have. Wonder if metaserver (or an ipv6 metaserver) change would be needed also. From mwedel at sonic.net Sun Jul 30 00:52:36 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 29 Jul 2006 22:52:36 -0700 Subject: [crossfire] blasphemy, vulgarities etc. In-Reply-To: <44CBD91D.60108@telus.net> References: <1154177478.14625.8.camel@localhost.localdomain> <44CBD91D.60108@telus.net> Message-ID: <44CC4924.2030203@sonic.net> Alex Schultz wrote: > Andrew Fuchs wrote: >> - no/minimal anti women's rights material allowed in the game (see mikeeusa) >> - the "14 year old wife" in mlab was questionably offensive, >> inappropriate for the game > One note on that, not just anti-woman's-rights content, but things > likely to offend a group in general. Also, IMHO there should be a bit of > leeway for cultures in the crossfire world to have customs that wouldn't > be considered acceptable in the real world. I would personally consider > it fine for a culture in the crossfire world to use slave labor, however > I would not consider it fine if map content tried to tell the player > that slave labor is morally right. > That said, that is just my opinion on the topic. This is of course a complicated issue, because what is offensive varies. IIRC, there are some maps out there that have naked dancing girls. Should some minimum amount of clothing be put on them? And in the case of slave labor, while that itself could be fine, it would probably be questionable if the slaves were black people or something. That said, quick rundown of thoughts: - Offensive language/words should not be used. There are not many words that fall into this category anymore. - Political statements should not be made (this definition could be pretty hard to really define). - Using american MPAA rules, game probably shouldn't be any worse than PG-13, so explicit sexual conduct would probably be out (prostitution, etc). However, probably be best way is if someone finds something offensive, they report it and we discuss it to consider if it is appropriate or not. From lalo.martins at gmail.com Sun Jul 30 12:01:09 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 31 Jul 2006 01:01:09 +0800 Subject: [crossfire] Some pending patches on tracker References: <200607291232.15517.nicolas.weeger@laposte.net> Message-ID: On Sat, 29 Jul 2006 12:32:15 +0200, Nicolas Weeger (Laposte) wrote: > https://sourceforge.net/tracker/index.php?func=detail&aid=1389033&group_id=13833&atid=313833 > New coins. > > I see no reason to not commit'em, it makes it easier to carry money :) eh, funny... we had a long discussion when that came up, and even I kind of gave up on them myself :-P The archetypes are actually already committed, I believe... the changes in the patch are what makes them actually work though (without the patch, putting one such coin in the game will cause very ugly breakage) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From fuchs.andy at gmail.com Sun Jul 30 21:43:19 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun, 30 Jul 2006 22:43:19 -0400 Subject: [crossfire] Some pending patches on tracker In-Reply-To: <200607291232.15517.nicolas.weeger@laposte.net> References: <200607291232.15517.nicolas.weeger@laposte.net> Message-ID: On 7/29/06, Nicolas Weeger (Laposte) wrote: > Hello. > > Here are some patches i'd like opinions on: > > ------------------------------------- > https://sourceforge.net/tracker/index.php?func=detail&aid=1389033&group_id=13833&atid=313833 > New coins. > > I see no reason to not commit'em, it makes it easier to carry money :) The new coins where not meant to be given out by stores as change (except possibly if the store is very rich), which happens with this patch. Before the new coins can be used someone has to modify the code so the new coins are not normaly given out by stores. > ------------------------------------ > https://sourceforge.net/tracker/index.php?func=detail&aid=1428566&group_id=13833&atid=313833 > new face for booze. > > Looks ok to me, though maybe we want items to be seen from left/horizontally, > instead of top-down like monsters? Items with a top-down perspective look good in the inventory, but look a bit weird IMO on the map. > ------------------------------------ > https://sourceforge.net/tracker/index.php?func=detail&aid=1389432&group_id=13833&atid=313833 > per-race hall of selection > > I like the idea, and think it should be committed (note that patch doesn't > work, conflict in main.c, but shouldn't be hard to fix) I'd say commit it, then somebody design the halls. > ----------------------------------- > https://sourceforge.net/tracker/index.php?func=detail&aid=1497089&group_id=13833&atid=313833 > fix for some random items > > Indeed a weapon from Gaea is kind of weird :) I say commit. Gaea is supposed to be peaceful, and AFAIK there is no role playing background to this. For the alchemy recipes that reference the items removed from the game, change it to some other comparable item. > ---------------------------------- > https://sourceforge.net/tracker/index.php?func=detail&aid=1526745&group_id=13833&atid=313833 > new serpentman images > > They look much better than the ones we got, i'm for'em!! I would commit. > ---------------------------------- > https://sourceforge.net/tracker/index.php?func=detail&aid=1073461&group_id=13833&atid=313833 > pshop floor2 > > Now that's an old one, but should be committed imo The original mapper has some plans for floor2 (an actual shop), so I wouldn't commit this. Instead, set it to either pending or closed. > ----------------------------------- > https://sourceforge.net/tracker/index.php?func=detail&aid=1216811&group_id=13833&atid=313833 > send more detailed information to client > > It's broken apparently > Also there was no consensus on whether we do want to send more information to > client or not This would make scripting, and bots (except for implementing the protocol) a bit easier. Otherwise it makes the protocol more complex. > --------------------------------- > https://sourceforge.net/tracker/index.php?func=detail&aid=1382884&group_id=13833&atid=313833 > changes to wraith race > > Anyone tried it, and noticed any unwanted effect? I think this was still under debate. Looks fine to me though, but it may upset some existing players. Also make sure that the player description is changed for wraiths, so the new features are noted. ... -- Andrew Fuchs From mwedel at sonic.net Mon Jul 31 00:38:44 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 30 Jul 2006 22:38:44 -0700 Subject: [crossfire] Some pending patches on tracker In-Reply-To: References: <200607291232.15517.nicolas.weeger@laposte.net> Message-ID: <44CD9764.3060706@sonic.net> Andrew Fuchs wrote: > On 7/29/06, Nicolas Weeger (Laposte) wrote: >> Hello. >> >> Here are some patches i'd like opinions on: >> >> ------------------------------------- >> https://sourceforge.net/tracker/index.php?func=detail&aid=1389033&group_id=13833&atid=313833 >> New coins. >> >> I see no reason to not commit'em, it makes it easier to carry money :) > > The new coins where not meant to be given out by stores as change > (except possibly if the store is very rich), which happens with this > patch. Before the new coins can be used someone has to modify the > code so the new coins are not normaly given out by stores. I wonder if this could be added as a new attribute to the map header, like the shopitems stuff? Something like max_denomination or the like (and if that isn't set, keep the current setting of platinum/gold/silver). A question could be whether that should control both what currency it takes and what it gives out. A shop that generally deals in cheap stuff could be seen not to stock large coins, and thus won't give them out. It could also be extrapolated that cheap shops won't have change on hand to make large amounts of change. OTOH, we probably do want to be careful not to overly complicate things - if I'm buying something from a shop and only have jade coins, it would be annoying (eg, not fun) to have to leave the shop to go to the bank to get change, go back to the shop, etc. From lalo.martins at gmail.com Mon Jul 31 08:10:37 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 31 Jul 2006 21:10:37 +0800 Subject: [crossfire] Some pending patches on tracker References: <200607291232.15517.nicolas.weeger@laposte.net> <44CD9764.3060706@sonic.net> Message-ID: On Sun, 30 Jul 2006 22:38:44 -0700, Mark Wedel wrote: > Andrew Fuchs wrote: >> On 7/29/06, Nicolas Weeger (Laposte) wrote: >>> New coins. >>> >>> I see no reason to not commit'em, it makes it easier to carry money :) >> >> The new coins where not meant to be given out by stores as change >> (except possibly if the store is very rich), which happens with this >> patch. Before the new coins can be used someone has to modify the >> code so the new coins are not normaly given out by stores. There were a number of suggestions; one was what you say, another was what Mark describes below, there was even a vague idea of national coinage. The alternative patch that does what you ask is attached; I'm pretty sure I put it on sourceforge somewhere, but it's easier to attach here than look for it there. (It probably won't attach cleanly; my crossfire tree is months outdated, as I've been really busy.) > I wonder if this could be added as a new attribute to the map header, like the > shopitems stuff? Something like max_denomination or the like (and if that isn't > set, keep the current setting of platinum/gold/silver). I think that's a sweet idea. It could be argued that gem shops would usually have the higher-denomination coins in stock, at least. > A question could be whether that should control both what currency it > takes and what it gives out. I think they should accept all kinds. Realistically, it would be reasonable for them to "not have change" as you say, but then again you're always saying we don't want to get too realistic and spoil the fun :-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ Index: server/shop.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/shop.c,v retrieving revision 1.50 diff -u -r1.50 shop.c --- server/shop.c 19 Nov 2005 21:05:30 -0000 1.50 +++ server/shop.c 27 Dec 2005 18:15:17 -0000 @@ -54,8 +54,11 @@ static uint64 pay_from_container(object *pl, object *pouch, uint64 to_pay); static uint64 value_limit(uint64 val, int quantity, object *who, int isshop); -#define NUM_COINS 3 /* number of coin types */ -static char *coins[] = {"platinacoin", "goldcoin", "silvercoin", NULL}; +#define NUM_COINS 5 /* number of coin types */ +#define LARGEST_COIN_GIVEN 2 /* never give amber or jade, but accept them */ +static char *coins[] = {"ambercoin", "jadecoin", + "platinacoin", "goldcoin", + "silvercoin", NULL}; /* Added F_TRUE flag to define.h to mean that the price should not * be adjusted by players charisma. With F_TRUE, it returns the amount @@ -335,7 +338,8 @@ static char buf[MAX_BUF]; archetype *coin, *next_coin; char *endbuf; - int num, cointype = 0; + int num; + int cointype = LARGEST_COIN_GIVEN; coin = find_next_coin(cost, &cointype); if (coin == NULL) @@ -412,7 +416,8 @@ if (!idskill2 || !find_skill_by_number(who, idskill2)) { if (!find_skill_by_number(who,SK_BARGAINING)) { static char buf[MAX_BUF]; - int num, cointype = 0; + int num; + int cointype = LARGEST_COIN_GIVEN; archetype *coin = find_next_coin(real_value, &cointype); if (coin == NULL) return "nothing"; From lalo.martins at gmail.com Mon Jul 31 08:15:05 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 31 Jul 2006 21:15:05 +0800 Subject: [crossfire] Some pending patches on tracker References: <200607291232.15517.nicolas.weeger@laposte.net> Message-ID: On Sat, 29 Jul 2006 12:32:15 +0200, Nicolas Weeger (Laposte) wrote: > https://sourceforge.net/tracker/index.php?func=detail&aid=1389432&group_id=13833&atid=313833 > per-race hall of selection > > I like the idea, and think it should be committed (note that patch doesn't > work, conflict in main.c, but shouldn't be hard to fix) Missed this one the first time around... The part of the patch that touches main.c is very very simple, so it shouldn't be hard to fix. The reason we didn't commit this one (I was given cvs access just a few days after writing it) was that Mark favoured going in the general direction of a client-side character creation process, which I think is much better. But people agree this is a good intermediary measure, then yay. For one, schmorp is running this code (might be worth checking if they made improvements to it). I know Pippijn designed at least a few of these halls, and they looked really nice. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/