From rbrockway at opentrend.net Tue Aug 1 09:22:29 2006 From: rbrockway at opentrend.net (Robert Brockway) Date: Tue, 1 Aug 2006 10:22:29 -0400 (EDT) Subject: [crossfire] blasphemy, vulgarities etc. In-Reply-To: <44CC4924.2030203@sonic.net> References: <1154177478.14625.8.camel@localhost.localdomain> <44CBD91D.60108@telus.net> <44CC4924.2030203@sonic.net> Message-ID: On Sat, 29 Jul 2006, Mark Wedel wrote: > - Using american MPAA rules, game probably shouldn't be any worse than > PG-13, so explicit sexual conduct would probably be out (prostitution, > etc). Depends how explicit it gets I think. A seedy tavern isn't complete without a few prostitutes hanging around for atmosphere :) > 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. What about a runtime flag which sets the "rating level" for the server. Depending on the level set, this could block access certain maps and even automatically set warnings. So if the rating level was set to "PG13" then any maps with a higher rating would be blocked. If the rating level was set to "R" then all maps would be available but a warning would automatically be present in the issue (message before login). Maps would need to contain information on their ratings level of course. 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 wim-cf at villerius.nl Tue Aug 1 10:06:38 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Tue, 01 Aug 2006 17:06:38 +0200 Subject: [crossfire] blasphemy, vulgarities etc. In-Reply-To: References: <1154177478.14625.8.camel@localhost.localdomain> <44CBD91D.60108@telus.net> <44CC4924.2030203@sonic.net> Message-ID: <1154444798.17392.76.camel@localhost.localdomain> On Tue, 2006-08-01 at 10:22 -0400, Robert Brockway wrote: > What about a runtime flag which sets the "rating level" for the server. > Depending on the level set, this could block access certain maps and even > automatically set warnings. > > So if the rating level was set to "PG13" then any maps with a higher > rating would be blocked. If the rating level was set to "R" then all maps > would be available but a warning would automatically be present in the > issue (message before login). Maps would need to contain information on > their ratings level of course. As long as there is no request for maps rated other than (at most) PG13, I think this is not worth the efford. And I doubt this demand will ever arise (unless CF becomes much more graphical) My main concern was however the language use of NPC's. I don't remember which NPC's this concerns, but some use expressions that are forbidden on Metalforge. Another issue is the naming of certain maps monsters. I guess angels - and especially arch angels - might upset some people, not to mention the appearance of 'holy ghosts' in Valriel's church. Also fighting devils or demons could be too much for some, especially when it comes to Demon Lords ;-) And the entry to '/euthville/devil.church1' - a building filled with devils - is for some reason not manifest to me called 'jesus weeping' (see as well the name of /eutville/devil.church3). Does this game bring the gospel? ;-) Further, IMO things that are usually regarded as 'morally bad' (such as slavery) could be no problem as long as this is not propagated. A society with much less woman rights as is common to us might be proper content as long as 1) it does make sense and 2) there is no attempt to justify this. From yann.chachkoff at myrealbox.com Tue Aug 1 12:05:24 2006 From: yann.chachkoff at myrealbox.com (Yann CHachkoff) Date: Tue, 1 Aug 2006 19:05:24 +0200 (CEST) Subject: [crossfire] blasphemy, vulgarities etc. In-Reply-To: <1154444798.17392.76.camel@localhost.localdomain> References: <1154177478.14625.8.camel@localhost.localdomain> <44CBD91D.60108@telus.net> <44CC4924.2030203@sonic.net> <1154444798.17392.76.camel@localhost.localdomain> Message-ID: <4791.10.0.0.5.1154451924.squirrel@khelens.lan> > As long as there is no request for maps rated other than (at most) PG13, > I think this is not worth the efford. And I doubt this demand will ever > arise (unless CF becomes much more graphical) > I agree with this - and given the tone Crossfire has kept until now, I doubt the problem is worth a code patch now. > My main concern was however the language use of NPC's. I don't remember > which NPC's this concerns, but some use expressions that are forbidden > on Metalforge. > I disagree. If the NPC represents somebody that uses rude language, so be it. As long as the usage doesn't become excessive, I see no reason to change that *if that fits the character depicted*. I'd easily understand that an "upset" NPC or a gruesome pirate to use rude words; OTOH, for most NPCs, that would be inappropriate. > Another issue is the naming of certain maps monsters. I guess angels - > and especially arch angels - might upset some people, not to mention the > appearance of 'holy ghosts' in Valriel's church. > Huh, what ? I strongly disagree with this. Angels are a concept found in just about all mythologies (including the judeo-christian one); they are present in the "collective cultural background" of many players. Why the heck representing angels should ever be a concern ? Who exactly would be offended, outside of a couple of fundamentalists ? Let's make my point clear on this: just because some symbols are used in real-world mythos and religions doesn't mean it is forbidden or offending to use them in another context. Religions depicted in Crossfire are fictional ones, and claim no relationship with real-world ones. Making that position clear in the user's guide (maybe it is already ?) seems good; OTOH, I'm opposed to start removing/changing creatures on the sole pretext a couple of fundamentalists could consider their religion has a monopoly on them. About holy ghosts - if anybody creates problems with that name (hey ! that's something that belongs to christians, remove that, it is insulting !), I suggest reading them the following explanation from the notorious Compendium Khelentika, written by nobody else than the famous wizard Dhelyy Olyy himself: "Shadow-like creatures, born from the spirit of deceased priests of Valriel, that defended the Temple of Valriel of Ka?rudan when it was attacked by the Arch-Demon Zurnad, during the Dark War impressed Valriel so much by their bravery and their devotion that the god blessed them and their descendants, protecting them by a part of its holy aura. Since that time, they are called 'holy ghosts' for obvious reasons. It is considered an honor by monks of Valriel to be reincarnated in a holy ghost." > Also fighting devils or demons could be too much for some, especially > when it comes to Demon Lords ;-) > Again, I think it is excessive. Just about every mythos has demons and devils, which are basically nothing more than the embodiement of "bad principles". In most mythos, there's a "hierarchy of evil", just as there's one on the "good side", hence the idea of Demon lords - those are leaders in the ranks of the demons. If we start that way, then why not banning dwarves (they're an insulting joke to players affected by nanism) or elves (they are an insulting caricature of ecologists, and, besides that, we may displease fans of Tolkien) ? I agree that we shouldn't offend existing religious groups, but this seems to go way too far IMHO. > And the entry to '/euthville/devil.church1' - a building filled with > devils - is for some reason not manifest to me called 'jesus weeping' > (see as well the name of /eutville/devil.church3). Does this game bring > the gospel? ;-) > Well, the game initially used "God" and "Satan" for the two Gods named now Valriel and Gorokh. The "Jesus Weeping" map dates back in the early days of Crossfire, when that still was true, and the CF mythos wasn't really defined. I think it would be a good idea to rename it to something like "Valriel Weeping" or anything else more in sync with the current CF mythos. > Further, IMO things that are usually regarded as 'morally bad' (such as > slavery) could be no problem as long as this is not propagated. A > society with much less woman rights as is common to us might be proper > content as long as 1) it does make sense and 2) there is no attempt to > justify this. > I agree. As long as we don't promote such concepts (like by winning a girl slave for example), I think it is perfectly acceptable to depict them, as they were rather common in a lot of past civilizations. From mwedel at sonic.net Tue Aug 1 22:47:19 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 01 Aug 2006 20:47:19 -0700 Subject: [crossfire] blasphemy, vulgarities etc. In-Reply-To: <4791.10.0.0.5.1154451924.squirrel@khelens.lan> References: <1154177478.14625.8.camel@localhost.localdomain> <44CBD91D.60108@telus.net> <44CC4924.2030203@sonic.net> <1154444798.17392.76.camel@localhost.localdomain> <4791.10.0.0.5.1154451924.squirrel@khelens.lan> Message-ID: <44D02047.60502@sonic.net> Yann CHachkoff wrote: >> My main concern was however the language use of NPC's. I don't remember >> which NPC's this concerns, but some use expressions that are forbidden >> on Metalforge. >> > I disagree. If the NPC represents somebody that uses rude language, so be > it. As long as the usage doesn't become excessive, I see no reason to > change that *if that fits the character depicted*. I'd easily understand > that an "upset" NPC or a gruesome pirate to use rude words; OTOH, for most > NPCs, that would be inappropriate. I think it depends specifically on the words in use. For many people/parents, certain words are off limits, and at some level, it isn't as much about the context. So having an NPC say 'you stupid bastard' would probably be fine. Or we could even go the 'don't use swear words, but use symbols instead', so it could be 'you !%$ bastard!'. The context is there to know what the NPC thinks of you and that it is rude language, but doesn't use actual swear words. Some of this I'm sure comes back from metalforge, and maybe others, prohibit use of swear words in chatting and the like, so having NPC use these same prohibited words is a bit odd. From wim-cf at villerius.nl Wed Aug 2 01:47:47 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Wed, 02 Aug 2006 08:47:47 +0200 Subject: [crossfire] blasphemy, vulgarities etc. In-Reply-To: <4791.10.0.0.5.1154451924.squirrel@khelens.lan> References: <1154177478.14625.8.camel@localhost.localdomain> <44CBD91D.60108@telus.net> <44CC4924.2030203@sonic.net> <1154444798.17392.76.camel@localhost.localdomain> <4791.10.0.0.5.1154451924.squirrel@khelens.lan> Message-ID: <1154501267.17392.120.camel@localhost.localdomain> On Tue, 2006-08-01 at 19:05 +0200, Yann CHachkoff wrote: > > My main concern was however the language use of NPC's. I don't remember > > which NPC's this concerns, but some use expressions that are forbidden > > on Metalforge. > > > I disagree. If the NPC represents somebody that uses rude language, so be > it. As long as the usage doesn't become excessive, I see no reason to > change that *if that fits the character depicted*. I'd easily understand > that an "upset" NPC or a gruesome pirate to use rude words; OTOH, for most > NPCs, that would be inappropriate. As Mark already wrote, it's about consistency. Why prohibit players the use of certain words if NPC's can use it? > > Another issue is the naming of certain maps monsters. I guess angels - > > and especially arch angels - might upset some people, not to mention the > > appearance of 'holy ghosts' in Valriel's church. > > > Huh, what ? I strongly disagree with this. Angels are a concept found in > just about all mythologies (including the judeo-christian one); they are > present in the "collective cultural background" of many players. Why the > heck representing angels should ever be a concern ? Who exactly would be > offended, outside of a couple of fundamentalists ? What exactly do you disagree with? Disagreeing that someone might possibly be upset by the use of angels (and holy ghosts)? It's the only thing I said, without suggesting that they should be removed. > Let's make my point clear on this: just because some symbols are used in > real-world mythos and religions doesn't mean it is forbidden or offending > to use them in another context. Religions depicted in Crossfire are > fictional ones, and claim no relationship with real-world ones. And that's exactly why there is no single reason to these symbols and names, for there is no relationship with real-world religions ;-) This becomes even a stronger argument when we're talking about symbols and names that are highly important for a religion. Do you remember the fuss about those few Danish cartoons? That's not (only) because people like to riot. It's also one (out of many) of the reasons why it's a good thing that crossfire religions do not match with real-world religions, and that's why it's a good thing to minimalize the use of (important) names and symbols (is there any difference?) from real-world religions, such as 'holy ghost', 'Jesus', 'JWHW', etc. > Making that position clear in the user's guide (maybe it is already ?) > seems good; OTOH, I'm opposed to start removing/changing creatures on the > sole pretext a couple of fundamentalists could consider their religion has > a monopoly on them. So we ban excessive use of rude words and don't want to create maps containing mature content for those little children. We also don't want to include political statements for the few players from China, nor do we allow anti-woman rights rants because that's offending, but we don't care for religious players that find it a bit offending that the name of their god is used in the game? > About holy ghosts - if anybody creates problems with that name (hey ! > that's something that belongs to christians, remove that, it is insulting > !), I suggest reading them the following explanation from the notorious > Compendium Khelentika, written by nobody else than the famous wizard > Dhelyy Olyy himself: Eh, that's what I would call 'post hoc justification', making some lore with the sole purpose to 'allow' the existence of something odd :) > "Shadow-like creatures, born from the spirit of deceased priests of > Valriel, that defended the Temple of Valriel of Ka?rudan when it was > attacked by the Arch-Demon Zurnad, during the Dark War impressed Valriel > so much by their bravery and their devotion that the god blessed them and > their descendants, protecting them by a part of its holy aura. Since that > time, they are called 'holy ghosts' for obvious reasons. It is considered > an honor by monks of Valriel to be reincarnated in a holy ghost." You could name them "blessed souls", that fits the story as well. > > Also fighting devils or demons could be too much for some, especially > > when it comes to Demon Lords ;-) > > > Again, I think it is excessive. Just about every mythos has demons and > devils, which are basically nothing more than the embodiement of "bad > principles". In most mythos, there's a "hierarchy of evil", just as > there's one on the "good side", hence the idea of Demon lords - those are > leaders in the ranks of the demons. Yes, I agree that it would be excessive to remove them, though that is not what's under discussion. > If we start that way, then why not banning dwarves (they're an insulting > joke to players affected by nanism) or elves (they are an insulting > caricature of ecologists, and, besides that, we may displease fans of > Tolkien) ? Dwarves insulting? heh, they're pretty strong folk. I would rather consider hobbits as offending ;-) > I agree that we shouldn't offend existing religious groups, but > this seems to go way too far IMHO. I agrree that it would go way too far if we indeed remove angels and demons, even though I think there must be a better name, since crosfire's angels and demons don't fit the concepts most people have about them. Demons and angels are, as you say, followers of evil c.q. good - which suggests that there are only two ways. In crossfire there are many ways, and - as far as I'm aware of - in no polytheistic religion, there are demons or angels. And that makes sense when good nor bad are 'copyrighted' by a single cult. > > And the entry to '/euthville/devil.church1' - a building filled with > > devils - is for some reason not manifest to me called 'jesus weeping' > > (see as well the name of /eutville/devil.church3). Does this game bring > > the gospel? ;-) > > > Well, the game initially used "God" and "Satan" for the two Gods named now > Valriel and Gorokh. The "Jesus Weeping" map dates back in the early days > of Crossfire, when that still was true, and the CF mythos wasn't really > defined. I think it would be a good idea to rename it to something like > "Valriel Weeping" or anything else more in sync with the current CF > mythos. Yep, and couldn't it be that the name 'holy ghost' is another remainder of these old days? ;-) From nicolas.weeger at laposte.net Wed Aug 2 03:43:59 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Wed, 2 Aug 2006 10:43:59 +0200 Subject: [crossfire] Quest management system proposal In-Reply-To: <200606092027.54507.nicolas.weeger@laposte.net> References: <200606092027.54507.nicolas.weeger@laposte.net> Message-ID: <200608021043.59482.nicolas.weeger@laposte.net> Hello. I'm resurrecting that topic :) (long mail warning) After much thinking, I've changed my mind. IMO a quest management system could very well be written in Python, with a few improvements to the plugin system. What I'd add: First, extend the NPC dialog system. To enable more interesting dialogs, add some "parameters" after the @match line, to build a graph-like system. Two things: * @name which would give the step's name "activated" when player says the matching * @follow which would be the required step to actually have a match would be any arbitrary name, with an optional * in front. No star => step is NPC specific, and thus step info is stored in NPC's inventory Star => step is player specific, and thus stored in player's inventory Let's illustrate that: -------------------------------- Random NPC: @match hello|Hello @name h Hello, what a bad weather, isn't it? @match weather @name w @follow h Yes, lately the weather's been really bad, people are starting to talk about curses and such @match curse|curses @name *weather_curse @follow w A witch living nearby said there was something about seeing curses. --------------------------------- For the witch: @match hello|Hello Hello stranger @match curse|curses @name c @follow *weather_curse Yes, my crystall ball shows me curses around this area @match can I help? @follow c If you find the source of the curses, everyone will be very glad! -------------------------------- This way, player must talk in a certain order to NPC before having the witch reply to "curse". And of course you activate the quest when player asks if she can help ;) For the quests, I'd do a plugin (or a Python script) to manage quest steps and rewards on a player-basis. The quest description file would include much information, but individual conditions to change steps would be in the maps themselves, through the events system. Something like: arch npc x 10 y 10 arch event_kill title Python slaying /python/quests/myquest/boss_dead.py end end and boss_dead.py would be approx: import Crossfire Crossfire.QuestStep( "kill_boss" "boss_killed" ) the quest system would look for step "boss_dead", and update player's status, give rewards, and such. Using the Python/plugin system to specify transitions is imo powerful, you can write pretty complex things with scripts (trace player position through time, things like that). I would personally include some Python scripts themselves in the quest file, for instance a script giving reward at quest end (Player.GiveExp hiding, 5000), again to be able to do complex things. The quest system will be responsible for ensuring player hasn't done the quest, and is doing steps in the right order, things like that. Would also manage party (so when a player starts a quest, all party members on same map start too, for instance). There are some caveats, though: * quest information will be dispatched between many maps, even if quest file could contain all information (duplication, in this case) * also, what should happen when players having done different steps of a quest party together and do a quests's step? All players move to new step (unless they are at a next step already), players not having done previous steps don't gain anything? * doing quest would request Python scripting (unless we add a quest-specific basic language, like: "give hiding 5000" for rewards) Here's a small quest file example that could be done: quest kill_boss description You must kill the evil boss that sends minions to the town enddescription transition boss_killed end step end message Congratulations, you killed the evil boss! People in town rejoice! endmessage reward give exp 5000 hiding endreward endstep For some NPC add an event in Python saying: import Crossfire Quests.Start( "kill_boss") and add a event_kill to the boss (see above) Ok, this probably needs formalizing, but I'm sending to have preliminary opinions :) From yann.chachkoff at myrealbox.com Wed Aug 2 07:05:31 2006 From: yann.chachkoff at myrealbox.com (Yann CHachkoff) Date: Wed, 2 Aug 2006 14:05:31 +0200 (CEST) Subject: [crossfire] blasphemy, vulgarities etc. In-Reply-To: <1154501267.17392.120.camel@localhost.localdomain> References: <1154177478.14625.8.camel@localhost.localdomain> <44CBD91D.60108@telus.net> <44CC4924.2030203@sonic.net> <1154444798.17392.76.camel@localhost.localdomain> <4791.10.0.0.5.1154451924.squirrel@khelens.lan> <1154501267.17392.120.camel@localhost.localdomain> Message-ID: <1250.10.0.0.5.1154520331.squirrel@khelens.lan> > As Mark already wrote, it's about consistency. Why prohibit players the > use of certain words if NPC's can use it? > I'd like to point out that prohibiting the use of some words by players is a decision made by the administrator of each server, not a general rule. Although I definitely don't think that rude language used without any reason in the NPC dialogs are a bad thing, I'm not opposed to that when it is really in-sync with the character depicted. > What exactly do you disagree with? Disagreeing that someone might > possibly be upset by the use of angels (and holy ghosts)? It's the only > thing I said, without suggesting that they should be removed. > I disagree that this should even be an issue to consider, at least for something as basical as names like "angels", "demons" and such. > And that's exactly why there is no single reason to these symbols and > names, for there is no relationship with real-world religions ;-) > Of course there is - angels and demons do not only belong to religions, but also to a cultural background of supranatural creatures, like djinns, ghosts, dragons and faeries. Their concept existed long before the religions using them nowadays appeared. Crossfire - and just about every other fictional fantasy universe invented - uses various symbols well known by most humans because of the inconscious association behind them. Say "angel", and most people will immediately think "winged people, holy messenger, defender of the good"; say "dragon", and they'll say "huge intelligent reptile with powerful magical abilities". There is nothing religious in that - those symbols all exist outside a single religious context and are part of our very own civilization background. Now, my position on *explicit* religious symbols is very different: name of religious leaders or divinities, for example, should never appear in the game. That's exactly why I said earlier that changing "Jesus Weeping" was a good idea, as Jesus is the symbol of a religion, and not a "shared concept". > This becomes even a stronger argument when we're talking about symbols > and names that are highly important for a religion. > Then, why speak about angels and demons, which not only don't "belong" to a religion in particular, but are also not the strongest symbols of those using them by far ? Why not a single word about the "holy symbol" that is represented in the game by a cross, for example ? > Do you remember the fuss about those few Danish cartoons? > What is the relationship between a cartoon that was making a direct (and offensive) reference to a specific religious group and the use of cultural elements that are parts of the mankind fantastic world for thousands of years ? > It's also one (out of many) of the reasons why it's a good thing that > crossfire religions do not match with real-world religions, > They don't, IMHO. Does Valriel profess that other gods are fake, and that it is the only true one ? No - by its eternal fight against Gorokh, it is inherently a very different religion than the Christian one. Are there similarities ? Of course there are - but there are as much similarities between Valrialism and Christianism than there is between Valrialism and Mazdeism, for example. > and that's why it's a good thing to minimalize the > use of (important) names and symbols (is there any difference?) > The question is when a name or a symbol is considered sufficiently significant to be 'forbidden'. Suppose for example that the critera is: as long as it is an important religious symbol for an important community, then we should change it. Sounds fine ? Well, then we should remove humans from the game - representing humans as we do now could offend Muslims. We should also remove dragons - they play a very important role in oriental beliefs. And zombies, too - those are part of the voodoo web of beliefs. See my point ? I agree that we shouldn't offend existing religions on purpose, and try to avoid making direct references to them - for example, don't use names of religious leaders, founders, or divinities like "Jesus" or "Vishnu". Do angels, demon lords and others belong to that category ? I don't think so. > So we ban excessive use of rude words and don't want to create maps > containing mature content for those little children. We also don't want > to include political statements for the few players from China, nor do > we allow anti-woman rights rants because that's offending, but we don't > care for religious players that find it a bit offending that the name of > their god is used in the game? > Where is the name of their god used in the game ? I already expressed that I was *for* the removal of "Jesus Weeping" (and, of course, of any similar name clearly making a reference to our own world). Angels and demons are not a symbol specific to a religion, even nowadays. > Eh, that's what I would call 'post hoc justification', making some lore > with the sole purpose to 'allow' the existence of something odd :) > I see nothing "odd" (well, not odder than most of Crossfire :) ) and, besides that, I see nothing wrong in creating some lore to justify a game element "a posteriori" if no further explanation existed. > You could name them "blessed souls", that fits the story as well. > Their 'physical' manifestation in-game is one of a ghost - calling them "souls" would thus be illogical. And they are more than just 'blessed' - they are amongst the most faithful guardians of Valriel, recognized by the god itself. > Yes, I agree that it would be excessive to remove them, though that is > not what's under discussion. > Yes, but if removing or changing them is not the discussion, I wonder why you mentioned those in the first place. > Dwarves insulting? heh, they're pretty strong folk. I would rather > consider hobbits as offending ;-) > Is see only one possible answer here: :D. > Demons and angels are, as you say, followers of evil c.q. > good - which suggests that there are only two ways. In crossfire there > are many ways, and - as far as I'm aware of - in no polytheistic > religion, there are demons or angels. And that makes sense when good nor > bad are 'copyrighted' by a single cult. > This is an interesting point. However, in a polytheistic system as the one depicted in Crossfire, it is still very consistent, IMHO. Valriel is the personification of "Good". Gorokh is the one representing "Bad". And of course, Valriel and Gorokh fight each other. But they are just personifications of those two concepts, without even suggesting that the whole world can be explained by them alone. What about Mostrai, Lythander and the others ? Well, sometimes, they are in the same camp as Valriel, like when dwarven priests helped cure the Great Plague of 3456EK. Sometimes, they are on Gorokh's side, as when the Mostra?an Archbishop of Navar ordered the slaughter of the Elvish community that lived there in 4322EK. The polytheism of Crossfire is a very dualistic one: Mostra? vs Lythander; Gaia vs Devourers; Valriel vs Gorokh... I suppose that in such a system, people would see two 'camps', with temporary alliances, wars, and exchanges between gods, depending on their moods and interests. Or maybe priests of Lythander or Gaia believe Valriel and Gorokh are fake gods ? Who knows ? Maybe we should ask the priests in the game about this :). One may then wonder why angels only serve Valriel and demons, Gorokh. The answer is simple - they are the incarnation of the concepts of Good and Evil, just like a Fire Elemental couldn't follow any other god than Ruggili precisely because it is made of fire. Regarding real polytheistic religions, there are always "good" and "evil" monsters, some helping humanity, others trying to corrupt it. Those concepts are of course stronger in a dualistic vision of the world - but a lot of polytheistic religions followed such a dualistic vision (the most well known example of a polytheistic religion that makes use of "angels" is probably Zoroastrism and its descendants, which influenced christianism). > Yep, and couldn't it be that the name 'holy ghost' is another remainder > of these old days? ;-) > Maybe, but given that a logical explanation for that name (which, besides that, doesn't capitalize the two words using "Holy Ghost" as a name labelling a single entity, but "holy ghosts", thus a specific subclass of ghosts), I think it shouldn't be considered bothersome. **** So, to summarize my thoughts about all this: -------------------------------------------- - Yes to limit the use of rude language (I liked a lot the idea of replacing insults by stuff like "*#@ !") only when necessary; - Yes to not make references to specific real-world religions (names like "Jesus", "Vishnu", etc. should be replaced if present); - No to extend that to more common names (angels, demons, holy ghosts, etc), as they belong to "common background mythos" more than to a given religion. From mwedel at sonic.net Fri Aug 4 01:48:09 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 03 Aug 2006 23:48:09 -0700 Subject: [crossfire] Quest management system proposal In-Reply-To: <200608021043.59482.nicolas.weeger@laposte.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608021043.59482.nicolas.weeger@laposte.net> Message-ID: <44D2EDA9.9000900@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > I'm resurrecting that topic :) > (long mail warning) > > After much thinking, I've changed my mind. IMO a quest management system could > very well be written in Python, with a few improvements to the plugin system. > > What I'd add: > > First, extend the NPC dialog system. > To enable more interesting dialogs, add some "parameters" after the @match > line, to build a graph-like system. > Two things: > * @name which would give the step's name "activated" when player says > the matching > * @follow which would be the required step to actually have a match > > would be any arbitrary name, with an optional * in front. > No star => step is NPC specific, and thus step info is stored in NPC's > inventory > Star => step is player specific, and thus stored in player's inventory Looking at that, and looking at your example, it seems hardly really clear to follow. It also seems like under such a system, it could be difficult for conversations/quests to skip steps. I'm not sure of where that would be used, but perhaps cases where the quest is looking for prerequsites (must have some skill, if not, tell player to get skill, if player has skill, skip to stage about telling playg about next thing to do). As such, I wonder if having a variable, or even better, multiple variables, that hold actual values instead of follows would be better. eg,: @match hello @set state=1 Hello, what bad weather, isn't it? @match weather @compare state=1 @set state=2 Yes, lately the weather's been really bad, people are starting to talk about curses and such @match curse @compare state>1 @set *weather_curse=1 A witch living nearby said there was something about seeing curses. .... @match * @compare *weather_curse>2 # this is set when player completes quest Than you for taking care of that witch I think this isn't that much complicated (limit the @set to simple syntax, limit @compare to basic set of operations) And to me, that is easier to follow/debug. I would think that internally, the name/follow would have to store some value in the variables, but if we expose that to the map maker, it gives more flexibility. Also, if we presume all of these player (*variables) are global, it means different NPC's could update quest information. I think that for the NPC state data, that should probably be stored in a force object that expires after some amount of time (like 1 minute real-time after last update). After all, other players may interact with that NPC, and state should reset for them. Also, from what I can see, these changes are actually unrelated to the quest management piece - this is just improved NPC interaction, which is needed for quests. > > For the quests, I'd do a plugin (or a Python script) to manage quest steps and > rewards on a player-basis. My personal inclination would be the quest not to be a script - ideally a core part of the server, lesser would be a plugin. I'd put using a python script near the bottom. Not that python is inherently bad, but I think for developer reasons. In theory, the entire crossfire server could be in python - that obviously won't happen. But given that the server is currently in C, it is quite reasonable to expect all developers to know C. But if there are bugs/improvements that need to be done to the script, but the developer doesn't know python, not sure where that really leaves things. > There are some caveats, though: > * quest information will be dispatched between many maps, even if quest file > could contain all information (duplication, in this case) > * also, what should happen when players having done different steps of a quest > party together and do a quests's step? All players move to new step (unless > they are at a next step already), players not having done previous steps > don't gain anything? That's a trickier one - especially if completing the quest requires some item. If the party has the item, but doesn't complete the quest before the party breaks up (or more importantly, one of the members log out), a player quest state could be at a point where they really can't be at. OTOH, you don't want a case where player is about to complete quest and get reward, and then have everyone join them to get that bonus exp (one question if the reward is exp, does it get divided by number of people in party? Does each player just get full reward?). I'd almost say quests can't be shared across parties. > * doing quest would request Python scripting (unless we add a quest-specific > basic language, like: "give hiding 5000" for rewards) As a note, the ability to give such rewards just in general could be nice not really related to quests. Drop an item, get some exp reward, etc. > > > Here's a small quest file example that could be done: > > quest kill_boss > description > You must kill the evil boss that sends minions to the town > enddescription > transition boss_killed end > step end > message > Congratulations, you killed the evil boss! > People in town rejoice! > endmessage > reward > give exp 5000 hiding > endreward > endstep That isn't really readable at a first glance, but perhaps if indentation is used like treasurelists, that would be better. I also wonder if the transition and step are both needed - it seems somewhat redundant - something like: transition boss_killed message ... endmessage reward ... endreward endtransition From nicolas.weeger at laposte.net Fri Aug 4 02:55:24 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Fri, 4 Aug 2006 09:55:24 +0200 Subject: [crossfire] Quest management system proposal In-Reply-To: <44D2EDA9.9000900@sonic.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608021043.59482.nicolas.weeger@laposte.net> <44D2EDA9.9000900@sonic.net> Message-ID: <200608040955.24116.nicolas.weeger@laposte.net> I won't reply (yet) too all your points, just one :) > OTOH, you don't want a case where player is about to complete quest and > get reward, and then have everyone join them to get that bonus exp (one > question if the reward is exp, does it get divided by number of people in > party? Does each player just get full reward?). I'd almost say quests > can't be shared across parties. Quests should be shared across parties. It would encourage collaborative play, also enable to do fun/creative things. I for one will either work on a quest system enabling players to share quests, or won't work on it at all :) Nicolas From alex_sch at telus.net Fri Aug 4 10:16:29 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 04 Aug 2006 09:16:29 -0600 Subject: [crossfire] Quest management system proposal In-Reply-To: <200608040955.24116.nicolas.weeger@laposte.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608021043.59482.nicolas.weeger@laposte.net> <44D2EDA9.9000900@sonic.net> <200608040955.24116.nicolas.weeger@laposte.net> Message-ID: <44D364CD.2000602@telus.net> Nicolas Weeger (Laposte) wrote: >> OTOH, you don't want a case where player is about to complete quest and >> get reward, and then have everyone join them to get that bonus exp (one >> question if the reward is exp, does it get divided by number of people in >> party? Does each player just get full reward?). I'd almost say quests >> can't be shared across parties. >> > > Quests should be shared across parties. It would encourage collaborative play, > also enable to do fun/creative things. > I for one will either work on a quest system enabling players to share quests, > or won't work on it at all :) > > Nicolas I would think a good way to prevent cases of the issues Mark says, would be making it so only players who were in the party at the start of the quest, and are still in the party when the quest finished, and are on one of the maps for the quest when it finishes, should get the reward. Alex Schultz From mwedel at sonic.net Fri Aug 4 23:10:59 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 04 Aug 2006 21:10:59 -0700 Subject: [crossfire] Quest management system proposal In-Reply-To: <44D364CD.2000602@telus.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608021043.59482.nicolas.weeger@laposte.net> <44D2EDA9.9000900@sonic.net> <200608040955.24116.nicolas.weeger@laposte.net> <44D364CD.2000602@telus.net> Message-ID: <44D41A53.6000404@sonic.net> Alex Schultz wrote: > Nicolas Weeger (Laposte) wrote: >>> OTOH, you don't want a case where player is about to complete quest and >>> get reward, and then have everyone join them to get that bonus exp (one >>> question if the reward is exp, does it get divided by number of people in >>> party? Does each player just get full reward?). I'd almost say quests >>> can't be shared across parties. >>> >> Quests should be shared across parties. It would encourage collaborative play, >> also enable to do fun/creative things. >> I for one will either work on a quest system enabling players to share quests, >> or won't work on it at all :) >> >> Nicolas > > I would think a good way to prevent cases of the issues Mark says, would > be making it so only players who were in the party at the start of the > quest, and are still in the party when the quest finished, and are on > one of the maps for the quest when it finishes, should get the reward. Have to be careful about map requirements - don't want people to lose out because they were on the previous level of the dungeon when something happened (say healing). Some may come in how many steps are done to complete the quest. And also what is considered the critical parts of the quest - if the quest is to kill some boss, but some of the difficulty is getting to the boss, there is no way to really prevent part members from joining in near the end (talk to quest giver, join party, go help kill boss). It may just be a case of overcomplicating the problem - if there is a rash of people joining the party late just for reward, some method of correction. But as thinking about it, how to enforce these is also odd. For example, in the kill monster scenario, just giving credit to the person doing the killing blow may not work - imagine a case where the boss is fighting a character but uses an item that creates a fireball that kills him - that character he was fighting should get credit for completely the quest, even though he didn't do the killing blow (it would really suck in fact to be in such a situation) - you sort of need to do something like all players within 10 spaces get credit. Also, as I think about it, there may be need to have a flag which says which quests can be group quests and which can't be. For example, you could have some pretty basic quests - bring me a, b, c and I'll teach you about something. Such an offer should really be to a single person, not a group of people, so being in a party shouldn't have any advantage on that. From nicolas.weeger at laposte.net Sat Aug 5 09:26:49 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 5 Aug 2006 16:26:49 +0200 Subject: [crossfire] NPC recursive bug Message-ID: <200608051626.50008.nicolas.weeger@laposte.net> Hello. Related to bug: https://sourceforge.net/tracker/index.php?func=detail&aid=1534889&group_id=13833&atid=113833 I can see 2 solutions: * prevent NPCs to react to other NPCs' chat * add a static variable somewhere to prevent infinite recursion First solution I wonder if that wouldn't break maps? Probably a good compromise is just a static variable in talk_to_npc function. Opinions? Nicolas From mwedel at sonic.net Sat Aug 5 13:54:13 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 05 Aug 2006 11:54:13 -0700 Subject: [crossfire] NPC recursive bug In-Reply-To: <200608051626.50008.nicolas.weeger@laposte.net> References: <200608051626.50008.nicolas.weeger@laposte.net> Message-ID: <44D4E955.4030900@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > Related to bug: > https://sourceforge.net/tracker/index.php?func=detail&aid=1534889&group_id=13833&atid=113833 > > I can see 2 solutions: > * prevent NPCs to react to other NPCs' chat I can't think of anyplace where that would break something, bu that doesn't mean it wouldn't. So probably not a good solution. > * add a static variable somewhere to prevent infinite recursion That'd probably work OK. From alex_sch at telus.net Sat Aug 5 17:42:34 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 05 Aug 2006 16:42:34 -0600 Subject: [crossfire] NPC recursive bug In-Reply-To: <44D4E955.4030900@sonic.net> References: <200608051626.50008.nicolas.weeger@laposte.net> <44D4E955.4030900@sonic.net> Message-ID: <44D51EDA.7040608@telus.net> Mark Wedel wrote: >> * add a static variable somewhere to prevent infinite recursion >> > That'd probably work OK. I'm a bit inclined against that, because if we ever want to add threading to the server, a topic that had a significant amount of discussion on IRC a while ago, we would want to avoid use of static variables inside of functions wherever possible. Currently there are many instances of functions returning an internally defined static char array, to return a string, and to make it work with threading those would need to be modified to take a char pointer in for what to output to, and modify all calls to them. Removing unnecessary static variables may be a significant amount of work (as I once found when attempting to start that conversion once), and perhaps one extra static variable won't make much of a difference for when doing new code, however I'm cautious of using static variables in newly written code as it may set a precedent to use them even more which could be a pain for eventual threading. Alex Schultz From nicolas.weeger at laposte.net Sun Aug 6 04:50:18 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 6 Aug 2006 11:50:18 +0200 Subject: [crossfire] Quest management system proposal In-Reply-To: <44D2EDA9.9000900@sonic.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608021043.59482.nicolas.weeger@laposte.net> <44D2EDA9.9000900@sonic.net> Message-ID: <200608061150.18274.nicolas.weeger@laposte.net> > Looking at that, and looking at your example, it seems hardly really > clear to follow. After some thinking, having a Python script handle the dialog seems the best way, actually :) This way, the whole dialog is written into the Python script, including the logic. > I think that for the NPC state data, that should probably be stored in a > force object that expires after some amount of time (like 1 minute > real-time after last update). After all, other players may interact with > that NPC, and state should reset for them. I'd say each player has his/her own state, so they don't conflict. > My personal inclination would be the quest not to be a script - ideally a > core part of the server, lesser would be a plugin. Well, there aren't that many quest-general things, actually. Maybe utilities (like: do this for every player in the quest party) could be written to help write quests scripts. > I'd put using a python script near the bottom. Not that python is > inherently bad, but I think for developer reasons. In theory, the entire > crossfire server could be in python - that obviously won't happen. But > given that the server is currently in C, it is quite reasonable to expect > all developers to know C. But if there are bugs/improvements that need to > be done to the script, but the developer doesn't know python, not sure > where that really leaves things. I'd say you underestimate developers :) Scripting wouldn't require many functions in Python, just basic ones, and any C developer would feel at home looking at the logic imo. > As a note, the ability to give such rewards just in general could be nice > not really related to quests. Drop an item, get some exp reward, etc. This can already be done, via a Python script for instance. Unless I'm mistaking what you mean? So what I'd do is: * remove existing quest system, which is a bastardized version * write a Python "quests" command, with a few parameters (to get descriptions and so on) * write a few Python scripts to help write quest scripts and manage quests and such Then it's just a matter of writing Python scripts to handle quests :) Nicolas From nicolas.weeger at laposte.net Sun Aug 6 10:47:55 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 6 Aug 2006 17:47:55 +0200 Subject: [crossfire] Makefile fun Message-ID: <200608061747.56320.nicolas.weeger@laposte.net> Hello. I think the makefiles for the plugins are kind of weird :) Currently the Python makefile references directly the ../common/plugin_common.c file, so the makefile for plugin_common is basically useless. Meaning when we add files to the common directory we must update the Python makefiles, something I think is weird. IMO, plugin_common should generate a library, which the Python plugin links to during build. But I'm no makefile expert, so I don't want to break anything :) Nicolas From alex_sch at telus.net Sun Aug 6 11:39:48 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 06 Aug 2006 10:39:48 -0600 Subject: [crossfire] Makefile fun In-Reply-To: <200608061747.56320.nicolas.weeger@laposte.net> References: <200608061747.56320.nicolas.weeger@laposte.net> Message-ID: <44D61B54.1000902@telus.net> Nicolas Weeger (Laposte) wrote: > Hello. > > I think the makefiles for the plugins are kind of weird :) > > Currently the Python makefile references directly > the ../common/plugin_common.c file, so the makefile for plugin_common is > basically useless. > > Meaning when we add files to the common directory we must update the Python > makefiles, something I think is weird. > > IMO, plugin_common should generate a library, which the Python plugin links to > during build. > > But I'm no makefile expert, so I don't want to break anything :) > > Nicolas I was one talking to Yann Chachkoff (Gros/Lauwenmark) about that, and when he was setting up the makefiles, he had some concerns about about weird things happening if you load two shared objects that contain the same instance of plugin_common linked in. I'm not really a linking expert, so I decided to leave it as I wasn't sure what the correct/safe way was to do it. Alex Schultz From mwedel at sonic.net Mon Aug 7 02:11:17 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 07 Aug 2006 00:11:17 -0700 Subject: [crossfire] Quest management system proposal In-Reply-To: <200608061150.18274.nicolas.weeger@laposte.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608021043.59482.nicolas.weeger@laposte.net> <44D2EDA9.9000900@sonic.net> <200608061150.18274.nicolas.weeger@laposte.net> Message-ID: <44D6E795.8080805@sonic.net> Nicolas Weeger (Laposte) wrote: >> Looking at that, and looking at your example, it seems hardly really >> clear to follow. > > After some thinking, having a Python script handle the dialog seems the best > way, actually :) > > This way, the whole dialog is written into the Python script, including the > logic. I'd rather not have the NPC conversation be in python. IT has long been discusses that the NPC conversation needs to be improved, with things like conversation states, etc. This is unrelated to quests in particular - just a general good thing to do. IMO, having some basic scripting syntax for states in the message/endmessage would be a good thing - after all, map makers are people that would be using that, and at current time, there isn't a requirement that map makers also be programmers. I suppose and answer could be 'just copy the npc script from elsewhere' to the less technical map makers, but I'm not sure that is a good answer. > >> I think that for the NPC state data, that should probably be stored in a >> force object that expires after some amount of time (like 1 minute >> real-time after last update). After all, other players may interact with >> that NPC, and state should reset for them. > > I'd say each player has his/her own state, so they don't conflict. OTOH, for NPCs, such conflicting/local state may make sense. If you think of a case of a couple players talking to the same NPCs at the same time, it would make perfect sense for the NPC to progress the conversation as it perceives it - if the npc responds differently to 'foo' based on its state, and player a says foo, npc responds, then player b says foo, the npc should give its second answer to foo. This also makes sense that anything the NPC says can be heard to anyone near by (it isn't just at the player). This is why I was thinking NPC's should have some limited state just for general conversations (the case this really covers is when you should be able to keep saying 'yes' to the npc to get more info, but the current mechanism doesn't allow that, so instead players have to start guessing what is the word to continue the conversation). There certainly should be state information for the player itself related to npc conversations in some cases (especially quests). >> I'd put using a python script near the bottom. Not that python is >> inherently bad, but I think for developer reasons. In theory, the entire >> crossfire server could be in python - that obviously won't happen. But >> given that the server is currently in C, it is quite reasonable to expect >> all developers to know C. But if there are bugs/improvements that need to >> be done to the script, but the developer doesn't know python, not sure >> where that really leaves things. > > I'd say you underestimate developers :) > Scripting wouldn't require many functions in Python, just basic ones, and any > C developer would feel at home looking at the logic imo. It seems like every year or so, the discussion of what should be in C and what should be in plugins shows up, and this is sort of one of those. I suppose we really should come up with a standard and document it. But some also goes to above - the people who will use quests are mapmakers. Should it be a requirement for mapmakers to know python/have scripting skills to use many of the handy features of crossfire/map maker? If the answer there is yes, then no real issues. If the answer is no, then we perhaps need to revisit if python is the best solution. > >> As a note, the ability to give such rewards just in general could be nice >> not really related to quests. Drop an item, get some exp reward, etc. > > This can already be done, via a Python script for instance. Unless I'm > mistaking what you mean? Sort of goes to the same question above - what skills do developers need. That said, it may be reasonable to have some set of basic scripts that do basic actions (add exp, etc) - in a sense standard scripts that map makers can use without having to know scripting. they just need to be well documented. > So what I'd do is: > * remove existing quest system, which is a bastardized version > * write a Python "quests" command, with a few parameters (to get descriptions > and so on) > * write a few Python scripts to help write quest scripts and manage quests and > such > > Then it's just a matter of writing Python scripts to handle quests :) One question completely unrelated to this - would it make sense for the scripts themselves to be located in the same directory as the maps itself? For example, right now, all scripts are in python/.... This makes it a little harder to have modularized maps (I just can't tar up 'mwedel-newmaps' and send it out) - I also need to tar up the appropriate files within the python directory. If instead, I can have 'mwedel-newpaps/script1.py, ...' that is more convenient. And I'd imagine it probably wouldn't be too hard to modify the python loader to look for scripts in the same directory as the map itself. From mwedel at sonic.net Mon Aug 7 02:16:36 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 07 Aug 2006 00:16:36 -0700 Subject: [crossfire] NPC recursive bug In-Reply-To: <44D51EDA.7040608@telus.net> References: <200608051626.50008.nicolas.weeger@laposte.net> <44D4E955.4030900@sonic.net> <44D51EDA.7040608@telus.net> Message-ID: <44D6E8D4.8060701@sonic.net> I agree that adding new static variables may not be the best thing. And actually, for the NPC code, making it so it doesn't need them may not be so hard (since I think it recursives pretty locally). OTOH, it may not be so easy - I briefly looked at the apply code before formulating my reply, and it can recurse, but pretty indirectly, which is probably why it uses a static. The advantage of it actually recursing with passed in value is that it eliminates any bug where the count isn't being decremented - to start out with, you pass in zero when the player is saying something. From tchize at myrealbox.com Mon Aug 7 01:49:10 2006 From: tchize at myrealbox.com (Tchize) Date: Mon, 07 Aug 2006 08:49:10 +0200 Subject: [crossfire] Makefile fun In-Reply-To: <200608061747.56320.nicolas.weeger@laposte.net> References: <200608061747.56320.nicolas.weeger@laposte.net> Message-ID: <44D6E266.1010108@myrealbox.com> Have plugin_common make a static lib other plugins can use, that will mean duplicate code in memory when running various plugin uing common code, but that also is safer to isolate various plugins. Nicolas Weeger (Laposte) wrote: > Hello. > > I think the makefiles for the plugins are kind of weird :) > > Currently the Python makefile references directly > the ../common/plugin_common.c file, so the makefile for plugin_common is > basically useless. > > Meaning when we add files to the common directory we must update the Python > makefiles, something I think is weird. > > IMO, plugin_common should generate a library, which the Python plugin links to > during build. > > But I'm no makefile expert, so I don't want to break anything :) > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From mwedel at sonic.net Mon Aug 7 03:11:37 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 07 Aug 2006 01:11:37 -0700 Subject: [crossfire] Crossfire Release Cycles/Methodology Message-ID: <44D6F5B9.1020508@sonic.net> Per the recent discussion on code reorganization and what goes in what release, this document is an attempt to gather the points raised and make it into a formal document that can be included in the code or put on the wiki. This document does not attempt to justify or explain why different things are done for reasons of brevity - if we actually want every developer to read it, we want to stick to the what the rules are, and not as much how we arrived at those rules. If I missed anything, or there is strong disagreement on any of these points, speak up. . ------------------------------------------------------------------------------ - Crossfire versioning is described as major.minor.micro - 2.3.4 means major version 2, minor 3, micro 4 - The main (head) of the CVS branch contains what will be the next major release. - A branch for the minor releases will be made when a major release is done - It is from this stable-major branch that future minor releases are made. - If a micro release is necessary, it will be branched from the stable-major branch, as stable-major-minor. - The RE may choose to make a branch for an upcoming minor release to limit changes, as stable-major-minor. - Minor releases will be made at periodic intervals (2-4 months apart). - Micro releases will only be done if an immediate release is necessary due to a critical bug, and waiting for the next minor release is not an option. - All releases will be symbolically tagged as rel-major-minor-micro - There is no practical upper limit to minor or micro versions - crossfire 1.16.22 is valid. - Client and server releases will be done at same time, with matching version numbers. - Exception is micro releases, where it may be only the client or only the server released. - Public servers expected to run the stable branch, not the head branch. - stable branch will be made for all arch, maps, client, and server components of crossfire. - What goes in each version of Crossfire: - All changes go into the main head branch, what will become the the next major release. - Smaller features/additions will also be done in the stable branch. - Developer discretion on whether to make change to stable branch in addition to head branch - Bug fixes go in both branches. - Developer making bug fix responsible for updating both branches - Following changes can only be made in the head (next major) branch: - Changes that break compatibility - Changes that make signficant changes to the code. - Removal of programs (discontinue support for a client as an example) - Changing name of executables. - Feature set of next major release to be discussed by developers. - List of proposed changes sent to mailing list. - Developers comment, decide priorities on list of features for next major release. - For major features, brief design document needs to be written, describing the feature, why it is important, and in broad terms, how it will be done. - All changes to protocol must have a design doc, no matter how small. - Design doc must be done before changes are commited - no writing design doc after code is written - Major release is done when feature set is complete. - For 2.0, smaller list of features should be the criteria since this change of release strategy is happening later in the 1.x release cycle. ------------------------------------------------------------------------------ Open Issues: - Should we switch to SVN? Switching repositories at same time as switching what the head branch means would make the most sense. - Need some way to drive development - need some way to make sure items on TODO list for next release get done, and that developers just don't work on cool features they want that may not match TODO list. From nicolas.weeger at laposte.net Mon Aug 7 03:20:16 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 7 Aug 2006 10:20:16 +0200 Subject: [crossfire] Another bug on tracker :) Message-ID: <200608071020.16477.nicolas.weeger@laposte.net> Hello. About bug https://sourceforge.net/tracker/index.php?func=detail&aid=1527978&group_id=13833&atid=113833 "summon fog spell is somewhat broken", here's what happens: * the fog summon code uses the same code as pets * based on level, it'll generate some fog squares * it tries inserting rotating around player * when hitting a wall, it just stops trying to insert This raises the question of what the behaviour should be, for pets and fog too. Should fog appear randomly, like pets? Or always try to surround player? Or appear like "darkness" or "create earth wall", in a line perpendicular to player's direction? Nicolas From subs at eracc.com Mon Aug 7 14:49:39 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 7 Aug 2006 14:49:39 -0500 Subject: [crossfire] create earth wall totally nerfed ... Message-ID: <200608071449.40460.subs@eracc.com> I give up. I have about a dozen Zorn quest maps I have worked at on and off for the past several months on my local system that rely on players being able to cast spells and prayers through and jump over their own earth walls to survive. Unless the player is VERY high level s/he is unlikely to survive. Now that I have upgraded my local server and such-like the earth walls are horribly, horribly broken. I want the old creatable earth walls back that allowed casting through and jumping over. Please. I am not redoing these maps again and will just delete them and forget finishing the Zorn quest if this will not be done. Gene Alexander (aka poof) -- Mandriva Linux release 2006.0 (Official) for i586 14:39:22 up 1 day, 11:32, 10 users, load average: 0.30, 0.14, 0.10 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From alex_sch at telus.net Mon Aug 7 15:31:21 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 07 Aug 2006 14:31:21 -0600 Subject: [crossfire] Crossfire Release Cycles/Methodology In-Reply-To: <44D6F5B9.1020508@sonic.net> References: <44D6F5B9.1020508@sonic.net> Message-ID: <44D7A319.10901@telus.net> Mark Wedel wrote: > Per the recent discussion on code reorganization and what goes in what > release, this document is an attempt to gather the points raised and make it > into a formal document that can be included in the code or put on the wiki. > > Those rules seem to make alot of sense to me. I can't think of any disagreement I have with them. > ------------------------------------------------------------------------------ > Open Issues: > > - Should we switch to SVN? Switching repositories at same time as switching > what the head branch means would make the most sense. > I agree that when switching what the head branch means makes the most sense, however I'm not sure that to SVN would be a great type of move to me. SVN from what I've seen does address some of CVS's weaknesses, however I have heard that the way it handles branching for example is ugly. Could someone with more experience with SVN comment on branching in SVN? Also, if we are willing/able to move off of sf.net for version control, it might be worth considering other version control options (I personally think that if we don't use either SVN or CVS, we should see if we can set up a read-only CVS or SVN mirror for people to download off of who don't have the other type of version control software.) > - Need some way to drive development - need some way to make sure items > on TODO list for next release get done, and that developers just don't > work on cool features they want that may not match TODO list Well, the best method of dealing with this I've seen, is with how many projects set things like "Blocking 2.0" in their bugzilla system. We might be able to use either categories or priority with the sf.net tracker, however that seems hackish to me and wouldn't be the clearest. That said, I think if we are to continue using the sf.net tracker, it would be best to use that for TODO goals, however I think it may be worth considering moving off of sf.net for bug tracking. Alex Schultz From subs at eracc.com Mon Aug 7 16:47:38 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 7 Aug 2006 16:47:38 -0500 Subject: [crossfire] create earth wall totally nerfed ... In-Reply-To: <200608071449.40460.subs@eracc.com> References: <200608071449.40460.subs@eracc.com> Message-ID: <200608071647.39635.subs@eracc.com> On Monday 07 August 2006 02:49 pm ERACC Subscriptions wrote: > I give up. > > I have about a dozen Zorn quest maps I have worked at on and off for the > past several months on my local system that rely on players being able to > cast spells and prayers through and jump over their own earth walls to > survive. Unless the player is VERY high level s/he is unlikely to survive. > Now that I have upgraded my local server and such-like the earth walls are > horribly, horribly broken. I want the old creatable earth walls back that > allowed casting through and jumping over. Please. > > I am not redoing these maps again and will just delete them and forget > finishing the Zorn quest if this will not be done. > > Gene Alexander (aka poof) Ok, I obviously needed to take a walk and a breather before writing that. I was just SO discouraged when my maps "broke" after that upgrade. My mind was screaming "NO!NO!NO!NO!NO!NO!" when I tried to play the four basically completed maps I have that are in the depths of the earth under Zorn castle and my local level 90 character could not survive even though I know ALL the tricks in the maps. With the earth walls prior to my local "upgrade" I was able to do those maps at level 75 with that character. Alright, if a player could JUMP on and over her/his own earth walls that would be better than now. That way my maps are not going to be TOO hard just very, very challenging. I want people to survive the quest and the earth walls are the best way (if a player can figure that out). Please see what you can do to fix this at least for jumping on and over created earth walls. I will be more than willing to do any testing and provide feedback. Thanks. Gene Alexander (aka poof) -- Mandriva Linux release 2006.0 (Official) for i586 16:38:34 up 1 day, 13:31, 10 users, load average: 0.11, 0.09, 0.09 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From subs at eracc.com Mon Aug 7 19:57:10 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 7 Aug 2006 19:57:10 -0500 Subject: [crossfire] New spell? Message-ID: <200608071957.11525.subs@eracc.com> I just thought of a new spell: disinfect It would be a cone or other area prayer that removes diseases from items, critters and players. Any groups that can cast disease should also have the disinfect prayer. Perhaps make it a low level prayer that increases in power with advancement in praying. Of course it could not disinfect disease that is stronger than the caster's praying level. Gene Alexander (aka poof) -- Mandriva Linux release 2006.0 (Official) for i586 19:53:46 up 1 day, 16:46, 11 users, load average: 0.14, 0.09, 0.10 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From nicolas.weeger at laposte.net Tue Aug 8 02:14:51 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 8 Aug 2006 09:14:51 +0200 Subject: [crossfire] Crossfire Release Cycles/Methodology In-Reply-To: <44D6F5B9.1020508@sonic.net> References: <44D6F5B9.1020508@sonic.net> Message-ID: <200608080914.51924.nicolas.weeger@laposte.net> Hello. I globally agree, a few points: > - Client and server releases will be done at same time, with matching > version numbers. > - Exception is micro releases, where it may be only the client or > only the server released. This supposes client will evolve too. Experience shows client has a development cycle way slower than server. So we may have cases where client doesn't really need to be released. > - Major release is done when feature set is complete. That I'm not totally sure I agree. It's nice to agree on a feature set for next major release. But sometimes no one feels working on some point for some months, whereas code moves in another area, enough to warrant a major release. So I'd say we decide on a "wanted features list", but we can release a major anyway if enough changes were made. > - Should we switch to SVN? Switching repositories at same time as > switching what the head branch means would make the most sense. Support switching to SVN. Note that I don't think moving out of Sourceforge would make sense, unless we got really really good reasons :) > - Need some way to drive development - need some way to make sure items > on TODO list for next release get done, and that developers just don't > work on cool features they want that may not match TODO list. I don't think we can. I'd say that's the nature of voluntary work :) There may be features we think would be required for a major release, but if no one feels like implementing it, well, we can't really force people, he ^_- But hopefully if something makes it to the feature list someone put it there and is motivated to do it (yeah, that's dreaming ;p) Nicolas From nicolas.weeger at laposte.net Tue Aug 8 02:31:04 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 8 Aug 2006 09:31:04 +0200 Subject: [crossfire] Quest management system proposal In-Reply-To: <44D6E795.8080805@sonic.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608061150.18274.nicolas.weeger@laposte.net> <44D6E795.8080805@sonic.net> Message-ID: <200608080931.04812.nicolas.weeger@laposte.net> > I'd rather not have the NPC conversation be in python. IT has long been > discusses that the NPC conversation needs to be improved, with things like > conversation states, etc. This is unrelated to quests in particular - just > a general good thing to do. > > IMO, having some basic scripting syntax for states in the > message/endmessage would be a good thing - after all, map makers are people > that would be using that, and at current time, there isn't a requirement > that map makers also be programmers. I suppose and answer could be 'just > copy the npc script from elsewhere' to the less technical map makers, but > I'm not sure that is a good answer. The issue I see with this is that it adds Yet Another Scripting Language to Crossfire... Right now we're using C, autoconf/autotools, LaTeX (documentation - is it uptodate, actually??), Perl, Python, NSIS (Windows installer). Adding Crossfire's Scripting Language would add some complexity, including making sure we don't break that, add features mapmakers will want/need, and before we know we reimplemented an existing language :) What could be done, though: let mapmakers write messages with an extended syntax, like you suggested, and have a Python plugin/script handle that internally (or handle it in server core, but that's less easier to switch i think). > This also makes sense that anything the NPC says can be heard to anyone > near by (it isn't just at the player). This is why I was thinking NPC's > should have some limited state just for general conversations (the case > this really covers is when you should be able to keep saying 'yes' to the > npc to get more info, but the current mechanism doesn't allow that, so > instead players have to start guessing what is the word to continue the > conversation). > > There certainly should be state information for the player itself related > to npc conversations in some cases (especially quests). Well, then I guess it'll depend on the NPC considered. > It seems like every year or so, the discussion of what should be in C and > what should be in plugins shows up, and this is sort of one of those. I > suppose we really should come up with a standard and document it. > > But some also goes to above - the people who will use quests are > mapmakers. Should it be a requirement for mapmakers to know python/have > scripting skills to use many of the handy features of crossfire/map maker? > > If the answer there is yes, then no real issues. If the answer is no, > then we perhaps need to revisit if python is the best solution. As I said earlier, I'm not that eager to add/create a new scripting language :) > That said, it may be reasonable to have some set of basic scripts that do > basic actions (add exp, etc) - in a sense standard scripts that map makers > can use without having to know scripting. they just need to be well > documented. All methods are referenced in http://wiki.metalforge.net/doku.php/cfpython True, it could use some examples and such. OTOH, I'm sure a mapmaker not knowing how to write scripts and asking on the list or IRC would get some help. > One question completely unrelated to this - would it make sense for the > scripts themselves to be located in the same directory as the maps itself? > > For example, right now, all scripts are in python/.... Yes, it'd make sense if scripts are related to a map. Having: * mymap * mymapscripts/*py makes it easier to package the map. Note that for "local" events (ie related to a player's action, as opposed to a global event like time, death, kill, login/logout), you can already put scripts in such a subdirectory, you just have to put in the full filename. Nicolas From mwedel at sonic.net Tue Aug 8 02:44:01 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 08 Aug 2006 00:44:01 -0700 Subject: [crossfire] Crossfire Release Cycles/Methodology In-Reply-To: <44D7A319.10901@telus.net> References: <44D6F5B9.1020508@sonic.net> <44D7A319.10901@telus.net> Message-ID: <44D840C1.8020302@sonic.net> Alex Schultz wrote: > >> - Should we switch to SVN? Switching repositories at same time as switching >> what the head branch means would make the most sense. >> > I agree that when switching what the head branch means makes the most > sense, however I'm not sure that to SVN would be a great type of move to > me. SVN from what I've seen does address some of CVS's weaknesses, > however I have heard that the way it handles branching for example is > ugly. Could someone with more experience with SVN comment on branching > in SVN? Also, if we are willing/able to move off of sf.net for version > control, it might be worth considering other version control options (I > personally think that if we don't use either SVN or CVS, we should see > if we can set up a read-only CVS or SVN mirror for people to download > off of who don't have the other type of version control software.) I looked over the manual, and it is different for versions/branches. Within SVN, when doing a branch, or symbolic tag, you basically make a copy of the tree to a new location (there are svn commands for it). So under their scheme, you would have something like: crossfire/branches/1.9 crossfire/branches/1.10 ... crossfire/trunk/... (Same as CVS head). There are also commands to do merges between a revisions in a branch and the head. Thus, suppose a bugfix is made between 500 and 501 in button.c in branch 1.10. There is a svn command you can use which will pull that difference and try to apply that change to the trunk (or really, any other directory). All that looks pretty good. The downside to all of this is that things like log/history can only show ancestors of the tree you are in. Thus, a svn log of the 1.10 branch/include/define.h will show the 1.9, and so on, back to where it broke off from the trunk. Doing that within the trunk will only show the revisions in the trunk - it, for lack of better term, has no knowledge of the branches, so can't show those. Thus, managing changes in branches can become harder, as it can be harder to find out all the info related to file. For example, suppose a 1.10.1 release is needed because of a critical bug. Developer goes and makes the branch, and fixes up the file in that branch and commits it. Suppose for whatever reason, they don't update the other trees (in a rush, going on vacation, whatever). Unless you know to check out the 1.10.1 branch, you won't be able to see such a change has been made. In comparison, CVS makes this a little easier - a cvs log on foo/bar.c will show all info, including branches, for that file, so you can easily see 'ah, such and such change was made in 1.6.1.1'. I'm not sure how big a deal that really is. It certainly looks like SVN has nicer abilities to merge changes. As far as going to something else, I think it would have to be vastly better - sourceforge provides a nice free environment - it keeps things very simple - it is associated with a group, not a single person. Something that is not free or associated with one person can become a problem. Suppose there is some cool site that provides a nice source control package for a relatively nominal amount of money, and I'm willing to pay it. That works great unless I'm hit by a meteorite, and which time, that could just disappear without anyone really knowing why (same points apply to services hosted on a persons private computer, etc - it sounds reasonable, but if something happened to that computer (house burns down), first priority for that person probably isn't getting that server set up again). >> - Need some way to drive development - need some way to make sure items >> on TODO list for next release get done, and that developers just don't >> work on cool features they want that may not match TODO list > Well, the best method of dealing with this I've seen, is with how many > projects set things like "Blocking 2.0" in their bugzilla system. We > might be able to use either categories or priority with the sf.net > tracker, however that seems hackish to me and wouldn't be the clearest. > That said, I think if we are to continue using the sf.net tracker, it > would be best to use that for TODO goals, however I think it may be > worth considering moving off of sf.net for bug tracking. I don't see any issue with the SF net tracker. The real problem is that if items alpha, beta, and gamma are on the list of things to do for the next release, and someone does epsilon, which isn't on the list, do you reject the changes saying 'hey, not on the list'? We really can't do it, so what can happen is that alpha, beta, gamma might never get done but other features show up. OTOH, maybe that is a good indication that some features should be revisited - if no one is willing to work on what is considered some needed feature, maybe that feature isn't as needed as people think. From mwedel at sonic.net Tue Aug 8 02:49:16 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 08 Aug 2006 00:49:16 -0700 Subject: [crossfire] Crossfire Release Cycles/Methodology In-Reply-To: <200608080914.51924.nicolas.weeger@laposte.net> References: <44D6F5B9.1020508@sonic.net> <200608080914.51924.nicolas.weeger@laposte.net> Message-ID: <44D841FC.2090807@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > I globally agree, a few points: > >> - Client and server releases will be done at same time, with matching >> version numbers. >> - Exception is micro releases, where it may be only the client or >> only the server released. > > This supposes client will evolve too. Experience shows client has a > development cycle way slower than server. So we may have cases where client > doesn't really need to be released. True - OTOH, it isn't really harmful to release the client periodically. Actually, given this release model, the changes in the server will be greatly diminished. If we look back what was done since 1.0, all of the big features would be in the 2.0 target and missing from the 1.x releases. > >> - Major release is done when feature set is complete. > > That I'm not totally sure I agree. > It's nice to agree on a feature set for next major release. But sometimes no > one feels working on some point for some months, whereas code moves in > another area, enough to warrant a major release. > So I'd say we decide on a "wanted features list", but we can release a major > anyway if enough changes were made. Perhaps ammended that the list can be revisited at various times. If we are talking years between major releases, I think that is a requirement - how can anyone really say what things will be like 18 months from now - things may change such that some new feature/changes is critically needed. Likewise, if there are features on the list that no one is willing to do, it may be reasonable to discuss if those features should really be on that list - if the list is determined by the developers, there should probably be some willingness by the developers to work on those things. I guess the main point is that it should be a surprise to anyone when the release is done. From mwedel at sonic.net Tue Aug 8 03:03:06 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 08 Aug 2006 01:03:06 -0700 Subject: [crossfire] Quest management system proposal In-Reply-To: <200608080931.04812.nicolas.weeger@laposte.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608061150.18274.nicolas.weeger@laposte.net> <44D6E795.8080805@sonic.net> <200608080931.04812.nicolas.weeger@laposte.net> Message-ID: <44D8453A.1010104@sonic.net> Nicolas Weeger (Laposte) wrote: > The issue I see with this is that it adds Yet Another Scripting Language to > Crossfire... > Right now we're using C, autoconf/autotools, LaTeX (documentation - is it > uptodate, actually??), Perl, Python, NSIS (Windows installer). Latex stuff could probably go away - I don't know the last time anyone updated the tex stuff (but to be fair, not sure last time any documentation has been updated). > > Adding Crossfire's Scripting Language would add some complexity, including > making sure we don't break that, add features mapmakers will want/need, and > before we know we reimplemented an existing language :) OTOH, we are talking a very basic scripting language here. If we want to be technical, we could say the existing message/endmessage stuff if some very very basic scripting language - its just simple enough that it is easy to for anyone to use because it has very few options/commands. > > What could be done, though: let mapmakers write messages with an extended > syntax, like you suggested, and have a Python plugin/script handle that > internally (or handle it in server core, but that's less easier to switch i > think). One thought I did have is that the map editor could be modified to make use of such scripting easier. Have something which says the variable name, whether that is a player persistent variable or not, what operation to use (<>, =, >=, etc) and what value to check against. Likewise, another dialogue/option could be similarly used to set variables. Not sure, but one issue with the scripts right now is that they live in a separate directory, so if the map editor creates them (which would be an option), the map developer would have to know 'also include so and so script'. > All methods are referenced in http://wiki.metalforge.net/doku.php/cfpython > True, it could use some examples and such. But that just lists what you can use in writing a python script. It doesn't say what scripts may be available for use already and how to use them. For example, if the method we decide to go for is that we will use scripts to give out exp, then it probably would make sense to have a generic script that takes some parameters on what skill and how much exp to add, so you could do something like: event_activate give_exp.pyc throwing 6000 (no idea if that is really the correct syntax, but you get the point). If that is done, then the give_exp.pyc, and other general purpose scripts need to be well documented so people know about them That is one advantage of archetypes - while it may be hard to find something, they are all available in the editor, and the editor provides customized dialogues based on type. So if there was an exp giving archetype, the editor file would be modified to ask for the skill to give, how much exp to give, and perhaps some other parameters (all members of the party, etc). > > OTOH, I'm sure a mapmaker not knowing how to write scripts and asking on the > list or IRC would get some help. True, but I'm not sure if that is indication of a good design/easy to use system. Most people want instant gratification - if they have to wait hours or more to get the answer for something like 'how do I give an exp reward to a character', they may get a bit discouraged. And just going forward, it doesn't seem like 'get a developer to help you write your maps' isn't really the right thing to say. This is why I push for the idea the common/general purpose operations should be in the core server with archetype attached to it, so it is easy for people to use. Of course, an archetype with a script created could be made, with certain fields of that archetype containing the skill and exp. But then you start to ask, if we're going to do that, why don't we just write the C code? From lalo.martins at gmail.com Tue Aug 8 03:19:28 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 08 Aug 2006 16:19:28 +0800 Subject: [crossfire] Crossfire Release Cycles/Methodology References: <44D6F5B9.1020508@sonic.net> <44D7A319.10901@telus.net> <44D840C1.8020302@sonic.net> Message-ID: On Tue, 08 Aug 2006 00:44:01 -0700, Mark Wedel wrote: > Alex Schultz wrote: >>> - Should we switch to SVN? Switching repositories at same time as switching >>> what the head branch means would make the most sense. >>> >> I agree that when switching what the head branch means makes the most >> sense, however I'm not sure that to SVN would be a great type of move to >> me. SVN from what I've seen does address some of CVS's weaknesses, >> however I have heard that the way it handles branching for example is >> ugly. Could someone with more experience with SVN comment on branching >> in SVN? Also, if we are willing/able to move off of sf.net for version >> control, it might be worth considering other version control options (I >> personally think that if we don't use either SVN or CVS, we should see >> if we can set up a read-only CVS or SVN mirror for people to download >> off of who don't have the other type of version control software.) I have written broadly over SVN a few months ago, I'd rather not repeat myself: http://lalo.revisioncontrol.net/entry/oooh-lets-migrate-to-svn > I'm not sure how big a deal that really is. It certainly looks like > SVN has > nicer abilities to merge changes. Merging between multiple branches -- in this case, potentially applying an important fix to the trunk, stable branch, last release branch, micro branch, and a branch frozen as candidate for the next release -- is not so simple; even CVS does this better than SVN. Merging between two branches -- eg trunk and stable -- more than once is inconvenient in CVS and nightmarish in SVN. > As far as going to something else, I think it would have to be vastly > better - sourceforge provides a nice free environment - it keeps > things very simple - it is associated with a group, not a single > person. > > Something that is not free or associated with one person can become a > problem. Suppose there is some cool site that provides a nice source > control package for a relatively nominal amount of money I don't think anyone's talking about a non-free alternative. I believe the idea is to try some proper revision control system like bzr (there's free hosting at launchpad.net; you can host your own using only ssh and a webserver), git/cogito (used by the kernel and many freedesktop.org packages; I'm sure there must be free hosting somewhere) or darcs (again, needs only ssh and http to host). IIRC, we've had this discussion before... more or less once every 5 months or so... 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 alex_sch at telus.net Tue Aug 8 03:28:13 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 08 Aug 2006 02:28:13 -0600 Subject: [crossfire] Crossfire Release Cycles/Methodology In-Reply-To: <44D840C1.8020302@sonic.net> References: <44D6F5B9.1020508@sonic.net> <44D7A319.10901@telus.net> <44D840C1.8020302@sonic.net> Message-ID: <44D84B1D.8060400@telus.net> Mark Wedel wrote: > As far as going to something else, I think it would have to be vastly better - > sourceforge provides a nice free environment - it keeps things very simple - it > is associated with a group, not a single person. > > Something that is not free or associated with one person can become a problem. > Suppose there is some cool site that provides a nice source control package > for a relatively nominal amount of money, and I'm willing to pay it. That works > great unless I'm hit by a meteorite, and which time, that could just disappear > without anyone really knowing why (same points apply to services hosted on a > persons private computer, etc - it sounds reasonable, but if something happened > to that computer (house burns down), first priority for that person probably > isn't getting that server set up again). For such reasons I would agree, we shouldn't go for something that is not free, or associated with one person. My point was more saying that perhaps it would be worth also evaluating the possibility of using some other version control system such as bazaar-ng (personally I think that's a pretty good one, however I don't think it would be a great idea for cf, largely because it becomes rather slow with source trees as large as crossfire, but I was just primarily using that as an example). Personally I currently think that either SVN or CVS are the best options for crossfire, but I just wanted to make a point that other options are worth looking at a little too. In terms of hosting, that is an issue for use of other, the metalforge server may or may not work (don't know if Leaf would or not), however that too has a little bit of those "associated with one person" potential issues, though it is less significant. One thought, is distributed version control systems would make "associated with one person" issues less significant, thought it wouldn't eliminate those issues. Alex Schultz From alex_sch at telus.net Tue Aug 8 03:55:36 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 08 Aug 2006 02:55:36 -0600 Subject: [crossfire] Crossfire Release Cycles/Methodology In-Reply-To: References: <44D6F5B9.1020508@sonic.net> <44D7A319.10901@telus.net> <44D840C1.8020302@sonic.net> Message-ID: <44D85188.7000102@telus.net> Lalo Martins wrote: > > Ahh yes, those are the sorts of SVN issues I've heard about, though I'm not experienced with SVN myself. > I believe the idea is to try some proper revision control system like bzr (there's > free hosting at launchpad.net; you can host your own using only ssh and > a webserver), git/cogito (used by the kernel and many freedesktop.org > packages; I'm sure there must be free hosting somewhere) or darcs (again, > needs only ssh and http to host). One little note, bzr I find to be rather nice, however I find it's a bit annoyingly memory and cpu intensive on source trees as large as cf. git/cogito looks interesting, the tools seem pretty nice from what little I've looked at, though it will be a bit of pain under windows (and we do have a couple windows-using developers) as under windows it requires cygwin. One other thought, darcs looks like an interesting one too, however the fact that it's written in hacksel makes it a bit of a pain to compile if one can't get binaries for one's system. Personally I'm thinking just sticking with CVS is best though, largely due to sticking with sf being easiest. I'm now thinking that SVN wouldn't be too bad, but wouldn't be worth switching from CVS to use unless one has some significant reason. Alex Schultz From nicolas.weeger at laposte.net Tue Aug 8 14:09:09 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 8 Aug 2006 21:09:09 +0200 Subject: [crossfire] New spell? In-Reply-To: <200608071957.11525.subs@eracc.com> References: <200608071957.11525.subs@eracc.com> Message-ID: <200608082109.09655.nicolas.weeger@laposte.net> Le Mardi 08 Ao?t 2006 02:57, ERACC Subscriptions a ?crit?: > I just thought of a new spell: disinfect > > It would be a cone or other area prayer that removes diseases from items, > critters and players. Any groups that can cast disease should also have the > disinfect prayer. Perhaps make it a low level prayer that increases in > power with advancement in praying. Of course it could not disinfect disease > that is stronger than the caster's praying level. Could be a fun one :) It's basically a higher level cure disease, though. Nicolas From subs at eracc.com Tue Aug 8 21:25:19 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Tue, 8 Aug 2006 21:25:19 -0500 Subject: [crossfire] New spell? In-Reply-To: <200608082109.09655.nicolas.weeger@laposte.net> References: <200608071957.11525.subs@eracc.com> <200608082109.09655.nicolas.weeger@laposte.net> Message-ID: <200608082125.20483.subs@eracc.com> On Tuesday 08 August 2006 02:09 pm Nicolas Weeger (Laposte) wrote: > Le Mardi 08 Ao?t 2006 02:57, ERACC Subscriptions a ?crit?: > > I just thought of a new spell: disinfect > > > > It would be a cone or other area prayer that removes diseases from items, > > critters and players. [...] > > Could be a fun one :) > It's basically a higher level cure disease, though. True. Cure disease works on players. Thus the "disinfect" spell would work on places and objects (maybe NPCs, pets and monsters?). I know that some diseases leave hidden debris behind that can cause a player walking over or near the space to get infected. So, no need to have disinfect and cure disease overlap. One can be for players the other for all else. Gene Alexander (aka poof) -- Mandriva Linux release 2006.0 (Official) for i586 21:17:43 up 2 days, 18:10, 12 users, load average: 0.32, 0.24, 0.14 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From alex_sch at telus.net Wed Aug 9 00:12:24 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 08 Aug 2006 23:12:24 -0600 Subject: [crossfire] New spell? In-Reply-To: <200608082125.20483.subs@eracc.com> References: <200608071957.11525.subs@eracc.com> <200608082109.09655.nicolas.weeger@laposte.net> <200608082125.20483.subs@eracc.com> Message-ID: <44D96EB8.5050802@telus.net> ERACC Subscriptions wrote: > On Tuesday 08 August 2006 02:09 pm > Nicolas Weeger (Laposte) wrote: >> Le Mardi 08 Ao?t 2006 02:57, ERACC Subscriptions a ?crit : >> >>> I just thought of a new spell: disinfect >>> >>> It would be a cone or other area prayer that removes diseases from items, >>> critters and players. [...] >>> >> Could be a fun one :) >> It's basically a higher level cure disease, though. >> > > True. Cure disease works on players. Thus the "disinfect" spell would work on > places and objects (maybe NPCs, pets and monsters?). I know that some > diseases leave hidden debris behind that can cause a player walking over or > near the space to get infected. So, no need to have disinfect and cure > disease overlap. One can be for players the other for all else. I'm thinking that perhaps it might be interesting to in addition make it deal a very very minor amount of damage (however so minor it would be hard to even kill a mouse), which would make things get angry for getting disinfectant magic in their eyes :) Alex Schultz From mwedel at sonic.net Wed Aug 9 00:47:01 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 08 Aug 2006 22:47:01 -0700 Subject: [crossfire] Crossfire Release Cycles/Methodology In-Reply-To: <44D85188.7000102@telus.net> References: <44D6F5B9.1020508@sonic.net> <44D7A319.10901@telus.net> <44D840C1.8020302@sonic.net> <44D85188.7000102@telus.net> Message-ID: <44D976D5.5060903@sonic.net> Some of SVN big advantages appears to be able to work offline (keeps copy of data you checked out around so you can do diffs without needing connection, as well as ungets). Some of the other features may not make as big a difference to us - ability to use different connection methods (that really is up to the hosting agent) and better binary support. But the fact it doesn't do branching as well as CVS is probably a major shortcoming, especially since we are looking at needing to use branches a lot more. I'm not sure about the other systems out there - once can spend a lot of time looking over all the documentation, etc. AS with our last discussion, I'm most inclined to stick with CVS since we know what it does and doesn't have any real major shortcomings (it works right now). From nicolas.weeger at laposte.net Wed Aug 9 02:33:28 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Wed, 9 Aug 2006 09:33:28 +0200 Subject: [crossfire] Quest management system proposal In-Reply-To: <44D8453A.1010104@sonic.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608080931.04812.nicolas.weeger@laposte.net> <44D8453A.1010104@sonic.net> Message-ID: <200608090933.28972.nicolas.weeger@laposte.net> > Latex stuff could probably go away - I don't know the last time anyone > updated the tex stuff (but to be fair, not sure last time any documentation > has been updated). Actually, it seems to be kind of uptodate, since it generates data from archetypes and such. I'd be more inclined to keep it - spoilers, handbook and such are nice. Also a list of gods is nice to have locally. (could be used to make PDF manuals distributed with client) > OTOH, we are talking a very basic scripting language here. If we want to > be technical, we could say the existing message/endmessage stuff if some > very very basic scripting language - its just simple enough that it is easy > to for anyone to use because it has very few options/commands. True. But at some point people will want more than what the message/endmessage offers, so we'll be back at square one - either use our own scripting language, or an existing one. > One thought I did have is that the map editor could be modified to make > use of such scripting easier. Have something which says the variable name, > whether that is a player persistent variable or not, what operation to use > (<>, =, >=, etc) and what value to check against. > > Likewise, another dialogue/option could be similarly used to set > variables. Yes, if dialog is a state automate, it could be created through dialog boxes. > Not sure, but one issue with the scripts right now is that they live in a > separate directory, so if the map editor creates them (which would be an > option), the map developer would have to know 'also include so and so > script'. Scripts can be put in any directory :) > But that just lists what you can use in writing a python script. > > It doesn't say what scripts may be available for use already and how to > use them. > > For example, if the method we decide to go for is that we will use > scripts to give out exp, then it probably would make sense to have a > generic script that takes some parameters on what skill and how much exp to > add, so you could do something like: > > event_activate give_exp.pyc throwing 6000 > > (no idea if that is really the correct syntax, but you get the point). > > If that is done, then the give_exp.pyc, and other general purpose scripts > need to be well documented so people know about them Yes, but there aren't many scripts around - the IPO, a few related to guilds, casino, misc. They should probably be documented, yes. Note that right now you can't easily directly add exp to a skill, but imo that's a function to be added. Will try to do that at some point. > That is one advantage of archetypes - while it may be hard to find > something, they are all available in the editor, and the editor provides > customized dialogues based on type. So if there was an exp giving > archetype, the editor file would be modified to ask for the skill to give, > how much exp to give, and perhaps some other parameters (all members of the > party, etc). True. Then maybe editor could be extended to know about Python functions, and our built-in stuff :) > True, but I'm not sure if that is indication of a good design/easy to use > system. > > Most people want instant gratification - if they have to wait hours or > more to get the answer for something like 'how do I give an exp reward to a > character', they may get a bit discouraged. > > And just going forward, it doesn't seem like 'get a developer to help you > write your maps' isn't really the right thing to say. This is why I push > for the idea the common/general purpose operations should be in the core > server with archetype attached to it, so it is easy for people to use. > > Of course, an archetype with a script created could be made, with certain > fields of that archetype containing the skill and exp. But then you start > to ask, if we're going to do that, why don't we just write the C code? But at some point there will need to have a developer involved, when the script starts to become complex. Yes a mapmaker could, with a simple script, make a quest to have a player deliver an item from one NPC to another. But to check whether 5 players do the Holy Dance of Purification correctly to finish the temple cleaning quest, you'll need more than what message/endmessage offers :) I agree though we should try to make it the easiest for mapmakers, by offering the more easy functions to access. Nicolas From tchize at myrealbox.com Wed Aug 9 07:13:28 2006 From: tchize at myrealbox.com (Tchize) Date: Wed, 09 Aug 2006 14:13:28 +0200 Subject: [crossfire] Crossfire Release Cycles/Methodology In-Reply-To: <44D976D5.5060903@sonic.net> References: <44D6F5B9.1020508@sonic.net> <44D7A319.10901@telus.net> <44D840C1.8020302@sonic.net> <44D85188.7000102@telus.net> <44D976D5.5060903@sonic.net> Message-ID: <44D9D168.7090304@myrealbox.com> svn does branching and tagging, and according to this faq (http://subversion.tigris.org/faq.html#merge-using-tags) it does it pretty well. basically svn does this to handle branching and merging copy trunk -> myBranch copy myBranch -> myBranchMerged modify myBranch at will copy the diff between myBranch and myBranchMerged to trunk CVS on his side does this tag the main branch create a branch from given tag (don't forget to give that branch a name that must be different than tag) modify the branch copy all changes made to branch to main As a result, same number of operation, and svn is 'supposed' to be faster than cvs at this because the operations do not depend on repository size but on change size. I think that because the branch name appear in url, it make it easier for user to checkout a given branch or revision from anonymous svn and the fact branches appear on http browsing (which is not the case of svn) is also a pro for svn. Mark Wedel wrote: > Some of SVN big advantages appears to be able to work offline (keeps copy of > data you checked out around so you can do diffs without needing connection, as > well as ungets). Some of the other features may not make as big a difference to > us - ability to use different connection methods (that really is up to the > hosting agent) and better binary support. > > But the fact it doesn't do branching as well as CVS is probably a major > shortcoming, especially since we are looking at needing to use branches a lot more. > > I'm not sure about the other systems out there - once can spend a lot of time > looking over all the documentation, etc. AS with our last discussion, I'm most > inclined to stick with CVS since we know what it does and doesn't have any real > major shortcomings (it works right now). > > > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From nicolas.weeger at laposte.net Thu Aug 10 02:10:06 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Thu, 10 Aug 2006 09:10:06 +0200 Subject: [crossfire] Crossfire Release Cycles/Methodology In-Reply-To: <44D976D5.5060903@sonic.net> References: <44D6F5B9.1020508@sonic.net> <44D85188.7000102@telus.net> <44D976D5.5060903@sonic.net> Message-ID: <200608100910.06110.nicolas.weeger@laposte.net> > I'm not sure about the other systems out there - once can spend a lot of > time looking over all the documentation, etc. AS with our last discussion, > I'm most inclined to stick with CVS since we know what it does and doesn't > have any real major shortcomings (it works right now). I'm in no way CVS/SVN expert (I use both, but I never really played with branches). IMO, if SVN isn't too bad for branches, we should switch. SVN has atomic transactions, that's a great feature, specially with upcoming talk about restructuration and such - makes it much easier to revert commits. Nicolas From tchize at myrealbox.com Thu Aug 10 02:50:27 2006 From: tchize at myrealbox.com (Tchize) Date: Thu, 10 Aug 2006 09:50:27 +0200 Subject: [crossfire] Crossfire Release Cycles/Methodology In-Reply-To: <200608100910.06110.nicolas.weeger@laposte.net> References: <44D6F5B9.1020508@sonic.net> <44D85188.7000102@telus.net> <44D976D5.5060903@sonic.net> <200608100910.06110.nicolas.weeger@laposte.net> Message-ID: <44DAE543.4070503@myrealbox.com> Also, about restructurations of code, svn unlike cvs does not 'forget' the history of a file when it's moved. I use cvs a lot for work and dureing refactoring of our code (which happens from time to time) we already lost versions of some files because they were deleted / restored / deleted and as result, you have an unconsistent attic (2 files with same name at same directory got deleted, you only have access to latest on in Attic) Nicolas Weeger (Laposte) wrote: >> I'm not sure about the other systems out there - once can spend a lot of >> time looking over all the documentation, etc. AS with our last discussion, >> I'm most inclined to stick with CVS since we know what it does and doesn't >> have any real major shortcomings (it works right now). >> > > I'm in no way CVS/SVN expert (I use both, but I never really played with > branches). > > IMO, if SVN isn't too bad for branches, we should switch. SVN has atomic > transactions, that's a great feature, specially with upcoming talk about > restructuration and such - makes it much easier to revert commits. > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From fuchs.andy at gmail.com Thu Aug 10 21:17:14 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Thu, 10 Aug 2006 22:17:14 -0400 Subject: [crossfire] create earth wall totally nerfed ... In-Reply-To: <200608071647.39635.subs@eracc.com> References: <200608071449.40460.subs@eracc.com> <200608071647.39635.subs@eracc.com> Message-ID: On 8/7/06, ERACC Subscriptions wrote: ... > Alright, if a player could JUMP on and over her/his own earth walls that would > be better than now. That way my maps are not going to be TOO hard just very, > very challenging. I want people to survive the quest and the earth walls are > the best way (if a player can figure that out). Please see what you can do to > fix this at least for jumping on and over created earth walls. I will be more > than willing to do any testing and provide feedback. Thanks. I'm thinking that adding a new movement type, then redoing the jumping code to use it, would probably be the best way to go. Anyone want to comment or impliment this? -- Andrew Fuchs From fuchs.andy at gmail.com Thu Aug 10 21:57:25 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Thu, 10 Aug 2006 22:57:25 -0400 Subject: [crossfire] Quest management system proposal In-Reply-To: <200608090933.28972.nicolas.weeger@laposte.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608080931.04812.nicolas.weeger@laposte.net> <44D8453A.1010104@sonic.net> <200608090933.28972.nicolas.weeger@laposte.net> Message-ID: This is starting too look like the discussion on implimenting LUA for scripting. http://mailman.metalforge.org/pipermail/crossfire/2005-July/008844.html Also, IIRC, there is nothing stopping someone from putting scripts anywhere in the map tree. Every hook into a script that i've seen uses a full path (with the map directory as root). -- Andrew Fuchs From mwedel at sonic.net Fri Aug 11 00:36:48 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 10 Aug 2006 22:36:48 -0700 Subject: [crossfire] create earth wall totally nerfed ... In-Reply-To: References: <200608071449.40460.subs@eracc.com> <200608071647.39635.subs@eracc.com> Message-ID: <44DC1770.5020102@sonic.net> Andrew Fuchs wrote: > On 8/7/06, ERACC Subscriptions wrote: > ... >> Alright, if a player could JUMP on and over her/his own earth walls that would >> be better than now. That way my maps are not going to be TOO hard just very, >> very challenging. I want people to survive the quest and the earth walls are >> the best way (if a player can figure that out). Please see what you can do to >> fix this at least for jumping on and over created earth walls. I will be more >> than willing to do any testing and provide feedback. Thanks. > > I'm thinking that adding a new movement type, then redoing the jumping > code to use it, would probably be the best way to go. Anyone want to > comment or impliment this? a new movement type for jump? I suppose that could be done - OTOH, I'm not sure how many movement types we want. One theory, and what I originally envisioned, was keeping them fairly broad - walking, fly low, fly high (spells vs say flying on a dragon), swimming, boat. The other side is that you have a movement type for every particular way of moving - crawl, run, jump, swim, skip, etc. The later provides lots of way to control movement. OTOH, if movement types are automatic, it may not mean much (ok, you have to crawl in that low passage, but since you will crawl automatically, what difference does it make?), etc. That said, looking at the actual problem at hand, I think this is the commit that changed the behaviour: revision 1.4 date: 2006/06/01 17:24:00; author: akirschbaum; state: Exp; lines: +1 -0 Make earthwalls block all movement types. This makes the spell earth to dust wor k again. Yet all the earth to dust code looks for is: if (GET_MAP_MOVE_BLOCK(m, sx, sy)) { ... } So the move_block for earthwalls could be changed to just block move_walk, and you could jump over the earthwalls and earth to dust would still work. The downside is that spells then go over earthwalls, since most spells fly. I think letting spells go over (through) earthwalls would cause problems on some maps. One possibility is to make a new earthwall archetype that only blocks walking and have the spell use that new archetype, so earthwalls created by the spell only block walking, but those on maps block everything. Map makers could of course change behaviour of earthwalls on maps to match what they want it to do. I'm not sure if that causes any problems - letting players fire spells or other attacks over earthwalls at monsters may cause problems, as I'm not 100% sure all monsters are smart enough to try and break through the earthwall (but that could then be considered a different problem). From fuchs.andy at gmail.com Fri Aug 11 20:36:19 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri, 11 Aug 2006 21:36:19 -0400 Subject: [crossfire] create earth wall totally nerfed ... In-Reply-To: <44DC1770.5020102@sonic.net> References: <200608071449.40460.subs@eracc.com> <200608071647.39635.subs@eracc.com> <44DC1770.5020102@sonic.net> Message-ID: On 8/11/06, Mark Wedel wrote: ... > a new movement type for jump? I suppose that could be done - OTOH, I'm not > sure how many movement types we want. > > One theory, and what I originally envisioned, was keeping them fairly broad - > walking, fly low, fly high (spells vs say flying on a dragon), swimming, boat. > > The other side is that you have a movement type for every particular way of > moving - crawl, run, jump, swim, skip, etc. > > The later provides lots of way to control movement. OTOH, if movement types > are automatic, it may not mean much (ok, you have to crawl in that low passage, > but since you will crawl automatically, what difference does it make?), etc. It depends. Can everyone and everything crawl, or only a few races or monsters? > That said, looking at the actual problem at hand, I think this is the commit > that changed the behaviour: > > revision 1.4 > date: 2006/06/01 17:24:00; author: akirschbaum; state: Exp; lines: +1 -0 > Make earthwalls block all movement types. This makes the spell earth to dust wor > k again. > > Yet all the earth to dust code looks for is: > if (GET_MAP_MOVE_BLOCK(m, sx, sy)) { > ... > } > > So the move_block for earthwalls could be changed to just block move_walk, and > you could jump over the earthwalls and earth to dust would still work. > > The downside is that spells then go over earthwalls, since most spells fly. I > think letting spells go over (through) earthwalls would cause problems on some maps. > > One possibility is to make a new earthwall archetype that only blocks walking > and have the spell use that new archetype, so earthwalls created by the spell > only block walking, but those on maps block everything. Map makers could of > course change behaviour of earthwalls on maps to match what they want it to do. Yes, if you can jump over earthwalls, they are probably low enough to fly over. > I'm not sure if that causes any problems - letting players fire spells or > other attacks over earthwalls at monsters may cause problems, as I'm not 100% > sure all monsters are smart enough to try and break through the earthwall (but > that could then be considered a different problem). Flying mobs would be able to get over too, but every spell has its limits, right? Though i don't think that most mobs would fly over one, unless they are able to see a target (possible redo of the line of site code for everything). Earthwalls are general used by players for protection, either by limiting the movement of monsters, or blocking spells and other projectiles. On the other hand, mobs don't cast spells unless they have a target, so another player or a friendly mob would have to be visible to the hostile mobs. This would additionally stop players hiding behind earthwalls from exploiting "charm monsters" in most situations. Whether this is desirable or not is up for debate. However it will not fix every instance of charm-killing. -- Andrew Fuchs From mwedel at sonic.net Sat Aug 12 00:50:39 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 11 Aug 2006 22:50:39 -0700 Subject: [crossfire] create earth wall totally nerfed ... In-Reply-To: References: <200608071449.40460.subs@eracc.com> <200608071647.39635.subs@eracc.com> <44DC1770.5020102@sonic.net> Message-ID: <44DD6C2F.8060907@sonic.net> Andrew Fuchs wrote: > On 8/11/06, Mark Wedel wrote: > ... >> a new movement type for jump? I suppose that could be done - OTOH, I'm not >> sure how many movement types we want. >> >> One theory, and what I originally envisioned, was keeping them fairly broad - >> walking, fly low, fly high (spells vs say flying on a dragon), swimming, boat. >> >> The other side is that you have a movement type for every particular way of >> moving - crawl, run, jump, swim, skip, etc. >> >> The later provides lots of way to control movement. OTOH, if movement types >> are automatic, it may not mean much (ok, you have to crawl in that low passage, >> but since you will crawl automatically, what difference does it make?), etc. > > It depends. Can everyone and everything crawl, or only a few races or monsters? A fair question. But that is why I think addition of movement types needs some discussion - otherwise, the potential for having 20 movement types and then looking at them and saying 'well, crawl and slither are really the same, levitate and fly is the same, etc'. Of course, this really gets driven by having some reason for the different movement type - there isn't any reason to add a crawl movement type if everyone that has walk also has crawl. And my thought is more that movement types should be general to describe constraints on the movement, and not the movement type itself. Eg, instead of saying crawl is a movement type, you'd instead have a movement type that denotes that the space is small/limited. So that you give small creatures that movement type also (for example, the small snakes). If you say crawl, you get the case of people saying 'well, snakes don't crawl, so that doesn't make sense'. >> One possibility is to make a new earthwall archetype that only blocks walking >> and have the spell use that new archetype, so earthwalls created by the spell >> only block walking, but those on maps block everything. Map makers could of >> course change behaviour of earthwalls on maps to match what they want it to do. > > Yes, if you can jump over earthwalls, they are probably low enough to fly over. agree. > >> I'm not sure if that causes any problems - letting players fire spells or >> other attacks over earthwalls at monsters may cause problems, as I'm not 100% >> sure all monsters are smart enough to try and break through the earthwall (but >> that could then be considered a different problem). > > Flying mobs would be able to get over too, but every spell has its > limits, right? Though i don't think that most mobs would fly over > one, unless they are able to see a target (possible redo of the line > of site code for everything). I think that in general, if a monster is hit by an attack, it will make the person that did the damage its enemy. Now whether the monster in this case will be smart enough to actually figure its way over the earthwall is a different discussion. Some monsters do have a flag which says to tear the earthwalls down. If the problem is that monsters are too stupid, we should fix that logic, and not limit the earthwalls. There are certainly cases where there are bugs that players exploit. However, if players are reasonably clever on the use of spells, we shouldn't go and try to prevent the players from using those tricks, but rather make the monsters smart enough to try and avoid it, etc (or at least monsters that should be smart enough). It is completely reasonable to me that if you put up and earthwall, you should be able to pick off things like snakes, rats, or other stupid creatures with out them getting to you in return. Those are pretty low exp creatures, so if a player really wants to spend the time to get exp safely but slowly, that is fine by me. From mwedel at sonic.net Sat Aug 12 01:36:24 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 11 Aug 2006 23:36:24 -0700 Subject: [crossfire] Quest management system proposal In-Reply-To: <200608090933.28972.nicolas.weeger@laposte.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608080931.04812.nicolas.weeger@laposte.net> <44D8453A.1010104@sonic.net> <200608090933.28972.nicolas.weeger@laposte.net> Message-ID: <44DD76E8.9000500@sonic.net> Nicolas Weeger (Laposte) wrote: >> Latex stuff could probably go away - I don't know the last time anyone >> updated the tex stuff (but to be fair, not sure last time any documentation >> has been updated). > > Actually, it seems to be kind of uptodate, since it generates data from > archetypes and such. > I'd be more inclined to keep it - spoilers, handbook and such are nice. Also a > list of gods is nice to have locally. > (could be used to make PDF manuals distributed with client) But there is html version of that same data. Granted, HTML doesn't print out as nicely, but I wonder how many people really print out the crossfire information (I actually rarely print out information of any sort - having it on the computer often makes it easier to search). The spoiler is pretty much completely generated from archetype data, so yes, it probably remains up to date. The handbook has a lot more static data. The reason that is probably still up to date (effectively) is that there haven't been changes made that conflict/contradict the data that is there. A lot of changes we are talking about in the future would likely make some portion of this data out of date. At some point, it is a bit of a bother to have to update 2 different files (html + latex). But more to the point, not sure how many people really use the latex data vs the html (I wonder how many people use latex in general now, given that there are lots more good & free WYSIWIG editors for *nix now). > >> OTOH, we are talking a very basic scripting language here. If we want to >> be technical, we could say the existing message/endmessage stuff if some >> very very basic scripting language - its just simple enough that it is easy >> to for anyone to use because it has very few options/commands. > > True. But at some point people will want more than what the message/endmessage > offers, so we'll be back at square one - either use our own scripting > language, or an existing one. Maybe. I'm not 100% sure that is a compelling argument - on that basis, anything done could be considered incomplete because it may not do something that someone may want in the future. Of course, it could be a case that you do the conversation by plugin, and people see it too cumbersome/complicated for basic conversation, and a 'conversation light' syntax is added without need for plugins. Right now of course, there is no real scripting at all for messages. So any addition, well, adds functionality, so basic scripting as I described may be enough for a large number of needs, and if it goes beyond that, then telling them to write a script would seem reasonable. >> If that is done, then the give_exp.pyc, and other general purpose scripts >> need to be well documented so people know about them > > Yes, but there aren't many scripts around - the IPO, a few related to guilds, > casino, misc. They should probably be documented, yes. > > Note that right now you can't easily directly add exp to a skill, but imo > that's a function to be added. Will try to do that at some point. My point for scripts is that if general purpose scripts are added, for things like adding experience, etc, then those scripts need to be documented so it is easy for people to use. But I'll also continue to say that there should be an archetype that can be used to add exp, and that it shouldn't be necessary to use a script for such a basic operation. From alex_sch at telus.net Sat Aug 12 02:43:36 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 12 Aug 2006 01:43:36 -0600 Subject: [crossfire] Quest management system proposal In-Reply-To: <44DD76E8.9000500@sonic.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608080931.04812.nicolas.weeger@laposte.net> <44D8453A.1010104@sonic.net> <200608090933.28972.nicolas.weeger@laposte.net> <44DD76E8.9000500@sonic.net> Message-ID: <44DD86A8.4090106@telus.net> Mark Wedel wrote: > The spoiler is pretty much completely generated from archetype data, so yes, > it probably remains up to date. One little note about that, thought it's generated from archetype data, it's still rather out of date/incomplete in areas (particularly spells) because it doesn't account for new attributes and alternative attribute meanings that weren't considered. Alex Schultz From mwedel at sonic.net Sat Aug 12 02:50:59 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 12 Aug 2006 00:50:59 -0700 Subject: [crossfire] crossfire source code control systems Message-ID: <44DD8863.4000401@sonic.net> The recent discussion on the release cycle lead to another conversation about what source code system could be used. There seemed to be a lot of opinions on what should be used without any real clear test to see what is needed. I think a better way would be to define what crossfire needs are, and then see what system meets those needs best. (as an aside, at current time, it seems like we'll stick with CVS for now, as there isn't any system that clearly seems better, and CVS is working for us right now. Second aside is other than official support from sourceforge, mercurial seems better than SVN). Please note that this list probably isn't complete. Before we start going over what each system provides, we should first make sure this list complete. Also, it is probably reasonable that some of these perhaps move between categories I put them in - these categories are just from my point of view. Key requirements (if it doesn't meet these, not usuable - probably everything out there does) --------------- - Network based access (checkouts and commits - shouldn't be a need to log in to a specific host to do a commit) - Multiplatform (*nix & windows at minimum) - Access control lists (limit specific people on who can do check ins). - Read-only access to everyone. - Supported by sourceforge, or secondarily, some other free hosting service (I'd much rather someone else has to deal with any adminstrative issues of the software, like update to latest version, etc) - E-mail notification of commits. - Ability to convert to CVS to whatever the new format is. Top Features: ------------------- - Readily available/easily installable software (shouldn't need to do a dozen steps to be able to install/use the software) - Tracking of when merges are done. - Good branch handling (fairly vague here, as not sure what would be considered good in this case, as I don't think CVS is that great as is). - Efficient use of resources (network bandwidth, cpu, etc) - it shouldn't take 15 minutes to check out the server, for example. - Global revisioning - instead of each file having a revision that increases, there is a global revision - this makes it very easy to get status right before commits or back out changes. - support for symbolic tagging within the repository (and not have to create another repository as the tag) Other nice to have features: ---------------------------- - Atomic checkins (killing your checkin while happening shouldn't leave repository in inconsistent state - I don't think we have ever run into this, and there are not a huge number of files in crossfire repository which is why this is lower priority) - Maximum ability to do SCCS operations without access to repository (diffs, status, etc). - good binary file handling (this may be a duplicate of efficient use of resources. This also really comes in with the crossfire.[01] files in the lib directory, which given how that file is constructed, not sure exactly how much better the binary diffs can handle that) - Ability to do local branches (and make those branches available to others) I know I'm forgetting something, which is why I'm sending this out. From alex_sch at telus.net Sat Aug 12 04:13:14 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 12 Aug 2006 03:13:14 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44DD8863.4000401@sonic.net> References: <44DD8863.4000401@sonic.net> Message-ID: <44DD9BAA.3010703@telus.net> Mark Wedel wrote: > Key requirements (if it doesn't meet these, not usuable - probably everything > out there does) > --------------- > - Network based access (checkouts and commits - shouldn't be a need to log in to > a specific host to do a commit) > Well, some/most distributed SCMs technically require 'logging into' a host to push to it, however that process is usually handled completely transparently via ssh, so I think that counts sufficiently as 'network based access'. > - Access control lists (limit specific people on who can do check ins). > Most distributed SCMs (including bzr and Mercurial) I see tend to rely on ssh authentication to deal with this. IMHO this is sufficient for access control, though it isn't really an "access control list". > - Supported by sourceforge, or secondarily, some other free hosting service (I'd > much rather someone else has to deal with any adminstrative issues of the > software, like update to latest version, etc) > That is a trickier requirement and limits things a bit. Most mainstream ones are just CVS and/or SVN. Launchpad.net (funded/ran by Canonical Ltd.) provides bzr SCM. Also, Mercurial can run out of sf.net project web space. However I've missed some hosting or something else can run in project web space, I don't think we can look go beyond CVS, SVN, bzr, and Mercurial with this requirement (not that it's a problem, just that unless someone knows of something I've missed, that's something that limits our choices). > Top Features: > ------------------- > - Efficient use of resources (network bandwidth, cpu, etc) - it shouldn't take > 15 minutes to check out the server, for example. > I know bzr used to be really slow but apparently has been improved alot, however I have heard it is not bandwidth efficent still. CVS and SVN are both reasonable in speed. I don't know how Mercurial compares to CVS and SVN, however speed is one of the primary aims of Mercurial so I would assume it is pretty good. I'm thinking that some time I might try some benchmarks with a variety of SCMs such as these on the crossfire tree. > - Global revisioning - instead of each file having a revision that increases, > there is a global revision - this makes it very easy to get status right before > commits or back out changes. > Every SCM I have heard of except CVS does this from what I've seen :) > Other nice to have features: > ---------------------------- > - Atomic checkins (killing your checkin while happening shouldn't leave > repository in inconsistent state - I don't think we have ever run into this, and > there are not a huge number of files in crossfire repository which is why this > is lower priority) > I haven't heard of of a modern SCM that didn't have this :) > - Maximum ability to do SCCS operations without access to repository (diffs, > status, etc). > Well, for true maximum ability one essentially needs local branches. > - good binary file handling (this may be a duplicate of efficient use of > resources. This also really comes in with the crossfire.[01] files in the lib > directory, which given how that file is constructed, not sure exactly how much > better the binary diffs can handle that) > Unless the process for generating those files changes, then binary diffs should handle it very much better. SVN, bzr, and Mercurial all support this well from what I can see, and I don't know of any modern systems that don't. > - Ability to do local branches (and make those branches available to others) bzr and Mercurial support this as do all other distributed version control systems. SVN does not support this, however one can use local SVK repositories with a central SVN repository very transparently, that said I would personally not like to rely on SVK for local branches due to it's dependency on numerous perl modules, and IMHO it just feels 'hackish'. Alex Schultz From lalo.martins at gmail.com Sat Aug 12 05:59:55 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 12 Aug 2006 18:59:55 +0800 Subject: [crossfire] crossfire source code control systems References: <44DD8863.4000401@sonic.net> <44DD9BAA.3010703@telus.net> Message-ID: On Sat, 12 Aug 2006 03:13:14 -0600, Alex Schultz wrote: > Mark Wedel wrote: >> Key requirements (if it doesn't meet these, not usuable - probably everything >> out there does) It looks complete to me, at least it has everything *I* want :-) Maybe I should make a point here I made on IRC, for the record. It's about local branches. One thing we should keep in mind is maintenance of local map trees. About two years ago, a friend of mine who works on bugzilla commented on how useful distributed SCMs would be for them, because "in practise, every bugzilla installation is a fork". That rings true to me; I'd expect a large percentage of server admins to have some hacked maps, local maps, and hacked/local scripts; or else they wish they had but they're afraid cvs will clobber their stuff. With a distributed SCM, you'll install your maps dir as a local branch, branched from the maps mainline. Then you can make your own changes and commit them -- you even get local revision control for your stuff. And when you need to update your maps, you just merge from the mainline; that *may* cause conflicts, but it's guaranteed to never lose your changes (as they will, at the very least, be in the history). >> - Supported by sourceforge, or secondarily, some other free hosting >> service (I'd much rather someone else has to deal with any >> adminstrative issues of the software, like update to latest version, >> etc) >> > That is a trickier requirement and limits things a bit. Most mainstream > ones are just CVS and/or SVN. Launchpad.net (funded/ran by Canonical > Ltd.) provides bzr SCM. Also, Mercurial can run out of sf.net project > web space. However I've missed some hosting or something else can run in > project web space, I don't think we can look go beyond CVS, SVN, bzr, > and Mercurial with this requirement (not that it's a problem, just that > unless someone knows of something I've missed, that's something that > limits our choices). Actually most distributed SCMs can work from sourceforge's web hosting space, including bzr. That's not a very nice setup though; repositories tend to get quite large, so they'll probably fill your quota before long, and if you cry for sf support, they'll say "damn man, you're not supposed to be using it this way". I should note that other sf-like sites explicitly allow you to do that; for one, before launchpad was up, I published my powerchick branch at gna.org (not in my web area, but in my file download space). And finally, as an extra note on launchpad -- all the crossfire trees are already there in bzr format, except maps that for some reason failed to convert. They provide their own cvs->bzr conversion, all you have to do is put the cvs info in a form and launchpad will convert it and keep it up to date. So anyone who wants to try pulling some crossfire source tree via bzr can use the branches at launchpad. >> - Efficient use of resources (network bandwidth, cpu, etc) - it >> shouldn't take 15 minutes to check out the server, for example. >> > I know bzr used to be really slow but apparently has been improved alot, > however I have heard it is not bandwidth efficent still. They released 0.9 which is supposedly much faster yesterday. I've yet to try it out... I'll let you know what I find when I do :-) 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 lalo.martins at gmail.com Sat Aug 12 06:16:06 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 12 Aug 2006 19:16:06 +0800 Subject: [crossfire] crossfire source code control systems References: <44DD8863.4000401@sonic.net> <44DD9BAA.3010703@telus.net> Message-ID: I should add that I'm not saying we should use bzr; I'll just play the part of its advocate in the evaluation process, because it's the one I know the most about (I use it on a daily basis). Personally I'm a bit put off about it right now due to speed issues, let's see if 0.9 is better. On Sat, 12 Aug 2006 18:59:55 +0800, Lalo Martins wrote: > And finally, as an extra note on launchpad -- all the crossfire trees are > already there in bzr format, except maps that for some reason failed to > convert. D'oh, I know why it failed, it's because of a bug I reported myself. The bug is fixed in 0.9, so in a few days launchpad should have maps as well. (https://launchpad.net/bugs/6373 in case anyone's curious) 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 lalo.martins at gmail.com Sun Aug 13 00:08:27 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Sun, 13 Aug 2006 13:08:27 +0800 Subject: [crossfire] crossfire source code control systems References: <44DD8863.4000401@sonic.net> <44DD9BAA.3010703@telus.net> Message-ID: On Sat, 12 Aug 2006 18:59:55 +0800, Lalo Martins wrote: > On Sat, 12 Aug 2006 03:13:14 -0600, Alex Schultz wrote: >> I know bzr used to be really slow but apparently has been improved alot, >> however I have heard it is not bandwidth efficent still. > > They released 0.9 which is supposedly much faster yesterday. I've yet to > try it out... I'll let you know what I find when I do :-) lalo:~SRC/crossfire> time bzr get http://bazaar.launchpad.net/~vcs-imports/crossfire-server/main server-launchpad Branched 2690 revision(s). bzr get http://bazaar.launchpad.net/~vcs-imports/crossfire-server/main 73.19s user 12.43s system 1% cpu 1:59:20.98 total guess it's not quite there yet. 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 alex_sch at telus.net Sun Aug 13 19:05:32 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 13 Aug 2006 18:05:32 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: References: <44DD8863.4000401@sonic.net> <44DD9BAA.3010703@telus.net> Message-ID: <44DFBE4C.9040004@telus.net> Lalo Martins wrote: > On Sat, 12 Aug 2006 18:59:55 +0800, Lalo Martins wrote: > >> On Sat, 12 Aug 2006 03:13:14 -0600, Alex Schultz wrote: >> >>> I know bzr used to be really slow but apparently has been improved alot, >>> however I have heard it is not bandwidth efficent still. >>> >> They released 0.9 which is supposedly much faster yesterday. I've yet to >> try it out... I'll let you know what I find when I do :-) >> > > lalo:~SRC/crossfire> time bzr get http://bazaar.launchpad.net/~vcs-imports/crossfire-server/main server-launchpad > Branched 2690 revision(s). > bzr get http://bazaar.launchpad.net/~vcs-imports/crossfire-server/main 73.19s user 12.43s system 1% cpu 1:59:20.98 total > > guess it's not quite there yet. I just did some benchmarks on Mercurial and bzr (thinking about also benchmarking some others at some point perhaps) and the results are here: http://wiki.metalforge.net/doku.php/user:rednaxela:scms In terms of performance and such, Mercurial is a little better, of course, the time difference between the two is not very significant in practical usage *except* that bzr is very slow pulling repositories over http, because it establishes separate connections many many times and when going over the internet spends much time establishing connections and doing the dns lookups, which is why the time Lalo points out is so large, and since local branches are so commonly used on distributed systems I think that matters alot and is a strong point against bzr on trees with large histories (like crossfire). Mercurial however doesn't have the ability to get a "checkout" in a traditional CVS manner, it has no way of downloading a working directory without the history, except if the server is set up to generate downloadable tarballs, and that still doesn't allow changes to be directly "checked in" from such working directories. That is largely because people most people would use it anyways, uses local branches, which IMHO are much nicer to develop on than a checkout. That said, if we do choose to move to mercurial, it would be a fairly trivial task for me to make a robust wrapper script for mercurial to allow checkout/checkin style development over mercurial ssh, so if we do go with mercurial and anyone wishes for that, I could make such a script. Btw, one thing I'd like to mention, is the way that Mercurial/bzr (and many/most distributed SCMs) keep track of merging branches. Revisions get cryptographic IDs that should be unique regardless of which branch they are in and will be preserved when merging into a different branch however revision numbers would be different, that allows one to find where the same revisions are in different branches. Also, revisions keep track of their parent revision, so when branches diverge and one is merged into another, it would keep track of the point at which diverge and where they merge back again, which is good for history and also makes the merge work nicely. One note on using such systems with the crossfire branch, I believe it would be best to make any changes that are wanted in both branches, on the stable branch first, because they one can just merge the stable branch into the 2.0 branch, and it will account for where they diverged, where they merged, however one would need to manually deal with conflict resolution, however many SCMs can use external tools (i.e. meld) to make conflict resolution easier and really, dealing with conflict resolution shouldn't be harder than manually porting the changes to 2.0. That model would also ensure that all fixes in the stable branch are not forgotten in the 2.0 branch because the merge would merge what it can and allow the user to resolve conflicts fairly easily. Currently I'm not advocating any specific SCM (however the more I look at distributed SCMs the more I like their branching methods), so just mentioning what I see as the biggest issues with bzr, with Mercurial, as well as explaining a little about how distributed systems such as them deal with branching. Alex Schultz From raphael at gimp.org Mon Aug 14 04:21:37 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Mon, 14 Aug 2006 11:21:37 +0200 Subject: [crossfire] Proposal for better in-game information: client-side "player books" Message-ID: <20060814112137.169ec054.raphael@gimp.org> Here is a rather long proposal for improving the information available to the players. This is something that I had in mind since quite a while and I originally did not want to talk about until I had some time to work on it. But Lauwenmark/gros asked me nicely to describe what I had in mind. :-) And it looks like I will not have the time to work on this in the near future, so I'd better do a brain dump now in case someone is interested... Introduction ------------ The basic idea is to replace most of the books, scrolls and other readable stuff in the game by permanent "player books" that collect the information automatically and make it available to the player at any time. This information would become richer as the player explores the crossfire world. These books would be a client-side feature accessible at any time and they could even be made available outside the game as a set of player-specific HTML pages. These "player books" would more or less replace the Crossfire Spoiler: they would eventually contain the same information in a format that is easily browsable. But the contents would be provided gradually by the game itself instead of being available all at once from a web site or from one big file. These books would also replace the list of spells that can be displayed by most clients. They would give an overview of the spells and prayers that are known by the player, including their description and an indication about which ones are denied/repelled/atuned (probably laid out as in the gtk2 client, with options for sorting). In the current game, there is a difference in the way spellbooks or skill scrolls are handled compared to other types of books: a spellbook disappears if the player learns a new spell or prayer from it. But other books or cards do not vanish after being read. With this proposal, all books related to skills, spells, spell paths, monsters, religions, artifacts and quests would be handled in the same way: they would be removed from the game as if the player had taken the pages and added them to her own book. Note: this only applies to the generic random books - other readable items such as signs, cards and unique books that are included in maps will not be "consumed" by the player. Additions to the client-server protocol --------------------------------------- The new information will probably have to be sent to the client using a new S->C command similar to "drawextinfo" (it would also include some information that is currently sent by "addspell" or "updspell"). Like for most new commands, the client could indicate that it supports it by using a new "setup" option. The new command could be called "addinfo" or "storeinfo" or something similar - its name is not really important. The format of the command could be: addinfo ... Basically, this command would allow the server to send one or several messages, each of them containing: - is one of: skill, spell, monster, object (artifact), god, quest or formula (the latter could be more than one type: alchemy_formula, smithery_formula, etc.) - identifies the skill, spell, monster... - is for the messages that can be split in several parts. For example, the information about monsters can be divided in: the image of the monster, a list of abilities, a longer description and some hints about how to deal with them. See below for details. I am not sure if should be sent as 3 numbers, as a string or as a mix of both. Numbers are probably easier to handle (e.g., 8 bits for , 16 bits for and 8 bits for ) but strings could be easier to map to URLs or file names, which can be useful if the "player book" should be available in HTML format. One option would be to send and as numbers (to save space and ensure uniqueness) and send as a string. In the following paragraphs, I will use a string representation that could be suitable for URLs: /#. This is only for clarity - this does not imply that a string representation is better than using numbers. For example, the S->C protocol could send numbers that are then converted to strings (URLs) on the client side. Monsters -------- * monsters/intro - general info about monsters (this may be split in several parts: intro#1, intro#2, ...) * monsters/#name - full name of the monster or generator * monsters/#img - image of the monster (face #) * monsters/#abil - like the current description of abilities * monsters/#gen - optional reference to generated monster (id) * monsters/#desc - extended description and hints about how to deal with that monster The could be the name of the archetype (which may be different from the name of the monster) or some unique number. The client will automatically generate a table giving a list of all monsters (in HTML format, this could be the index page). As the information is sent in parts depending on the contents of random books, it could be possible that a monster is only known by its image and abilities while another one has a name and description but no image yet. Artifacts --------- * objects/intro - general information about weapons, armour, rings, talismans and other objects (this may be split in objects#weapons, ...) * objects/#name - full name of that object * objects/#img - image of that object (face #) * objects/#abil - abilities, like the current description of the properties of the artifacts * objects/#desc - hints about how to use that object or maybe a long description of the object (for those that have one) if all hints are already in "intro" Like for the monsters, the could be the name of the artifact (archetype + title) or some unique number. The client will also automatically generate a table including all known objects. Alchemy ------- * formula/ - formula and description The could be name of the result, although this is not always unique (some objects can be created in more than one way). The uniqueness could be ensured by appending a number to the name of the objects that are the target of more than one formula. The could also be some number based on a hash of the ingredients. If the result of the formula or its ingredients match some artifacts, a cross-reference to the corresponsing object/ could be added. In order to make sorting easier for the player, it may be better to replace the single type "formula" by several types depending on the skill required: formula_alchemy/, formula_jeweler/, ... Spells, spellpaths and skills ----------------------------- * spells/#name - full name of that spell or prayer * spells/#img - image of the spell effect (face #) * spells/#level - level and skill required for that spell * spells/#desc - hints about how to use that spell * paths/ - list of spells belonging to path * skills/ - description and hints for skill The client will automatically generate a table including all known spells. In addition, it will generate a cross-referenced list for each path. Note that it may be possible for a path to refer to a spell for which no information is known. Maybe the name of the spell should always be sent in this case? When a player reads a spell book or prayer book, the name of the spell and the corresponsing skill and level are automatically sent, even if the player fails to learn the spell (this information is already sent today in a normal message). Spells that are not known by the player would be mentioned in the "player book" with a sentence like "You do not know that spell". Spells that are known but that the player is unable to cast (insufficient level or denied path) would be mentioned with a sentence like "You know that spell but are unable to cast it." I am not sure if it would be interesting (wrt. gameplay) to have to find the hints or the detailled description of the spell in random books. It may be better to always include this information in the spellbooks (as this is currently done via the "addspell" command). In that case, it would not make much sense to split the spell description in several parts (#name, #img, #level, #desc) if they are always sent together. The same applies for the skill scrolls: the description of the skill could be sent to the client when the skill is acquired instead of having to be found in a random book (except for skills that cannot be found in scrolls, such as the writing skill). Currently, the "addspell" command includes path information. This is used for highlighting some spells (attuned/repelled/denied) when the client displays the list of spells to the player. With this proposal, this would no longer be the case and the player would have to find and read some books about spellpaths in order to get the automatic highlighting in the list. Gods and religions ------------------ * gods/#img - image of the avatar (face #) * gods/#ennemy - name of the ennemy god * gods/#ennemy_race- name of the ennemy race * gods/#align_race - name of the aligned race * gods/#aura - protections and vulnerabilities * gods/#paths - attuned/repelled/denied paths * gods/#blessing - effects of blessing/curse * gods/#possession - effects of holy possession Quests and other random messages -------------------------------- * info/ - description of a quest or other useful stuff Some random messages contain hints about where to find a quest or general information about the game or the crossfire world. The could be just a sequence number but it could also be a name if each of these messages is given a unique name. Some of these messages could also be sent to the client immediately after creating a new character: they would replace the information that is currently given in the HallOfSelection and the general game hints that are given in the initial mission and in the central square of Scorn. This would ensure that all new characters start with a few pages of information about crossfire, how to play the game, and what are the main features of the race and class that have been selected. All characters starting with some spells and skills would also be given the corresponding information (see spells and skills above). Changes to the archetypes and maps ---------------------------------- In order to provide the information described above, some changes to the archetypes and maps will be necessary: all books and other readable items would have to be reorganized. It may be better to have a clear difference between the books that will be "consumed" by the player (spell books and other random books and scrolls) and the ones that are part of some maps and should not be grabbed by the player. New descriptions would be needed for some monsters, for the skills and for all "info" messages that should replace the current player handbook. These would probably require new files in the lib directory. I am not sure about where to store the extended description and the hints for dealing with specific monsters. The "msg" field of the archetypes is already used by some monsters so it cannot be used for this purpose. Libraries are a bit special because the new concept of grabbing pages from random books and putting them into one's own book would not work well with libraries (this could upset the librarian and other readers). One workaround would be that if a readable object has "no_pick 1", then the player would get the message "You copy the information about into your book" instead of getting the message "You take the information about and add it to your book". In that case, it would not be necessary to modify the libraries and other maps using books that cannot be picked up. This could even be applied to spell books: a map could have a "no_pick" spell book or prayer book so that the book stays there even after being read. This could be useful to ensure that quest spells that are difficult to get at cannot be taken out of a deep dungeon and given to a low-level player. Open questions -------------- - When a player reads a book or scroll in the game, the information is taken from it and put into the "player book". Should the book or scroll disappear or should it be replaced by an empty book (from which the pages have been removed)? - If the player already knows some piece of information, it would be nice to leave the corresponding page(s) in the game instead of taking it away. This is how spell books and skill scrolls work today. How should the server know if the page(s) should be removed or not? Should the server keep a list of all things that have already be sent to the client? - These special books could be represented as objects in the players' inventory or they could be "out of the game" with a specific client interface to access them (just like the list of skills or spells can be obtained without using an object). - If these special books appear in the inventory, they could slowly gain weight as more pages are added to them. Is this a good idea? And in that case, how could the player avoid gaining too much weight, especially if the character is weak? - If these special books are in-game objects, how to prevent players from exchanging these books, destroying them or losing them? They could be permanently locked with no way to unlock them but that does not feel right. Marking them as godgiven items would cause a great loss to the players who unlock and drop the wrong items by accident. - Should there be just one "player book" per player (divided into chapters for spells, monsters, etc.) or should there be one book of each type? - Should there be a way for the player to add her own notes to any page? Or could there be a special part of the book or a separate book (notepad) in which the player could add some notes? - It would be nice to allow the player to read all that stuff outside the game. This could be done from the client itself or from a web browser if the information is availble in HTML format. Should everything be stored as static HTML pages overwritten by the client after each update? Or is it better to add a tiny web server to the client and let it generate the pages on-the-fly? - The "player book" could be stored per character or per client/player (shared between characters created by the same player). Although the purist way to do it would be to store it per character, it could also be argued that the player knows the information anyway, so why not let it be shared between all her characters? - All messages described above can be sent in plain text (maybe with a bit of markup for cross-references), including the images if they refer to existing faces. However, if we find an artist who has a lot of spare time to spend on crossfire, it may be possible to enhance the messages with custom images to be included in the HTML rendering of the player book. How should the images be sent to the client in this case? As special faces or as part of the messages? Conclusion ---------- I think that such a system could improve the world of crossfire because the important information would be given by the game itself instead of being found in some external document (spoiler, handbook). It would also reduce the artificial difference that exists between the behavior of spell books and other types of books: some of them vanish after use, some others don't. However, implementing all this will require a lot of work. I will not have the time to do that in the near future (next 6 months or so) and I am not even sure that I will have the time to discuss this proposal. For the moment, I prefer to spend the bits of spare time that I find on other things such as creating more alchemy quest maps and finishing my map checking script. So please consider this proposal as a brain dump without any promise that it will ever be implemented. If you like these ideas and would like to implement them, feel free to try... -Raphael From alex_sch at telus.net Mon Aug 14 16:19:22 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 14 Aug 2006 15:19:22 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44DD8863.4000401@sonic.net> References: <44DD8863.4000401@sonic.net> Message-ID: <44E0E8DA.3060307@telus.net> Ok, I just made up a table of the criteria that Mark listed, and a couple others, for CVS, SVN, Mercurial, Bzr, and Darcs (anyone want any others on the table?). If anyone has any revisions or wants to add any other SCMs feel free to make them. Currently storing it in my namespace on the wiki at: http://wiki.metalforge.net/doku.php/user:rednaxela:scmtable Make sure to read the numerous footnotes when looking at the table. Alex Schultz From mwedel at sonic.net Mon Aug 14 23:28:21 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 14 Aug 2006 21:28:21 -0700 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44E0E8DA.3060307@telus.net> References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> Message-ID: <44E14D65.4050409@sonic.net> Alex Schultz wrote: > Ok, I just made up a table of the criteria that Mark listed, and a > couple others, for CVS, SVN, Mercurial, Bzr, and Darcs (anyone want any > others on the table?). If anyone has any revisions or wants to add any > other SCMs feel free to make them. > Currently storing it in my namespace on the wiki at: > http://wiki.metalforge.net/doku.php/user:rednaxela:scmtable > Make sure to read the numerous footnotes when looking at the table. Few notes on this: I was looking over the sourceforge documentation, and hosting mercurial or darcs on the project web space and getting the data via the webserver looks to be a violation of their terms of usage. In particular, two things stand out - the quota for the web space is 100 mb, and they don't want bandwidth intensive use (specifically say to use the file release mechanism for file releases, not the web space). Crossfire, with CVS history and all, uses about a gigabyte of space. The file access rules might be another issue. OTOH, mercurial makes it much easier to have children, given it is a replicated system. So one could easily have sourceforge or the like the definitive location, but not allow the read-only access from there, instead, various sites could have branches that make it available, and they just do pullovers nightly or whatever. But the sourceforge is certainly an issue, but if we decide something not officially supported by sourceforge is best, we can then start the process of seeing what would work. Also, I'm not sure if I'd put a yes in the symbolic tagging for SVN - IIRC, SVN doesn't actually have symbolic tags, rather, you make a new repository of your tag. Thus, we'll end up with like 50 repositories. That approach isn't bad, but i really like to be able to do something like a 'cvs log', see for what version the symbolic tag was done, and thus what has been done after that (if a bug was reported with the last version as having the bug, has it already been fixed?) - with SVN, from what I gather, you'd need to go to the repository for that tag/release, see the version there, then go back to the head branch and see the changes since that time. There may be ways to do that with scripts they have, and I may be wrong in that, but that is what I gather (Actually, when I think about this, I don't think there is anything preventing changes in that copied repository, so even that may not be accurate, eg, I make a rel-1-10 repository, then someone checks in a change there for a 1.10.1 release instead of making another repository) Also, for SCCS operations without access to repository, my understanding again: SVN: yes - like mercurial, it stores all the change log information, etc, when you check out, so you can do diffs, see changed files, revert to last pristine file without network connection (or maybe it only stores a subset of the tree, but from my reading of the SVN docs, it suggest you can do diffs, unget, and see what files you have modified in your local directory without need for connection to repository, so I'd mark it as a yes for that) mercurial: same as SVN, and you don't need a branch - that is the downside to footnote 12 - no light weight checkout. OTOH, I think this means checkins are more lightweight - it can just send the diffs to the server. It's sort of a tradeoff - more time for the initial checkout but less time for future operations (I think it was the SVN doc which said this was intentional - disk space has become much cheaper/more available than network bandwidth, so it makes sense to try and cache as much data locally as reasonable). From mwedel at sonic.net Tue Aug 15 00:21:38 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 14 Aug 2006 22:21:38 -0700 Subject: [crossfire] Proposal for better in-game information: client-side "player books" In-Reply-To: <20060814112137.169ec054.raphael@gimp.org> References: <20060814112137.169ec054.raphael@gimp.org> Message-ID: <44E159E2.9020609@sonic.net> Some quick thoughts: id being the archetype probably makes the most sense. If you make it numeric, it would have to be some sort of hash I'd think so that it is consistent, and then there is always the danger that something new is added causing the hash conflict, resulting in the hash changing anyways. Alternatively, the number itself could be in the archetype, but that would seem to be full of problems - duplicate numbers, etc. Given this content isn't sent very often, not sure if using the longer archetype name would be a problem. Spells: As of now, you can't learn a spell unless you are sufficient level to cast it (DM's could teach you spell without that restriction, but that is a bit of an edge case). Now it is possible you learned a spell, died, lost some levels, but then in that case, you still knew all the attributes at once. While it is reasonable to say that since you can't cast the spell, you can't remember the details - the problem is that could then lead to outside game notetaking on what you did know. For the same reason, I think it is good to give full information for the spells the player knows. Some of it could be figured out empirically - I'm denied healing, and can't cast that spell, thus it must be in the healing path, etc. But some is playability - if that information is really needed, and isn't being provided, I'll just go elsewhere for the information (spoiler, whatever). Storing information: It should be stored in the archetype it describes - the addition of files in the lib directory to describe archetype is the wrong way to go (if anything, we are trying to move away from that, with things like the .trs file). There is the lore/endlore fields right now which was envisioned to hold information on various things that would then go into books. I'd suggest that could be used, with perhaps defined tags for different fields, eg: abilities: ... desc: .... other: .... and so on. There may still need to be some information in the lib directory for data that isn't directly related to any archetype (rumors of a dungeon, etc). One thought on that is that the file should probably be extended to have region clauses - it doesn't make much sense to be hearing about information of a dungeon near scorn if you're in wolfsburg. By localizing the messages, it then means when in scorn, you'd get lots of information about what is in and about scorn, etc. > Open questions > -------------- > - When a player reads a book or scroll in the game, the information is > taken from it and put into the "player book". Should the book or > scroll disappear or should it be replaced by an empty book (from > which the pages have been removed)? either would be fine - it could be argued that since the pages are removed, the book is effectively destroyed - it hasn't been erased after all. > - If the player already knows some piece of information, it would be > nice to leave the corresponding page(s) in the game instead of > taking it away. This is how spell books and skill scrolls work > today. How should the server know if the page(s) should be removed > or not? Should the server keep a list of all things that have > already be sent to the client? I might have missed it further above, but this note here suggests that this information in cached client information? If so, I'm not sure that is a good approach or not - there is no guarantee that players will be on the same computer, and thus would lose that information (currently, the only thing the client really stores locally is the user preferences). I'd say that would be unexpected by most players. And if done, then such caching would have be be segregated based on the server it came from, since different might not agree on all the data. The client caching the data would also infer that this knowledge is really player knowledge, so if you played a bit and made a new character, that first level character would have a lot of knowledge. Maybe that isn't bad - not 100% sure. I do say I think it would be nice from a game perspective to actually know what information the character has learned - alchemy could require you know the recipe, quests/npcs could give pieces of missing information, etc. > - These special books could be represented as objects in the players' > inventory or they could be "out of the game" with a specific client > interface to access them (just like the list of skills or spells can > be obtained without using an object). I'd think that if they are in game, then if you applied one, there would be too much information pretty quickly to reasonable read/parse, so I think some other interface is needed. > - If these special books appear in the inventory, they could slowly > gain weight as more pages are added to them. Is this a good idea? > And in that case, how could the player avoid gaining too much > weight, especially if the character is weak? And what happens if a player drops it? If they no longer have their travel book, what happens if they find one of those readables? Can someone else then pick up that dropped book? I'd generally say like above, this should be hidden information - it should be seen as a convenience for players, and with that, some better interface to navigate the information. If there are disadvantages to the new system, you'll either get people not using it, and/or just copying the information from crossfire to an editor they have and store the information there. It could really be seen as an interface to the characters memory. > - Should there be a way for the player to add her own notes to any > page? Or could there be a special part of the book or a separate > book (notepad) in which the player could add some notes? It'd probably be nice to have some method for the player to add notes - I'd say for the different attributes, each having a potential 'player notes' section. I'd expect that there will be gaps in information. A player may find a really good attack for a monster that isn't recorded with the info we provide - they may want to record it for the next time. Or maybe record location of dungeons, best places to sell stuff, etc. Once again, make the game more convenient for the player. > - It would be nice to allow the player to read all that stuff outside > the game. This could be done from the client itself or from a web > browser if the information is availble in HTML format. Should > everything be stored as static HTML pages overwritten by the client > after each update? Or is it better to add a tiny web server to the > client and let it generate the pages on-the-fly? Not sure how much need there is to store/access this outside the game. If stored as a file, the location has to be easily accessible. Adding a mini webserver to the client doesn't seem like the right approach - too many problems with that - it'd have to run on a non standard port (need root to run on the standard port), more issues to support it, etc. I think it might be cleanest to add an export option in the client that exports this data to a location the player specifies. > - The "player book" could be stored per character or per client/player > (shared between characters created by the same player). Although > the purist way to do it would be to store it per character, it could > also be argued that the player knows the information anyway, so why > not let it be shared between all her characters? I'd say player, for reasons I state above. > - All messages described above can be sent in plain text (maybe with a > bit of markup for cross-references), including the images if they > refer to existing faces. However, if we find an artist who has a > lot of spare time to spend on crossfire, it may be possible to > enhance the messages with custom images to be included in the HTML > rendering of the player book. How should the images be sent to the > client in this case? As special faces or as part of the messages? There isn't any reason that the image couldn't be added in the archetypes and sent in the normal way (I'm not even sure if there is any real maximum size if it is just an image not displayed on the map). Sending it as part of the message would seem ugly. From alex_sch at telus.net Tue Aug 15 00:26:53 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 14 Aug 2006 23:26:53 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44E14D65.4050409@sonic.net> References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <44E14D65.4050409@sonic.net> Message-ID: <44E15B1D.3060606@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> Ok, I just made up a table of the criteria that Mark listed, and a >> couple others, for CVS, SVN, Mercurial, Bzr, and Darcs (anyone want any >> others on the table?). If anyone has any revisions or wants to add any >> other SCMs feel free to make them. >> Currently storing it in my namespace on the wiki at: >> http://wiki.metalforge.net/doku.php/user:rednaxela:scmtable >> Make sure to read the numerous footnotes when looking at the table. >> > > Few notes on this: > Updated the table to account for your notes. > I was looking over the sourceforge documentation, and hosting mercurial or > darcs on the project web space and getting the data via the webserver looks to > be a violation of their terms of usage. > > In particular, two things stand out - the quota for the web space is 100 mb, > and they don't want bandwidth intensive use (specifically say to use the file > release mechanism for file releases, not the web space). Crossfire, with CVS > history and all, uses about a gigabyte of space. The file access rules might be > another issue. > Indeed, that is an issue that prevents it from being usable on sf.net, though I have heard that project space of some other free hosts does allow this sort of usage, though I am unsure of if the web space provided is sufficient on those. > OTOH, mercurial makes it much easier to have children, given it is a > replicated system. So one could easily have sourceforge or the like the > definitive location, but not allow the read-only access from there, instead, > various sites could have branches that make it available, and they just do > pullovers nightly or whatever. But the sourceforge is certainly an issue, but > if we decide something not officially supported by sourceforge is best, we can > then start the process of seeing what would work. > (mercurial, and most other distributed systems) Well, even if that avoided the issue of "bandwidth intensive use", the quota of 100MB makes it so we still couldn't do that on sf.net, however doing such a thing on other free hosts may be a possibility. One issue with that though would be, where should such children systems be anyways? I think the main thing we need to figure out right now, is if we have a viable way to host systems such as Mercurial. One thing to note, is we could move to a more decentralized system, however: 1) We would still need some tree to be considered "official" or "authoritative" for the purposes of what we will release and such things. It would be possible to let a given developer handle that however I am unsure if that would work very well. 2) Many developers don't have the means to host a branch for others to pull from Anyone have any ideas for hosting such things? Also, bzr, which launchpad.net can provide hosting for, looks reasonable (see the chart) except that it is very slow to do a branch over http with (see Lalo's email: 2 hours), so would that sort of wait to make one's first local branch be acceptable to people, considering that to pull further updates is reasonable in speed, and that further local branches can be done from existing local branches? Also note, bzr can do cvs-style lightweight checkouts if that is reasonable to the people who won't wait 2 hours for their first local branch. Alex Schultz From mwedel at sonic.net Tue Aug 15 00:56:15 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 14 Aug 2006 22:56:15 -0700 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44E15B1D.3060606@telus.net> References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <44E14D65.4050409@sonic.net> <44E15B1D.3060606@telus.net> Message-ID: <44E161FF.9000601@sonic.net> Alex Schultz wrote: > Indeed, that is an issue that prevents it from being usable on sf.net, > though I have heard that project space of some other free hosts does > allow this sort of usage, though I am unsure of if the web space > provided is sufficient on those. Before we put the cart before the horse, we really need to figure out what system we will use. I see a lot of talk about mercurial, and it looks pretty good. If we decide to go that route, we can then start to worry about this more. SF does say you can drop them a note about getting more space. And there may be other/more possibilities as mercurial gets more acceptance, etc. > I think the main thing we need to figure out right now, is if we have a > viable way to host systems such as Mercurial. One thing to note, is we > could move to a more decentralized system, however: > 1) We would still need some tree to be considered "official" or > "authoritative" for the purposes of what we will release and such > things. It would be possible to let a given developer handle that > however I am unsure if that would work very well. An official tree is definitely needed - you have to have some way to know where to go to get the latest code. You just need that, for that matter, for people to do the initial pull from - there has to be an initial repository. > 2) Many developers don't have the means to host a branch for others to > pull from > Anyone have any ideas for hosting such things? Well, re-hosting becomes easier - all anyone really needs is a static IP (or for that matter, dydns setup). I'd presume in such a setup, there would be a limited number of known/trusted sources. But if these repositories are read-only, getting them set up may be easier (that said, you do need some form of shell access itself to do the pull, or at least make it most efficient, etc). > > Also, bzr, which launchpad.net can provide hosting for, looks reasonable > (see the chart) except that it is very slow to do a branch over http > with (see Lalo's email: 2 hours), so would that sort of wait to make > one's first local branch be acceptable to people, considering that to > pull further updates is reasonable in speed, and that further local > branches can be done from existing local branches? Also note, bzr can do > cvs-style lightweight checkouts if that is reasonable to the people who > won't wait 2 hours for their first local branch. Aspects of crossfire are odd from a SCCS system however. In crossfire, we have the arch and maps trees, where you can easily have hundreds of files modified in a big change - if bzr is slow on checkouts, I'd think it would be slow on updates for the same reason? Or is it more efficient when doing updates? From mwedel at sonic.net Tue Aug 15 02:09:07 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 15 Aug 2006 00:09:07 -0700 Subject: [crossfire] Crossfire Release Cycles/Methodology In-Reply-To: <44D6F5B9.1020508@sonic.net> References: <44D6F5B9.1020508@sonic.net> Message-ID: <44E17313.7040905@sonic.net> Just a note - I've put a copy of this document, with a few minor changes, on the wiki: http://wiki.metalforge.net/doku.php/crossfire_release_cycle From mwedel at sonic.net Tue Aug 15 02:42:33 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 15 Aug 2006 00:42:33 -0700 Subject: [crossfire] TODO list items. Message-ID: <44E17AE9.6060207@sonic.net> With crossfire release methodology slowly moving forward (I think one way or another we'll have figured out what we're doing in terms of a SCCS system by weeks end), I thought it was time to look at some of the TODO lists. Most of these are from the wiki or one in the server directory I want to try to keep this somewhat shorter, so basically a list of things to do and when to do them. The list below is just a quick first pass I did - almost certainly not complete, and just basic gut feelings on target version and priority. I'm putting this out for the purpose of discussion. change: briefly, what the change is. target release: 1.x (minor release), 2.0 (next major release), 3.0 (major release after next). Anything with 1.x is presumed it will be completed before 2.0 and thus 2.0 will include it, if it is a high priority feature. Some determination on target release is how big a change I think it is - if I think the change may be small enough to go in a minor release, I have a 1.x target. priority: How important a change is. If another change depends on the first one, that will also result in the first one having a higher priority. Priority is from 1 to 3, one being the highest. Basically: 1 - Something that must be done, or prerequisite for something else 2 - Should really be done, but not critical to game play. 3 - nice to have feature, but if not done, not critical. Many of these may really be a 3.0 targets. Enhancements vs fixing known problems are most likely to be in this category. The different items should in general also be done in the priorities listed - P1 before P2, P2 before P3. Change Target Release Priority Fix/Revamp sound 2.0 2 Ambient music 2.0 3 Fix Weather 1.x? 2 Improve lighting 2.0 2 Changes to the clients (better ui) ? 1 (more details on what is meant by this is needed) New character creation method 2.0 1 Game Balance 2.0 1 Land Plots 1.x 3 Code Cleanup 2.0 1 Better NPC logic 1.x? 1 Add Kandora maps 1.x 3 Map Cleanup (more details?) 1.x? 3? Big worldify pupland 1.x? 2 Auction house map? 1.x? 3? archetype cleanup (remove old params so no 1.x? 1 legacy loader code needed) Buildable shops 2.0 3? Newspaper (script based) 1.x? 3? Player clothing (image change based on clothing) 3.0 3? Time of day based events 2.0 2 Player economy 3.0? 2 Quest management system 2.0 1 Improved player communications 3.0 2 Performance improvements (lots of spells on 1.x 1 map causes performance hit) Thread the server 3.0 2 Make slaying more consistent 2.0 2 Change speed of players (high levels players 2.0 2 move way too fast) Improve NPC communication (tag keywords so 2.0 3 are more obvious to players) discrete attack damage (dam_fire, dam_cold.) 2.0 3 From nicolas.weeger at laposte.net Tue Aug 15 02:54:49 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 15 Aug 2006 09:54:49 +0200 Subject: [crossfire] TODO list items. In-Reply-To: <44E17AE9.6060207@sonic.net> References: <44E17AE9.6060207@sonic.net> Message-ID: <200608150954.49718.nicolas.weeger@laposte.net> I won't comment on the priority, just other things :) > Better NPC logic 1.x? 1 Can be scripted. I'm no mapmaker, but if someone gives me the flow of the dialog I can write the script. I could look at adding utility functions to help write such dialogs, too. (Daimonin does that, I think) > Newspaper (script based) 1.x? 3? Can already be done, but no one actually did it... (may require scripts to access timeofday stuff, but not that hard) > Player clothing (image change based on clothing) 3.0 3? Would require many graphics artists, though, and already many things to redo first :) > Time of day based events 2.0 2 See newspaper :) > Make slaying more consistent 2.0 2 What do you mean by that? > discrete attack damage (dam_fire, dam_cold.) 2.0 3 Hu? Nicolas From raphael at gimp.org Tue Aug 15 04:15:07 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Tue, 15 Aug 2006 11:15:07 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44E161FF.9000601@sonic.net> References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <44E14D65.4050409@sonic.net> <44E15B1D.3060606@telus.net> <44E161FF.9000601@sonic.net> Message-ID: <20060815111507.2af6b590.raphael@gimp.org> On Mon, 14 Aug 2006 22:56:15 -0700, Mark Wedel wrote: > Alex Schultz wrote: > > Indeed, that is an issue that prevents it from being usable on sf.net, > > though I have heard that project space of some other free hosts does > > allow this sort of usage, though I am unsure of if the web space > > provided is sufficient on those. > > Before we put the cart before the horse, we really need to figure out what > system we will use. ...and carefully weight the pros and cons of each system. Currently, I think that CVS is still the safer solution despite its drawbacks (lack of support for file/directory renames, relatively slow diff...). [...] > An official tree is definitely needed - you have to have some way to know > where to go to get the latest code. > > You just need that, for that matter, for people to do the initial pull from - > there has to be an initial repository. > > > 2) Many developers don't have the means to host a branch for others to > > pull from > > Anyone have any ideas for hosting such things? > > Well, re-hosting becomes easier - all anyone really needs is a static IP (or > for that matter, dydns setup). Those who are still using dialup or who have metered broadband access will not be able to host a branch on their own. Especially if the charging model of their ISP is based on time rather than volume, because this basically prevents the "always on" connections. They would have to find a way to host their branch on some external server anyway, so for them there is no advantage in using a system that supports local branches. In fact, although I am not against using a system that supports local branches and distributed repositories, I would be against a system that requires or even encourages such distributed usage, for the following reasons: 1) Some developers may not be able to host local branches on their own or would have problems doing it. This problem does not exist on centralized systems (such as CVS, SVN, etc.). 2) Local branches will not stay around forever. It happens frequently that some development made on a local branch cannot be merged immedately into the "official" tree. It may take several months before someone tries to merge into the main tree all or parts of the changes done in a local branch. In the meantime, that branch could be gone: the owner of that branch may be gone, have lost her internet access, suffered a disk crash, or decided that the branch was not interesting anymore. Those who want to access that branch some months later would be stuck. The advantage and disadvantage of a centralized system is that everything is in one place: either everything is available, or nothing is. There is also only one place that has to be mirrored or backed up to prevent most disasters. With a centralized system, it is easier to ensure that all branches will be accessible forever (well, as long as the project exists). 3) Some developers or users may have problems accessing branches that are hosted outside the well-known servers such as sourceforge, freedesktop.org, gnome.org, kde.org and some others. Currently, my main internet access is at work (I also have a much slower and more expensive access at home, but I barely use it). It is behind a corporate firewall that blocks almost everything and only allows some (filtered) web and e-mail access. In addition, some exceptions may be requested for CVS or SSH access to specific hosts such as sourceforge.net (there are good business reasons for allowing access to some projects on sf.net and the access to the other projects also hosted on sf.net is tolerated). If we move to a distributed system, it is likely that it would be rather difficult for me to access the branches that are not hosted on a well-known server. So regardless of the system that is selected for the future, I hope that the development of crossfire will still happen mostly on a centralized server, hosting the main branch, the maintainance branches and the more experimental branches. It is of course possible to use a system that supports local branches, but I hope that the usage of local branches will not be encouraged. -Rapha?l From raphael at gimp.org Tue Aug 15 04:40:46 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Tue, 15 Aug 2006 11:40:46 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44E0E8DA.3060307@telus.net> References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> Message-ID: <20060815114046.33706ee6.raphael@gimp.org> On Mon, 14 Aug 2006 15:19:22 -0600, Alex Schultz wrote: > Ok, I just made up a table of the criteria that Mark listed, and a > couple others, for CVS, SVN, Mercurial, Bzr, and Darcs (anyone want any > others on the table?). If anyone has any revisions or wants to add any > other SCMs feel free to make them. > Currently storing it in my namespace on the wiki at: > http://wiki.metalforge.net/doku.php/user:rednaxela:scmtable > Make sure to read the numerous footnotes when looking at the table. I think that the rename support should be in the "top features". This is one of the weak points of CVS and (from my point of view) would be the main reason to look at something else. Being able to move files and directories around while preserving their full revision history could be important for the maps. For example, if the kandora maps are moved out of the "unliked" directory, their revision history would be lost. This is even more important for bigger changes such as re-organizing the mlab maps. The only way to do it with CVS (if you do not play tricks with the repository) is to delete and re-create all files, which generates very large diffs and causes problems with the revision history. One thing that could be added in the "nice to have" list is the support for migrating local branches to another repository. This would only apply to the systems that support local branches. So the choices could be "Easy", "Hard" or "Not applicable". Or maybe just "Yes", "No", "N/A". As I mentioned in my previous message, local branches could cause some availability problems. So if a system supports local branches, it would be interesting to know whether it is easy or hard to move these branches to a different place (which could be the central server or some other server used as failover). I would consider that a system does not support relocating local branches if it is necessary to do a full archive of the repository and then extract it in the new location. I would also consider it insufficient if the main way to move a local branch requires a merge with the main branch and/or only preserves the last entry in the revision history. Good support for relocating local branches would be offered if the system allows anybody (not just the owner of that branch) to extract all information about that branch (including the history of all changes) and create an exact copy of that branch on another server. -Rapha?l From lalo.martins at gmail.com Tue Aug 15 09:39:59 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 15 Aug 2006 22:39:59 +0800 Subject: [crossfire] crossfire source code control systems References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <20060815114046.33706ee6.raphael@gimp.org> Message-ID: On Tue, 15 Aug 2006 11:40:46 +0200, Rapha?l Quinet wrote: > One thing that could be added in the "nice to have" list is the > support for migrating local branches to another repository. This > would only apply to the systems that support local branches. So the > choices could be "Easy", "Hard" or "Not applicable". That's easy; all distributed revision control systems have that ability (they call it "pushing" or "mirroring" the branch, depending on the system). It's a requirement of the distributed model, for reasons you expose quite well in your message. 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 lalo.martins at gmail.com Tue Aug 15 09:42:20 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 15 Aug 2006 22:42:20 +0800 Subject: [crossfire] crossfire source code control systems References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> Message-ID: On Mon, 14 Aug 2006 15:19:22 -0600, Alex Schultz wrote: > Ok, I just made up a table of the criteria that Mark listed, and a > couple others, for CVS, SVN, Mercurial, Bzr, and Darcs (anyone want any > others on the table?). If anyone has any revisions or wants to add any > other SCMs feel free to make them. I'd like to see git. I don't really like it, but SourceMage just spent a few months researching all those systems (and they actually tried them all out for a few weeks each), and they picked git, so it must be good for something. I find its model highly unintuitive, but it's very fast -- and supposedly cogito is more reasonable to work with. 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 raphael at gimp.org Tue Aug 15 10:13:07 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Tue, 15 Aug 2006 17:13:07 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <20060815114046.33706ee6.raphael@gimp.org> Message-ID: <20060815171307.7c9720da.raphael@gimp.org> On Tue, 15 Aug 2006 22:39:59 +0800, Lalo Martins wrote: > On Tue, 15 Aug 2006 11:40:46 +0200, Rapha??l Quinet wrote: > > One thing that could be added in the "nice to have" list is the > > support for migrating local branches to another repository. > > That's easy; all distributed revision control systems have that ability > (they call it "pushing" or "mirroring" the branch, depending on the > system). It's a requirement of the distributed model, for reasons you > expose quite well in your message. Do you know if all of them allow any user to perform that mirroring? I thought that some of them required some action from the branch owner, not just any user (as I mentioned in my previous message, requiring the owner to do it would not fit in the "good support" category). If all of them provide good support for moving or mirroring local branches back to the "official" repository, then there is no need to add this feature to the comparison table. And anyway, I would prefer to avoid using local branches for the reasons explained in my other message. -Rapha?l From alex_sch at telus.net Tue Aug 15 10:12:28 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 15 Aug 2006 09:12:28 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <20060815114046.33706ee6.raphael@gimp.org> References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <20060815114046.33706ee6.raphael@gimp.org> Message-ID: <44E1E45C.1050001@telus.net> Rapha?l Quinet wrote: > One thing that could be added in the "nice to have" list is the > support for migrating local branches to another repository. This > would only apply to the systems that support local branches. So the > choices could be "Easy", "Hard" or "Not applicable". Or maybe just > "Yes", "No", "N/A". As I mentioned in my previous message, local > branches could cause some availability problems. So if a system > supports local branches, it would be interesting to know whether it is > easy or hard to move these branches to a different place (which could > be the central server or some other server used as failover). I would > consider that a system does not support relocating local branches if > it is necessary to do a full archive of the repository and then > extract it in the new location. I would also consider it insufficient > if the main way to move a local branch requires a merge with the main > branch and/or only preserves the last entry in the revision history. > Good support for relocating local branches would be offered if the > system allows anybody (not just the owner of that branch) to extract > all information about that branch (including the history of all > changes) and create an exact copy of that branch on another server. Yes, I would agree that it would be a "nice to have" feature, though I'm not sure this is useful to add to the table because really, I don't know of any distributed SCM that doesn't allow easily migrating local (or any) branches. Usually one would do it by initializing a new repository/branch (most consider each branch a separate repository, however allow proper merging etc. as to not require branches to be hosted in the same place) at the remote location and then typically using the "push" command to push all of the data including history to the remote repository. Alex Schultz From alex_sch at telus.net Tue Aug 15 10:51:14 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 15 Aug 2006 09:51:14 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <20060815171307.7c9720da.raphael@gimp.org> References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <20060815114046.33706ee6.raphael@gimp.org> <20060815171307.7c9720da.raphael@gimp.org> Message-ID: <44E1ED72.2090605@telus.net> Rapha?l Quinet wrote: > On Tue, 15 Aug 2006 22:39:59 +0800, Lalo Martins wrote: > >> On Tue, 15 Aug 2006 11:40:46 +0200, Rapha??l Quinet wrote: >> >>> One thing that could be added in the "nice to have" list is the >>> support for migrating local branches to another repository. >>> >> That's easy; all distributed revision control systems have that ability >> (they call it "pushing" or "mirroring" the branch, depending on the >> system). It's a requirement of the distributed model, for reasons you >> expose quite well in your message. >> > > Do you know if all of them allow any user to perform that mirroring? > I thought that some of them required some action from the branch owner, > not just any user (as I mentioned in my previous message, requiring the > owner to do it would not fit in the "good support" category). If all > of them provide good support for moving or mirroring local branches > back to the "official" repository, then there is no need to add this > feature to the comparison table. And anyway, I would prefer to avoid > using local branches for the reasons explained in my other message. Well, most of them operate over ssh, so if you could make a branch on at a remote location, simply requires that you have permissions to the parent directory of where the branches are stored, in addition to the branches. Some distributed systems are able to init over ssh, however there are other systems that would require you to manually log in to the remote location and init a repository before you can push to it. Of course, it is trivial to make a miniature bash script a couple lines long to handle the logging in to the remote system to init the repository. Mercurial for example seems to supposed to be able to do that however at least in 0.9.1 seems to be buggy at initing a repository over ssh. Alex Schultz From mwedel at sonic.net Wed Aug 16 00:01:14 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 15 Aug 2006 22:01:14 -0700 Subject: [crossfire] TODO list items. In-Reply-To: <200608150954.49718.nicolas.weeger@laposte.net> References: <44E17AE9.6060207@sonic.net> <200608150954.49718.nicolas.weeger@laposte.net> Message-ID: <44E2A69A.9080401@sonic.net> Nicolas Weeger (Laposte) wrote: > I won't comment on the priority, just other things :) > >> Better NPC logic 1.x? 1 > > Can be scripted. I'm no mapmaker, but if someone gives me the flow of the > dialog I can write the script. > I could look at adding utility functions to help write such dialogs, too. > (Daimonin does that, I think) I think for NPC logic, it should be termed monster logic really. I think that is what it is talking about. So what I'd see if monsters being smarter on what attacks they choose, finding a path to the player (right now, I think they just pretty much do a straight path logic, so easy to duck around a wall and never have them get to you), sensibly use healing spells, etc. OTOH, some of these depends on other issues - as long as monsters have 10x the number of HP as players, most healing spells will be pretty pointless for them. > >> Newspaper (script based) 1.x? 3? > > Can already be done, but no one actually did it... > (may require scripts to access timeofday stuff, but not that hard) Probably also needs more detail in terms of what information it will actually present. As it is now, it is relatively vague in terms of what it would do. > >> Player clothing (image change based on clothing) 3.0 3? > > Would require many graphics artists, though, and already many things to redo > first :) Which is why I put it as 3.0. And at some level, given the relatively small image sizes, might be really hard to distinguish (most if the images for actual equipment uses the full 32x32 pixels, and thus just can't be overlayed on top of the image for the characters. A perhaps easier thing would be using different color channels (or whatever) so that the color of clothing could be changed - eg, you get a new color key to use. So you don't need seperate images for a red mage vs a blue mage, just a different color key. The problem is that has to get communicated down to the client, which means revising the protocol. And, unlike animations and smoothing, which are basically image/archetype attributes and only need to be sent once, color keys (or clothing changes) is an object attribute - could have bunch of different mages currently in the game with different colored garb. > >> Time of day based events 2.0 2 > > See newspaper :) Depends on the level and commonality of the events. The most basic use of this I would see would be exits (shops) closing at night and opening during the day. Could be certain places (taverns) that only open at night. Scripts could be used for that, but sort of back to some previous things, if we are looking to use that a lot, may make sense to have an easier hook (or need common scripts, so that you don't need need to write a custom one for each shop). Secondarily would be NPCs saying different things. I think scripts may be needed for that. Also, having the different connected values based on time. It would make sense that the scorn gate is open during daylight hours, but closing during the night. But like a lot of these, exactly how it is done isn't as important. If these can be easily done with scripts, thats great, but those scripts still need to be written, tested, etc. Saying it can be done with scripts isn't that much different than saying 'it can be written in C code' - that code still needs to be written :) > >> Make slaying more consistent 2.0 2 > > What do you mean by that? From the TODO list: Slaying is sloppy in that it uses strstr. This, an item that has 'slaying giant' (like holyword of mostrai) will kill ants. strstr matching was most likely added to support comma seperated slaying lists (slaying demon,undead). However, the code should really insist on exact matching, and if necessary break apart the comma seperated list. Probably best to make something like a 'does_slay()' function which can be used all over the place (consistent behaviour is a good thing). If performance for this becomes an issue, making a slaying a set of pointers could be done (char **slaying), and it gets filled in at load time, and at save time, gets filled in the opposite direction. However, from a simple basis, a check in does_slay() can be done to see if slaying does contain a comma, and if not, just do simple strcmp, and only if it does does extra work need to be done. MSW 2003-03-28 > >> discrete attack damage (dam_fire, dam_cold.) 2.0 3 > > Hu? Right now, if you have a weapon that has attacktype physical & fire, and dam 40, it will do dam 40 of whatever attack works best against the creature. It is fairly common in most games that extra attacktypes do some extra damage. Eg, this weapon does 20 physical damage and 10 fire damage. There isn't any way to do that right now (ok, maybe with scripts :), but that isn't really the point here). The effect of the unified damage in crossfire has some bad effects - for attacktypes which are really affects (paralyze, slow), the duration of the effect is determined by the damage. The problem this gets is if you have a weapon that does physical + paralyze, it is hard to balance the damage (the paralyze effect could be too strong in order for the weapon to do a reasonable amount of physical damage, etc). If those are separated out, it allows much finer tuning of objects. It would actually lower the power, as a weapon that currently has physical + fire with dam 30 should be changed so that it's dam_phys + dam_fire = ~30. For sake of argument, lets say it is an even split of 15/15. If your using that weapon fighting fire resistant creatures, you'll still do 15 physical, but much less fire. So I think it would make it less clear what the best weapon to use would be - right now, the more attacktypes a weapon has, the better basically. From mwedel at sonic.net Wed Aug 16 00:15:15 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 15 Aug 2006 22:15:15 -0700 Subject: [crossfire] crossfire source code control systems In-Reply-To: <20060815111507.2af6b590.raphael@gimp.org> References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <44E14D65.4050409@sonic.net> <44E15B1D.3060606@telus.net> <44E161FF.9000601@sonic.net> <20060815111507.2af6b590.raphael@gimp.org> Message-ID: <44E2A9E3.5070608@sonic.net> If a distributed model is used, this is how I would see local branches in use: - Mirrors of the official repository - could be for speed reasons (one in europe, one in asia, or just in general to cover outages if the official repository is down). - For developers to make their changes easily available - instead of sending what could be a long diff to the mailing list, they could say 'these changes are in my repository at ...'. - For several developers who are collaborating on a big change - to have a repository that they can make their changes on, and when done, commit those back. I note that in all of these cases, this is basically functionality that CVS doesn't really support well. I'd have to double check, but I thought most of the distributed ones have a method to reparent - if you did a checkout from a mirror, made some changes and wanted to put back, you have to commit to the main repository so need to reparent to that. Second and third points could be done in branches in CVS, but then as discussed, the CVS branching/merging model isn't great. It's also unclear, if even in a branch, CVS should be used to store work in progress files, etc. I don't see the use of distributed repositories as a substitution of committing stuff back to the main repository. And while there could be reasons that repositories disappear, and thus so do their changes, that also isn't really different than right now. It probably isn't uncommon for developers to have changes in their local CVS repositories - if their hard drive crashed now, or they disappeared, those changes would be lost. The only real difference right now is that no one would know about it. If anything, those extra repositories actually help out in this case. If someone has some changes and say 'you can get it at ABC', and it looks interesting and I do pull it down, now I have a local copy myself, so if ABC goes away, it still exists. I'll note that in no way do I see it being a requirement that developers make their changes available in this way - you could still send out diffs to the mailing list, etc, and decide not to look at other repositories. I don't really see that providing more options is a bad thing. From alex_sch at telus.net Wed Aug 16 01:09:54 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 16 Aug 2006 00:09:54 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44E2A9E3.5070608@sonic.net> References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <44E14D65.4050409@sonic.net> <44E15B1D.3060606@telus.net> <44E161FF.9000601@sonic.net> <20060815111507.2af6b590.raphael@gimp.org> <44E2A9E3.5070608@sonic.net> Message-ID: <44E2B6B2.6070405@telus.net> Mark Wedel wrote: > If a distributed model is used, this is how I would see local branches in use: > Agreed on the points you mentioned, just one comment. > I note that in all of these cases, this is basically functionality that CVS > doesn't really support well. I'd have to double check, but I thought most of > the distributed ones have a method to reparent - if you did a checkout from a > mirror, made some changes and wanted to put back, you have to commit to the main > repository so need to reparent to that. > Most distributed systems allow pushing to and pulling from arbitrary repositories, the "parent" that it keeps track of is just the default repository to pull from or push to if you don't specify one, so for the purposes of a one time push to the main repository, no need to even bother reparenting really. If you want to change the default "parent" though, I think you typically have to manually change that in a file, but those files are human readable just like CVS/Root files, and there is only one to change per branch, instead of one-per-directory like in CVS. Alex Schultz From kbulgrien at att.net Tue Aug 15 20:05:28 2006 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Tue, 15 Aug 2006 20:05:28 -0500 Subject: [crossfire] crossfire source code control systems References: <44DD8863.4000401@sonic.net> <44DD9BAA.3010703@telus.net> Message-ID: > With a distributed SCM, you'll install your maps dir as a local branch, > branched from the maps mainline. Then you can make your own changes and > commit them -- you even get local revision control for your stuff. And > when you need to update your maps, you just merge from the mainline; that > *may* cause conflicts, but it's guaranteed to never lose your changes (as > they will, at the very least, be in the history). This is an interesting thread, but I cannot help but think that people do not really know key things about CVS. CVS can handle precisely this sort of scenario quite handily. I did it just this weekend when I downloaded, ironically, the CVS CVS repository in order to give them a patch on docs. In my sandbox, I created my own sandbox that was for a local repository and in the same directory tree. cvs update at the top of the directory tree just worked. Remote things updated from remote repositories and local things updated from local repositories in one fell swoop. My opinion obviously means little as I'm not a project developer, but if crossfire went away from CVS, I would be very sad, as I have zero interest in dividing my brain into SCM compartments for every open source project out there that I dabble in. I can currently twiddle around and contribute (what very little I have) precisely because CVS is practically universal. There are nitpicky things about CVS, but I suspect if people tried to get their heads around it almost all issues that seem significant can be dealt with adequately in CVS. I admin a VC system at work, and spent a while looking at other systems and gave it up in the end, even after giving svn a go. Do not want to train people that don't care a hoot about version control, and just want to do work. Maybe your team is all about VC, but mine wasn't, and I saw no reason to subject myself and them to a whole host of new problems by tossing something that works really well, including branching. I don't get the comments about CVS branching being inadequate. To me its all about following CVS best practices and not necessarily the horde of people who don't do it according to those practices. It's just not that hard. The whole atomic commit/universal version number thing is far, far more an issue with highly concurrent development. If you haven't gotten bit yet, you likely never will, so it ends up being a non-reason if you ask me. Why take on a learning curve for a "feature" that really has almost zero chance of giving you a decent ROI. Besides, CVS will never trash your repository. How many times have there been svn issues that will trash your repository, even if it is only the doozer that forgets the backend is a database that cannot simply be copied from one system to another if the database version is a bit different. Also, one of those tools on the list was not even version 1.0. At work we are on CVS because every other tool (several) they used trashed the repository. In perhaps going on ten years now, not one byte has been lost to CVS malfunctions. Now those were commercial tools, and not ones on your list, but... if it ain't borked, don't fix it is what I say. Features aren't sexy enough if you ask me. Yeah, the whole "permanent directory" thing is hosed, but then so is the doofuss that goes in every six months and changes everything all around because they just had a girlfriend change. Shrug, ok, end of rant, do what you will, but I suspect it will cut down on participation because people won't be bothered to learn a system they don't already know how to use, and I don't see contributors flocking to the doors as it is. Just my ten cents... Kevin Bulgrien From alex_sch at telus.net Wed Aug 16 13:42:35 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 16 Aug 2006 12:42:35 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: References: <44DD8863.4000401@sonic.net> <44DD9BAA.3010703@telus.net> Message-ID: <44E3671B.90104@telus.net> Kevin R. Bulgrien wrote: >> With a distributed SCM, you'll install your maps dir as a local branch, >> branched from the maps mainline. Then you can make your own changes and >> commit them -- you even get local revision control for your stuff. And >> when you need to update your maps, you just merge from the mainline; that >> *may* cause conflicts, but it's guaranteed to never lose your changes (as >> they will, at the very least, be in the history). >> > > This is an interesting thread, but I cannot help but think that people do > not really know key things about CVS. CVS can handle precisely this sort > of scenario quite handily. I did it just this weekend when I downloaded, > ironically, the CVS CVS repository in order to give them a patch on docs. > In my sandbox, I created my own sandbox that was for a local repository > and in the same directory tree. cvs update at the top of the directory > tree just worked. Remote things updated from remote repositories and > local things updated from local repositories in one fell swoop. > Well, to me it seems unclear how well CVS would keep track of merging things from the mainline, plus it's nice if this history locally of changes in a large project, is copied to the mainstream. Also, downloading the cvsroot isn't exactly nice on sf.net, due to the different modules, one must rsync all of the modules in order for cvs to work properly on it, and that's over 800MB of data to transfer, and even if one was about to figure out a hack to get only the server module and some cvsroot files so cvs would like it, it would still be 184MB to transfer. Various distributed SCMs can deal with pulling the history and everything on their own, and can transfer the crossfire server tree history and all in as little as 77 MB. Even if sf.net had a nicer way of getting the cvsroot, it just doesn't seem to me CVS would handle the merges very well or keep track of them in a useful way. Also, one thing that distributed SCMs would allow easily that I don't think would work well in CVS at all, would be: A developer is planning on making a variety of experimental game-balance changing changes and wants to test them out locally, so the developer makes a couple different (temporary-until-merged-to-mainline) local branches for different aspects of the changes that he wants to be able to merge to the mainline separately easily. The developer also wants to test them all at once, so the developer makes another local branch and pulls the changes from all of those other ones, and builds a test server with that. Also, the developer could very very easily make that local branch viewable to others so they could get it to test out it's balance. That is IMHO something very useful that I can see happening with crossfire, that would be pretty trivial with distributed SCMs, that I don't think could be done very well at all with CVS. > My opinion obviously means little as I'm not a project developer, but if > crossfire went away from CVS, I would be very sad, as I have zero interest > in dividing my brain into SCM compartments for every open source project > out there that I dabble in. I can currently twiddle around and contribute > (what very little I have) precisely because CVS is practically universal. > > Shrug, ok, end of rant, do what you will, but I suspect it will cut down on > participation because people won't be bothered to learn a system they don't > already know how to use, and I don't see contributors flocking to the doors > as it is. The issue in those two paragraphs is warranted IMHO, however I personally feel that if moving to another SCM, it could be dealt with very trivially by using the SCM conversion program 'tailor', to keep a read-only CVS mirror perfectly in sync, history and all. That could even be setup to be done automatically every time a change is put in the mainline tree with many SCMs. Therefore people who just want read-only repository access can stick with CVS perfectly fine. > The whole atomic commit/universal version number thing is far, far > more an issue with highly concurrent development. If you haven't gotten > bit yet, you likely never will, so it ends up being a non-reason if you > ask me. Well, the universal version number thing has bitten me a couple times, when wanting to figure out how a revision changed a variety of files when the changes were too big to show up in sf.net cvs mail. That said, that is only a minor annoyance. > Besides, CVS will never trash your repository. How many times have > there been svn issues that will trash your repository, even if it is > only the doozer that forgets the backend is a database that cannot simply > be copied from one system to another if the database version is a bit > different. Also, one of those tools on the list was not even version 1.0. > At work we are on CVS because every other tool (several) they used trashed > the repository. In perhaps going on ten years now, not one byte has been > lost to CVS malfunctions. Now those were commercial tools, and not ones on > your list, but... if it ain't borked, don't fix it is what I say. Well, I have never heard of any distributed SCMs trashing repositories, however even if the very unlike event something were to the nature of people having local branches has a side affect of causing highly redundant backups, so the repository would be trivial to restore, even if the hard disk crashed where the mainline was kept and the server backups were lost. To me it seems that the highly unlikely chance that of server failure and backup loss at a single source, is more likely than the repositories getting trashed at 5+ separate places at once. > Yeah, the whole "permanent directory" > thing is hosed, but then so is the doofuss that goes in every six months > and changes everything all around because they just had a girlfriend change. > Yep, and there are valid reasons to move code around to make things more organized, not every 6 months, but every 5 years or so at least, and actually currently the archetypes module in CVS is currently littered with large numbers of empty directories from when things were poorly organized. That said, it's only a minor annoyance, but it's yet another thing contributing to CVS being annoying. Alex Schultz From raphael at gimp.org Thu Aug 17 09:47:50 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Thu, 17 Aug 2006 16:47:50 +0200 Subject: [crossfire] Proposal for better in-game information: client-side "player books" In-Reply-To: <44E159E2.9020609@sonic.net> References: <20060814112137.169ec054.raphael@gimp.org> <44E159E2.9020609@sonic.net> Message-ID: <20060817164750.388aa824.raphael@gimp.org> On Mon, 14 Aug 2006 22:21:38 -0700, Mark Wedel wrote: > id being the archetype probably makes the most sense. If you make it numeric, > it would have to be some sort of hash I'd think so that it is consistent, and > then there is always the danger that something new is added causing the hash > conflict, resulting in the hash changing anyways. In most cases, using the archetype as is the best choice. But I would also like to be able to document some artifacts, not only the archetypes. For the artifacts, the best choice would probably be "archetype name + title", which should be unique. > Alternatively, the number itself could be in the archetype, but that would > seem to be full of problems - duplicate numbers, etc. > > Given this content isn't sent very often, not sure if using the longer > archetype name would be a problem. Right. Even if the string is a bit longer when the title is included, that should still be acceptable for something that is not sent often. > Spells: > As of now, you can't learn a spell unless you are sufficient level to cast it > (DM's could teach you spell without that restriction, but that is a bit of an > edge case). Now it is possible you learned a spell, died, lost some levels, but > then in that case, you still knew all the attributes at once. While it is > reasonable to say that since you can't cast the spell, you can't remember the > details - the problem is that could then lead to outside game notetaking on what > you did know. Yes, I was thinking specifically of the case of a player losing levels after a painful death. And I think that it is better to let the player keep the information, but simply add a note saying something like: "you are currently unable to cast that spell". > For the same reason, I think it is good to give full information for the > spells the player knows. Some of it could be figured out empirically - I'm > denied healing, and can't cast that spell, thus it must be in the healing path, > etc. But some is playability - if that information is really needed, and isn't > being provided, I'll just go elsewhere for the information (spoiler, whatever). In that case, there is really no reason to keep the random books about spellpaths. If learning a spell is enough to know which path it belongs to and if the table of spells can be sorted by path, then the books about spellpaths are almost useless. The only hint that they could still provide is the name of some other spells belonging to the same path and that are not known yet by the player. However, this information is not very important and some of the spells may not even be available at all (e.g., special prayers). > Storing information: It should be stored in the archetype it describes - the > addition of files in the lib directory to describe archetype is the wrong way to > go (if anything, we are trying to move away from that, with things like the .trs > file). Right. When I mentioned a file in the lib directory, I was thinking about where the server can find this information. But it could of course be collected from the archetypes, just like the treasure lists. > There is the lore/endlore fields right now which was envisioned to hold > information on various things that would then go into books. I'd suggest that > could be used, with perhaps defined tags for different fields, eg: > abilities: ... > desc: .... > other: .... > > and so on. Good idea. Using the "lore" attribute is probably the best solution. > There may still need to be some information in the lib directory for data that > isn't directly related to any archetype (rumors of a dungeon, etc). One thought > on that is that the file should probably be extended to have region clauses - it > doesn't make much sense to be hearing about information of a dungeon near scorn > if you're in wolfsburg. By localizing the messages, it then means when in > scorn, you'd get lots of information about what is in and about scorn, etc. Also a good idea. This would encourage the players to visit other regions and collect their random books. The region-specific information could even be part of the maps module rather than the server module and then collected and stored into a file in the lib directory. > > - If the player already knows some piece of information, it would be > > nice to leave the corresponding page(s) in the game instead of > > taking it away. This is how spell books and skill scrolls work > > today. How should the server know if the page(s) should be removed > > or not? Should the server keep a list of all things that have > > already be sent to the client? > > I might have missed it further above, but this note here suggests that this > information in cached client information? Yes, my idea was to cache this information on the client side in order to allow the player to browse through it offline. I would like to have enough information in these player books so that the Crossfire spoiler and handbook would not be necessary anymore. And it is useful to be able to read this information offline, without playing. The client could provide its own interface for reading this special book (e.g., a large window with various tabs for the different kinds of information: monsters, spells, etc.) but I think that it would also be useful to be able to read it in a standard HTML browser, directly from files generated and stored on disk by the client. The HTML view could use nice CSS and images to make the information more attractive. Offering the HTML output would also make it easier for the clients: some clients could implement the book browser in their own interface but some other clients could simply rely on an external web browser and would not have to worry about displaying text and images from all these messages. So when a player using such a client gets a new piece of information and wants to read it, the client would simply trigger some external web browser or help browser, as this is done in other programs to display online docs. > If so, I'm not sure that is a good approach or not - there is no guarantee > that players will be on the same computer, and thus would lose that information > (currently, the only thing the client really stores locally is the user > preferences). I'd say that would be unexpected by most players. And if done, > then such caching would have be be segregated based on the server it came from, > since different might not agree on all the data. > > The client caching the data would also infer that this knowledge is really > player knowledge, so if you played a bit and made a new character, that first > level character would have a lot of knowledge. Maybe that isn't bad - not 100% > sure. Sure, these are pros and cons to the client caching option. I would like to have it because I am not permanently online and I would enjoy being able to read some of the hints and other information collected by my character even if I am not connected anymore. One way to avoid problems when players use multiple computers or connect to multiple servers would be to do a cache synchronization when the player (re)connects. If the server keeps track of what each character knows then it could send this list to the client, which would then remove some of the messages from its cache and request the missing ones from the server. I think that the general information about the religions, quests and other random messages should never be removed from the cache. Maybe this could even be the case for the monsters and artifacts. The only categories that the (non-cheating) client should remove from its cache are the list of spells and all formulae (alchemy). > I do say I think it would be nice from a game perspective to actually know > what information the character has learned - alchemy could require you know the > recipe, quests/npcs could give pieces of missing information, etc. Yes. The drawback is that the server would have to keep track of all that on a per-character basis and that could be a rather long list. > > - These special books could be represented as objects in the players' > > inventory or they could be "out of the game" with a specific client > > interface to access them (just like the list of skills or spells can > > be obtained without using an object). > > I'd think that if they are in game, then if you applied one, there would be > too much information pretty quickly to reasonable read/parse, so I think some > other interface is needed. Well, of course I never intended these objects to display their information in the normal info window. What I had in mind is that if these books are shown in the player's inventory, applying them would open the new book browser (new interface with images, etc.) or maybe even trigger an external web browser. Just like some programs do when you press F1 to get help. Showing the special book as an item in the inventory would simply provide another way to start the book browser (the other way being via the client menus) and maybe also a way to add weight to the player if the book contains a lot of information. > It could really be seen as an interface to the characters memory. Yes, that's a good way to describe it. So maybe it does not need to be shown in the inventory. > > - All messages described above can be sent in plain text (maybe with a > > bit of markup for cross-references), including the images if they > > refer to existing faces. However, if we find an artist who has a > > lot of spare time to spend on crossfire, it may be possible to > > enhance the messages with custom images to be included in the HTML > > rendering of the player book. How should the images be sent to the > > client in this case? As special faces or as part of the messages? > > There isn't any reason that the image couldn't be added in the archetypes and > sent in the normal way (I'm not even sure if there is any real maximum size if > it is just an image not displayed on the map). Sending it as part of the > message would seem ugly. Large images could be useful in some messages. For example, we have some random messages containing ASCII art maps. Replacing them by a nice PNG image would be an improvement. Especially because the ASCII art maps do not work anymore with a proportional font. Thanks for the feedback on this proposal. It is not for the near future anyway, but maybe some bits of it could be considered for 2.x or 3.x? -Rapha?l From raphael at gimp.org Thu Aug 17 10:04:54 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Thu, 17 Aug 2006 17:04:54 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44E1ED72.2090605@telus.net> References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <20060815114046.33706ee6.raphael@gimp.org> <20060815171307.7c9720da.raphael@gimp.org> <44E1ED72.2090605@telus.net> Message-ID: <20060817170454.7e010f5c.raphael@gimp.org> On Tue, 15 Aug 2006 09:51:14 -0600, Alex Schultz wrote: > Rapha?l Quinet wrote: > > On Tue, 15 Aug 2006 22:39:59 +0800, Lalo Martins wrote: > >> On Tue, 15 Aug 2006 11:40:46 +0200, Rapha??l Quinet wrote: > >>> One thing that could be added in the "nice to have" list is the > >>> support for migrating local branches to another repository. > >>> > >> That's easy; all distributed revision control systems have that ability [...] > Well, most of them operate over ssh, so if you could make a branch on at > a remote location, simply requires that you have permissions to the > parent directory of where the branches are stored, in addition to the > branches. OK, maybe that would be sufficient. One reason why I was asking if it is possible to do some mirroring without requiring special actions from the owner of a local branch was to see if some automatic mirroring could be put in place easily. i.e., something that could be done via a cron job rather than something requiring manual intervention. I forgot about some features that I would like to see in the "nice to have" part of the comparison matrix: the ability to do partial checkouts or partial updates. Some systems based on atomic commits support partial checkouts and/or updates but I do not know if this is the case for the ones listed in the table. CVS supports both. By "partial checkout", I mean the ability to check out only a part of a module. For example, if you are not using your usual computer that has all the modules checked out and you just want to fix a bug in one map, it is possible to do a "cvs checkout crossfire-maps-bigworld/some/map". Then you only transfer what you need, make the changes and commit them without having to check out the whole tree. By "partial update", I mean the ability to synchronize only the files that you want to update from the repository without having to update all files. For example, if I am in a hurry while traveling or if I do not want to spend too much time online, I can just go in my ~/cvs/crossfire directory and do a "cvs checkout Changelog" to update only that file. Then I have a quick look at it and I can decide if I want to transfer anything else. Even if some files are part of an atomic commit, some systems allow you to synchronize only a subset of these files if you do not intend to work on the other ones. Partial checkouts and partial updates are more useful for those who want to limit the amount of data to be transfered. I do not know if these features would be useful to all developers, but I use them rather often so I am curious to know if the systems proposed as alternatives to CVS are also able to do that. -Rapha?l Some distributed systems are able to init over ssh, however > there are other systems that would require you to manually log in to the > remote location and init a repository before you can push to it. Of > course, it is trivial to make a miniature bash script a couple lines > long to handle the logging in to the remote system to init the > repository. Mercurial for example seems to supposed to be able to do > that however at least in 0.9.1 seems to be buggy at initing a repository > over ssh. > > Alex Schultz > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From alex_sch at telus.net Thu Aug 17 12:55:08 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 17 Aug 2006 11:55:08 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <20060817170454.7e010f5c.raphael@gimp.org> References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <20060815114046.33706ee6.raphael@gimp.org> <20060815171307.7c9720da.raphael@gimp.org> <44E1ED72.2090605@telus.net> <20060817170454.7e010f5c.raphael@gimp.org> Message-ID: <44E4AD7C.3030302@telus.net> Rapha?l Quinet wrote: > By "partial checkout", I mean the ability to check out only a part of a > module. For example, if you are not using your usual computer that has > all the modules checked out and you just want to fix a bug in one map, it > is possible to do a "cvs checkout crossfire-maps-bigworld/some/map". Then > you only transfer what you need, make the changes and commit them without > having to check out the whole tree. > Well, Mercurial currently does not support 'lightweight checkouts', and you must pull the whole branch history (recently for fun I made an extension for Mercurial for 'lightweight checkouts' however it only supports making checkouts from local branches, and it will be a long time till lightweight checkouts from remote locations could be supported), as I noted on my table on the wiki. Darcs doesn't either. Bzr supports lightweight checkouts, however it doesn't support partial lightweight checkouts. Also, none of them support partial local branches (don't know of any that do), however Mercurial does have some plans for implementing that. > By "partial update", I mean the ability to synchronize only the files that > you want to update from the repository without having to update all files. > For example, if I am in a hurry while traveling or if I do not want to > spend too much time online, I can just go in my ~/cvs/crossfire directory > and do a "cvs checkout Changelog" to update only that file. Then I have > a quick look at it and I can decide if I want to transfer anything else. > Even if some files are part of an atomic commit, some systems allow you to > synchronize only a subset of these files if you do not intend to work on > the other ones. > In terms of lightweight checkouts, which only bzr supports, it doesn't support partial updates. Other than that an update, with distributed SCMs is considered just updating the working directory of a local branch (to get the latest changes from somewhere, you do a pull, and to update the working directory, do an update), which is a completely offline operation, so in terms of speed, it doesn't make a significant difference. > Partial checkouts and partial updates are more useful for those who want > to limit the amount of data to be transfered. I do not know if these > features would be useful to all developers, but I use them rather often > so I am curious to know if the systems proposed as alternatives to CVS > are also able to do that. Well, with the working practices of CVS, it is rather useful, however the working practice of distributed SCMs makes it IMHO unnecessary. With distributed SCMs, it is typical to keep a local "incoming" branch, which is a perfectly clean clone of the mainline remote repository, as well as an "outgoing" branch pulling changes from all of your local branches you are working on, and then make a temporary local branch for each feature you're working on. Making your incoming branch of the crossfire server would take 77MB of bandwidth, however pulling changes from the mainline to it in the future takes a matter of seconds. Making the other local branches can just be done by cloning the incoming branch, an offline operation which takes a mere 5 seconds on Mercurial for the crossfire server tree. So really, local branching and distributed SCM practices despite increasing the data stored locally, greatly decreases the necessary bandwidth in the long run (a checkout of the crossfire server takes 10-20 MB on CVS, not long before it exceeds the initial investment of a incoming local branch on distributed systems), so really, the usefulness of partial checkouts and updates is near zero IMHO. Alex Schultz From fuchs.andy at gmail.com Thu Aug 17 14:43:03 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Thu, 17 Aug 2006 15:43:03 -0400 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44E4AD7C.3030302@telus.net> References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <20060815114046.33706ee6.raphael@gimp.org> <20060815171307.7c9720da.raphael@gimp.org> <44E1ED72.2090605@telus.net> <20060817170454.7e010f5c.raphael@gimp.org> <44E4AD7C.3030302@telus.net> Message-ID: I would like to bring up another issue regarding the sf.net webspace and Mercurial. The last time I checked (looking into running a wiki on it) all scripts run without a sandbox and as the same user. This creates a large security issue, where it may be possible for someone else that has access to a sf.net webspace to screw around with the repository. -- Andrew Fuchs From alex_sch at telus.net Thu Aug 17 19:10:43 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 17 Aug 2006 18:10:43 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: References: <44DD8863.4000401@sonic.net> <44E0E8DA.3060307@telus.net> <20060815114046.33706ee6.raphael@gimp.org> <20060815171307.7c9720da.raphael@gimp.org> <44E1ED72.2090605@telus.net> <20060817170454.7e010f5c.raphael@gimp.org> <44E4AD7C.3030302@telus.net> Message-ID: <44E50583.2080808@telus.net> Andrew Fuchs wrote: > I would like to bring up another issue regarding the sf.net webspace > and Mercurial. The last time I checked (looking into running a wiki > on it) all scripts run without a sandbox and as the same user. This > creates a large security issue, where it may be possible for someone > else that has access to a sf.net webspace to screw around with the > repository. Well, unless we can get the quota expanded significantly, we wouldn't be able to use Mercurial on sf.net webspace anyways. Unless I'm missing something, sf.net doesn't run all scripts on the same user on SF, instead the security issue with wiki software on it, is that any project admin has read-access to any of the web accounts. For wiki servers, this often means that password hashes in the login system are publicly accessible. For Mercurial (and most distributed SCMs) that isn't an issue though, because Mercurial never stores any password hashes, because all access control is handled by SSH and/or HTTP authentication. From mwedel at sonic.net Fri Aug 18 02:50:02 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 18 Aug 2006 00:50:02 -0700 Subject: [crossfire] Proposal for better in-game information: client-side "player books" In-Reply-To: <20060817164750.388aa824.raphael@gimp.org> References: <20060814112137.169ec054.raphael@gimp.org> <44E159E2.9020609@sonic.net> <20060817164750.388aa824.raphael@gimp.org> Message-ID: <44E5712A.6030104@sonic.net> Rapha?l Quinet wrote: >> For the same reason, I think it is good to give full information for the >> spells the player knows. Some of it could be figured out empirically - I'm >> denied healing, and can't cast that spell, thus it must be in the healing path, >> etc. But some is playability - if that information is really needed, and isn't >> being provided, I'll just go elsewhere for the information (spoiler, whatever). > > In that case, there is really no reason to keep the random books about > spellpaths. If learning a spell is enough to know which path it > belongs to and if the table of spells can be sorted by path, then the > books about spellpaths are almost useless. The only hint that they > could still provide is the name of some other spells belonging to the > same path and that are not known yet by the player. However, this > information is not very important and some of the spells may not even > be available at all (e.g., special prayers). I'd probably say that the books about spellpaths are pretty much useless. They could perhaps be more interesting if they give more information - knowing the spellpaths isn't particularly interesting. Knowing what spells, with descriptions, damage, whatever could make things more interesting (spell abc looks really cool - I should find a copy). But it seems that the general case for games is that information of the spells is pretty widely available, so that if you know a spell, you know about it. >> There may still need to be some information in the lib directory for data that >> isn't directly related to any archetype (rumors of a dungeon, etc). One thought >> on that is that the file should probably be extended to have region clauses - it >> doesn't make much sense to be hearing about information of a dungeon near scorn >> if you're in wolfsburg. By localizing the messages, it then means when in >> scorn, you'd get lots of information about what is in and about scorn, etc. > > Also a good idea. This would encourage the players to visit other > regions and collect their random books. The region-specific > information could even be part of the maps module rather than the > server module and then collected and stored into a file in the lib > directory. Yes, and this regionalization could even go just beyond surrounding dungeons - one could envision that some alchemy formula only appear in certain reasons, or make more specific information about the local government, etc. >> If so, I'm not sure that is a good approach or not - there is no guarantee >> that players will be on the same computer, and thus would lose that information >> (currently, the only thing the client really stores locally is the user >> preferences). I'd say that would be unexpected by most players. And if done, >> then such caching would have be be segregated based on the server it came from, >> since different might not agree on all the data. >> >> The client caching the data would also infer that this knowledge is really >> player knowledge, so if you played a bit and made a new character, that first >> level character would have a lot of knowledge. Maybe that isn't bad - not 100% >> sure. > > Sure, these are pros and cons to the client caching option. I would > like to have it because I am not permanently online and I would enjoy > being able to read some of the hints and other information collected > by my character even if I am not connected anymore. > > One way to avoid problems when players use multiple computers or > connect to multiple servers would be to do a cache synchronization > when the player (re)connects. If the server keeps track of what each > character knows then it could send this list to the client, which > would then remove some of the messages from its cache and request the > missing ones from the server. I think that the general information > about the religions, quests and other random messages should never be > removed from the cache. Maybe this could even be the case for the > monsters and artifacts. The only categories that the (non-cheating) > client should remove from its cache are the list of spells and all > formulae (alchemy). Yes - having a method for the client to request the information is fine. Arguably, the client doesn't even need to request it until the player actual goes to access the information. One issue with never removing cached data is having old/obsolete entries stick about. Suppose a monster or object is renamed - there is no way for the client to know that, so it just has the old entry for the rest of time, which could eventually get annoying. > >> I do say I think it would be nice from a game perspective to actually know >> what information the character has learned - alchemy could require you know the >> recipe, quests/npcs could give pieces of missing information, etc. > > Yes. The drawback is that the server would have to keep track of all > that on a per-character basis and that could be a rather long list. but even then, probably wouldn't be that long/bad to handle. > Well, of course I never intended these objects to display their > information in the normal info window. What I had in mind is that if > these books are shown in the player's inventory, applying them would > open the new book browser (new interface with images, etc.) or maybe > even trigger an external web browser. Just like some programs do when > you press F1 to get help. Showing the special book as an item in the > inventory would simply provide another way to start the book browser > (the other way being via the client menus) and maybe also a way to add > weight to the player if the book contains a lot of information. I'd think from a cleanliness standpoint, it should be done as a menu item. Otherwise, it is odd in two regards - 1) The client has to know to handle the book activate request in a special way - instead of sending the apply event to the server, it has to go and do whatever is needed to access the info. 2) The player probably has some expectation what happens when they apply an item in their inventory, and having a window or whatever pop up with all that info probably isn't it. >>> - All messages described above can be sent in plain text (maybe with a >>> bit of markup for cross-references), including the images if they >>> refer to existing faces. However, if we find an artist who has a >>> lot of spare time to spend on crossfire, it may be possible to >>> enhance the messages with custom images to be included in the HTML >>> rendering of the player book. How should the images be sent to the >>> client in this case? As special faces or as part of the messages? >> There isn't any reason that the image couldn't be added in the archetypes and >> sent in the normal way (I'm not even sure if there is any real maximum size if >> it is just an image not displayed on the map). Sending it as part of the >> message would seem ugly. > > Large images could be useful in some messages. For example, we have > some random messages containing ASCII art maps. Replacing them by a > nice PNG image would be an improvement. Especially because the ASCII > art maps do not work anymore with a proportional font. Yes, having PNG maps would be nice. Even for other stuff, it could be nice, like images of important people, gods, etc. From raphael at gimp.org Fri Aug 18 08:39:24 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Fri, 18 Aug 2006 15:39:24 +0200 Subject: [crossfire] Proposal for better in-game information: client-side "player books" In-Reply-To: <44E5712A.6030104@sonic.net> References: <20060814112137.169ec054.raphael@gimp.org> <44E159E2.9020609@sonic.net> <20060817164750.388aa824.raphael@gimp.org> <44E5712A.6030104@sonic.net> Message-ID: <20060818153924.5d3da81b.raphael@gimp.org> Here is a quick summary of what was discussed a few hours ago on IRC. These are basically some additions and clarifications to what was posted here. Eventually, this information should be summarized and added to the wiki (dev_todo) and of course this should materialize as real code... * In order to explain why the readable items disappear after being read, it may be better to think about the "player books" as binders: the player finds some useful pages and stores them in her binder in order to carry them around easily. * A player who has collected a lot of information could get additional "player books" (binders) to organize this information. Another idea would be that each player starts with predefined binders, one for each type of information: one for monsters, one for religions, one for alchemy (or each sub-type: smithery, woodsman, ...) and so on. * It may be better to replace the current random books by scrolls or "scraped book pages". The information contained in the random books would usually fit on a single page anyway. * Spell books are magic items. This could explain why they disappear after being read. * Besides the non-random books used in some maps, we could still have a few random books. These would contain many pages and would be both (very) rare and (very) valuable. Their value would depend on their number of pages. * To explain the scattering of pages throughout the game: complete books are hard to find. In most cases, individual pages have been ripped out of the books by those who found the information interesting. * Since the server keeps track of what the player knows (contents of the "player book"), it is possible to only give litteracy exp for new information. * Although the players would never drop any pages from their binder (unbinding pages would be impossible), those who have the writing skill (pen) and sufficient experience could copy the information into new scrolls or books and re-sell the result. * As an added twist, the information copied from the books might not always be accurate. Depending on the player's writing experience compared to the number of pages of the book from which the data is copied, some errors could be introduced at random. In the copy, the description of an Ogre could be mixed with that of an Orc, for example. Or even worse: mixing up some spells and creating an incorrect copy that would result in a mana explosion when used. The player would not even know that she is selling or giving away some garbled information. These writing errors and their side-effects may not be easy to implement: if the server keeps track of what each player knows (maybe using a list of for each character as described in my first message) then we have to find a way to allow these errors. The server must remember what kind of erroneous information the player has. It must also allow the player who got some incorrect information to replace it by a correct version if it is found somewhere. But on the other hand, the player who wrote it should not be able to tell the difference (otherwise it would be trivial to check it by trying to read what has just been written). This is a bit tricky... -Rapha?l From lalo.martins at gmail.com Sat Aug 19 03:29:37 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 19 Aug 2006 16:29:37 +0800 Subject: [crossfire] Proposal for better in-game information: client-side "player books" References: <20060814112137.169ec054.raphael@gimp.org> Message-ID: My 4jiao on the subject: First, just thought I should mention, the best in-game help system I've ever used is FreeCiv's. It's just beautiful; everything is documented or it isn't in the game, it's very navigable, and you can reach it from all the places where it would be useful (eg, when choosing what to build in a city, you can with two clicks get the entry on any of the buildings or units you have available; same when choosing what technology to research.) I'd recommend anyone working on this feature to play a few games of FreeCiv for inspiration. Second, can we please PLEASE call this the "Encyclopedia Khelentika"? ;-) 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 alex_sch at telus.net Sat Aug 19 06:34:47 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 19 Aug 2006 05:34:47 -0600 Subject: [crossfire] Proposal for better in-game information: client-side "player books" In-Reply-To: References: <20060814112137.169ec054.raphael@gimp.org> Message-ID: <44E6F757.3050506@telus.net> Lalo Martins wrote: > My 4jiao on the subject: > > First, just thought I should mention, the best in-game help system I've > ever used is FreeCiv's. It's just beautiful; everything is documented or > it isn't in the game, it's very navigable, and you can reach it from all > the places where it would be useful (eg, when choosing what to build in a > city, you can with two clicks get the entry on any of the buildings or > units you have available; same when choosing what technology to research.) > I'd recommend anyone working on this feature to play a few games of > FreeCiv for inspiration. > I happened to be playing some freeciv last night, and I would agree, it's in-game help system is great. My only nitpicks about it are: 1) the view of what techs are required to get the one you're viewing the help for, may be very powerful, but is unintuitive 2) not enough cross referencing However, the basic design I personally think is excellent. One thought, is if we use such a system, it might be a good idea to make the file format of it pretty much the same as dokuwiki, that way the help could easily be drafted on the wiki. > Second, can we please PLEASE call this the "Encyclopedia Khelentika"? > ;-) I have no objections to that myself :P Alex Schultz From subs at eracc.com Sat Aug 19 10:59:12 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Sat, 19 Aug 2006 10:59:12 -0500 Subject: [crossfire] Clothing Message-ID: <200608191059.12752.subs@eracc.com> I propose that robes and other cloth items (not cloaks) should be a new class of item called "clothing" not "armor". A new body spot created for that and archetypes updated. Special robes that may impart armor-like characteristics could then be adjusted in the archetypes for prevention of abuse (if that appears to become a problem). Discussion? Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 10:54:52 up 13 days, 7:47, 13 users, load average: 0.60, 0.32, 0.22 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From nicolas.weeger at laposte.net Sat Aug 19 12:46:17 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 19 Aug 2006 19:46:17 +0200 Subject: [crossfire] Death attack question Message-ID: <200608191946.17896.nicolas.weeger@laposte.net> Hello. I fixed a bug preventing death attack from working correctly, but there are a few things to decide concerning that: * what should happen in the case of friendly fire? Right now, damage dealt through death attack will be reduced, so player won't be killed. Should player be killed anyway? * if death_attack is combined with AT_MAGIC, a monster can survive if the save throw is successful. Is that a good behaviour? * death attack can success only if hitter level is twice the victim level. That sounds pretty arbitrary, no? Nicolas From nicolas.weeger at laposte.net Sat Aug 19 12:48:27 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 19 Aug 2006 19:48:27 +0200 Subject: [crossfire] Clothing In-Reply-To: <200608191059.12752.subs@eracc.com> References: <200608191059.12752.subs@eracc.com> Message-ID: <200608191948.27692.nicolas.weeger@laposte.net> Le Samedi 19 Ao?t 2006 17:59, ERACC Subscriptions a ?crit?: > I propose that robes and other cloth items (not cloaks) should be a new > class of item called "clothing" not "armor". A new body spot created for > that and archetypes updated. Special robes that may impart armor-like > characteristics could then be adjusted in the archetypes for prevention of > abuse (if that appears to become a problem). > > Discussion? I'm all for it. Maybe they could give a small bonus (charisma+1 or -1? resist cold +2?, ac+1?). And if we ever add overlays, we'll be able to have that be displayed too :) Nicolas From cher at riedquat.de Sat Aug 19 15:11:12 2006 From: cher at riedquat.de (Christian Hujer) Date: Sat, 19 Aug 2006 22:11:12 +0200 Subject: [crossfire] [Daimonin-devel] Proposal: object attribute cross-reference In-Reply-To: References: Message-ID: <200608192211.30570.cher@riedquat.de> Hi dear co-devs, Am Freitag, 18. August 2006 21:48 schrieb Bj?rn Axelsson: > I got started on this despite the lacking enthusiasm from the list. :-) Don't worry, you're not the only one feeling ignored by *-devel lists :-) > The proof-of-concept prototype is available as static HTML at > http://www.acc.umu.se/~gecko/daimonin/object_ref/ Looks good. > It is basically a cross reference using data mined from the editor docs, > the lua documentation, C headers and lex grammar files. > At the moment it lacks some info for different reasons, but it works good > enough to show the principle. > > If scripters and/or coders find this useful, I will try to finish it and > also get it integrated into the editor. (Hint: feedback wanted ;-). It looks useful. > > I propose the following project: > > 1. Extend types.xml with documentation of server-internal attributes and > > mappings for server code and the lua plugin attribute names. > > - I think this is the best way to document attribute usage, since it > > already contains a good deal of the needed info. Yes. That's also good because it keeps this information in one single central place. I think this suggestion is also interesting for crossfire (that's why I crossposted to crossfire). > > 2. Create a cross reference where one can search the information in > > types.xml. > > - Currently the info in types.xml can only be accessed through the online > > help in the editor attribute editing window. > > - This should be accessible from the map editor's embedded script editor, > > but maybe also in some external way (for people who doesn't use the > > embedded editor, or server developers who don't want the editor open). > > - I see several ways of searching the info, for example I might want to > > know which lua attributes are relevant to waypoint obejcts, or I might > > want to find out which attribute the "waypoint active" flag corresponds > > to. As a server developer I want to see which attributes are used by a > > specific object type, and which are free to use for new purposes. Yep. > > I can whip up a prototype in perl and run it as a web service (like I do > > with the core reference), but then someone would have to reimplement it > > in Java for integration in the editor. My Java is simply to rusty to do > > this efficiently myself. Any ideas or reflections from the > > Gridarta team? I think a prototype in Perl is a good idea. Most if not all Gridarta developers know Perl, either good enough to at least understand a prototype, or good enough to write a word histogram (which word occurs which often) with sorted output in two statements. (My sole recent usage of Perl is looking for the holy grail to solve this problem in a single statement ;-) Also, there are some Perl-evangelists active on the Crossfire side, so if you prototype it in Perl there's a good chance that Gridarta won't be the only editor implementing it. (On the other side, they might also lynch you if you're not using their Perl style, but that's your problem not mine ;-) > > While I'm at it, the embedded script editor needs a few updates: > > - syntax highlighting for lua (should be only a little work). Ummm... strange, should already be there. Strange, very strange. I'll have a look at that. > > - integration with the lua core reference for function popups and > > built-in documentation (I can supply a XML document with the lua function > > documentation used for the core documentation if needed, just propose a > > format to use). Currently I don't prefer a particular format, just send it to the gridarta developer list if it's below 50k or to me if it's bigger than that. Of course I prefer valid XML over invalid XML, so if you could supply a DTD or Schema (I prefer W3C Schema over Relax NG, but Relax NG would also do) along with it? Cu :-) -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- 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/20060819/f1842922/attachment.pgp From alex_sch at telus.net Sat Aug 19 17:07:56 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 19 Aug 2006 16:07:56 -0600 Subject: [crossfire] [Daimonin-devel] Proposal: object attribute cross-reference In-Reply-To: <200608192211.30570.cher@riedquat.de> References: <200608192211.30570.cher@riedquat.de> Message-ID: <44E78BBC.20305@telus.net> Christian Hujer wrote: > Also, there are some Perl-evangelists active on the Crossfire side, so if you > prototype it in Perl there's a good chance that Gridarta won't be the only > editor implementing it. > (On the other side, they might also lynch you if you're not using their Perl > style, but that's your problem not mine ;-) Well, one note, most of the Perl-evangelists seem to be over in this one other fork of crossfire (it's staying pretty close to crossfire in most ways, though they've went and replaced the the python plugin (which as an off topic note has been improving alot lately) with perl, and are writing their own editor and client in perl), and in the main of crossfire, we have more Python-evangelists than Perl-evangelists from what I've seen :P That said, the Python-evangelists (myself included :)) here are friendly enough to perl that they won't object to things of this nature being written in perl. So there's my irrelevant blabber where I end up saying it doesn't matter anyways ;-) Alex Schultz From nicolas.weeger at laposte.net Sat Aug 19 17:11:13 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 20 Aug 2006 00:11:13 +0200 Subject: [crossfire] About a feature request Message-ID: <200608200011.13378.nicolas.weeger@laposte.net> Hello. I'm looking at https://sourceforge.net/tracker/index.php?func=detail&aid=656191&group_id=13833&atid=363833 historical feature request to have blessed/cursed scrolls and books. Here's what I see as effects (copied from the page) * cursed scroll: ill effect, depending on spell - identify would make player forget about an identified item, and such. Would require some work to define ill effects for all spells, though. Option "fast" is to cast some mana explosion, of course. Or leech player's mana? Could be fun :) * blessed scroll: add 2 levels to casting. Other option: more exp when used? * cursed spellbook: forget a spell * blessed spellbook: bonus to learn a spell Of course, blessed/cursed should be rare occurrances. Codewise, cursed we got a flag. For blessed, I don't know the best way to signal that. I'm not too eager to add a flag just for that, on the other hand using an existing flag for something else that its destination is weird. Or maybe insert a special object in inventory? (and thus use treasure list to add the blessed stuff) What do you think? Nicolas From alex_sch at telus.net Sat Aug 19 18:48:19 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 19 Aug 2006 17:48:19 -0600 Subject: [crossfire] Death attack question In-Reply-To: <200608191946.17896.nicolas.weeger@laposte.net> References: <200608191946.17896.nicolas.weeger@laposte.net> Message-ID: <44E7A343.8010101@telus.net> Nicolas Weeger (Laposte) wrote: > I fixed a bug preventing death attack from working correctly, but there are a > few things to decide concerning that: > > * what should happen in the case of friendly fire? Right now, damage dealt > through death attack will be reduced, so player won't be killed. Should > player be killed anyway? > I'm not really sure about that issue, on one hand it might seem harsh to accidentally pk so easily with that, on the other hand there are pk allowed servers where it may seem silly to have the death attacktype not do what it says on players. > * if death_attack is combined with AT_MAGIC, a monster can survive if the save > throw is successful. Is that a good behaviour? > It depends, when the saving throw is successful, does it take any damage, or just not do anything? If not do anything, that is desirable IMHO considering AT_MAGIC is supposed to be only on spells and similar, and the saving throw is supposed to affect all spells. If it's currently causing partial damage with that, then I would say it's bad behavior. > * death attack can success only if hitter level is twice the victim level. > That sounds pretty arbitrary, no? It does seem pretty arbitrary, but IMHO some limit is needed and that seems like as reasonable a place as any. Alex Schultz From alex_sch at telus.net Sun Aug 20 00:03:00 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 19 Aug 2006 23:03:00 -0600 Subject: [crossfire] Invisibility and monsters Message-ID: <44E7ED04.60201@telus.net> Bug report #1542895 on the sf.net tracker (http://sourceforge.net/tracker/index.php?func=detail&aid=1542895&group_id=13833&atid=113833) notes that: "All monsters seem to be able to "see" an invisible player: even ogres see a player wearing a God Finger." I'm pretty sure that's because that character didn't have stealth, and hence is intended to allow the ogre to see the character. Despite it being 'intended behavior', I'm not sure the way stealth is necessarily the 'right behavior'. How stealth works is something that I find few players understand, because there are few visual or text cues about it. Personally I'm thinking stealth should be made much more obvious to the player. Here are some ideas I had of possible ways to do that: - Give stealth some use when one isn't invisible/hiding - Make a visual cue (i.e. animation of detect invisible for a moment) when an invisible/hiding player without stealth moves - Make stealth more available - Document stealth better in-game. Alex Schultz From nicolas.weeger at laposte.net Sun Aug 20 04:35:55 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 20 Aug 2006 11:35:55 +0200 Subject: [crossfire] Old event system cleaning Message-ID: <200608201135.55365.nicolas.weeger@laposte.net> Hello. Unless someone objects really much, I'd like to trash the old plugin/event system. It is based on the "event_trigger" and such lines in the archetype definition, and includes a few functions/fields (object->event for instance). With the archetype-based event system, it is obsolete. Currently, only artifacts of occidental mages (ring and weapon) still use it. Not even sure that works :) We'll need a way to add inventory through the artifacts, actually. I checked the maps, and none uses that system anywhere. Nicolas From nicolas.weeger at laposte.net Sun Aug 20 06:00:34 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 20 Aug 2006 13:00:34 +0200 Subject: [crossfire] Where would you put... Message-ID: <200608201300.34565.nicolas.weeger@laposte.net> Hello. After some fun chat on the irc channel, I'm creating a talking fireplace which'll tell stories to players. Small Python scripts, that'll be all :) Now the question is, where should we put the stories? IMO, a good place is in the share directory, maybe in a 'stories' subdirectory. A story could be quite long, so using the msg field isn't the best way imo. Nicolas From nicolas.weeger at laposte.net Sun Aug 20 07:52:20 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 20 Aug 2006 14:52:20 +0200 Subject: [crossfire] Where would you put... In-Reply-To: <200608201300.34565.nicolas.weeger@laposte.net> References: <200608201300.34565.nicolas.weeger@laposte.net> Message-ID: <200608201452.20643.nicolas.weeger@laposte.net> I've made a first version of that talking fireplace. Anyone minds if I commit it? It's an extra feature, though, but I'd find that fun to have :) It's basically: * 3 new archetypes (object + 2 events) * 1 new treasure list (to have the events in the object) * 4 Python scripts (3 to react to events, one "main" class doing all the work) and probably a storage directory for stories :) Nicolas From alex_sch at telus.net Sun Aug 20 12:09:18 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 20 Aug 2006 11:09:18 -0600 Subject: [crossfire] Old event system cleaning In-Reply-To: <200608201135.55365.nicolas.weeger@laposte.net> References: <200608201135.55365.nicolas.weeger@laposte.net> Message-ID: <44E8973E.50306@telus.net> Nicolas Weeger (Laposte) wrote: > We'll need a way to add inventory through the artifacts, actually. > Well, I think we've been needing to add inventory though the artifacts support for a long while now. *goes to add that to the feature requests list on the tracker* Alex Schultz From kbulgrien at att.net Sun Aug 20 14:05:55 2006 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Sun, 20 Aug 2006 14:05:55 -0500 Subject: [crossfire] Spell path balance - Summoning Message-ID: First, I recall that there has been some discussion about playing crossfire that suggests that specialization of skills is necessary to get extremely advanced characters, and that crossing disciplines will tend to limit how far a character can go, or how easy it is to level up. Second, in spite of the above, I have been playing a character that has tended toward trying to raise several disciplines in a somewhat consistant manner. This approach was taken so as to be able to more easily experience different aspects of Crossfire so as to be able to enjoy taking a go at playing different games, but all the while using a single character instead of multiple characters. All that being said, a few years ago there was a concentrated effort to enhance the concept of creating balanced spell paths. What I am interested in is whether or not there are players out there that concentrate in the summoning path. The reason is two-fold. One is that I wonder if I do not know "how" to play a summoner, and the other is whether summoning is completely out-of-balance. It seems like it is extremely difficult to level a summoner. What sort of game playing style is needed to make a summoner level the same way that the other path players can. If killing monsters with summoned creatures is the primary way of getting experience, then the path is completely unbalanced as it takes eons of mind-bendingly boring snooze, summon, attack, snooze until summoned character is dead cycles. Am I just missing the point of this path, or is it really not very well balanced? From lalo.martins at gmail.com Sun Aug 20 17:47:24 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 21 Aug 2006 06:47:24 +0800 Subject: [crossfire] Spell path balance - Summoning References: Message-ID: On Sun, 20 Aug 2006 14:05:55 -0500, Kevin R. Bulgrien wrote: > completely unbalanced as it takes eons of mind-bendingly boring > snooze, summon, attack, snooze until summoned character is dead > cycles. Am I just missing the point of this path, or is it really > not very well balanced? Generally, I think summoning needs high-level spells that summon strong critters, rather than just relying on pets becoming stronger and stronger with level. 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 Aug 20 18:12:28 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun, 20 Aug 2006 19:12:28 -0400 Subject: [crossfire] Where would you put... In-Reply-To: <200608201300.34565.nicolas.weeger@laposte.net> References: <200608201300.34565.nicolas.weeger@laposte.net> Message-ID: On 8/20/06, Nicolas Weeger (Laposte) wrote: > Hello. > > After some fun chat on the irc channel, I'm creating a talking fireplace > which'll tell stories to players. > > Small Python scripts, that'll be all :) > > Now the question is, where should we put the stories? > > IMO, a good place is in the share directory, maybe in a 'stories' > subdirectory. > > A story could be quite long, so using the msg field isn't the best way imo. Im thinking "maps-bigworld/python/talkingfireplace" and a "data" or "stories" directory inside that for the stories, unless someone objects. Latter it may be a good idea to tie the fireplace into lore/story colleciton scripts. -- Andrew Fuchs From mwedel at sonic.net Sun Aug 20 22:23:12 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 20 Aug 2006 20:23:12 -0700 Subject: [crossfire] Invisibility and monsters In-Reply-To: <44E7ED04.60201@telus.net> References: <44E7ED04.60201@telus.net> Message-ID: <44E92720.60506@sonic.net> Alex Schultz wrote: > Bug report #1542895 on the sf.net tracker > (http://sourceforge.net/tracker/index.php?func=detail&aid=1542895&group_id=13833&atid=113833) > notes that: > "All monsters seem to be able to "see" an invisible player: even ogres > see a player wearing a God Finger." > I'm pretty sure that's because that character didn't have stealth, and > hence is intended to allow the ogre to see the character. Despite it > being 'intended behavior', I'm not sure the way stealth is necessarily > the 'right behavior'. How stealth works is something that I find few > players understand, because there are few visual or text cues about it. > Personally I'm thinking stealth should be made much more obvious to the > player. Here are some ideas I had of possible ways to do that: > - Give stealth some use when one isn't invisible/hiding > - Make a visual cue (i.e. animation of detect invisible for a moment) > when an invisible/hiding player without stealth moves > - Make stealth more available > - Document stealth better in-game. Looking at the code, it seems to do all sorts of odd things. the function in question appears to be can_detect_enemy() in server/monster.c The function itself seems relatively confusing, as it the ncalls things like can_see_enemy(), which in turn calls makes_invisible_to(), to see if the monster can detect the creature (those functions are in themselves not confusing, but then you get can_detect_enemy() that seems to do some of that work again). But gong after all of that, if the player is not hidden, then monsters can detect them if within MIN_MON_RADIUS (which is 3) or the monsters wis/5, whichever is higher. If the character has stealth, that detection radius is reduced. I'm not sure, but I have a feeling here that the real issue is the MIN_MON_RADIUS, which means if you are not stealthy/hidden, if you are within 3 spaces of a monster, they can always detect you. From mwedel at sonic.net Sun Aug 20 22:30:31 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 20 Aug 2006 20:30:31 -0700 Subject: [crossfire] Where would you put... In-Reply-To: <200608201300.34565.nicolas.weeger@laposte.net> References: <200608201300.34565.nicolas.weeger@laposte.net> Message-ID: <44E928D7.1000607@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > After some fun chat on the irc channel, I'm creating a talking fireplace > which'll tell stories to players. > > Small Python scripts, that'll be all :) > > Now the question is, where should we put the stories? > > IMO, a good place is in the share directory, maybe in a 'stories' > subdirectory. > > A story could be quite long, so using the msg field isn't the best way imo. Are the stories going to be 'general' stories, meaning other objects (whatever) on other maps may use them? If so, then a stories directory may be appropriate (OTOH, we already have a messages file - wonder if it would be better to extend that logic to cover types of messages/where they show up). If these stories will be unique to the object, then they should be associated with that object/script, and not clutter up the lib directory (presumably that is where the stories will be stored in CVS at least). From mwedel at sonic.net Sun Aug 20 22:33:36 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 20 Aug 2006 20:33:36 -0700 Subject: [crossfire] Spell path balance - Summoning In-Reply-To: References: Message-ID: <44E92990.4020107@sonic.net> Lalo Martins wrote: > On Sun, 20 Aug 2006 14:05:55 -0500, Kevin R. Bulgrien wrote: >> completely unbalanced as it takes eons of mind-bendingly boring >> snooze, summon, attack, snooze until summoned character is dead >> cycles. Am I just missing the point of this path, or is it really >> not very well balanced? > > Generally, I think summoning needs high-level spells that summon > strong critters, rather than just relying on pets becoming stronger and > stronger with level. the question then is how you get high level creatures. One thing that may help summoners is to just speed up the movement speed of summoned creatures. One reason why I think it takes eons is most monsters move very slow (at least compared to players), so it takes a monster quite a while to move to position and bash a creature. If summoned monsters had a speed of 1.0, with no other changes, at least they would move, attack, and kill quickly. They may die quickly themselves, but at least you could then summon another one and move on. From mwedel at sonic.net Sun Aug 20 22:42:13 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 20 Aug 2006 20:42:13 -0700 Subject: [crossfire] About a feature request In-Reply-To: <200608200011.13378.nicolas.weeger@laposte.net> References: <200608200011.13378.nicolas.weeger@laposte.net> Message-ID: <44E92B95.9080008@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > I'm looking at > https://sourceforge.net/tracker/index.php?func=detail&aid=656191&group_id=13833&atid=363833 > historical feature request to have blessed/cursed scrolls and books. > > Here's what I see as effects (copied from the page) > > * cursed scroll: ill effect, depending on spell - identify would make player > forget about an identified item, and such. Would require some work to define > ill effects for all spells, though. Option "fast" is to cast some mana > explosion, of course. Or leech player's mana? Could be fun :) It may be easiest to to do something like 'look for special spell effect, otherwise use random results table'. Or even if there is special spell effect, maybe only use it 50% of the time so player can not rely on what may happen with cursed scrolls. For some spells, like bullets, bolts, cones, could have the direction not be what the player wants (random direction, invoked on player, etc). > * blessed scroll: add 2 levels to casting. Other option: more exp when used? IIRC, casting scrolls isn't a 100% sure thing is it? If not, may increase casting odds? Scrolls already come in different levels, so adding a couple levels may not be that much of a benefit. Getting more exp when used would I think be a more complicated change (there isn't any way to record that right now - since the scroll may be long gone by the time the spell kills the monster, you'd need to record this exp bonus in the spell effect - right now, it records caster and skill used. > > * cursed spellbook: forget a spell (ideally, spell you are trying to learn - if you don't know that spell, something random) > * blessed spellbook: bonus to learn a spell > > Of course, blessed/cursed should be rare occurrances. > > > Codewise, cursed we got a flag. > For blessed, I don't know the best way to signal that. I'm not too eager to > add a flag just for that, on the other hand using an existing flag for > something else that its destination is weird. Flags are cheap - easy to do, use one bit. I think if we add blessed objects, it could be extended to more than just scrolls/spellbooks (potions maybe? Note sure about other equipment as harder to say effect). That said, while I didn't submit that RFE, my thought was that since there are other cursed objects, it would make sense for scrolls & spellbooks to also be cursed. For spellbooks at least, you can know longer try to read it as a safe identification method. I think focusing on the cursed aspect would be fine - if we want to added blessed items, as said, it should probably extend to a lot more than just these objects. From mwedel at sonic.net Sun Aug 20 22:54:50 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 20 Aug 2006 20:54:50 -0700 Subject: [crossfire] Death attack question In-Reply-To: <44E7A343.8010101@telus.net> References: <200608191946.17896.nicolas.weeger@laposte.net> <44E7A343.8010101@telus.net> Message-ID: <44E92E8A.6010100@sonic.net> Alex Schultz wrote: > Nicolas Weeger (Laposte) wrote: >> I fixed a bug preventing death attack from working correctly, but there are a >> few things to decide concerning that: >> >> * what should happen in the case of friendly fire? Right now, damage dealt >> through death attack will be reduced, so player won't be killed. Should >> player be killed anyway? >> > I'm not really sure about that issue, on one hand it might seem harsh to > accidentally pk so easily with that, on the other hand there are pk > allowed servers where it may seem silly to have the death attacktype not > do what it says on players. Maybe could change effect, based on if the players are in a party together or not? >> * if death_attack is combined with AT_MAGIC, a monster can survive if the save >> throw is successful. Is that a good behaviour? >> > It depends, when the saving throw is successful, does it take any > damage, or just not do anything? If not do anything, that is desirable > IMHO considering AT_MAGIC is supposed to be only on spells and similar, > and the saving throw is supposed to affect all spells. If it's currently > causing partial damage with that, then I would say it's bad behavior. It is intended design that if an attacktype also has AT_MAGIC, then the creature gets any benefit from protections it has to magic, etc. The basic idea is that if a creature is immune to magic, you shouldn't be able to kill it with a death attack spell - otherwise, what does being immune to magic really mean? I think the problem here is that in the current system, if an attack has some damage value, there is no way to know what that damage is for. So I guess what is happening here is something like a spell having AT_MAGIC | AT_DEATH and damage 40. Creature makes its death saving throw, no damage from that (it either damages you or doesn't). But now there is a magic attack with 40 damage - what should happen with that? I'd probably say that it should be ignored - the magic in this case isn't suppose to do damage, it is just noting that this is a magic effect. However, if you had a spell like deathfire (AT_FIRE | AT_DEATH), then if the death attack doesn't kill them, the creature should still take damage from the fire. This would get all fixed up in the proposal of discrete damage types, as then there would be no question what the damage is from/for, but where not there at this time. >> * death attack can success only if hitter level is twice the victim level. >> That sounds pretty arbitrary, no? > It does seem pretty arbitrary, but IMHO some limit is needed and that > seems like as reasonable a place as any. IIRC, that limit was put in so that low level players couldn't kill high level creatures with a death attack and get lots of exp. So yes, some limit is needed, and twice is as good as any. One thought might be to adjust that based on current damage to creature. Eg, a creature normally has 1000 maxhp. It is currently at 400 hp from other damage. Thus, its effectively level to resist a death attack is only 40% of its normal level. This borrows from other games, but the idea being if a creature is already beat up and near to death, a death attack should have an easier time killing it. From mwedel at sonic.net Sun Aug 20 23:01:23 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 20 Aug 2006 21:01:23 -0700 Subject: [crossfire] Clothing In-Reply-To: <200608191059.12752.subs@eracc.com> References: <200608191059.12752.subs@eracc.com> Message-ID: <44E93013.5060708@sonic.net> ERACC Subscriptions wrote: > I propose that robes and other cloth items (not cloaks) should be a new class > of item called "clothing" not "armor". A new body spot created for that and > archetypes updated. Special robes that may impart armor-like characteristics > could then be adjusted in the archetypes for prevention of abuse (if that > appears to become a problem). technically, this is pretty easy to do. But balance wise, this is more an issue. Whenever new body positions are added, it basically means the player becomes more powerful. Ignoring artifacts or other special quest items, just from a basic low level character point of view - in addition to what I was able to wear before, I'm able to add a robe on top of that. So if I can find a robe +2 in the shop, I now have 2 AC points I didn't have before. If I'm a fighter, that extra weight isn't likely to be an issue. Given that CF uses d20 for attack rolls, that amounts to a 10% advantage. But there is then the issue of artifact robes (midnight robe to be one). If I can wear that with other armor, that is pretty darn nice. If it gets tuned down so that it wouldn't be an issue to wear with other armor, well then, it probably becomes a pretty worthless reward/quest item. so I'd like to see some more reasoning on why this is really needed and how it will be used. From mwedel at sonic.net Sun Aug 20 23:21:04 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 20 Aug 2006 21:21:04 -0700 Subject: [crossfire] Proposal for better in-game information: client-side "player books" In-Reply-To: <20060818153924.5d3da81b.raphael@gimp.org> References: <20060814112137.169ec054.raphael@gimp.org> <44E159E2.9020609@sonic.net> <20060817164750.388aa824.raphael@gimp.org> <44E5712A.6030104@sonic.net> <20060818153924.5d3da81b.raphael@gimp.org> Message-ID: <44E934B0.9090802@sonic.net> Rapha?l Quinet wrote: > * A player who has collected a lot of information could get additional > "player books" (binders) to organize this information. Another idea > would be that each player starts with predefined binders, one for > each type of information: one for monsters, one for religions, one > for alchemy (or each sub-type: smithery, woodsman, ...) and so on. What is the actual effect of the books in this case? My personal thought is that we are trying to make the information presentable/easy to find for the player, as well as provide a record for it so they don't have to do it themselves. Because of that, the information should always be presented in the easiest way we can reasonably to do - I shouldn't have to need to pick up a new book to record information on that subject or be able to see it organized in a handy fashion. Otherwise, players will either not get that information well organized, or just keep recording it outside the game/client interface, which is annoying. (also, given that the client will present this information to the player, to only way you could make this information less useful is if the server doesn't provide all the needed info so that the client can't organize it, otherwise, players will just modify the client to do the right thing anyways) > * Although the players would never drop any pages from their binder > (unbinding pages would be impossible), those who have the writing > skill (pen) and sufficient experience could copy the information > into new scrolls or books and re-sell the result. I'd think in this case, re-sell would be to other players, and not necessarily shops - having shops try to figure value of such information could be hard. > > * As an added twist, the information copied from the books might not > always be accurate. Depending on the player's writing experience > compared to the number of pages of the book from which the data is > copied, some errors could be introduced at random. In the copy, the > description of an Ogre could be mixed with that of an Orc, for > example. Or even worse: mixing up some spells and creating an > incorrect copy that would result in a mana explosion when used. The > player would not even know that she is selling or giving away some > garbled information. The easiest thing for written information (I think) is to take bits of pieces from different entries. For example, for monsters, you'd probably have something like: attacks (what it attacks with - spells, etc) defenses (protections, other immunities) difficulty (hp/ac/level) other notes So you go and transcribe information about ogres for a friendly player, because he is having a hard time fighting them. So the server does your inscription check, and you fail, but not by a lot. So one of those 4 pieces of information is incorrect. Lets say defenses in this case. Rather than having the server try to figure out how to modify it (change resistance to vulnerability, which ones, etc), it just grabs one at random from another monster. Maybe devil instead. Easiest would be to take a random one from the character book - if he doesn't have anything, then maybe something from all creatures. > These writing errors and their side-effects may not be easy to > implement: if the server keeps track of what each player knows (maybe > using a list of for each character as described in my > first message) then we have to find a way to allow these errors. The > server must remember what kind of erroneous information the player > has. It must also allow the player who got some incorrect information > to replace it by a correct version if it is found somewhere. But on > the other hand, the player who wrote it should not be able to tell the > difference (otherwise it would be trivial to check it by trying to > read what has just been written). This is a bit tricky... True - OTOH, it may not be unreasonable for the inscribing player to read what he wrote and see if it is incorrect. In a sense, this isn't really much different than proofreading something you write now. If inscribing actually takes some real time (lets say 10 real seconds), a player may decide he doesn't want to keep writing to get a perfect copy. And of course, you need blank paper, etc (another question is what does he do with these incorrect copies? Maybe the shop will buy them for a few silver, so a player seeing them in the shop doesn't have any idea that they are wrong. Maybe things like inkwells should be added, to add some real cost beyond just the paper and time to inscribe. In terms of correct errors, that is more difficult. In theory, the character won't really know what information is correct and what is wrong. On possibility is to allow both pieces of information to be recorded, and put up a note to the player saying 'conflicting information found, do you want to add it' or something. Then have some ability for information to be removed by the player, so after finding enough notes (or talking with other players) may be able to figure out what is the correct info and what isn't. I think it was discussed that the player should be able to add their own notes, so this logic is just a minor extention. From raphael at gimp.org Mon Aug 21 03:29:52 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Mon, 21 Aug 2006 10:29:52 +0200 Subject: [crossfire] About a feature request In-Reply-To: <200608200011.13378.nicolas.weeger@laposte.net> References: <200608200011.13378.nicolas.weeger@laposte.net> Message-ID: <20060821102952.7117f685.raphael@gimp.org> On Sun, 20 Aug 2006 00:11:13 +0200, "Nicolas Weeger (Laposte)" wrote: > * cursed scroll: ill effect, depending on spell - identify would make player > forget about an identified item, and such. Would require some work to define > ill effects for all spells, though. Option "fast" is to cast some mana > explosion, of course. Or leech player's mana? Could be fun :) > * blessed scroll: add 2 levels to casting. Other option: more exp when used? > > * cursed spellbook: forget a spell > * blessed spellbook: bonus to learn a spell To be frank, I do not like this idea very much, especially for spellbooks. I do not think that cursed or blessed spellbooks would have any impact on medium and high-level characters (or experienced players, even if they play a low-level character) because they will probably not use an item without identifying it first. The only players that would be significantly affected by such a change are the low-level characters or the players who are just starting to learn how the game works. And they would probably be affected negatively more than positively. For those players, finding a spellbook is like finding a major treasure because they probably do not know many spells yet. If their stats (Int/Wiz) are not very high, they already have a disadvantage because there is a high risk that they fail to learn the spell. A cursed spellbook would not only be a piece of treasure that becomes worthless, but it would be even worse: they would lose one of their hard-earned spells. Having blessed spellbooks would probably not compensate the negative effect that cursed ones could have. I think that crossfire is already too hard and too complex for many new players. Adding cursed spellbooks would not really improve that aspect of the game. Adding cursed scrolls may be a bit more reasonable if the ill effects are not too severe, but I would prefer to avoid them as well. -Rapha?l From raphael at gimp.org Mon Aug 21 04:54:45 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Mon, 21 Aug 2006 11:54:45 +0200 Subject: [crossfire] Spell path balance - Summoning In-Reply-To: References: Message-ID: <20060821115445.1ce88555.raphael@gimp.org> On Sun, 20 Aug 2006 14:05:55 -0500, "Kevin R. Bulgrien" wrote: > One is that I wonder if I do not know "how" to play a summoner, Probably not. :-) > and the other is whether summoning is completely out-of-balance. Yes, but probably not in the way you think. > It seems > like it is extremely difficult to level a summoner. What sort of > game playing style is needed to make a summoner level the same way > that the other path players can. If killing monsters with summoned > creatures is the primary way of getting experience, then the path is > completely unbalanced as it takes eons of mind-bendingly boring > snooze, summon, attack, snooze until summoned character is dead > cycles. Am I just missing the point of this path, or is it really > not very well balanced? It is not well balanced. Gaining the first few levels is difficult but after that, gaining levels in summoning is far too easy. In fact, I usually try to create balanced characters and level up several skills at the same time instead of focusing on a single one. And I find it difficult to _avoid_ gaining exp in the summoning skill. If you want to know how to use the summoning skill, here is a little *SPOILER*: - Gaining the first 2-3 levels in summoning is rather boring because you have to rely on your golem or lesser golem. Gaining exp with these takes time. In (very) old versions of the game, summoning pet monsters was also useful because you could summon some monsters that were able to kill other monsters faster than you, but this is not the case anymore so you will have to rely on golems and be patient. Make sure that you use your golems in narrow corridors so that they only fight one monster at a time. - Once you reach levels 4, 5 and above, you can start summoning elementals. Here again, the cost in mana compared the speed at which you gain experience is not really good but you have to be patient and keep on killing lots of low-level monsters with your elementals until you can gain more levels. - After a while, you will have learned the spell "charm monsters". This is what changes the game completely: at first you will only be able to charm a few low-level monsters so you will not much exp with that. You may have to continue practicing killing monsters with a fire elemental. But after reaching level 10 or more, you will be able to charm more and more monsters and gain a lot of exp. - Gaining exp by charming monsters is so convenient that I have bound a key to "invoke charm monsters; killpets". I have also done the same for "invoke command undead; killpets" for the praying skill. You will probably find that it takes you as much time to go from level 15 to level 107 in the summoning skill than it took you to go from level 1 to level 15. This shows that the skill is not well balanced: it is too hard at the low levels (the mana cost vs. exp gain per time unit is too high) but it is too easy at the high levels (the the exp gain is several orders of magniture faster for roughly the same mana cost). When you reach level 100+ in that skill, you can kill a dozen dragons or big wizards instantly by casting "charm monsters" once and spending less than 100 mana points. Something needs to be done to re-balance this skill (and also some other skills). However, some of the solutions that have been proposed so far would only make "charm monsters" useless or dangerous to use, which would not solve the other part of the problem: this skill is too difficult to use at low levels. -Rapha?l From lalo.martins at gmail.com Mon Aug 21 07:25:50 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 21 Aug 2006 20:25:50 +0800 Subject: [crossfire] Clothing References: <200608191059.12752.subs@eracc.com> <44E93013.5060708@sonic.net> Message-ID: On Sun, 20 Aug 2006 21:01:23 -0700, Mark Wedel wrote: > ERACC Subscriptions wrote: >> I propose that robes and other cloth items (not cloaks) should be a new class >> of item called "clothing" not "armor". A new body spot created for that and >> archetypes updated. Special robes that may impart armor-like characteristics >> could then be adjusted in the archetypes for prevention of abuse (if that >> appears to become a problem). > > technically, this is pretty easy to do. > > But balance wise, this is more an issue. Whenever new body positions are > added, it basically means the player becomes more powerful. I think the solution to the problem eracc described on irc is not new body spots, but just a new type. I don't think you can wear gloves and gauntlets at the same time, or a robe over a breastplate. (You can wear a breastplate over a shirt, and usually you'll want to, but for game purposes, let's say that's, er, a different kind of shirt.) Then flags like can_use_armor only need to check the type -- which I believe is the way it is already. yes-lets-stop-the-disgusting-naked-Rugillites-ly yours, 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 alex_sch at telus.net Mon Aug 21 12:09:25 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 21 Aug 2006 11:09:25 -0600 Subject: [crossfire] Spell path balance - Summoning In-Reply-To: <20060821115445.1ce88555.raphael@gimp.org> References: <20060821115445.1ce88555.raphael@gimp.org> Message-ID: <44E9E8C5.4050509@telus.net> Rapha?l Quinet wrote: > Something needs to be done to re-balance this skill (and also some > other skills). However, some of the solutions that have been proposed > so far would only make "charm monsters" useless or dangerous to use, > which would not solve the other part of the problem: this skill is too > difficult to use at low levels. Well, note though, that past level 20 or so, summoning is *completely* useless *except* for charm monster. Summoned monsters are far too weak to have any use at level 30 and up, and sure there's animate weapon, however the only things strong enough to be worth animating are not worth the risk of loosing. Personally I think there are four things that could be done to balance summoning properly: - Make charmkilling not so powerful without completely making it useless. (personally I think requiring line of sight and limited range might be a good method, possibly in addition to making 'killpets' not always work) - Add more powerful types of summoned creatures at higher levels (Possibly just more things for 'summon creature' or possibly (a) new spell(s) like 'summon greater creature') - Make the first few levels more practical to use it with, possibly by making the summoned creatures faster or more powerful. - Not as needed to balance as the other notes, but somehow reducing the risk of loss of a weapon used with animate weapon. Alex Schultz From nicolas.weeger at laposte.net Mon Aug 21 16:05:13 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 21 Aug 2006 23:05:13 +0200 Subject: [crossfire] Where would you put... In-Reply-To: <44E928D7.1000607@sonic.net> References: <200608201300.34565.nicolas.weeger@laposte.net> <44E928D7.1000607@sonic.net> Message-ID: <200608212305.14001.nicolas.weeger@laposte.net> > Are the stories going to be 'general' stories, meaning other objects > (whatever) on other maps may use them? If so, then a stories directory may > be appropriate (OTOH, we already have a messages file - wonder if it would > be better to extend that logic to cover types of messages/where they show > up). Well, I like the idea of having general stories. I guess it could be extended to have one specific story for one specific fireplace, of course, but I've designed for randomly choosing a story each time. Nicolas From fuchs.andy at gmail.com Mon Aug 21 18:30:21 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon, 21 Aug 2006 19:30:21 -0400 Subject: [crossfire] About a feature request In-Reply-To: <20060821102952.7117f685.raphael@gimp.org> References: <200608200011.13378.nicolas.weeger@laposte.net> <20060821102952.7117f685.raphael@gimp.org> Message-ID: On 8/21/06, Rapha?l Quinet wrote: ... > To be frank, I do not like this idea very much, especially for spellbooks. ... > The only players that would be significantly affected by such a change are > the low-level characters or the players who are just starting to learn how > the game works. And they would probably be affected negatively more than > positively. For those players, finding a spellbook is like finding a major > treasure because they probably do not know many spells yet. If their stats > (Int/Wiz) are not very high, they already have a disadvantage because there > is a high risk that they fail to learn the spell. A cursed spellbook would > not only be a piece of treasure that becomes worthless, but it would be > even worse: they would lose one of their hard-earned spells. Having > blessed spellbooks would probably not compensate the negative effect that > cursed ones could have. Agreed. For a beginning player, loosing a spell can be a major set back. The best alternative I can think of would be a small experience penalty. The role-playing explanation of this would be that the misinformation from the book has been learned by the player. > I think that crossfire is already too hard and too complex for many new > players. Adding cursed spellbooks would not really improve that aspect of > the game. Adding cursed scrolls may be a bit more reasonable if the ill > effects are not too severe, but I would prefer to avoid them as well. Also agreed. -- Andrew Fuchs From fuchs.andy at gmail.com Mon Aug 21 18:36:59 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon, 21 Aug 2006 19:36:59 -0400 Subject: [crossfire] Clothing In-Reply-To: References: <200608191059.12752.subs@eracc.com> <44E93013.5060708@sonic.net> Message-ID: On 8/21/06, Lalo Martins wrote: > On Sun, 20 Aug 2006 21:01:23 -0700, Mark Wedel wrote: > > ERACC Subscriptions wrote: > >> I propose that robes and other cloth items (not cloaks) should be a new class > >> of item called "clothing" not "armor". A new body spot created for that and > >> archetypes updated. Special robes that may impart armor-like characteristics > >> could then be adjusted in the archetypes for prevention of abuse (if that > >> appears to become a problem). Having more general clothing in the game, would add more depth for role playing (formal whatevers). If it's armor, set it's type to armor. > > technically, this is pretty easy to do. > > > > But balance wise, this is more an issue. Whenever new body positions are > > added, it basically means the player becomes more powerful. > > I think the solution to the problem eracc described on irc is not new body > spots, but just a new type. I don't think you can wear gloves and > gauntlets at the same time, or a robe over a breastplate. (You can wear a > breastplate over a shirt, and usually you'll want to, but for game > purposes, let's say that's, er, a different kind of shirt.) Yes. > Then flags like can_use_armor only need to check the type -- which I > believe is the way it is already. > > yes-lets-stop-the-disgusting-naked-Rugillites-ly yours, THANK YOU. -- Andrew Fuchs From fuchs.andy at gmail.com Mon Aug 21 18:55:44 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon, 21 Aug 2006 19:55:44 -0400 Subject: [crossfire] Spell path balance - Summoning In-Reply-To: <44E9E8C5.4050509@telus.net> References: <20060821115445.1ce88555.raphael@gimp.org> <44E9E8C5.4050509@telus.net> Message-ID: On 8/21/06, Alex Schultz wrote: > Rapha?l Quinet wrote: > > Something needs to be done to re-balance this skill (and also some > > other skills). However, some of the solutions that have been proposed > > so far would only make "charm monsters" useless or dangerous to use, > > which would not solve the other part of the problem: this skill is too > > difficult to use at low levels. > Well, note though, that past level 20 or so, summoning is *completely* > useless *except* for charm monster. Summoned monsters are far too weak > to have any use at level 30 and up, and sure there's animate weapon, > however the only things strong enough to be worth animating are not > worth the risk of loosing. Personally I think there are four things that > could be done to balance summoning properly: > - Make charmkilling not so powerful without completely making it > useless. (personally I think requiring line of sight and limited range > might be a good method, possibly in addition to making 'killpets' not > always work) Agreed. For modifying "killpets", I'd change it to "dismisspets". Then code it so summoned monsters are killed and charmed monsters are set to be peaceful. However, this doesn't address the issue of what happens when a monster is charmed, then taken to another map. > - Add more powerful types of summoned creatures at higher levels > (Possibly just more things for 'summon creature' or possibly (a) new > spell(s) like 'summon greater creature') There is "Magehound", but I think it was added more as an example. Someone would have to check for balance issues before it is actually made available to players. > - Make the first few levels more practical to use it with, possibly by > making the summoned creatures faster or more powerful. Agreed. > - Not as needed to balance as the other notes, but somehow reducing the > risk of loss of a weapon used with animate weapon. Can't think of anything other than giving it temporary immunity to being damaged (burnt up, icecubed, etc) or making the weapon come back to the player after the spell's effect ends. -- Andrew Fuchs From lalo.martins at gmail.com Mon Aug 21 19:27:59 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 22 Aug 2006 08:27:59 +0800 Subject: [crossfire] Spell path balance - Summoning References: <20060821115445.1ce88555.raphael@gimp.org> <44E9E8C5.4050509@telus.net> Message-ID: On Mon, 21 Aug 2006 19:55:44 -0400, Andrew Fuchs wrote: > On 8/21/06, Alex Schultz wrote: >> Rapha?l Quinet wrote: >> - Make charmkilling not so powerful without completely making it >> useless. (personally I think requiring line of sight and limited range >> might be a good method, possibly in addition to making 'killpets' not >> always work) > > Agreed. For modifying "killpets", I'd change it to "dismisspets". > Then code it so summoned monsters are killed and charmed monsters are > set to be peaceful. +1, that's exactly what I was thinking. It doesn't make sense to me that you can "unsummon" a creature you didn't summon in the first place. > However, this doesn't address the issue of what > happens when a monster is charmed, then taken to another map. Simple; they follow you if there's space for them, and break free (go peaceful) if not. >> - Add more powerful types of summoned creatures at higher levels >> (Possibly just more things for 'summon creature' or possibly (a) new >> spell(s) like 'summon greater creature') One idea, as mwedel said, is to make creatures that aren't necessarily stronger, but that have player-level speeds. 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 mwedel at sonic.net Mon Aug 21 23:08:12 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 21 Aug 2006 21:08:12 -0700 Subject: [crossfire] About a feature request In-Reply-To: References: <200608200011.13378.nicolas.weeger@laposte.net> <20060821102952.7117f685.raphael@gimp.org> Message-ID: <44EA832C.4060307@sonic.net> Just a note/thought: the reasoning for cursed spellbooks harming lowlevel players more is probably true for cursed objects in general. I doubt a mid/high level character is ever really hurt with cursed objects - they will detect curse/identify the objects. And even if they did apply one, easy enough for them to get a remove curse spell. But this then almost leads to the question - should cursed objects just in general be removed then? I think it adds something to the game, so I'd probably say it shouldn't be, but then by that same logic, it should get extended to more objects. One thought would be a setting for this - right now, some fixed percentage of objects are made as cursed objects. Instead of having that be hard coded, make it a settable parameters. Servers that want to be easy on players could set that to 0, so cursed objects never show up (except on maps designed for it). Servers that want things really difficult could set it higher. Some servers could set it to a very low non zero number (1%? .1%?) I think that setting is more interesting - cursed objects in general would be so rare you might not check for them, and thus get hit by them once in a while. Other random thoughts: If you are not sufficient level to learn a spell from a spellbook, it does not identify it for you - thus, you have no clue what it is. In order to be affected by a cursed spellbook, you must be sufficient level to learn the spell - a low level mage can't be hit by a cursed 20th level spellbook. If loss of spell is done, then the spell that is lost has to be less than equal to the level of the cursed spellbook (you can't lose a level 5 spell on a cursed level 1 spellbook). Or if you want to be more kind, it only removes the spell it is a cursed version of (a cursed burning hands would only remove a burning hands spell if you know it - if you don't, maybe confuses you for a while or some other effect). If the percentage of spellbooks that are cursed are low enough, this may not be a big deal - odds being that if you found a cursed spellbook of some spell, you probably found 10 uncursed versions, so even if you lose the spell, not the end of the world. From mwedel at sonic.net Mon Aug 21 23:15:13 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 21 Aug 2006 21:15:13 -0700 Subject: [crossfire] Spell path balance - Summoning In-Reply-To: References: <20060821115445.1ce88555.raphael@gimp.org> <44E9E8C5.4050509@telus.net> Message-ID: <44EA84D1.10307@sonic.net> Andrew Fuchs wrote: > Can't think of anything other than giving it temporary immunity to > being damaged (burnt up, icecubed, etc) or making the weapon come back > to the player after the spell's effect ends I don't think the temporary immunity would really help out. From what I've seen is what happens is that the weapon is fine as long as the spell is going on. But when the spell ends, the object on the ground is now hit by some attacktype the destroyes it. So any addition of immunities would have to last beyond the length of the spell, and that gets tricky, as if the player picks it up and wields it, they shouldn't really get those immunities. Having the object return to the player when the spell ends or is destroyed is probably the best/safest thing. It'd be a little odd to explain why. Another thing, which would also be harder, is to know the relative power of the weapon, so you know when it is close to death, and could perhaps have it start returning to you, etc. From mwedel at sonic.net Mon Aug 21 23:20:19 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 21 Aug 2006 21:20:19 -0700 Subject: [crossfire] Clothing In-Reply-To: References: <200608191059.12752.subs@eracc.com> <44E93013.5060708@sonic.net> Message-ID: <44EA8603.2040808@sonic.net> Ok. If that is what is being asked, no issues what so ever. You may not even need a new type if the object in itself doesn't have any properties other than it being clothing (no ac, no protections/resistances/whatever). I wonder if this could in fact be done with a new subtype - something like light armor. I think in that case, all that would be needed is some minor change to the IS_ARMOR() macro to check against the subtype, and that is it. That is probably easier to do than making a new type. In fact, the different types of armor right now (cloak, bracers, shield, etc) really isn't correct given the type/subtype setup now days - they should really all be the same type, with different subtypes (or perhaps not even a need for that since we don't really care what the type is that much) From alex_sch at telus.net Tue Aug 22 00:32:30 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 21 Aug 2006 23:32:30 -0600 Subject: [crossfire] Spell path balance - Summoning In-Reply-To: <44EA84D1.10307@sonic.net> References: <20060821115445.1ce88555.raphael@gimp.org> <44E9E8C5.4050509@telus.net> <44EA84D1.10307@sonic.net> Message-ID: <44EA96EE.8080206@telus.net> Mark Wedel wrote: > Andrew Fuchs wrote: > >> Can't think of anything other than giving it temporary immunity to >> being damaged (burnt up, icecubed, etc) or making the weapon come back >> to the player after the spell's effect ends >> > > I don't think the temporary immunity would really help out. > > From what I've seen is what happens is that the weapon is fine as long as the > spell is going on. But when the spell ends, the object on the ground is now hit > by some attacktype the destroyes it. > > So any addition of immunities would have to last beyond the length of the > spell, and that gets tricky, as if the player picks it up and wields it, they > shouldn't really get those immunities. > Well, to make an object immune to being damaged on the ground, there are ways other than resists. In particular material tricks could allow it, and wouldn't have the drawback of giving the player the immunity. However there is still another issue to deal with, which is it still wouldn't be good to make it permanent. A solution to that would be: -allowing forces to give material traits to their parents and -making subtypes of forces that can do things like disappear when the container of the force is picked up or moved. That could allow the weapon to be immune to destruction until picked up. > Having the object return to the player when the spell ends or is destroyed is > probably the best/safest thing. It'd be a little odd to explain why. > Despite what I said about though, I would personally favor just returning the object when the weapon is no longer animated, due to simplicity. Alex Schultz From mwedel at sonic.net Tue Aug 22 01:26:29 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 21 Aug 2006 23:26:29 -0700 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44DD8863.4000401@sonic.net> References: <44DD8863.4000401@sonic.net> Message-ID: <44EAA395.6090701@sonic.net> It's been a couple weeks. So doing a quick scoring (using http://wiki.metalforge.net/doku.php/user:rednaxela:scmtable as the reference): CVS SVN Hg BZR DARCS Key Requirements (7) 7 7 6? 7 6? Top Features (6) 3 3 5.5 4 4 Nice to Haves (7) 2 6 6.5 7 7 TOTAL (20) 12 16 18 18 17 TOTAL2? (30) 20.5 24.5 26.7 27 25 ?missing known free hosting service ?weighted so that key features are times 2, top features times 1.5 so BZR would seem to be the winner, but except for CVS, all score pretty closely. What throws off the results some is the ability of a hosting service. If someone added mercurial or a darcs hosting service tomorrow, that changes the results. OTOH, that can be said for most features - the next release of SVN could add new features, changing some nos to a yes, etc, so one can't really plan on what may happen. (as an aside, I asked sourceforge support about using web space for mercurial hosting, and the short answer was use SVN or CVS, and given the web space on SF isn't enough for crossfire, we couldn't use that for either Hg or Darcs even unofficially). So quick thoughts: CVS: path of least resistance, since that is what we are currently using. To continue using it doesn't preclude us from changing in the future. SVN: Only reason to switch to this is because sourceforge supports it - it clearly isn't the best choice in set of features, but is better than CVS. Still, probably not worth the effort of changing. Mercurial: If a good hosting service is available, this may be the best option. But hosting here is tricky - commits, at current time, seem to need ssh access (may change to https in the future). Free web hosting services may work, but only if unlimited bandwidth is provided and a common user account can be used (unique user accounts/user would probably be a pretty big security risk, as most likely anyone else with an account on the server could muck with the repository also). The one advantage of distributed SCM's is that the central repository isn't quite as key (eg, if it went away for some reason, the copy developers have is completely and could be used to make a new master repository, where as with SVN/CVS, the data just isn't there in the local repository) BZR: The two things it is missing to get a perfect score is efficient use of resources and support for symbolic tagging. As far as I can tell, BZR has no support for any form of tagging, so using 'branch' tagging would be necessary. The other issue is that it needs to make a new http connection for each file to pull. This may not be that big an issue for the server component (where there are not a lot of files), but this could make things really slow for arch or maps updates. That said, BZR is the most feasible solution right now (OTOH, launchpad.net web site has been down for maintenance for the past hour, so not sure how much better they are from a reliability standpoint over sourceforge) Darcs: Has the same lack of hosting as mercurial, and otherwise isn't really better in any regard, so don't see a very compelling reason to look into darcs. From alex_sch at telus.net Tue Aug 22 02:11:23 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 22 Aug 2006 01:11:23 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44EAA395.6090701@sonic.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> Message-ID: <44EAAE1B.8030701@telus.net> Mark Wedel wrote: > Mercurial: If a good hosting service is available, this may be the best option. > But hosting here is tricky - commits, at current time, seem to need ssh access > (may change to https in the future). > One note on this, as of Mercurial 0.9.1, you can push via http as well, and for that one uses apache's http authentication to control access, so it can run as pure CGI on a web server without even the ssh need. https is also supported in the same way, provided the web server supports it. > BZR: > The other issue is that it needs to make a new http connection for each file to > pull. This may not be that big an issue for the server component (where there > are not a lot of files), but this could make things really slow for arch or maps > updates. Well, it's a reasonably big issue on the server anyways, it takes about 2 hours (see one of Lalo's messages) to branch the crossfire server over http with bzr. (of course, if one can handle that wait one time, it isn't so bad after if one keeps an 'incoming' branch due to never having to download the whole history ever again) Alex Schultz From mwedel at sonic.net Tue Aug 22 02:30:13 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 22 Aug 2006 00:30:13 -0700 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44EAAE1B.8030701@telus.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <44EAAE1B.8030701@telus.net> Message-ID: <44EAB285.2040702@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> Mercurial: If a good hosting service is available, this may be the best option. >> But hosting here is tricky - commits, at current time, seem to need ssh access >> (may change to https in the future). >> > One note on this, as of Mercurial 0.9.1, you can push via http as well, > and for that one uses apache's http authentication to control access, so > it can run as pure CGI on a web server without even the ssh need. https > is also supported in the same way, provided the web server supports it. The question then, I suppose, is if there is a free hosting site that is provides the needs, those being space (probably need about 1 gigabyte), cgi-bin, unlimited bandwidth, etc. From alex_sch at telus.net Tue Aug 22 03:24:13 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 22 Aug 2006 02:24:13 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44EAB285.2040702@sonic.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <44EAAE1B.8030701@telus.net> <44EAB285.2040702@sonic.net> Message-ID: <44EABF2D.5030303@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> Mark Wedel wrote: >> >>> Mercurial: If a good hosting service is available, this may be the best option. >>> But hosting here is tricky - commits, at current time, seem to need ssh access >>> (may change to https in the future). >>> >>> >> One note on this, as of Mercurial 0.9.1, you can push via http as well, >> and for that one uses apache's http authentication to control access, so >> it can run as pure CGI on a web server without even the ssh need. https >> is also supported in the same way, provided the web server supports it. >> > > The question then, I suppose, is if there is a free hosting site that is > provides the needs, those being space (probably need about 1 gigabyte), cgi-bin, > unlimited bandwidth, etc. I was looking around a bit, and I couldn't really find any until I found Dotsrc.org (formerly SunSITE.dk), which looks like it might be able to support a Mercurial server for crossfire. They look like they tend to be more accommodating to unusual configurations and if there is a default web quota would likely be willing to expand it due to it being used for version control. Might want to investigate them for hosting if we indeed want to use Mercurial. Alex Schultz From tchize at myrealbox.com Tue Aug 22 03:28:24 2006 From: tchize at myrealbox.com (Tchize) Date: Tue, 22 Aug 2006 10:28:24 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44EAA395.6090701@sonic.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> Message-ID: <44EAC028.50300@myrealbox.com> Mark Wedel wrote: > It's been a couple weeks. So doing a quick scoring (using > http://wiki.metalforge.net/doku.php/user:rednaxela:scmtable as the reference): > > CVS SVN Hg BZR DARCS > Key Requirements (7) 7 7 6? 7 6? > Top Features (6) 3 3 5.5 4 4 > Nice to Haves (7) 2 6 6.5 7 7 > TOTAL (20) 12 16 18 18 17 > TOTAL2? (30) 20.5 24.5 26.7 27 25 > > I did not follow this thread, but am curious on this point on the wiki page. It's stated 'good branch handling' on CVS and SVN as no. Am sorry to raise it now, but i have been using branching on CVS at work for a while and we never had any problem with branching. Also, what is support for symbolic tagging within one repository 'No' on svn, SVN has support for tags, and because tags&branch create a new urls in svn, it make it easy to retrieve a specific version or branches using that url. You can even mix tags if you want (tag only some folders or get different revision of different folder under a same tag) The ability to do local branch (which is suppose mean creating a local repository, working on it and then push your local repository branch to main server) is marked as 'no' for svn, but according to some doc, it can be done with SVN-Mirror or SVN-Pusher, it's client side tools you can install to create your own repository. Tracking when merge are done is not No on svn, but svn docs about branching and merging explicitly explain how to track it efficiently and easily. In fact, reading the wiki page, svn has all the request and all the nice to have features (bringing a total of 20 and a total2 of 36.5) Another fact that was not taken into account it the fact sourceforge hosted revision control has the advantage of not having to duplicate user accounts. You can use the same accounts for revision control, bug tracking, releasing, web management, and project admins can manage all that using a single interface. I have never heard of darcs, bzr and hg before, but if we get to free hosting service for those tool, we need to ensure those service won't disappear in the next 3 years. Sourceforge is a solid corporation held by VA linux. The best solution to decide will probably be a vote amongst commiters as everyone probably has it's preferences. From drnlmuller+crossfire at gmail.com Tue Aug 22 06:05:39 2006 From: drnlmuller+crossfire at gmail.com (Neil Muller) Date: Tue, 22 Aug 2006 13:05:39 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44EAA395.6090701@sonic.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> Message-ID: > Darcs: Has the same lack of hosting as mercurial, and otherwise isn't really > better in any regard, so don't see a very compelling reason to look into darcs. alioth.debian.org hosts several projects using darcs and they're quite happy to host non-debian projects. This has the disadvantage of moving the repoisitory from sourceforge, and the alioth machines have had stability issues in the past, although they've been pretty stable this year. -- Neil Muller From raphael at gimp.org Tue Aug 22 09:44:53 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Tue, 22 Aug 2006 16:44:53 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44EAC028.50300@myrealbox.com> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <44EAC028.50300@myrealbox.com> Message-ID: <20060822164453.4d7f9134.raphael@gimp.org> On Tue, 22 Aug 2006 10:28:24 +0200, Tchize wrote: > I did not follow this thread, but am curious on this point on the wiki > page. It's stated 'good branch handling' on CVS and SVN as no. Am sorry > to raise it now, but i have been using branching on CVS at work for a > while and we never had any problem with branching. I would like to second that. As a GIMP developer, I have been using CVS branches extensively: we always maintain HEAD together with at least one stable branche, while several experimental features are developed in their own branches, such as the recent Google Summer of Code projects. We also perform a lot of merges from the HEAD branch to the stable branch and sometimes from the stable or experimental branches to the HEAD branch, as you can see in the ChangeLog from the stable branch: http://developer.gimp.org/ChangeLog-2.2 So regardless of how the different systems support branching and merging, I think that the support offered by CVS and SVN is good enough in practice, including for large projects. So all systems would get 1 point there. [...] > In fact, reading the wiki page, svn has all the request and all the nice > to have features (bringing a total of 20 and a total2 of 36.5) I think that the scores could even be adjusted further: - The "learning curve from CVS" has not been taken into account. This should not be underestimated. This would probably deserve more than 1 point (which would be given to CVS and SVN). By the way, I do not think that Bzr or Mercurial are really easier to learn than Darcs (or Arch or Cogito/git), but that is of course subjective. - The popularity of each system should also be taken into account, for two reasons: using similar tools would be better for those who work on several projects (daimonin, cfplus, cf-extended, or other projects from GNOME, KDE, Xorg, various Linux distributions, etc.) and using a popular tool means that it is easier to get support or to switch to a different host in case there is some problem with the current host of the repositiory. Again, CVS and SVN would get an extra point here. > Another fact that was not taken into account it the fact sourceforge > hosted revision control has the advantage of not having to duplicate > user accounts. You can use the same accounts for revision control, bug > tracking, releasing, web management, and project admins can manage all > that using a single interface. Indeed, this is also an important point. The integrated support for releases and downloads is not too critical because it only concerns a small subset of the developers (often a singleton) but having good links between the bug/patch/request tracker and the source code management system is a big plus for most developers. So the systems supported by SourceForge get an extra point here. I also like the way the GNOME and KDE projects have nice cross-references between the Bugzilla entries and the corresponding CVS or SVN changes: commit messages mention bug numbers that will be automatically linked to the bug reports in the viewcvs/viewsvn interfaces, and the comments closing the bug reports include the corresponding commit message. > The best solution to decide will probably be a vote amongst commiters as > everyone probably has it's preferences. Yes, because although the matrix is nice, it does not and cannot accurately reflect the opinions of all developers: some reasons why some developers would prefer some systems over another may not have been stated yet in this discussion, or maybe they have been stated but not included in the matrix (for example, I suggested to rate the support for partial checkouts and for partial updates). Also, some developers may think that some features are more important than others and give them more weight. For example, I think that the support for renames is a "top feature" or maybe even a "key requirement" rather than "nice to have" because this could be very useful when renaming map directories (and being able to track the changes across branches and merges). I would therefore count more than one point for this feature. Same for the availability of hosting services like SourceForge, which is worth more than 1 point according to Mark's TOTAL2 formula in which the weights are 2, 1.5 and 1. So if I take into account all the changes mentioned above and promote or demote some features accordingly, I end up with a rather different table: CVS SVN Hg BZR DARCS Key Requirements (11) 10 10 6 8 8 Top Features (7) 6 7 5.5 4 4 Nice to Haves (6) 3 5 6 6 6 TOTAL (24) 19 22 17.5 18 18 TOTAL2 (38.5) 32 35.5 26.3 30 30 Now we get a totally different picture: SVN comes on top, followed by our good old CVS, then come Bzr and Darcs, and then only Mercurial. Of course some may claim that the updated table is biased, but that's the whole point! I give more weight to the features that I consider more important: availability of hosting solutions (multiple choices if possible), support for renames, support for partial updates, etc. Others may have different priorities and that's fine for me. The current table is probably biased toward what Mark or Alex consider as being important. If there was a vote, this updated table would help me to decide how I would vote. Others with different priorities would probably vote differently. -Rapha?l From alex_sch at telus.net Tue Aug 22 12:29:59 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 22 Aug 2006 11:29:59 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <20060822164453.4d7f9134.raphael@gimp.org> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <44EAC028.50300@myrealbox.com> <20060822164453.4d7f9134.raphael@gimp.org> Message-ID: <44EB3F17.6060109@telus.net> Rapha?l Quinet wrote: > As a GIMP developer, I have been using > CVS branches extensively: we always maintain HEAD together with at > least one stable branche, while several experimental features are > developed in their own branches, such as the recent Google Summer of > Code projects. We also perform a lot of merges from the HEAD branch > to the stable branch and sometimes from the stable or experimental > branches to the HEAD branch, as you can see in the ChangeLog from the > stable branch: http://developer.gimp.org/ChangeLog-2.2 > > So regardless of how the different systems support branching and > merging, I think that the support offered by CVS and SVN is good > enough in practice, including for large projects. So all systems > would get 1 point there. > Well, I'm curious how the workflow would work for doing things like bugfixes that you want merged so they are in both branches. In systems with a distributed design like Mercurial and Bzr, the ideal workflow (that I can see) would be to, make the bugfix in the stable branch, and then pull from the stable branch to the head branch, and do a merge, and fix the conflicts (which could be anywhere from so trivial the system could deal with it on it's own, to making small changes to the fix, to simply manually ignoring the bugfix's changes due to it no longer applying). This keeps track of history the best, and actually would even allow one to reconstruct the stable branch from the head branch, because it would contain information about which revision they diverged at, and not only how the bugfixes applied to the head branch, but also how they applied to the revision where it branched from stable (not necessarily the most useful of features, but it takes no effort to keep track of oneself and makes the logs extremely accurate and complete). Now that I've described the workflow one would probably use in distributed systems, could you explain the workflow that is considered best to use for CVS and SVN type systems for handling putting a bugfix in multiple branches? >> Another fact that was not taken into account it the fact sourceforge >> hosted revision control has the advantage of not having to duplicate >> user accounts. You can use the same accounts for revision control, bug >> tracking, releasing, web management, and project admins can manage all >> that using a single interface. >> > Indeed, this is also an important point. The integrated support for > releases and downloads is not too critical because it only concerns a > small subset of the developers (often a singleton) but having good > links between the bug/patch/request tracker and the source code > management system is a big plus for most developers. So the systems > supported by SourceForge get an extra point here. I also like the way > the GNOME and KDE projects have nice cross-references between the > Bugzilla entries and the corresponding CVS or SVN changes: commit > messages mention bug numbers that will be automatically linked to the > bug reports in the viewcvs/viewsvn interfaces, and the comments > closing the bug reports include the corresponding commit message. > I'm not really sure that this integration is really so helpful. It's not like sf.net does any cross referencing of it's own with that, and if we were to do something along the lines of Mercurial over http, a policy of using the same usernames as on sf.net could easily be used. The only point of disadvantage I can see is from the admin point of view, where to add a developer one would need to add both on sf.net and also to wherever the repository is stored, however though I'm not a project admin, I would imagine this would be a rather minor bother to them. >> The best solution to decide will probably be a vote amongst commiters as >> everyone probably has it's preferences. >> > Yes, because although the matrix is nice, it does not and cannot > accurately reflect the opinions of all developers: some reasons why > some developers would prefer some systems over another may not have > been stated yet in this discussion, or maybe they have been stated but > not included in the matrix (for example, I suggested to rate the > support for partial checkouts and for partial updates). > Agreed, indeed the matrix can't accurately reflect the opinions of all developers; when I made it I intended it to be simple a quick reference for some of the features people were considering important in discussion, and was aware that it was probably biased to some degree though I did try to avoid bias as much as I could, of course avoiding bias isn't a precise process. Alex Schultz From nicolas.weeger at laposte.net Tue Aug 22 12:39:09 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 22 Aug 2006 19:39:09 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44EAA395.6090701@sonic.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> Message-ID: <200608221939.09957.nicolas.weeger@laposte.net> Hello :) I'm not gonna discuss or argue, I'll just vote for SVN - we'll stay on SF & have atomic commits. ^_- Nicolas From alex_sch at telus.net Tue Aug 22 14:03:25 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 22 Aug 2006 13:03:25 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44EAC028.50300@myrealbox.com> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <44EAC028.50300@myrealbox.com> Message-ID: <44EB54FD.3030705@telus.net> Tchize wrote: > Also, what is support for symbolic tagging within one repository 'No' > on svn, SVN has support for tags, and because tags&branch create a new > urls in svn, it make it easy to retrieve a specific version or branches > using that url. You can even mix tags if you want (tag only some folders > or get different revision of different folder under a same tag) > From mwedel at sonic.net Tue Aug 22 23:41:39 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 22 Aug 2006 21:41:39 -0700 Subject: [crossfire] crossfire source code control systems In-Reply-To: <200608221939.09957.nicolas.weeger@laposte.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <200608221939.09957.nicolas.weeger@laposte.net> Message-ID: <44EBDC83.40804@sonic.net> Any selection method is flawed at some level. Voting probably does make the most sense - but even then, you get some complications - should the amount of commits a person do also have weight on the number of votes? A person who does 5 commits a week is using the system a lot more than the person that does 1 commit a month. Do we attempt to weigh that at all? And if so, how? (its probably worth noting that different people work on different things, which probably also weighs on what they want to use. Rename feature is going to be much more important for maps and archetypes than for the code area, where files are seldom renamed) Is the voting method just vote for what you want to use? Or does each person provide a list, and you weigh the bottom vote getters with some negative points? (for example, if lots of people put the same thing as their bottom choice, that suggest some strong dislike). And how long should the voting process be for? Need some finite time - probably a week or so. Should we vote on the voting method? :) From alex_sch at telus.net Wed Aug 23 01:42:53 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 23 Aug 2006 00:42:53 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44EBDC83.40804@sonic.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <200608221939.09957.nicolas.weeger@laposte.net> <44EBDC83.40804@sonic.net> Message-ID: <44EBF8ED.8050403@telus.net> Mark Wedel wrote: > Any selection method is flawed at some level. > > Voting probably does make the most sense - but even then, you get some > complications - should the amount of commits a person do also have weight on the > number of votes? > > A person who does 5 commits a week is using the system a lot more than the > person that does 1 commit a month. Do we attempt to weigh that at all? And if > so, how? > Personally, I don't think it's worth trying to weight such things, too much potential for arguing of fairness. IMHO any commiter who bothers to vote should just have an equal vote with everyone else. > Is the voting method just vote for what you want to use? Or does each person > provide a list, and you weigh the bottom vote getters with some negative points? > (for example, if lots of people put the same thing as their bottom choice, that > suggest some strong dislike). > I'm thinking perhaps a list would be a more accurate gage of opinions involved, or at least have a 'first-choice second-choice' system, though IMHO a full list from the options people have been evaluating would be best. > And how long should the voting process be for? Need some finite time - > probably a week or so. > Personally a week seems reasonable. > Should we vote on the voting method? :) Or perhaps we should vote on the voting method, to vote on the voting method. Or if along that line of thinking, how about one hundred layers of voting? :P Alex Schultz From tchize at myrealbox.com Wed Aug 23 04:27:34 2006 From: tchize at myrealbox.com (Tchize) Date: Wed, 23 Aug 2006 11:27:34 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44EBDC83.40804@sonic.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <200608221939.09957.nicolas.weeger@laposte.net> <44EBDC83.40804@sonic.net> Message-ID: <44EC1F86.6080407@myrealbox.com> A quite common way of voting is to let people mark all thing they want. For example if we have item a,b,c,d and i can vote a; that mean a has my preference vote a, b; that mean a and b have my preference over c and d vote a, b, c; that mean i don't like d For the delay, i think we can afford a 1 month time voting (to give opportunity to vote for commiters on holidays). We are not in a hurry to switch :) For the notions of weighting vote, that's quite stupid, every time you try to weight something, you always introduce arbitrary that can frustate people it's definitly more unfair than fair. I proposed the idea of having people select different items because, if i remember well my student time, it's the system that vote for a candidate that is the most widly accepted, but not necessary the most widely preffered, and it take into account the case were similar candidates have to share the voters. Also, the idea of a 'first choice' and 'second choice' is bad, because, again, it introduce a weighting system and people have several choice don't necessary have a first and second choice and you fall back in case where similar cnadidate have to share the first choice, leading the path to another less accepted candidate. However, because we can't argue on the voting system nor vote for a voting system ;) i suggest the project manager take a wise decision on how we will vote on the source repository change and by the same time, how we will vote next time we have something important to vote on (its probably worth noting that different people work on different things, which probably also weighs on what they want to use. Rename feature is going to be much more important for maps and archetypes than for the code area, where files are seldom renamed) I don't agree, i think all commiters are aware that we have different part in crossfire and different need, and commiter can vote based on such requirements. Mark Wedel a ?crit : > Any selection method is flawed at some level. > > Voting probably does make the most sense - but even then, you get some > complications - should the amount of commits a person do also have weight on the > number of votes? > > A person who does 5 commits a week is using the system a lot more than the > person that does 1 commit a month. Do we attempt to weigh that at all? And if > so, how? > > (its probably worth noting that different people work on different things, > which probably also weighs on what they want to use. Rename feature is going to > be much more important for maps and archetypes than for the code area, where > files are seldom renamed) > > Is the voting method just vote for what you want to use? Or does each person > provide a list, and you weigh the bottom vote getters with some negative points? > (for example, if lots of people put the same thing as their bottom choice, that > suggest some strong dislike). > > And how long should the voting process be for? Need some finite time - > probably a week or so. > > Should we vote on the voting method? :) > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From lalo.martins at gmail.com Wed Aug 23 05:12:36 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 23 Aug 2006 18:12:36 +0800 Subject: [crossfire] crossfire source code control systems References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <200608221939.09957.nicolas.weeger@laposte.net> <44EBDC83.40804@sonic.net> <44EC1F86.6080407@myrealbox.com> Message-ID: A few days ago a friend was describing the Australian system to me. He (she?) probably didn't describe it very precisely, and I probably didn't understand it perfectly, but it goes more or less like this: You vote for a number of options in order: your favourite, your second choice, and so on. I think you're supposed to cast 5 votes and you're allowed to cast less. Then we count only first choices. We remove some candidates -- maybe the one with less votes, maybe half of them, maybe all candidates that didn't achieve a minimum of votes, maybe leave only X candidates. Next we "revise" the votes, by popping choices out of the top of each ballot that aren't running anymore. So if your first choice was GNU Arch and on the second count GNU Arch isn't running anymore, we "pop that off", pretending your second choice was your first and so on. Then we count only first choices and eliminate from the bottom again, and repeat these two steps a number of times until there's only one left. Sounds complicated, but it's rather trivial to write a script to do that. And if you try to understand why it's designed this way, you'll concede it's probably the fairest systems you can think of. (Is "fairest" even a word? Can we vote on that?) 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 nicolas.weeger at laposte.net Wed Aug 23 15:24:39 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Wed, 23 Aug 2006 22:24:39 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44EBDC83.40804@sonic.net> References: <44DD8863.4000401@sonic.net> <200608221939.09957.nicolas.weeger@laposte.net> <44EBDC83.40804@sonic.net> Message-ID: <200608232224.39418.nicolas.weeger@laposte.net> > Voting probably does make the most sense - but even then, you get some > complications - should the amount of commits a person do also have weight > on the number of votes? Ha sorry, I was merely talking metaphorically :) So I'll say another way: if we were to vote, I'd vote for SVN, but I'm definitely not calling for a vote ^_- Apart that I don't really mind, as long as we don't change everything for the sake of changing. Nicolas From mwedel at sonic.net Thu Aug 24 01:46:13 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 23 Aug 2006 23:46:13 -0700 Subject: [crossfire] crossfire source code control systems In-Reply-To: References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <200608221939.09957.nicolas.weeger@laposte.net> <44EBDC83.40804@sonic.net> <44EC1F86.6080407@myrealbox.com> Message-ID: <44ED4B35.2020703@sonic.net> Lalo Martins wrote: > A few days ago a friend was describing the Australian system to me. He > (she?) probably didn't describe it very precisely, and I probably didn't > understand it perfectly, but it goes more or less like this: > > You vote for a number of options in order: your favourite, your second > choice, and so on. I think you're supposed to cast 5 votes and you're > allowed to cast less. You basically described the instant run off system, which is sometimes called the australian system. More info: http://en.wikipedia.org/wiki/Instant-runoff_voting It is probably a good method to use, because I doubt any system will get a majority on the first vote, and it avoids run-offs. From tchize at myrealbox.com Thu Aug 24 03:34:01 2006 From: tchize at myrealbox.com (Tchize) Date: Thu, 24 Aug 2006 10:34:01 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44ED4B35.2020703@sonic.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <200608221939.09957.nicolas.weeger@laposte.net> <44EBDC83.40804@sonic.net> <44EC1F86.6080407@myrealbox.com> <44ED4B35.2020703@sonic.net> Message-ID: <44ED6479.10007@myrealbox.com> This seems to be a fair system, considering it aims at getting a majority. Mark Wedel a ?crit : > > > You basically described the instant run off system, which is sometimes called > the australian system. More info: > > http://en.wikipedia.org/wiki/Instant-runoff_voting > > It is probably a good method to use, because I doubt any system will get a > majority on the first vote, and it avoids run-offs. > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From raphael at gimp.org Thu Aug 24 06:06:43 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Thu, 24 Aug 2006 13:06:43 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44ED4B35.2020703@sonic.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <200608221939.09957.nicolas.weeger@laposte.net> <44EBDC83.40804@sonic.net> <44EC1F86.6080407@myrealbox.com> <44ED4B35.2020703@sonic.net> Message-ID: <20060824130643.3f7ed16c.raphael@gimp.org> On Wed, 23 Aug 2006 23:46:13 -0700, Mark Wedel wrote: > http://en.wikipedia.org/wiki/Instant-runoff_voting > > It is probably a good method to use, because I doubt any system will get a > majority on the first vote, and it avoids run-offs. I agree, this is a good method. If every participant rates at least 3 systems (to avoid the problem of 'exhausted' ballots as described in the wikipedia article) then it should be possible to pick the winner easily. It should also be possible to suggest other source code management systems even if they are not included in the matrix, such as SVK (even if it is basically a layer above SVN), Monotone, Cogito (git), GNU arch and others. Previous messages mentioned the option to weight the votes. If the main developers are happy with the outcome of the vote without any weighting, then it is not an issue anyway. But if the results of the vote are not so clear, then Mark (and maybe Leaf, Ryo and other major contributors) should have a vote that counts double. Or maybe Mark could simply have the final say. After all, experience shows that among the free software projects, those that are led by benevolent dictators tend to be more successful than the projects attempting to have a pure democracy (the latter end up stagnating or forking after a while). At first I thought that I should not vote because I have been away from Crossfire for several years and I only got commit access recently. But now I think that it would be better to allow everybody to vote, including those who do not have commit access. I prefer to encourage people to contribute more in the future because they have cast a ballot than to have anybody feeling left out of the community because they were not allowed to vote. So I suggest to open the vote to everybody who is on this list, including the lurkers. I don't think that it would introduce a major bias in the votes. I will let Mark decide if a vote is really necessary and how long it should last. If we choose to have a vote, then my ballot would be influenced by the updated matrix that I suggested two days ago, except that I would be a bit more conservative and still keep CVS in front. So here is my vote: 1 CVS, 2 SVN, 3 Darcs, 4 Bzr, 5 SVK, 6 Monotone. -Rapha?l From tchize at myrealbox.com Thu Aug 24 07:13:01 2006 From: tchize at myrealbox.com (Tchize) Date: Thu, 24 Aug 2006 14:13:01 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <20060824130643.3f7ed16c.raphael@gimp.org> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <200608221939.09957.nicolas.weeger@laposte.net> <44EBDC83.40804@sonic.net> <44EC1F86.6080407@myrealbox.com> <44ED4B35.2020703@sonic.net> <20060824130643.3f7ed16c.raphael@gimp.org> Message-ID: <44ED97CD.4060002@myrealbox.com> Rapha?l Quinet a ?crit : > > Previous messages mentioned the option to weight the votes. If the > main developers are happy with the outcome of the vote without any > weighting, then it is not an issue anyway. But if the results of the > vote are not so clear, then Mark (and maybe Leaf, Ryo and other major > contributors) should have a vote that counts double. Or maybe Mark > could simply have the final say. After all, experience shows that > among the free software projects, those that are led by benevolent > dictators tend to be more successful than the projects attempting to > have a pure democracy (the latter end up stagnating or forking after a > while). > Hehe, that's the idea, keep democracy, but still behave as a managed project, with leaders :D > At first I thought that I should not vote because I have been away > from Crossfire for several years and I only got commit access > recently. Welcome back :D > But now I think that it would be better to allow everybody > to vote, including those who do not have commit access. I prefer to > encourage people to contribute more in the future because they have > cast a ballot than to have anybody feeling left out of the community > because they were not allowed to vote. So I suggest to open the vote > to everybody who is on this list, including the lurkers. I don't > think that it would introduce a major bias in the votes. > I think it will tend to allow voting from person who either have no interrest in the repository and vote for principle without really knowing consequence of each technlogy choice, or i could even lead to 'spam vote' (don't forget we had an expert in trolling the ml). However, it might be that people not commiters have real interrest in our choice, either because they use the anonymous CVS for a local fork, either because they plan to be commiter in the near future. Suggestion limit votes to people members of one of the following group - commiters and project admins - members of the crossfire-devel mailing list - people requesting the right to vote by explictly showing interest in development process (can be a few lines of text send to mwedel, this is deliberatly vague) > I will let Mark decide if a vote is really necessary and how long it > should last. > > If we choose to have a vote, then my ballot would be influenced by > the updated matrix that I suggested two days ago, except that I would > be a bit more conservative and still keep CVS in front. So here is > my vote: 1 CVS, 2 SVN, 3 Darcs, 4 Bzr, 5 SVK, 6 Monotone. > > -Rapha?l > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From alex_sch at telus.net Thu Aug 24 19:53:24 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 24 Aug 2006 18:53:24 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44ED4B35.2020703@sonic.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <200608221939.09957.nicolas.weeger@laposte.net> <44EBDC83.40804@sonic.net> <44EC1F86.6080407@myrealbox.com> <44ED4B35.2020703@sonic.net> Message-ID: <44EE4A04.2080807@telus.net> Mark Wedel wrote: > http://en.wikipedia.org/wiki/Instant-runoff_voting > > It is probably a good method to use, because I doubt any system will get a > majority on the first vote, and it avoids run-offs. To me this seems a reasonable system, however I think we should consider the "Schulze method" (see http://en.wikipedia.org/wiki/Schulze_method ), a type of "Condorcet method" (A Condorcet method is one that is mathematically shown to fit certain criteria, including but not limited to choosing the most preferred candidate. See http://en.wikipedia.org/wiki/Condorcet_method ), which seems fairly popular among free software groups (i.e. Debian and Gentoo) for votes of internal policy. Actually, we could start using debian's voting software "devotee", which used the "Schulze method", for voting of such things, however personally I feel that would be overkill considering I doubt we would need to do votes very often. Assuming we want to use a preferential system my vote would go as follows: 1) Mercurial 4) SVN 2) CVS 3) Bzr 5) Darcs Note though that between those choices I don't have much of a preference between them, in particular I had a hard time deciding the order for Bzr, SVN, and CVS and I'm still not certain I like that order. Alex Schultz From leaf at real-time.com Thu Aug 24 20:43:24 2006 From: leaf at real-time.com (Rick Tanner) Date: Thu, 24 Aug 2006 20:43:24 -0500 Subject: [crossfire] Spell path balance - Summoning In-Reply-To: References: Message-ID: <44EE55BC.5010603@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lalo Martins wrote: > On Sun, 20 Aug 2006 14:05:55 -0500, Kevin R. Bulgrien wrote: >> completely unbalanced as it takes eons of mind-bendingly boring >> snooze, summon, attack, snooze until summoned character is dead >> cycles. Am I just missing the point of this path, or is it really >> not very well balanced? > > Generally, I think summoning needs high-level spells that summon > strong critters, rather than just relying on pets becoming stronger and > stronger with level. Looking at some other gaming systems as a reference.. Let's not forget the possibility of "reverse summoning." As an example: level 6 - Summon Air Elemental: Summons an Air Elemental to do the caster's bidding Level 7 - Dismiss Air Elemental: A single target range spell that attempts to banish the Air Elemental back to it's native plane. Higher level versions of the spell could then make these "reverse" spells area of effect spells, too. Just an idea. There are more fine tuned details to work out though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE7lW8hHyvgBp+vH4RApA4AJ9BySNBL1MlQrNFHwHoQTM3OByiDQCfcPH3 eytlu4QQzECHSM0VWh09M40= =A5T7 -----END PGP SIGNATURE----- From mwedel at sonic.net Thu Aug 24 23:40:03 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 24 Aug 2006 21:40:03 -0700 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44ED97CD.4060002@myrealbox.com> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <200608221939.09957.nicolas.weeger@laposte.net> <44EBDC83.40804@sonic.net> <44EC1F86.6080407@myrealbox.com> <44ED4B35.2020703@sonic.net> <20060824130643.3f7ed16c.raphael@gimp.org> <44ED97CD.4060002@myrealbox.com> Message-ID: <44EE7F23.1060503@sonic.net> My personal thought is to open the vote to everyone, but also require that each person include a line on what type of user/developer they are, something along the lines of frequent committer, infrequent committer, read only access (play the game, use the SCS to keep up to date), and not currently a developer. While we want to be inclusive, I do think they may be some differences in voting - in particular, taking all the votes is good, but if the results from the frequent committers is much different than the rest, that needs to be taken into consideration. As someone said, this is because the more active developers are more likely to be aware of the different systems, and the shortcomings, etc. I know that if I wasn't a developer, I'd vote for CVS. Why? Because it is working fine for me, and I wouldn't see any real advantages of any other system (having local pristine data like SVN doesn't buy me anything if I never modify my source). I'll admit that for myself, I wasn't that aware of what the different systems offered until this discussion came up, and at which time I read the manual for some of these different systems. Before that, I really wouldn't have had enough info to make a useful decision. Not to say that all infrequent developers are in that situation (some may be familiar with other systems just based on being part of other projects etc). But it is really the developers that are going to see the many issues related to the system. I also think that a private ballot (e-mail) method may be best. Simply as some way to sort of people trying to adjust the votes based on results they currently see. May not be an issue, but it will also avoid a bunch of e-mails to the mailing list. I think a 2 week voting period is more than long enough. Yes, a few people may be on vacation and unable to vote, but I'd say that is probably going to be a relatively insignificant amount of total voters. It seems doubtful that it will swing the election one way or another. In addition, this has been bouncing around for quite a while already, and until a decision on this is made, it doesn't make sense to make the major/stable branches, which also means work in the major new features have to happen in local copies, etc. If the election is very close, I may use my executive powers to make the decision anyways (system A is easier to set up, or of the more mainstream developers, this system was the winner, etc). I'll probably sending out the voting form in the near future. From tchize at myrealbox.com Fri Aug 25 02:40:44 2006 From: tchize at myrealbox.com (Tchize) Date: Fri, 25 Aug 2006 09:40:44 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44EE7F23.1060503@sonic.net> References: <44DD8863.4000401@sonic.net> <44EAA395.6090701@sonic.net> <200608221939.09957.nicolas.weeger@laposte.net> <44EBDC83.40804@sonic.net> <44EC1F86.6080407@myrealbox.com> <44ED4B35.2020703@sonic.net> <20060824130643.3f7ed16c.raphael@gimp.org> <44ED97CD.4060002@myrealbox.com> <44EE7F23.1060503@sonic.net> Message-ID: <44EEA97C.8010809@myrealbox.com> I am ok with a 'private voting' as long a list of votes is published after everyone has voted. Also, this tool might be of interrest to help you count the vote. Especially if you go with a schulze system which seems quite difficult and error prone to handle by hand :) http://vote.sourceforge.net/ 2 weeks seems reasonable for voting, 1 week is too short. Mark Wedel a ?crit : > My personal thought is to open the vote to everyone, but also require that > each person include a line on what type of user/developer they are, something > along the lines of frequent committer, infrequent committer, read only access > (play the game, use the SCS to keep up to date), and not currently a developer. > > While we want to be inclusive, I do think they may be some differences in > voting - in particular, taking all the votes is good, but if the results from > the frequent committers is much different than the rest, that needs to be taken > into consideration. > > As someone said, this is because the more active developers are more likely to > be aware of the different systems, and the shortcomings, etc. > > I know that if I wasn't a developer, I'd vote for CVS. Why? Because it is > working fine for me, and I wouldn't see any real advantages of any other system > (having local pristine data like SVN doesn't buy me anything if I never modify > my source). > > I'll admit that for myself, I wasn't that aware of what the different systems > offered until this discussion came up, and at which time I read the manual for > some of these different systems. Before that, I really wouldn't have had enough > info to make a useful decision. Not to say that all infrequent developers are > in that situation (some may be familiar with other systems just based on being > part of other projects etc). But it is really the developers that are going to > see the many issues related to the system. > > I also think that a private ballot (e-mail) method may be best. Simply as > some way to sort of people trying to adjust the votes based on results they > currently see. May not be an issue, but it will also avoid a bunch of e-mails > to the mailing list. > > I think a 2 week voting period is more than long enough. Yes, a few people > may be on vacation and unable to vote, but I'd say that is probably going to be > a relatively insignificant amount of total voters. It seems doubtful that it > will swing the election one way or another. In addition, this has been bouncing > around for quite a while already, and until a decision on this is made, it > doesn't make sense to make the major/stable branches, which also means work in > the major new features have to happen in local copies, etc. > > If the election is very close, I may use my executive powers to make the > decision anyways (system A is easier to set up, or of the more mainstream > developers, this system was the winner, etc). > > I'll probably sending out the voting form in the near future. > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From nicolas.weeger at laposte.net Fri Aug 25 16:06:57 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Fri, 25 Aug 2006 23:06:57 +0200 Subject: [crossfire] insert_ob_in_map question Message-ID: <200608252306.57460.nicolas.weeger@laposte.net> Hello. Debugging the weather system, I found some weirdness I'm not sure how to fix. When laoding an overlay, insert_ob_in_map gets in some circumstances as flags INS_MAP_LOAD and INS_ABOVE_FLOOR_ONLY The trouble is that sometimes leads to inserting the item *below* another floor. So we have puddles below the ground :) Any idea on how to fix that? Nicolas From mwedel at sonic.net Sat Aug 26 00:36:01 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 25 Aug 2006 22:36:01 -0700 Subject: [crossfire] insert_ob_in_map question In-Reply-To: <200608252306.57460.nicolas.weeger@laposte.net> References: <200608252306.57460.nicolas.weeger@laposte.net> Message-ID: <44EFDDC1.50308@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > Debugging the weather system, I found some weirdness I'm not sure how to fix. > > > When laoding an overlay, insert_ob_in_map gets in some circumstances as flags > INS_MAP_LOAD and INS_ABOVE_FLOOR_ONLY > The trouble is that sometimes leads to inserting the item *below* another > floor. > > So we have puddles below the ground :) > > Any idea on how to fix that? I'd think that the correct behaviour for INS_ABOVE_FLOOR_ONLY should insert the object above the topmost first, not the first floor. I'm not sure if the code currently does that. From mwedel at sonic.net Sat Aug 26 02:54:09 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 26 Aug 2006 00:54:09 -0700 Subject: [crossfire] Vote: Crossfire source code control system. Message-ID: <44EFFE21.6030001@sonic.net> As any readers of the mailing list know, there has been much discussion on what source code control system should be used for crossfire (stick with CVS, or switch to something else, and if we do switch, what to switch to). This is your chance to vote. Ballot is below. Send these back to me (mwedel at sonic.net) to reduce traffic on the mailing list. Voting ends ~September 8. I don't know precisely what time I will tabulate the ballots, and I'll include any I receive up to the the time I start tabulating. If you want to make sure your vote is in, send it before then. I'll then send out results, including what everyone voted for. Please use the ballot below and keep to that form, so it will be easier to process the data with scripts. One ballot per person. The exact method of tallying is yet to be decided - most precisely potential different weight based on peoples current usage. Hopefully, no matter what method is used, the votes will be sufficiently clear cut that there will not be any issues, but I can perhaps forsee some discussion after all the votes are in and tallied. To make things easier, please only include the ballot portion in the e-mail. ------------------------ Ballot Starts Here --------------------------------- Crossfire user names (irc, sourceforge accounts, other names you be be known as): Please check what best describes your use of the current source code control system (current system being the CVS repository): _ Frequent (average more than once a week) committer _ Infrequent committer (at least once a year, but less than 4/month) _ Read only access (keep server/client up to date, etc) _ Do not currently use CVS access Please rank in order of preference which system should be used, with 1 being the system you would most like to use, 5 being least desirable. If you select the other line, then rank 6 choices): _ BZR _ CVS _ Darcs _ Mercurial _ SVN _ Other (specify: ) ----------------------------- Ballot Ends Here --------------------------------- Sample ballot example (before anyone reads anything too much into the list of preferences below, I randomly generated those): ------------------------ Sample Ballot Starts Here ---------------------------- Crossfire user names (irc, sourceforge accounts, other names you be be known as): Joe User, juser, bigjoe Please check what best describes your use of the current source code control system (current system being the CVS repository): _ Frequent (average more than once a week) committer X Infrequent committer (at least once a year, but less than 4/month) _ Read only access (keep server/client up to date, etc) _ Do not currently use CVS access Please rank in order of preference which system should be used, with 1 being the system you would most like to use, 5 being least desirable): 3 BZR 2 CVS 4 Darcs 5 Mercurial 1 SVN _ Other (specify: ) ----------------------------- Sample Ballot Ends Here ------------------------- From nicolas.weeger at laposte.net Sat Aug 26 12:27:52 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 26 Aug 2006 19:27:52 +0200 Subject: [crossfire] Client-side scripting Message-ID: <200608261927.52478.nicolas.weeger@laposte.net> Hello. I would like to enhance client-side scripting with a LUA engine, and before potentially applying my changes I'd like to discuss that, and reply to objections. Note I don't plan on trashing current scripting system, just on adding things :) My rationale is to have at least one common scripting language for all clients versions (those using the common library, at least). My choice of LUA was based on the following requirements: * small footprint - we don't want client to grow really too big * no external dependencies required once client is built - imo it's ok to require to install Python for running a server, but it isn't nice to do that for the client. * available on many platforms - LUA seems portable enough * some base libraries - LUA has enough for the uses I see (string, files, ...) * syntax not too exotic (ok, that's totally subjective, but i don't feel like doing scripts in LISP ^_-) LUA also offers an object layer, to write player.hp instead of gethp() hp or something like that. I'm sure it isn't the only language matching that :) Simply LUA is the one I used. My implementation choice is to rely on function names to know what to call. For instance a script having an "event_stats" function will have it called each time the client gets some stats from the server. Script is responsible to check what changed. Scripts will have all player's information, including inventory, items on ground and visible faces on map, available already (global objects). As current scripting, it'll be possible to watch commands sent by the player, and received from the server. My current proof-of-concept has the basic things ready: player info, inventory, ground. The rest isn't hard to do (maybe to debug), but since it takes some time I'd rather wait i'm sure there won't be an angry mob trying to trash me if I commit :) Nicolas From nicolas.weeger at laposte.net Sat Aug 26 15:56:26 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 26 Aug 2006 22:56:26 +0200 Subject: [crossfire] Fun proof of concept Message-ID: <200608262256.27264.nicolas.weeger@laposte.net> Hello. For the fun I made a small proof of concept in Python :) Sending it here in case someone wants to use that for something else. Basically, if the player moves 5 squares to the top of the detector, then 5 right, then 5 down, then 5 bottom, she gets some platinum coins. You must move in a 2 (game) minutes delay before each position, else it resets. *thinks of fun things like 3 players doing complex moves to activate something ;p Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: dance.tar.gz Type: application/x-tgz Size: 1852 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060826/74db41c4/attachment.bin From nicolas.weeger at laposte.net Sun Aug 27 09:58:35 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 27 Aug 2006 16:58:35 +0200 Subject: [crossfire] Quest management system proposal In-Reply-To: <44D8453A.1010104@sonic.net> References: <200606092027.54507.nicolas.weeger@laposte.net> <200608080931.04812.nicolas.weeger@laposte.net> <44D8453A.1010104@sonic.net> Message-ID: <200608271658.35380.nicolas.weeger@laposte.net> > For example, if the method we decide to go for is that we will use > scripts to give out exp, then it probably would make sense to have a > generic script that takes some parameters on what skill and how much exp to > add, so you could do something like: > > event_activate give_exp.pyc throwing 6000 The code I just committed will let you do just that. Example: want to give xp to player dropping item on altar, add an 'event_activate' hook, and just write: import Crossfire player = Crossfire.WhoIsActivator() player.AddExp(6000, "throwing",0) Pretty easy :) Nicolas From mwedel at sonic.net Sun Aug 27 23:12:44 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 27 Aug 2006 21:12:44 -0700 Subject: [crossfire] extended info markup language Message-ID: <44F26D3C.80507@sonic.net> I'm looking at extending the extended info text logic for the gtkv2 client. Not that it will bring up popup windows, but rather so that the gtkv2 client can change text faces, colors, etc within the text. I really got to thinking on this with the issue of the client always using the same font for all output from the server, and that doesn't make sense for things like the shop listing, or who and maps command (where you want a fixed width font). So drawextinfo is the correct approach - add a new type, and the client can know what to do with that type. However, looking at what is currently there, the rules file as is in the server/lib directory uses some simple markup language. Unfortunately, there is no documentation anyplace that I can find of what this markup language is - the other documentation is to look at the source code, which really isn't acceptable (both from a developer perspective of trying to write something that handles this, but I'd also think from a user perspective, who will have no idea what markup they can in fact use). Can the original author of this please write up some documentation of this markup language and add it the the server/doc/developers directory? From tchize at myrealbox.com Mon Aug 28 02:25:18 2006 From: tchize at myrealbox.com (Tchize) Date: Mon, 28 Aug 2006 09:25:18 +0200 Subject: [crossfire] extended info markup language In-Reply-To: <44F26D3C.80507@sonic.net> References: <44F26D3C.80507@sonic.net> Message-ID: <44F29A5E.7060503@myrealbox.com> Strange, i am pretty sure i wrote this doc. However, browsing CVS it doesn't seem to be there. I probably forgot to cvs add the file :( I'll rewrite it tonight as it's a pretty short doc. Mark Wedel a ?crit : > I'm looking at extending the extended info text logic for the gtkv2 client. > Not that it will bring up popup windows, but rather so that the gtkv2 client can > change text faces, colors, etc within the text. > > I really got to thinking on this with the issue of the client always using the > same font for all output from the server, and that doesn't make sense for things > like the shop listing, or who and maps command (where you want a fixed width > font). So drawextinfo is the correct approach - add a new type, and the client > can know what to do with that type. > > However, looking at what is currently there, the rules file as is in the > server/lib directory uses some simple markup language. > > Unfortunately, there is no documentation anyplace that I can find of what this > markup language is - the other documentation is to look at the source code, > which really isn't acceptable (both from a developer perspective of trying to > write something that handles this, but I'd also think from a user perspective, > who will have no idea what markup they can in fact use). > > Can the original author of this please write up some documentation of this > markup language and add it the the server/doc/developers directory? > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From tchize at myrealbox.com Mon Aug 28 13:46:34 2006 From: tchize at myrealbox.com (tchize) Date: Mon, 28 Aug 2006 20:46:34 +0200 Subject: [crossfire] extended info markup language In-Reply-To: <44F26D3C.80507@sonic.net> References: <44F26D3C.80507@sonic.net> Message-ID: <44F33A0A.9030706@myrealbox.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wrote and commited the doc in the doc/mediaTags file Mark Wedel a ?crit : > I'm looking at extending the extended info text logic for the gtkv2 client. > Not that it will bring up popup windows, but rather so that the gtkv2 client can > change text faces, colors, etc within the text. > > I really got to thinking on this with the issue of the client always using the > same font for all output from the server, and that doesn't make sense for things > like the shop listing, or who and maps command (where you want a fixed width > font). So drawextinfo is the correct approach - add a new type, and the client > can know what to do with that type. > > However, looking at what is currently there, the rules file as is in the > server/lib directory uses some simple markup language. > > Unfortunately, there is no documentation anyplace that I can find of what this > markup language is - the other documentation is to look at the source code, > which really isn't acceptable (both from a developer perspective of trying to > write something that handles this, but I'd also think from a user perspective, > who will have no idea what markup they can in fact use). > > Can the original author of this please write up some documentation of this > markup language and add it the the server/doc/developers directory? > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFE8zoJHHGOa1Q2wXwRAms5AKDTx46jsFJgEXpi1V6nRYxlOzuUTgCeJ7ay dR/a/oQsBEAZKFgm06cZ6v4= =9xnZ -----END PGP SIGNATURE----- From rbrockway at opentrend.net Mon Aug 28 21:49:09 2006 From: rbrockway at opentrend.net (Robert Brockway) Date: Mon, 28 Aug 2006 22:49:09 -0400 (EDT) Subject: [crossfire] Fun proof of concept In-Reply-To: <200608262256.27264.nicolas.weeger@laposte.net> References: <200608262256.27264.nicolas.weeger@laposte.net> Message-ID: On Sat, 26 Aug 2006, Nicolas Weeger (Laposte) wrote: > Hello. > > For the fun I made a small proof of concept in Python :) > Sending it here in case someone wants to use that for something else. > > Basically, if the player moves 5 squares to the top of the detector, then 5 > right, then 5 down, then 5 bottom, she gets some platinum coins. > You must move in a 2 (game) minutes delay before each position, else it > resets. > > > *thinks of fun things like 3 players doing complex moves to activate > something ;p Hehehe - we could make them do coordinated dance routines to win the map ;) Or how about an "olympics" map where the best coordinated team get the gold medal :) 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 From mwedel at sonic.net Tue Aug 29 00:06:20 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 28 Aug 2006 22:06:20 -0700 Subject: [crossfire] extended info markup language In-Reply-To: <44F33A0A.9030706@myrealbox.com> References: <44F26D3C.80507@sonic.net> <44F33A0A.9030706@myrealbox.com> Message-ID: <44F3CB4C.3060802@sonic.net> while on this topic: The tags (and for that matter, gtk1 client) have the idea of different fonts - from the mediatags file: [fixed] set the font to fixed width [arcane] set the font to a magical one [hand] set the font to hand writing [strange] set the font to 'strange unknown language' [print] set the font to the client default one A few questions/notes: for the 'strange' font, is it meant to be literal/readable? For example, if I have '[strange]this is a short message', with the ideal strange font, should a person be able to read that and understand it, or should it appear basically as gibberish? If the later, is the assumption then that the text using it should also be gibberish, eg, '[strange]adsf kj23 adf la zxdv 12' type of thing? It gets sort of odd, because if the user doesn't have a strange font installed, things will fall back to normal font, and thus be in standard roman characters. Second question related to that - the gtk1 client has a list of a bunch of different fonts to use for arcane, hand, and strange. At least on my system (fedora core 5), I don't have any of those fonts, so I'll just get the normal fonts. Are their pointers where users can get those fonts? If the fonts are GPL, would it make sense to have a crossfire-fonts package to have the different fonts? The idea of these different fonts is nice, but if no one has them, and no one knows where to get them, doesn't do much good. With x/gnome, adding fonts I think is a bit of a pain (really want to put the fonts where the system expects them - hard to load them up from some custom directory). For the gtk2 client, I'm letting pango do the work, so just need to provide the font family. Lastly, I wonder if it worthwhile to add tags for any of the following: font size - there is bold and italics, but nothing to increase size. If this is done, I think the size would have to be relative to the base font size, eg: [fontsize=+2] - increase font size 2 points over base size [fontsize=0] - set font size to base size [fontsize=-2] - set font size smaller than base size When I say base size, I suppose meaning that the client is running with 14 point fonts, and adjust from that. underline: is supported - would it make sense? You can look at: http://developer.gnome.org/doc/API/2.0/gtk/GtkTextTag.html scroll down a few lines to the Properties box - those are properties we could easily set, but I don't think there are many others that make sense. From mwedel at sonic.net Tue Aug 29 00:48:21 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 28 Aug 2006 22:48:21 -0700 Subject: [crossfire] current plugins with python 2.2? Message-ID: <44F3D525.5060302@sonic.net> metalforge ran into some problem with latest cvs version of crossfire in the python plug. metalforge currently has python 2.2 installed. My fix was to add a return near the top of addConstants(). The crash was happening someplace inside of this call: new = Py_InitModule(tmp, NULL); It may be that calling convention for this is different in python 2.2 All that said, couple solutions: 1) require newer version of python (as with python 2.2, it clear seems broken) 2) Look at python 2.2 doc and figure out if code can be modified to work with it. From nicolas.weeger at laposte.net Tue Aug 29 15:43:47 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 29 Aug 2006 22:43:47 +0200 Subject: [crossfire] current plugins with python 2.2? In-Reply-To: <44F3D525.5060302@sonic.net> References: <44F3D525.5060302@sonic.net> Message-ID: <200608292243.47053.nicolas.weeger@laposte.net> > 1) require newer version of python (as with python 2.2, it clear seems > broken) 2) Look at python 2.2 doc and figure out if code can be modified to > work with it. Hello. Here's a patch that may fix the issue (I haven't checked the docs, but that's an obvious thing to test ;p) Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: python.diff Type: text/x-diff Size: 840 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060829/e92622f3/attachment.bin From lalo.martins at gmail.com Tue Aug 29 23:53:40 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 30 Aug 2006 12:53:40 +0800 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas Message-ID: Ok, one issue with balance is that, as someone mentioned, most monsters either kill you too easily or are killed too easily. I don't have a solution for that, only wanted to bring it up so we don't forget it ;-) The other thing is that there is a level beyond which you just progress up to demigodhood (110+). What level it is? That depends on the server -- more precisely on the exp_table. On MF I've been told it's about 20 something; I don't know personally as I never reached that level in MF. On my own server, which is set up for children, of course a good player can go to demigodhood in a day or two from scratch. The big problem is that if there is a point where the curve slopes, then you won't explore the world, look for new quests, or even interact much with other players; and on the other end this causes map makers to only want to make high-level quests. To encourage player interaction, the game needs to strongly nudge characters into having different strengths and weaknesses. This is already done to some extents (at low levels) by resistances, natural and god-given; of course at higher levels you start collecting artifacts and you have any resistances you want. An idea I think might be worth experimenting with is cutting the contribution that *ALL* skills make to general score. If you have more characters running around with level ~10 and their primary skill(s) at ~20 that would encourage them to get good at one skill, and therefore to interact with other players. Finally, the easy answer to the curve issue is tweaking the exp_table carefully. I want to start a mini-project, with the goal of tuning up a "perfect" (heh) exp_table. Here's what I'd need: - the server :-P I'd host it here but my bandwidth sucks. I need either an easy way to modify the exp_table and read player files, or a person willing to do that for us. - about three experienced players who are willing to play a lot of crossfire, to actually test the curves. I'll play the role of the noob -- I play better than a beginner, but not much. - ideally, a copy of MF's exp_table, which many people seem to regard as the best table out there, to start from - rough consensus on the ideal curve. Here's my draft: * half a playing hour per level up to 5; * 1h/l up to 10; * 2h/l up to 50; * 3h/l up to 70; * 5h/l up to 90; * 7.5h/l up to 100; * 10h/l beyond 100 These are for an average player of course. 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 alex_sch at telus.net Wed Aug 30 00:45:27 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 29 Aug 2006 23:45:27 -0600 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas In-Reply-To: References: Message-ID: <44F525F7.2040900@telus.net> Lalo Martins wrote: > Ok, one issue with balance is that, as someone mentioned, most monsters > either kill you too easily or are killed too easily. I don't have a > solution for that, only wanted to bring it up so we don't forget it ;-) > Well, I'm not really sure, but I think there are two main causes for that: -The of chance of hitting isn't very random, it's AC and WC, and has some random variation, however the random variation seems extremely insignificant compared to AC and WC. -The speed of hits is very fast, so the random variation of AC vs. WC gets averaged out very quickly. We could try to reduce the speed of battle, however that would take ALOT of tweaking to balance and not frustrate players. Perhaps one option would be to make it so the random variation of AC vs. WC should last longer than one hit, and "ebb and flow" a bit. > The other thing is that there is a level beyond which you just progress up > to demigodhood (110+). What level it is? That depends on the server -- > more precisely on the exp_table. On MF I've been told it's about 20 > something; I don't know personally as I never reached that level in MF. Well, it varies alot depending on player practices, but from what I've seen it can be anywhere from 20 to 50 on MF. > To encourage player interaction, the game needs to strongly nudge > characters into having different strengths and weaknesses. This is > already done to some extents (at low levels) by resistances, natural and > god-given; of course at higher levels you start collecting artifacts and > you have any resistances you want. > Personally I think we should also consider ways to make different classes slightly better at different skills. Perhaps a "skill attument" of sorts. Also class stat bonuses are currently very pointless very quick. > An idea I think might be worth experimenting with is cutting the > contribution that *ALL* skills make to general score. If you have more > characters running around with level ~10 and their primary skill(s) at ~20 > that would encourage them to get good at one skill, and therefore to > interact with other players. > IMHO this would be a good idea, though one would have to be careful about how much one cuts it by. Perhaps how much it cuts it by should also vary on a curve depending on the level. > Finally, the easy answer to the curve issue is tweaking the exp_table > carefully. I want to start a mini-project, with the goal of tuning up a > "perfect" (heh) exp_table. Well, I don't think tweaking the exp_table is the 'silver bullet' that will fix it the whole curve issue, however I feel it is an important step towards fixing it. > - ideally, a copy of MF's exp_table, which many people seem to regard as > the best table out there, to start from > MF's exp table is listed here: http://www.metalforge.net/features/index.html > - rough consensus on the ideal curve. Here's my draft: > > * half a playing hour per level up to 5; > * 1h/l up to 10; > * 2h/l up to 50; > * 3h/l up to 70; > * 5h/l up to 90; > * 7.5h/l up to 100; > * 10h/l beyond 100 > Seems reasonable to me at a glance. > These are for an average player of course. > And should be assuming we fix things widely regarded as overpowered of course. Also, for the purpose of this experiment, I would suggest that players participating try to avoid using things generally considered exploitive or overpowered, and preferable make note of any such things that come to mind. Alex Schultz From mwedel at sonic.net Wed Aug 30 02:02:51 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 30 Aug 2006 00:02:51 -0700 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas In-Reply-To: <44F525F7.2040900@telus.net> References: <44F525F7.2040900@telus.net> Message-ID: <44F5381B.9020003@sonic.net> Alex Schultz wrote: > Lalo Martins wrote: >> Ok, one issue with balance is that, as someone mentioned, most monsters >> either kill you too easily or are killed too easily. I don't have a >> solution for that, only wanted to bring it up so we don't forget it ;-) >> > Well, I'm not really sure, but I think there are two main causes for that: > -The of chance of hitting isn't very random, it's AC and WC, and has > some random variation, however the random variation seems extremely > insignificant compared to AC and WC. > -The speed of hits is very fast, so the random variation of AC vs. WC > gets averaged out very quickly. > We could try to reduce the speed of battle, however that would take ALOT > of tweaking to balance and not frustrate players. Perhaps one option > would be to make it so the random variation of AC vs. WC should last > longer than one hit, and "ebb and flow" a bit. Thinking about this, there are several issues: Even at level 1, a fighter type character will have a weapon speed of ~1.5 and a damage of 10. This means that each time he hits, he will average 8 points of damage kobolds have 2 hp. Pretty much no matter what you have, you will kill them. goblins have 6 hp. More or less same thing. orcs have 4 hp. gnolls have 8 - likely to take two hits. So the issue right there is that these creatures do not have many hp. In terms of their speed, the fastest of that group are orcs with a speed of 0.15 - and orcs do dam 1. gnolls have speed 0.1, dam 4. So at least at low level, that pretty clearly shows that things are geared for monsters being much easier to kill than players. Fixing this is harder. Various thoughts (note that all of these would have to be targeted towards a major release): 1) Reduce weapon speed - in fact, I'd suggest that weapon speed be driven purely by the weapon. This fixes some other problems, namely huge amounts of damage players inflict at high levels - not only do players get very high weapon speed, but they start doing a lot more damage, so effectively, at high level, a character is probably doing 10 times more damage than at low levels. Sure - they should do more, but not sure if 10x is the right answer (and in this case, high level may be ~30) 2) Increase players starting hp - in this way, for these monsters, players could take more hits and still survive. 3) At least at low levels, these monsters may need to be toughened up. In order to not muck too much with spells, perhaps give them a better natural armor so damage players cause is reduced (but I'd probably suggest that hp be increased) 4) Maybe change ac/wc? Right now, it is a d20 system, so any changes are big - a gnoll has AC13 and wc 12 - and in fact, all the monsters above have a 10+ ac, and my first level test character has a wc of 18. The basic hit method is if (ac + d20) > wc. So for the best of the creatures, with and ac of 13, it means that my character hits on a 5+, or 75% of the time. If we change it to a percentile system, that may have an advantage of greater variation, especially if the increase rate is reduced (1%/skill level?) Why that makes a difference is this - if you are in a marginally difficult to hit situation (say need a 15+), it means that having a few objects that give you a wc bonus, or being a few levels higher and having more bonuses could double how often you hit (10+ on a d20) This makes it very difficult to tune - one player could run through, and say 'that was too easy - it needs a higher ac'. Next person finds it impossible, because they just can't hit it. IF instead, it is a 50 vs 70, that is a ~30% difference - a big gap, but certainly a big difference from infrequently hitting to hitting all the time. With all that said, other thoughts: Each level range should undergo testing. Eg, concentrate on testing levels 1-5 (lets say) until all the balance there is worked on, then starting testing 5-10, 10-20, etc. This is because these changes will determine character to some extent - how hard it is to get to level 10 is likely to determine the items the character has at level 10, how many times they have improved stats, etc. I'm not sure that ebbing/flow attacks would really make any difference - it just means that when your hot, you kill a bunch of things quickly, when it goes the other way, you don't kill anything - on average, it doesn't seem like this would make much a difference, it would just seem frustrating to players (I was able to kill these really quickly an hour ago!). >> To encourage player interaction, the game needs to strongly nudge >> characters into having different strengths and weaknesses. This is >> already done to some extents (at low levels) by resistances, natural and >> god-given; of course at higher levels you start collecting artifacts and >> you have any resistances you want. >> > Personally I think we should also consider ways to make different > classes slightly better at different skills. Perhaps a "skill attument" > of sorts. Also class stat bonuses are currently very pointless very quick. I think some of this has been discussed before. Different type of skills, which determine rate of exp. The entire stat thing should probably be rethought - with current stat cap, stat potions become useless. More variation based on the starting stats could make sense. If we go to a 1-100 stat values, and say 20 is the nominal starting stat, with say ?5 based on race, you could make max stat based on 5*modifier. Lets say normal max stat is 50. If your character has a +5 strength bonus, his max strength is 75. If you have a -5 int, max int is 25. OR something like that - that would make a lot bigger difference on those modifiers. Right now, it is typically just ?2 or so, which has that same affect on max stat - it basically means that all the character stats are pretty close, and with magic, they can pretty easily be all the same. (under such a changed stat system, the bonuses most items give would also have to be increased to some extent) > >> An idea I think might be worth experimenting with is cutting the >> contribution that *ALL* skills make to general score. If you have more >> characters running around with level ~10 and their primary skill(s) at ~20 >> that would encourage them to get good at one skill, and therefore to >> interact with other players. >> > IMHO this would be a good idea, though one would have to be careful > about how much one cuts it by. Perhaps how much it cuts it by should > also vary on a curve depending on the level. I'm unsure how this makes any difference, unless you can somehow identify some skill as primary skill. Otherwise, all it seems you are doing is reducing exp gain - if I get 500 exp for literacy vs 500 exp for 1 handed weapons, how does that affect what gets contributed to overall score/exp? If you really want to change this, one could just remove skillscrolls from the game - what you start with is all you get. There are certainly issues that each character is basically standalone and don't need the others - I'm not sure if that can really be forced upon players. AT some level, that has to be allowed - if no one is on, I need some way to be able to heal myself, identify items, etc. Slowly combat down a bit may help out a bit - right now, most things are so fast that it can be really difficult for players to coordinate - if I kill that creature in 5 seconds, it becomes difficult to have the archer player get behind it an pelt it with arrows, etc (by the time the archer gets there, it is probably dead) > >> Finally, the easy answer to the curve issue is tweaking the exp_table >> carefully. I want to start a mini-project, with the goal of tuning up a >> "perfect" (heh) exp_table. > Well, I don't think tweaking the exp_table is the 'silver bullet' that > will fix it the whole curve issue, however I feel it is an important > step towards fixing it. I would say that it probably needs to figured out what are the problems that need to get fixed first, or what all will be fixed/changed. If combat is slowed down, you probably want to wait on adjusting the exp table until that is done - simply because you might find that with slower combats, characters get exp slower, etc. One other thought on this - the spells should be rebalanced/redistributed. IIRC, crossfire originally only had 30 levels. This is why for the most part, the top spell level is about 20. With 100 levels, this doesn't make a lot of sense. Rebalancing spells is a bit of work (as if you increase the level you get the spell, you probably need to increase damage a bit, etc). But back in terms with cooperative play in mind, we may want to also focus more on spells which work good in groups. In particular, things like cones and exploding ball spells probably are not good - bullets, bolts, summoned creatures, healing, protective, make sense From lalo.martins at gmail.com Wed Aug 30 02:30:42 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 30 Aug 2006 15:30:42 +0800 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas References: <44F525F7.2040900@telus.net> <44F5381B.9020003@sonic.net> Message-ID: On Wed, 30 Aug 2006 00:02:51 -0700, Mark Wedel wrote: > Alex Schultz wrote: >>> An idea I think might be worth experimenting with is cutting the >>> contribution that *ALL* skills make to general score. If you have more >>> characters running around with level ~10 and their primary skill(s) at ~20 >>> that would encourage them to get good at one skill, and therefore to >>> interact with other players. > > Otherwise, all it seems you are doing is reducing exp gain - if I get 500 exp > for literacy vs 500 exp for 1 handed weapons, how does that affect what gets > contributed to overall score/exp? Your reply applies more to Alex' message than mine :-) The idea of cutting contribution (which is already supported by the skill system -- I believe there are already some skills that contribute less than 100% exp) is to encourage characters to have a few skills at levels much higher than their overall level. As in my example above, level ~10 character with one or three skills at ~20. Of course that ties in closely with the exp_table... with an exponential table, even a skill that contributes a very small portion can't be on a level much higher than the overall, or it will begin pulling it up. 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 alex_sch at telus.net Wed Aug 30 10:47:50 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 30 Aug 2006 09:47:50 -0600 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas In-Reply-To: <44F5381B.9020003@sonic.net> References: <44F525F7.2040900@telus.net> <44F5381B.9020003@sonic.net> Message-ID: <44F5B326.1020105@telus.net> Mark Wedel wrote: > 1) Reduce weapon speed - in fact, I'd suggest that weapon speed be driven purely > by the weapon. This fixes some other problems, namely huge amounts of damage > players inflict at high levels - not only do players get very high weapon speed, > but they start doing a lot more damage, so effectively, at high level, a > character is probably doing 10 times more damage than at low levels. Sure - > they should do more, but not sure if 10x is the right answer (and in this case, > high level may be ~30) > Well, I'm not sure "huge amounts of damage players inflict at high levels" is really so much of an issue, plus there are numerous monsters that require such "huge amounts of damage" to be able to kill. (Perhaps should those monsters have less regen/hp?) Also, I'm not so keen on having weapon speed driven purely by the weapon. It seems to me that the dexterity should have an affect on how fast one could attack with a dagger, and strength should have an affect on how fast one could attack with a longsword. That said, I do think the weapon itself should affect it's speed more than than other things, unlike now where the player primarily affects it. > If we change it to a percentile system, that may have an advantage of greater > variation, especially if the increase rate is reduced (1%/skill level?) Why > that makes a difference is this - if you are in a marginally difficult to hit > situation (say need a 15+), it means that having a few objects that give you a > wc bonus, or being a few levels higher and having more bonuses could double how > often you hit (10+ on a d20) > To me the range seems good at low levels currently, however I would say that the range needs to be greater at high levels, so I think a percentile system, or perhaps something a little fancier with a similar affect, would be positive. > I'm not sure that ebbing/flow attacks would really make any difference - it > just means that when your hot, you kill a bunch of things quickly, when it goes > the other way, you don't kill anything - on average, it doesn't seem like this > would make much a difference, it would just seem frustrating to players (I was > able to kill these really quickly an hour ago!). > Well, I don't think it would really be frustrating to players, as I was thinking on the smaller scale, ebbing/flowing over the course of something like 10 attacks. This wouldn't fix the kill-low-level-things-in-one-hit issue, however it would have a similar affect to reducing combat speed because it make it so the ac/wc rolls don't average out over time so much, which is part of the > One other thought on this - the spells should be rebalanced/redistributed. > > IIRC, crossfire originally only had 30 levels. This is why for the most part, > the top spell level is about 20. > > With 100 levels, this doesn't make a lot of sense. Rebalancing spells is a > bit of work (as if you increase the level you get the spell, you probably need > to increase damage a bit, etc). > IMHO adding more spells is also needed for rebalancing spells. With current spells stretched over a range of 100 or even 70 or so levels, gaining a couple levels in spellcasting may seem too boring to the player, so adding more spells seems to make sense. Also, meteor swarm is currently level 12, the quest to do it on the other hand is only completable above level 50 or so, but certainly doesn't take level 100 to do, so it makes sense to make a level 40-60 spells or so, but that leads to the question, if meteor swarm is moved to there, what would be put above it? > But back in terms with cooperative play in mind, we may want to also focus > more on spells which work good in groups. In particular, things like cones and > exploding ball spells probably are not good - bullets, bolts, summoned > creatures, healing, protective, make sense Also, making use of some of the 'party spells' code there is could help. Alex Schultz From lalo.martins at gmail.com Wed Aug 30 13:06:43 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 31 Aug 2006 02:06:43 +0800 Subject: [crossfire] Splitting "spellbook" Message-ID: (Very simple change, archetypes-only) Currently we have "prayerbook" and "spellbook", a throwback to the old magic system. But then there are "sorcerer's spellbook", "evoker's spellbook" etc, which makes it harder to see the title in your inventory or the "look" window. It's also slightly less cool. I'm proposing changing them to new names: Sorcery -> Grimoire Evocation -> Spellbook Summoning -> Codex Pyromancy -> Flametome (unless someone comes up with a better one) I know there are books titled "codex of FOO" in the game, but I don't think that will be a problem, as they have different faces. As the change is very simple, I'll commit it myself if/when people agree with the idea (and the names). 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 kbulgrien at worldnet.att.net Tue Aug 29 23:18:21 2006 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 29 Aug 2006 23:18:21 -0500 Subject: [crossfire] Bogus XP gains? Message-ID: For some time now, I have noticed that the XP loss when you die is no big deal because after leveling a few skills you almost always get back your lost XP. I thought this was a "feature", but now I wonder if there is a bug somewhere in CVS. Tonight I was messing around in the trio of caves to the east of the Tower of the Stars. They are low level caves. Due to several server crashes, I never got deeper than two or three levels in one of the caves. These are low-level caves. At the end of the evening, my score change is 446 7139867 Rayvin the Scripter left the game on map apartments [133][73][57] 420 8723235 Rayvin the Scripter left the game on map apartments [127][81][61] There is no way that I gained this XP tonight, and, I got two quantum leaps in XP, so my working theory that you just got back XP you lost when you died seems flawed. Is there some kind of mechanism to give back XP when you raise stats that where hosed by death? The XP jumps all seem to occur after leveling a skill. I mean, it is cool to be up at this level and all, but it feels like I didn't earn it. Also, maybe my thinking is off, but I was under the impression that your score was the sum of your skill XPs. My score is 8723235, but when I add up my skill XP, I only get 5067405. I checked a character on another server, and the matches the sum of the skills experience. Does anyone else see this odd behavior and should it be put into a tracker, or is there a simple explanation? -- Kevin R. Bulgrien From nicolas.weeger at laposte.net Wed Aug 30 17:26:10 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Thu, 31 Aug 2006 00:26:10 +0200 Subject: [crossfire] Splitting "spellbook" In-Reply-To: References: Message-ID: <200608310026.10932.nicolas.weeger@laposte.net> > Currently we have "prayerbook" and "spellbook", a throwback to the old > magic system. But then there are "sorcerer's spellbook", "evoker's > spellbook" etc, which makes it harder to see the title in your inventory > or the "look" window. It's also slightly less cool. > > I'm proposing changing them to new names: > > Sorcery -> Grimoire > Evocation -> Spellbook > Summoning -> Codex > Pyromancy -> Flametome (unless someone comes up with a better one) Sounds nice to me :) Nicolas From fuchs.andy at gmail.com Wed Aug 30 18:16:13 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Wed, 30 Aug 2006 19:16:13 -0400 Subject: [crossfire] Fun proof of concept In-Reply-To: References: <200608262256.27264.nicolas.weeger@laposte.net> Message-ID: On 8/28/06, Robert Brockway wrote: > On Sat, 26 Aug 2006, Nicolas Weeger (Laposte) wrote: > > Hello. > > > > For the fun I made a small proof of concept in Python :) > > Sending it here in case someone wants to use that for something else. > > > > Basically, if the player moves 5 squares to the top of the detector, then 5 > > right, then 5 down, then 5 bottom, she gets some platinum coins. > > You must move in a 2 (game) minutes delay before each position, else it > > resets. > > > > > > *thinks of fun things like 3 players doing complex moves to activate > > something ;p > > Hehehe - we could make them do coordinated dance routines to win the map > ;) > > Or how about an "olympics" map where the best coordinated team get the > gold medal :) I'm thinking that a slightly modified version of this script could be used to replace some things in pupland (statue by the castle, etc). -- Andrew Fuchs From mwedel at sonic.net Thu Aug 31 01:58:48 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 30 Aug 2006 23:58:48 -0700 Subject: [crossfire] Bogus XP gains? In-Reply-To: References: Message-ID: <44F688A8.90205@sonic.net> On servers running recent code, there is no rule that your total exp (score) equal the sum of all your skills. That was an intentional change - it allows one to get lots of skill exp without having lots of overall exp, or vice versa. Likewise, the exp loss is complex - there are various caps, limit number of lost levels, etc. So the amount of total exp you lose can differ than the total you lose from all the different skills. From fuchs.andy at gmail.com Thu Aug 31 18:59:33 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Thu, 31 Aug 2006 19:59:33 -0400 Subject: [crossfire] Splitting "spellbook" In-Reply-To: <200608310026.10932.nicolas.weeger@laposte.net> References: <200608310026.10932.nicolas.weeger@laposte.net> Message-ID: On 8/30/06, Nicolas Weeger (Laposte) wrote: > > Currently we have "prayerbook" and "spellbook", a throwback to the old > > magic system. But then there are "sorcerer's spellbook", "evoker's > > spellbook" etc, which makes it harder to see the title in your inventory > > or the "look" window. It's also slightly less cool. > > > > I'm proposing changing them to new names: > > > > Sorcery -> Grimoire > > Evocation -> Spellbook > > Summoning -> Codex > > Pyromancy -> Flametome (unless someone comes up with a better one) > > Sounds nice to me :) Fine here too, but it may mess up some scripts that some people might have. -- Andrew Fuchs From lalo.martins at gmail.com Thu Aug 31 23:37:36 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri, 01 Sep 2006 12:37:36 +0800 Subject: [crossfire] A polite request/reminder Message-ID: Alex has just found the explanation and fix for a particularly elusive/annoying bug on a webpage describing a server (that will remain unnamed). Crossfire is a very open project, which gladly accepts contribution, and does so on a more or less regular basis. So I'd remind you people that this situation should never happen. If you find a bug, please report it on the sourceforge tracker. If you find a bug *AND* the corresponding fix, even more true, as that will benefit all players everywhere. If you think it needs discussion, make a post to the mailing list instead or bring it up on IRC. What you shouldn't do is patch your own server and don't tell anyone about it. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/