From tchize at myrealbox.com Fri Sep 1 03:20:03 2006 From: tchize at myrealbox.com (Tchize) Date: Fri, 01 Sep 2006 10:20:03 +0200 Subject: [crossfire] Splitting "spellbook" In-Reply-To: References: <200608310026.10932.nicolas.weeger@laposte.net> Message-ID: <44F7ED33.7080901@myrealbox.com> Scripts should not be build based on object name but on arch id (archname) Andrew Fuchs a ?crit : > 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. > > From lalo.martins at gmail.com Fri Sep 1 06:39:41 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri, 01 Sep 2006 19:39:41 +0800 Subject: [crossfire] Splitting "spellbook" References: Message-ID: committed; on my test server it didn't seem to break anything (and it looks nice, plus it's much easier to browse a magic shop now) 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 Fri Sep 1 08:35:17 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri, 01 Sep 2006 21:35:17 +0800 Subject: [crossfire] crossfire source code control systems References: <44DD8863.4000401@sonic.net> Message-ID: In doing the homework for my vote, I spent my free time in the the last two days learning mercurial. I'm quite impressed by it in some accounts, but I guess I'm sticking to bzr. Here are my findings, if anyone's interested. Main shortcomings of bazaar - Slow over network. Can be solved as a temporary measure by a plugin that I can write in about 10 hours and I plan to do so tomorrow. - Slow locally. Can't be solved by plugins. Main shortcomings of mercurial - Poor support for file renaming and moving; this mean merging my pupland work wouldn't be any bit less painful on hg than cvs. Can't be solved by extensions. - Uses three-way merge, as opposed to bzr's weave merge ("codeville" style merge). This means we'd spend more time resolving merges manually. Can't be solved by extensions (it seems). - Local branches don't share storage. Since hg best practises encourage you to keep many branches around, that means you'll soon have a few gigabytes of arches and maps storage lying around. Can't be solved by extensions (it seems). The bottom line here is that both bzr shortcomings are being worked on; from the hg shortcomings, only one is recognised as such, and work on it is deferred till after 1.0. Also, there are at least two approaches for a temporary solution to one bzr problem, and the other one becomes much less troublesome if you use shared storage (bzr help init-repo). So while I think mercurial is a solid option and will be getting my second choice, I'm still sticking to bzr as first choice. As an exercise, I'll try one of the approaches for a fast-network-transaction plugin (I tried the other one earlier this week and it turned out more complicated than I thought). I'll let you know how it turns out. 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 Fri Sep 1 11:44:25 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 01 Sep 2006 10:44:25 -0600 Subject: [crossfire] Splitting "spellbook" In-Reply-To: <44F7ED33.7080901@myrealbox.com> References: <200608310026.10932.nicolas.weeger@laposte.net> <44F7ED33.7080901@myrealbox.com> Message-ID: <44F86369.6070609@telus.net> Tchize wrote: > Scripts should not be build based on object name but on arch id (archname) I'm pretty sure he meant client-side scripting, not server-side. I don't think there's a way to do it by arch id clientside ;) Alex Schultz From alex_sch at telus.net Fri Sep 1 11:58:38 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 01 Sep 2006 10:58:38 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: References: <44DD8863.4000401@sonic.net> Message-ID: <44F866BE.6020308@telus.net> Lalo Martins wrote: > - Poor support for file renaming and moving; this mean merging my pupland > work wouldn't be any bit less painful on hg than cvs. Can't be solved by > extensions. > Well, it would remember the history, which is a step up from cvs, but indeed it doesn't deal with merging nicely with that. Also in theory, could be solved by an extension, because despite merges not following renames, it does track them, and an extension could be written to look at all renamed files, and pull/merge changes from the original files in another repository, not a nice solution, but could be done as an extension in theory. > - Uses three-way merge, as opposed to bzr's weave merge ("codeville" > style merge). This means we'd spend more time resolving merges manually. > Can't be solved by extensions (it seems). > I'm not certain, but I'm betting it would be possible to write an extension for a "codeville" style merge. Manually resolving merges is rather easy IMHO though when using a nice tool such as meld which works well with hg. > - Local branches don't share storage. Since hg best practises encourage > you to keep many branches around, that means you'll soon have a few > gigabytes of arches and maps storage lying around. Can't be solved by > extensions (it seems). > Actually from what I have heard, hg uses hardlinks to save disk space on local branches where available, haven't verified this myself. (It even apparently supports using hardlinks on windows if the windows system is using ntfs). I think the hardlinking is what makes a "hg clone" localy, take 5 seconds, as opposed the "hg init && hg pull" locally taking a minute. (See http://wiki.metalforge.net/doku.php/user:rednaxela:scms for my timing of those two methods of locally coping in hg) Alex Schultz From lalo.martins at gmail.com Fri Sep 1 16:06:56 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 02 Sep 2006 05:06:56 +0800 Subject: [crossfire] crossfire source code control systems References: <44DD8863.4000401@sonic.net> <44F866BE.6020308@telus.net> Message-ID: Sorry if I sound too derisive of hg; it's a great system. I'm just too drunk to be nice. On Fri, 01 Sep 2006 10:58:38 -0600, Alex Schultz wrote: > Lalo Martins wrote: >> - Poor support for file renaming and moving; this mean merging my pupland >> work wouldn't be any bit less painful on hg than cvs. Can't be solved by >> extensions. >> > Well, it would remember the history, which is a step up from cvs, but > indeed it doesn't deal with merging nicely with that. Also in theory, > could be solved by an extension, because despite merges not following > renames, it does track them, and an extension could be written to look > at all renamed files, and pull/merge changes from the original files in > another repository, not a nice solution, but could be done as an > extension in theory. That's a good part of the way from writing your own revision control system... yeah it might be possible, but from what I've seen of mercurial's extension API, it's not the kind of thing extensions are meant for; it would involve quite a bit of dirty monkey-patching. >> - Local branches don't share storage. Since hg best practises encourage >> you to keep many branches around, that means you'll soon have a few >> gigabytes of arches and maps storage lying around. Can't be solved by >> extensions (it seems). >> > Actually from what I have heard, hg uses hardlinks to save disk space on > local branches where available, haven't verified this myself. (It even > apparently supports using hardlinks on windows if the windows system is > using ntfs). I think the hardlinking is what makes a "hg clone" localy, > take 5 seconds, as opposed the "hg init && hg pull" locally taking a > minute. (See http://wiki.metalforge.net/doku.php/user:rednaxela:scms for > my timing of those two methods of locally coping in hg) Up to a few revisions ago, you were encouraged to use hard links in bzr, and there are some serious problems with that. It's a bad hack. 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 Fri Sep 1 16:55:39 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 01 Sep 2006 15:55:39 -0600 Subject: [crossfire] crossfire source code control systems In-Reply-To: References: <44DD8863.4000401@sonic.net> <44F866BE.6020308@telus.net> Message-ID: <44F8AC5B.1010501@telus.net> Lalo Martins wrote: > Sorry if I sound too derisive of hg; it's a great system. I'm just too > drunk to be nice. > > On Fri, 01 Sep 2006 10:58:38 -0600, Alex Schultz wrote: > >> Well, it would remember the history, which is a step up from cvs, but >> indeed it doesn't deal with merging nicely with that. Also in theory, >> could be solved by an extension, because despite merges not following >> renames, it does track them, and an extension could be written to look >> at all renamed files, and pull/merge changes from the original files in >> another repository, not a nice solution, but could be done as an >> extension in theory. >> > > That's a good part of the way from writing your own revision control > system... yeah it might be possible, but from what I've seen of > mercurial's extension API, it's not the kind of thing extensions are meant > for; it would involve quite a bit of dirty monkey-patching. > Well, what I mean, is an extension could implement a separate command that essentially means "pull&merge changes in renamed files" reasonably trivially. Also, Mercurial doesn't use a separate extension API for most things, but one is encouraged to call whatever functions in the Mercurial code one needs to provided it's safe. I've looked at Mercurial internals a bit, and making an extension to that would actually rather simple and fairly clean, but yes, again, it wouldn't really be a nice solution, but I think would be rather easy to implement. >> Actually from what I have heard, hg uses hardlinks to save disk space on >> local branches where available, haven't verified this myself. (It even >> apparently supports using hardlinks on windows if the windows system is >> using ntfs). I think the hardlinking is what makes a "hg clone" localy, >> take 5 seconds, as opposed the "hg init && hg pull" locally taking a >> minute. (See http://wiki.metalforge.net/doku.php/user:rednaxela:scms for >> my timing of those two methods of locally coping in hg) >> > > Up to a few revisions ago, you were encouraged to use hard links in bzr, > and there are some serious problems with that. It's a bad hack. By the sounds of it, bzr used to encourage manually hard linking, which yes is a bad hack, but the way Mercurial does hard linking internally, it selectively hard links what files in the history can be safely hardlinked, and understands perfectly well when it should break the hard link. I don't really see anything wrong or hackish about the way Mercurial in particular handles it's hardlinks. I can see "oh, just hardlink your repository" as hackish for sure, but Mercurial handles hardlinking internally and does things more intelligently and safely than just hardlinking the whole repository. Alex Schultz From raphael at gimp.org Fri Sep 1 17:21:45 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Sat, 2 Sep 2006 00:21:45 +0200 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas In-Reply-To: References: Message-ID: <20060902002145.04c9dc37.raphael@gimp.org> On Wed, 30 Aug 2006 12:53:40 +0800, Lalo Martins wrote: > 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. Looking at the current experience tables shows that going from one level to the next one requires doubling your exp points for each level until you reach level 10. Then the ratio between successive levels drops very quickly: 1.13 for level 20, 1.06 for level 30, ... and becomes as low as 1.01 for levels above 90. This explains why one can reach the "demigod" status without too much trouble after reaching level 15-20 (the exact level depends on your skills, maps, etc.). > 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. In addition, the steeper slope for the lower levels can discourage beginners from playing crossfire. The game gets significantly easier after the first dozen levels, both because your character can explore more maps without fearing instant death and because it gets easier and easier to gain levels due to the ever diminishing ratio between them. People who have never played crossfire before can be discouraged by the fact that the first levels are rather hard for a beginner. > 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. As others have pointed out, it would be difficult to tune the exp table before fixing some other issues. But anyway, I am not sure that setting up a test server would help. Using experienced players may not be the best test because these players tend to know the best ways to gain exp in various skills. Beginners make more mistakes and have a harder time gaining the first few levels. So although running a test with experienced players could provide useful data for levels above 15 or 20, I don't think that this would really improve the balance for the lower levels (which are considered too hard by some beginners). But even for the higher levels, the test may not be very useful if there are only a few players and if they know that they are in a test environment. Instead of setting up a test server, I think that it would be much more interesting to start by monitoring what happens on the current servers. This would require adding a bit more logging information to the server code, but this would have significant benefits: a larger selection of players (from beginners to demigods) and a dataset collected from real games instead of from games in which people know that they are playing on a test server. Imagine this: the next release of crossfire (1.9.2) could include a new logging option (enabled by default) that records the following information: - a hash of the player name (to limit the privacy issues) - absolute timestamps whenever a player logs in or out (so that it is possible to know the total playing time in real world units) - also with timestamps, any significant gain or loss of experience in any skill (new level in a skill, death) - each log message would include the total exp of the player and the full list of skills and their exp/level > - ideally, a copy of MF's exp_table, which many people seem to regard as > the best table out there, to start from You can find this table in "lib/exp_table". It contains three tables: A (old), B (classic) and C (hard). Metalforge uses table C. You can compare these values with http://crossfire.real-time.com/exp.html and you will see that they are identical. As an exercise in trying to improve the exp_table and highlight the problems of the current tables, I have created a new wiki page: http://wiki.metalforge.net/doku.php/dev_todo:exp_table It contains graphs comparing the current tables with a proposal based on a smoother curve. I played a bit with Gnumeric in order to have a curve that makes it easier to gain levels at the beginning but keeps a constant ratio for the higher levels (so after a while, it gets more difficult than the current tables). In case anyone is interested, I can also provide the *.gnumeric file. Playing with this curve is an interesting exercise but it is a bit like putting the cart before the horse: before making any adjustments, it would be better to have real measurments of how much time an average player needs to get from one level to the next. We all know that the current curves are not ideal because they are (much) too easy for the higher levels and (a bit) too hard for the lower ones, but we do not know by how much exactly. > - 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 Does this include the time needed to regain some levels that were lost after a sudden death? I think that this time must be taken into account. If a player dies and loses one or two levels every time he/she gains three levels, then this makes the more than twice as long (this is especially true for beginners). In my opinion, the ideal curve would correspond to about 1 hour per level up to level 20 or so, including the time needed to recover after multiple deaths. And that should be evaluated for an average player (not an expert, not an absolute beginner). I think that the best way to fine tune the curve would be to start by collecting enough data from the current active servers, like I proposed above (the logs could be sent by the server admins or could even be included in an extended metaserver protocol). This would give us a much better picture of how experience is gained or lost by the average player. Even if the mapping between experience points and levels may change in the future when the exp_table is adjusted, having some reliable data would help a lot. Until we have this, we can keep on talking about rough guesses based on our personal experiences, but will still be poking in the dark as long as we do not have any real data. -Raphael From raphael at gimp.org Fri Sep 1 17:53:30 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Sat, 2 Sep 2006 00:53:30 +0200 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas In-Reply-To: References: <44F525F7.2040900@telus.net> <44F5381B.9020003@sonic.net> Message-ID: <20060902005330.4d9da196.raphael@gimp.org> On Wed, 30 Aug 2006 15:30:42 +0800, Lalo Martins wrote: > 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. This problem could be solved by using different curves for different skills. When I consider the characters that I have played and compare the levels that I have reached in each skill, I see that I can group the skills in several categories: - "combat skills": one/two handed weapons, missile weapons, punching/karate/clawing, evocation, praying, pyromancy, sorcery, summoning, ... - "mental/craft skills": bargaining, lockpicking, find/disarm traps, sense curse/magic, alchemy, bowyer, jeweler, literacy, ... - "other skills": climbing, jumping, ... Usually, I can reach level 100+ in several of the "combat skills" because these skills collect the exp from monsters. But for the "mental/craft skills", I am happy when I can reach level 20 (if I exclude the alchemy cheats). I don't know if it is possible to gain exp in the "other skills" so I will ignore these for the moment. The current exp_table (with its flaws) was obviously designed for the "combat skills" and for the total experience. But it does not work as well for the "mental/craft skills". Awarding more exp points for using these skills successfully would not be a good solution because these should not contribute as much to the total exp. But on the other hand, it would be nice if it was possible to reach level 100+ in literacy or other skills. So here is a proposal: use different curves for the "combat skills" and for the "mental/craft skills". The "combat skills" and the total exp would follow the current exp_table or an improved version of it (see http://wiki.metalforge.net/doku.php/dev_todo:exp_table), while the "mental/craft skills" would follow a similar curve in which the current range 1-20 (approx.) would be remapped to 1-100. For example, having 7500000 exp points in the woodsman skill would bring the player to level 100 in that skill instead of level 20 as in the current table. But this would still mean only level 20 for the total exp. The adjuted levels for the "mental/craft skills" would look better and would be more comparable to the "combat" skills, while the number of exp points and their contribution to the overall level would be smaller. -Rapha?l From alex_sch at telus.net Fri Sep 1 18:23:19 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 01 Sep 2006 17:23:19 -0600 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas In-Reply-To: <20060902005330.4d9da196.raphael@gimp.org> References: <44F525F7.2040900@telus.net> <44F5381B.9020003@sonic.net> <20060902005330.4d9da196.raphael@gimp.org> Message-ID: <44F8C0E7.6010705@telus.net> Rapha?l Quinet wrote: > This problem could be solved by using different curves for different > skills. > > When I consider the characters that I have played and compare the > levels that I have reached in each skill, I see that I can group the > skills in several categories: > - "combat skills": one/two handed weapons, missile weapons, > punching/karate/clawing, evocation, praying, pyromancy, > sorcery, summoning, ... > - "mental/craft skills": bargaining, lockpicking, find/disarm traps, > sense curse/magic, alchemy, bowyer, jeweler, literacy, ... > - "other skills": climbing, jumping, ... > > Usually, I can reach level 100+ in several of the "combat skills" > because these skills collect the exp from monsters. But for the > "mental/craft skills", I am happy when I can reach level 20 (if I > exclude the alchemy cheats). I don't know if it is possible to gain > exp in the "other skills" so I will ignore these for the moment. > Actually, I'm also thinking that tweaking the overall level exp curve as a separate one from combat or mental/craft might be a good idea. I think that proper adjustment of that might help to encourage people to specialize a little bit which IMHO would be a good thing, similar in effect to Lalo's suggestion of skills contributing less than 100% exp to overall exp. Alex Schultz From wim-cf at villerius.nl Sat Sep 2 04:50:06 2006 From: wim-cf at villerius.nl (Wim Villerius) Date: Sat, 02 Sep 2006 11:50:06 +0200 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas In-Reply-To: References: Message-ID: <1157190606.9633.49.camel@localhost.localdomain> I'd like to propose a different fix, a fix that might even allow a linear exp. curve. Just some quick thoughts, perhaps useful? The main problem i've observed when playing was that once you can kill a certain mob, you can continue killing it until you 'die' out of boredom. That means: hit - say - lvl 40 and start killing demon lords until you're lvl 110. A method that works perfectly. (and in case you get bored on demons, go dragons or angels, they work more or less the same) My suggestion is to adjust the amount of exp gained by killing a certain mob by at least hte following factors: 1) the number of that mob you have already killed 2) mob lvl / player lvl in that skill That would make a lvl 100 player that is about to kill his 10,007th demon lord gain about no experiece, while a lvl 40 player that kills his first will receive a huge exp boost. Fictive numbers: mob X gives 100000 exp and is lvl 60 Player A is lvl 100 in his one handed skill and has killed 1000 X before For another kill he'll get 100000 * 60/100 * f(1000) exp (where f(1000) is a pretty small number, maybe 10% or so. Player B is lvl 40 in his one handed skill and has never killed X before. His first kill will give him: 100000 * 60/40 * f(0), where f(0) is a big number, maybe even 10. This 1) stops players reaching demigod status fast - it will take them long, and a lot of different mobs as well. No more efficient TC-training 2) doesn't necessarily recuire a new exp curve 3) most important: makes sense. killing ants at lvl 110 should not give exp. that's rediculous :) Unfortunately, it requires the server to log the number of kills a player makes. And also, what if a player dies? does the number of kills stay the same? Makes lvling back harder. Mmm, perhaps reduce death penalty if gaining exp gets harder? Now aim your flamethrowers... ;-) On Wed, 2006-08-30 at 12:53 +0800, 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 ;-) > > 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/ > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From nicolas.weeger at laposte.net Sat Sep 2 08:54:37 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 2 Sep 2006 15:54:37 +0200 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas In-Reply-To: <1157190606.9633.49.camel@localhost.localdomain> References: <1157190606.9633.49.camel@localhost.localdomain> Message-ID: <200609021554.37327.nicolas.weeger@laposte.net> Hello. > I'd like to propose a different fix, a fix that might even allow a > linear exp. curve. Just some quick thoughts, perhaps useful? Sounds like an interesting idea. > Unfortunately, it requires the server to log the number of kills a > player makes. And also, what if a player dies? does the number of kills > stay the same? Makes lvling back harder. Mmm, perhaps reduce death > penalty if gaining exp gets harder? IMO, that's something easy to implement through a plugin: hook to the KILL event, record the kill for the player and adjust monster's exp based on different criteria. It also would mean it's easier to turn on/off :) Nicolas From nicolas.weeger at laposte.net Sat Sep 2 10:24:54 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 2 Sep 2006 17:24:54 +0200 Subject: [crossfire] Changes to swamp behaviour Message-ID: <200609021724.54932.nicolas.weeger@laposte.net> Hello. I implemented the feature request #1539125 by Andreas Kirschbaum. Swamps will now be fatal even to players having the woodsman skill. This skill will only means you'll survive on the swamp longer :) Nicolas From nicolas.weeger at laposte.net Sat Sep 2 11:04:58 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 2 Sep 2006 18:04:58 +0200 Subject: [crossfire] Plugin system extension Message-ID: <200609021804.58789.nicolas.weeger@laposte.net> Hello. I'd like to extend the plugin system to add new skills, and/or override the skill use. It would imo enable to do fun things, and make the server more flexible. I see that system working like that: * the items giving that skill are created, "inert" (with a type of 0 for instance) * plugin asks to register its own skill, and gets a unique skill subtype * plugin can alternatively declare handling one skill subtype (only "core" ones) * plugin parses archetypes and alters skill-giving items to use that subtype (and set the SKILL type) Except for "skill overriding", this can only be done at server init time (can't easily alter archetypes once objects have this very archetype, would cause a mess for loading/saving). Of course, the archetypes themselves are required to be part of the server anyway, for loading/saving purposes. For instance, the building system I made some time ago could be reimplemented using a real building skill (use_skill building, use_skill cooking, and such ;p), requiring tools to work, and so on. As it is not part of the core imo (even if it's fun ;p), a plugin would be the best way to do that. Nicolas From mwedel at sonic.net Sat Sep 2 16:47:34 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 02 Sep 2006 14:47:34 -0700 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas In-Reply-To: <20060902005330.4d9da196.raphael@gimp.org> References: <44F525F7.2040900@telus.net> <44F5381B.9020003@sonic.net> <20060902005330.4d9da196.raphael@gimp.org> Message-ID: <44F9FBF6.7060906@sonic.net> Rapha?l Quinet wrote: > The current exp_table (with its flaws) was obviously designed for the > "combat skills" and for the total experience. But it does not work as > well for the "mental/craft skills". Awarding more exp points for > using these skills successfully would not be a good solution because > these should not contribute as much to the total exp. But on the > other hand, it would be nice if it was possible to reach level 100+ in > literacy or other skills. I think there is more an issue of just monsters - for the combat skills, you can basically find tougher and tougher monsters, that give lots more exp. For most of the mental skills, the complication of things gets cut off. Readables above level 10 are pretty darn rare. I'm not sure about find/detect traps, and the item identification skills are another issue all together. I don't think multiple exp tables is really the way to go. Why? Because I think you may really need 6-7 tables for things to be fair for all the skills. And given that the exp table is currently a config file that can be customized, having lots of tables one has to adjust would seem to be really complicated for servers. I do think the correct approach is this: 1) re-adjust exp rewards for non combat skills so that level can go up in a reasonable fashion. For readables, it could mean that 10 readables at your current skill level amounts to a level for example, for lockpick, 30 doors, etc. 2) Adjust the non combat skills so they contribute less exp to the total - that can be done right now - make it 20% or something. However, this second point can be an issue - lots of people say that it should be reasonable to play non combat characters. Overall level doesn't mean a whole bunch - it is just hp. A level 100 character with no combat skills will still fair poorly in battles ` From mwedel at sonic.net Sat Sep 2 17:03:15 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 02 Sep 2006 15:03:15 -0700 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas In-Reply-To: <1157190606.9633.49.camel@localhost.localdomain> References: <1157190606.9633.49.camel@localhost.localdomain> Message-ID: <44F9FFA3.1040700@sonic.net> Wim Villerius wrote: > The main problem i've observed when playing was that once you can kill a > certain mob, you can continue killing it until you 'die' out of boredom. > That means: hit - say - lvl 40 and start killing demon lords until > you're lvl 110. A method that works perfectly. (and in case you get > bored on demons, go dragons or angels, they work more or less the same) > > My suggestion is to adjust the amount of exp gained by killing a certain > mob by at least hte following factors: > 1) the number of that mob you have already killed > 2) mob lvl / player lvl in that skill One problem here is that at higher levels specifically, the number of reasonable monsters go down. How many monsters are there really for characters at level 50+ to fight? If there are not a lot, you're effectively limiting exp gain because there is nothing left to kill. I'm not sure if that is a really good approach. There used to be code that would adjust exp based on creature level and player level. But that had several problems and was removed - notably it becomes really difficult to try to find correct exp values when you have many variables (exp table increases at some rate, amount you get for killing it at a different rate, etc). And then you start getting abuses, like I'll weaken it with my highest level skill, then kill it with a lower level skill to get more exp, etc. IMO, there are basically 2 ways to do this: 1) Make the exp table harder at higher levels - in this way, at level 60, you need to kill more of the creatures than at level 40 to gain a level. We don't need to further adjust that by level comparison - the exp table itself should be adjusted. 2) Make the exp table linear, make most monsters the same exp, but adjust reward based on level difference. The problem is that if a character, especially at lower levels, is able to kill a higher level creature, they get lots more exp (15/10 = 1.5 reward, where as 70/60 = 1.17 reward). With certain items/spells that are really effective against certain creatures, this means fast exp gain. It seems like the goal here is to make it so you have to kill more monsters at higher level. That is currently the case with the exp table, but it sounds like the exp table needs to be re-adjusted. > This > 1) stops players reaching demigod status fast - it will take them long, > and a lot of different mobs as well. No more efficient TC-training > 2) doesn't necessarily recuire a new exp curve > 3) most important: makes sense. killing ants at lvl 110 should not give > exp. that's rediculous :) Point #3 isn't much a point. Sure, the player gets some exp when killing an ant, but at level 100, probably needs to kill a million ants to gain a level - if he wants to do so, fine. I think one of the general problems is things like the training center and random dungeons (and even non random dungeons) where monsters are just stacked high. The fact players can basically find monsters to fight as fast as they can reasonable fight them is a bit of an issue. In the vast majority of games, that really isn't the case - there is some amount of exploring to do, etc. Even in nethack, which hack and slash, most rooms only had a single monster and only half a dozen rooms per level - you probably are spending as much time moving room to room as you are fighting. Recording number of kills of each monster the player does is interesting, if nothing else than for record keeping purposes. I think it was ularn which would provide stats of what you kill, as well as more info about the monster itself the more times you kill it. But as said, I'm not sure that adjusting exp is really the way to go. And the problem with all formulas is finding the right one. The current exp tables were not designed to be bad tables - the best table at the time was done. The same is true with formulas - while putting them out here sounds good, it may be after months of testing, we find the formula in fact isn't good (too easy/too hard). I'm most inclined to do exp table adjustments, because that is the easiest thing to adjust. If during play testing you find 'I got to level 28 way too easily - it should take 3 times longer', it is pretty clear that the exp table gets adjusted upwards accordingly by a factor of 3. From raphael at gimp.org Sat Sep 2 17:57:16 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Sun, 3 Sep 2006 00:57:16 +0200 Subject: [crossfire] Progressive exp table and removal of a bad hack: death_penalty_levels Message-ID: <20060903005716.716b5fb9.raphael@gimp.org> Note: this mail is a bit long. If you want just the summary, jump down to the "Proposed solution" below and read the last paragraphs. If you do not understand or if you disagree with this proposal, then maybe you should read the whole text. I would like to remove the option "death_penalty_levels", which limits the number of levels that can be lost when a player dies. After analyzing the reason why this option was added, I am now convinced that it is the wrong fix for just one symptom of a deeper problem: the interaction between the exp_table and the "death_penalty_percentage". Using this option hides a part of the real problem without fixing it. I would like to remove this option so that we can find a solution to the real problem. First, a bit of history: several years ago, crossfire had only about 20 levels (and no skills, but this does not matter much). The formula for the experience loss on death was added and the default percentage was set to 20% (this is now configurable: "death_penalty_percentage"). The experience table was revised a couple of times, with some attempts that were a bit more linear while others were more exponential. After a while, this table evolved to something similar to the first levels of table A: basically, reaching the second level required 1000 experience points and then each level required twice as many points as the previous one: a 100% increase per level. Due to the limited number of levels available in the game, gaining a level was a big thing that required several hours. On the other hand, losing 20% of that experience did not always imply losing a level because the relative increase between levels was about 100%. Later, the number of levels was greatly increased and eventually reached the 115 levels that we have today. Skills were also added in the meantime. After a few revisions, the experience table A was introduced: the lower levels require a 100% increase in exp points between levels, then the relative difference between levels gets smaller and smaller: above level 90, increasing the exp points by only 1% is sufficent to reach the next level. This flattening of the curve was introduced because near the higher levels, even a small relative increase of 1% represents a large amount of experience points. The consensus was that it was difficult to gain so much exp easily so it was better to use a curve that becomes almost linear near the high levels (except for levels above 110, for which a larger gap was introduced). But this created two problems: 1) Contrary to what was expected, it is not very difficult to gain a lot of exp near the high levels. Due to the availability of high level monsters and deep dungeons with a lot of monsters, the player can still collect points almost exponentially while the exp curve becomes almost linear. As a result, it takes less time to go from level 50 to level 100 than it takes to go from level 1 to level 15. 2) The death penalty was still 20% of the exp points (plus a stat loss). Because the ratio between levels was increasing only by about 1% near the high levels, losing 20% of the points meant losing a lot of levels: a level 100 player could drop down to level 85 by just dying once. A solution was found for the second problem: introduce a limit to the number of levels that can be lost at once. The default value of "death_penalty_levels" ensures that a dead player will not lose more than 3 levels. Although this seemed to be a good solution at that time, I am now convinced that it did more harm than good. This did not solve the first problem; on the contrary, it even made it worse. The option "death_penalty_levels" increased the gap between the high level players who would never lose more than 3 or 4% of their experience points while the low level players would still lose the full 20%. The real problem comes from the exp_table: the players can collect exp points almost exponentially even at relatively high levels. If this had been known when the curve was designed, it would have been better to keep the same ratio between successive levels instead of decreasing this ratio near the high levels. Then it would not have been necessary to introduce "death_penalty_levels". For example, if the ratio between successive levels would be 10% (for low, medium and high levels), then a penalty of 20% would always represent about two levels. With a ratio of 30%, the penalty of 20% could never cause the loss of more than one level. This does not work with the current system, which uses a ratio of 100% for the lowest levels and 1% for the highest ones. Proposed solution: - Get rid of death_penalty_levels. This option hides the real problem instead of solving it. - Switch to a new experience table that uses a constant ratio between levels for most of the table. Yesterday, I mentioned that designing an experience table before having reliable measurements aobut how much time is really spent for levelling up was like putting the cart before the horses. But I have changed my mind since then. I am now convinced that instead of trying design the "perfect" experience table and adjust the curve according to how experience is gained in real games, it would be better to start by selecting a new curve that is based on a constant ratio for most of the table and then adjust the parameters of the game (exp given by some monsters) to this curve. We still need to measure how experience is gained. But this data will be used to increase or decrease the sources of exp points in the game in order to ensure that a reasonable amount of playing time is necessary for each level according to the new exp_table. Doing the opposite (trying to adjust the exp_table according to how exp is gained) will never solve the problems associated with player deaths and the differences between high- and low-level characters. Note that I have updated the wiki page: http://wiki.metalforge.net/doku.php/dev_todo:exp_table I have now included two proposed exp_tables: the same as yesterday, renamed "Table D (Progressive 12%)" because each level (except for the lowest and highest ones) requires 12% more points than the previous one, and a new one called "Table E (Progressive 15%)" because each level (except for the lowest ones) requires 15% more points than the previous one. I have also updated the graphs, which should be easier to read now. -Raphael From fuchs.andy at gmail.com Sat Sep 2 19:09:39 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sat, 2 Sep 2006 20:09:39 -0400 Subject: [crossfire] Splitting "spellbook" In-Reply-To: <44F86369.6070609@telus.net> References: <200608310026.10932.nicolas.weeger@laposte.net> <44F7ED33.7080901@myrealbox.com> <44F86369.6070609@telus.net> Message-ID: On 9/1/06, Alex Schultz wrote: > Tchize wrote: > > Scripts should not be build based on object name but on arch id (archname) > I'm pretty sure he meant client-side scripting, not server-side. I don't > think there's a way to do it by arch id clientside ;) Yes. -- Andrew Fuchs From alex_sch at telus.net Sat Sep 2 19:52:22 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 02 Sep 2006 18:52:22 -0600 Subject: [crossfire] Progressive exp table and removal of a bad hack: death_penalty_levels In-Reply-To: <20060903005716.716b5fb9.raphael@gimp.org> References: <20060903005716.716b5fb9.raphael@gimp.org> Message-ID: <44FA2746.1060003@telus.net> Rapha?l Quinet wrote: > > > But this created two problems: > > 1) Contrary to what was expected, it is not very difficult to gain a > lot of exp near the high levels. Due to the availability of high > level monsters and deep dungeons with a lot of monsters, the player > can still collect points almost exponentially while the exp curve > becomes almost linear. As a result, it takes less time to go from > level 50 to level 100 than it takes to go from level 1 to level 15. > One little note on this, I would say the levels 95-100 are fairly tricky actually (of course not as much as 100-115 of course), and that your statement might be a more accurate with level 50 to level 95, but yes, despite the nitpicks I agree with your point, I might even say level 40-95 might more accurate for the range that is too quick to gain levels in. > 2) The death penalty was still 20% of the exp points (plus a stat > loss). Because the ratio between levels was increasing only by > about 1% near the high levels, losing 20% of the points meant > losing a lot of levels: a level 100 player could drop down to level > 85 by just dying once. > Well, with both default and metalforge exp tables, the situation with that improves after level ~107, however yes, with the exception of that minor nitpick I would agree with assessment of the problem. > > > Proposed solution: > - Get rid of death_penalty_levels. This option hides the real problem > instead of solving it. > I'm personally more inclined to leave the death_penalty_levels option, but set it's default to unlimited, so server admins could do things such as make their server do something like a 1 level per death max if they wanted to. > - Switch to a new experience table that uses a constant ratio between > levels for most of the table. > > Yesterday, I mentioned that designing an experience table before > having reliable measurements aobut how much time is really spent for > levelling up was like putting the cart before the horses. But I have > changed my mind since then. I am now convinced that instead of trying > design the "perfect" experience table and adjust the curve according > to how experience is gained in real games, it would be better to start > by selecting a new curve that is based on a constant ratio for most of > the table and then adjust the parameters of the game (exp given by > some monsters) to this curve. > This makes sense to me. > We still need to measure how experience is gained. But this data will > be used to increase or decrease the sources of exp points in the game > in order to ensure that a reasonable amount of playing time is > necessary for each level according to the new exp_table. Doing the > opposite (trying to adjust the exp_table according to how exp is > gained) will never solve the problems associated with player deaths > and the differences between high- and low-level characters. Measuring exp gain gives me an interesting idea. It might be interesting to devise an algorithm to have the game adjust the exp given by monsters according to how easily players kill them, perhaps analyze how much different traits affect the exp, and automatically change how much exp such monsters would give. Perhaps too much effort/trouble than it's worth, but it's an interesting idea anyways, making the game self-balancing (within limits). Alex Schultz From mwedel at sonic.net Sat Sep 2 21:37:51 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 02 Sep 2006 19:37:51 -0700 Subject: [crossfire] Reminder: Vote: Crossfire source code control system. Message-ID: <44FA3FFF.3030806@sonic.net> Reminder that there is less than a week of voting left. For every vote I receive, I reply confirming I received the vote - if you've voted but not received a confirmation, send mail again, and if still don't get a confirmation, try to find my on irc. 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 lalo.martins at gmail.com Sun Sep 3 01:02:02 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Sun, 03 Sep 2006 14:02:02 +0800 Subject: [crossfire] Rebalancing, difficulty curve -- simple ideas References: <44F525F7.2040900@telus.net> <44F5381B.9020003@sonic.net> <20060902005330.4d9da196.raphael@gimp.org> <44F9FBF6.7060906@sonic.net> Message-ID: On Sat, 02 Sep 2006 14:47:34 -0700, Mark Wedel wrote: > For most of the mental skills, the complication of things gets cut off. > Readables above level 10 are pretty darn rare. I'm not sure about find/detect > traps, and the item identification skills are another issue all together. I have found high-level traps in random maps; as a matter of fact, it's my primary reason for climbing heaven -- after 30 levels or so they start giving serious contribution to my find/disarm/lockpick skills, and after 50 they actually often kill me on my current 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 nicolas.weeger at laposte.net Sun Sep 3 05:00:06 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 3 Sep 2006 12:00:06 +0200 Subject: [crossfire] Weather system Message-ID: <200609031200.06765.nicolas.weeger@laposte.net> Hello. Following different bugfixes in the code, it seems to me the weather code is now operational, even at level 5. The tests I made seem to be correct. Weather correctly changes tiles, puts snow/rain, in short behaves like it should from the code, and like one would expect. Rednexela made some tests too, maybe he found something i missed :) The fun is that, if weather code is fixed, it would mean it wasn't bugged (ok, there was one small logic issue that we fixed) in the first place, other parts of the code were responsible for the missing tiles and trees appearing on the sea :) Nicolas From cher at riedquat.de Sun Sep 3 05:58:01 2006 From: cher at riedquat.de (Christian Hujer) Date: Sun, 3 Sep 2006 12:58:01 +0200 Subject: [crossfire] crossfire source code control systems In-Reply-To: <44DD8863.4000401@sonic.net> References: <44DD8863.4000401@sonic.net> Message-ID: <200609031258.03487.cher@riedquat.de> Hi all, I've just found out about another reason why I would prefer Subversion over other VCS: svn:externals Current situation: Gridarta uses Subversion. In Gridarta, we include certain files which we currently manually update to the latest version of crossfire resp. daimonin. Possibility: If crossfire (resp. daimonin) would use Subversion for its repository, we could use svn:externals to simply point to the corresponding file of crossfire resp. daimonin. It would then automatically be kept up-to-date. The arch/ directory would be the part which is of most interest, e.g. for collecting the arches or providing a jar archive containing this data. This advantage would also apply to other eventually existing editors or tools made for crossfire / daimonin, version controlled with svn and not held within crossfire's / daimonin's repository. Bye :-) -- 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/20060903/47f108f9/attachment.pgp From alex_sch at telus.net Sun Sep 3 09:22:11 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 03 Sep 2006 08:22:11 -0600 Subject: [crossfire] Weather system In-Reply-To: <200609031200.06765.nicolas.weeger@laposte.net> References: <200609031200.06765.nicolas.weeger@laposte.net> Message-ID: <44FAE513.1080408@telus.net> Nicolas Weeger (Laposte) wrote: > Rednexela made some tests too, maybe he found something i missed :) > Nope, seems fully operational to me too :) Alex Schultz From raphael at gimp.org Sun Sep 3 16:25:12 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Sun, 3 Sep 2006 23:25:12 +0200 Subject: [crossfire] Progressive exp table and removal of a bad hack: death_penalty_levels In-Reply-To: <44FA2746.1060003@telus.net> References: <20060903005716.716b5fb9.raphael@gimp.org> <44FA2746.1060003@telus.net> Message-ID: <20060903232512.44a34452.raphael@gimp.org> On Sat, 02 Sep 2006 18:52:22 -0600, Alex Schultz wrote: > One little note on this, I would say the levels 95-100 are fairly tricky > actually (of course not as much as 100-115 of course), and that your > statement might be a more accurate with level 50 to level 95, but yes, > despite the nitpicks I agree with your point, I might even say level > 40-95 might more accurate for the range that is too quick to gain levels in. Although I found the high levels too easy up to level 105 with some characters, this depends on the type of character played, skills, religion, etc. So it may be reasonable to consider 110 million exp points (approx. level 95 in the current table B) as the point after which the exp gains are not exponential anymore. This means that a balanced experience curve should be exponential at least until approx. 100 or 110 million points instead of becoming almost linear like the default one (table B). [...] > > Proposed solution: > > - Get rid of death_penalty_levels. This option hides the real problem > > instead of solving it. > > I'm personally more inclined to leave the death_penalty_levels option, > but set it's default to unlimited, so server admins could do things such > as make their server do something like a 1 level per death max if they > wanted to. But again, that would be the wrong way to limit the number of levels lost: if a server admin does not want players to lose more than 1 level per death, then the admin should modify the exp curve or lower the death_penalty_percentage. Using death_penalty_levels implies that the server admin wants to give an advantage to the high level players compared to the low level ones because high level players would not be hurt as much. Instead of using this unbalanced hack (death_penalty_levels), the server admin should ensure that the percentage of exp lost per death is not greater than the percentage of exp increase required for gaining a level. This is the only fair way to limit the number of levels lost per death (well, not really the only way: another solution would be to use a variable death_penalty_percentage that mimics the exp_table and decreases with each level, but this creates other problems). For example, a way to ensure that players never lose more than 1 level per death would be to set death_penalty_percentage to 15% and use an exp_table in which most of the curve uses a constant ratio of 15% for the exp points increase between levels. In fact, regardless of what is done to the exp_table, I would suggest changing the default death_penalty_percentage to 15%. By the way, the experience curve used by Metalforge (table C) has a curve that converges towards 5% so if death_penalty_percentage is kept at 20%, this limits the maximum loss to 4 or 5 levels. Limiting the loss to 3 levels would require an exp curve that converges above 7.2%. I prefer to use a constant ratio of increase for most of the curve (for example 15% or 12% as shown on the wiki page). However, another option would be to use a curve similar to the one used by Metalforge but converging towards 8% instead of 5%. The lower levels should be easier in any case. [...] > Measuring exp gain gives me an interesting idea. It might be interesting > to devise an algorithm to have the game adjust the exp given by monsters > according to how easily players kill them, perhaps analyze how much > different traits affect the exp, and automatically change how much exp > such monsters would give. Perhaps too much effort/trouble than it's > worth, but it's an interesting idea anyways, making the game > self-balancing (within limits). This would be rather tricky to balance: one player who is very good at killing a specific type of monsters could make them worthless for everybody. This could also create a "monster of the day" problem, in which players try to find the monsters that currently give the most experience until the values are adjusted again. The players will modify their playing style according to how much exp each monster gives, so a self-balancing system is unlikely to converge to a stable point. Although this is an interesting idea, I doubt that it could be implemented in a good way. As you wrote: perhaps too much effort/ trouble than it's worth. -Rapha?l From mwedel at sonic.net Sun Sep 3 17:27:20 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 03 Sep 2006 15:27:20 -0700 Subject: [crossfire] Progressive exp table and removal of a bad hack: death_penalty_levels In-Reply-To: <20060903232512.44a34452.raphael@gimp.org> References: <20060903005716.716b5fb9.raphael@gimp.org> <44FA2746.1060003@telus.net> <20060903232512.44a34452.raphael@gimp.org> Message-ID: <44FB56C8.9070601@sonic.net> Rapha?l Quinet wrote: >>> Proposed solution: >>> - Get rid of death_penalty_levels. This option hides the real problem >>> instead of solving it. >> I'm personally more inclined to leave the death_penalty_levels option, >> but set it's default to unlimited, so server admins could do things such >> as make their server do something like a 1 level per death max if they >> wanted to. > > But again, that would be the wrong way to limit the number of levels > lost: if a server admin does not want players to lose more than 1 > level per death, then the admin should modify the exp curve or lower > the death_penalty_percentage. But it seems like you are deciding server policy for server admins, who may not agree with that policy. I agree with Alex here - keeping that option around doesn't do any harm - it can be set to a high value such that it effectively does nothing. But if a server admin does want to set it, who are we really to say that you can't? IIRC, the reason that was added was that at high levels, a characters death could amount to losing quite a few levels. Sure, at high levels it may not be hard to regain them, but the point was that losing a whole bunch was considered excessive. I have a feeling that removing it may cause several complaints, as a character that dies loses more than they expect. (another issue related to this is overall level, which dictates items you can wear, etc). But this actually has more issues related to death. If the death penalty is not very high (in terms of whatever penalty, be it exp or stat loss, etc), then players are more likely to play aggressively. If a death costs me 15 minutes, but agressive playing more than makes up for it because of faster exp gain, you play agressive. OTOH, if death penalty is very high, players would play much more cautiously, because a death may mean several hours of lost work. In this case, playing slower/safer may make up for it, even with the slower exp gain. I'm not sure what the perfect balance is, but that is just some food for thought. From raphael at gimp.org Mon Sep 4 10:35:42 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Mon, 4 Sep 2006 17:35:42 +0200 Subject: [crossfire] Progressive exp table and removal of a bad hack: death_penalty_levels In-Reply-To: <44FB56C8.9070601@sonic.net> References: <20060903005716.716b5fb9.raphael@gimp.org> <44FA2746.1060003@telus.net> <20060903232512.44a34452.raphael@gimp.org> <44FB56C8.9070601@sonic.net> Message-ID: <20060904173542.432f6fe0.raphael@gimp.org> On Sun, 03 Sep 2006 15:27:20 -0700, Mark Wedel wrote: > Rapha?l Quinet wrote: > > But again, that would be the wrong way to limit the number of levels > > lost: if a server admin does not want players to lose more than 1 > > level per death, then the admin should modify the exp curve or lower > > the death_penalty_percentage. > > But it seems like you are deciding server policy for server admins, who may > not agree with that policy. > > I agree with Alex here - keeping that option around doesn't do any harm - it > can be set to a high value such that it effectively does nothing. But if a > server admin does want to set it, who are we really to say that you can't? I don't want to prevent server admins from limiting the number of levels that are lost when a player dies. I just want to be sure that it is done in the right way. In other words, I don't want to decide server policy, I just want to have a better way to implement that policy. The best solution would be to fix the exp_table so that the curve does not become almost flat near the high levels. This causes a large difference between the additional exp points required per level (which becomes as low as 1% for the high levels) and death_penalty_percentage which is fixed at 20%. If some server admins do not want to use a better exp_table (I hope that we could agree on a new one soon) and want to keep a system that is rather unbalanced by giving an advantage to the high level players, then I'm not opposed to that, but this should be done in a way that makes it obvious that the system is unbalanced. For example, the death_penalty_percentage could be variable: if the players should not lose more than 1 level, then the death_penalty_percentage could be kept at 20% for the first 16 levels, then decrease until it reaches 5% for level 35 and then 1% for levels between 70 and 109. The effect would be exactly the same as we have now, but its impact on the various levels would be more obvious. [...] > IIRC, the reason that was added was that at high levels, a characters death > could amount to losing quite a few levels. Sure, at high levels it may not be > hard to regain them, but the point was that losing a whole bunch was considered > excessive. I have a feeling that removing it may cause several complaints, as a > character that dies loses more than they expect. This is exactly what I mentioned in my first message: "[...] Because the ratio between levels was increasing only by about 1% near the high levels, losing 20% of the points meant losing a lot of levels: a level 100 player could drop down to level 85 by just dying once. A solution was found for the second problem: introduce a limit to the number of levels that can be lost at once. [...] Although this seemed to be a good solution at that time, I am now convinced that it did more harm than good." Using death_penalty_levels fixes one symptom, not the cause. The real problem is that the experience curve is broken: the percentage of score increase required to gain levels becomes too different from the death_penalty_percentage near the high levels. I think that in order to evaluate the death penalties correctly, we should not think in terms of levels but in terms of experience points. The time in the game is spent gaining experience points. Levels are gained indirectly through exp points and we know that there are problems with the exp_table (the exp_table C used by Metalforge is considered better than the default table B, but it still has problems). Although this would have to be confirmed by measurments in real games, there are strong indications that the exp gain per unit of time is roughly exponential, at least until about level 95 (as mentioned by Alex). I think that this is the case for the range of points between 2 million and 100 million (currently mapped between level 13 and level 89). The exact exponent would have to be derived from measurments but I guess that it would be somewhere around 1.15 (around 15% increase per unit of time, which could be mapped to a level). Maybe it is a bit higher or lower, but it is very likely to be between 1.10 and 1.20 (10% to 20% increase). A "fair" penalty per death should be related to the amount of time required to gain some exp points. Unfortunately, the current distribution of levels per amount of exp (the exp_table) is not ideal and not proportional to the amount of time spent on each level. If we could fix that, then maybe death_penalty_levels would become irrelevant anyway, and we would not even have to argue about whether the option should be kept or not. That's what these messages were about: fixing the exp table so that the levels become more proportional to the playing time. > If the death penalty is not very high (in terms of whatever penalty, be it exp > or stat loss, etc), then players are more likely to play aggressively. If a > death costs me 15 minutes, but agressive playing more than makes up for it > because of faster exp gain, you play agressive. > > OTOH, if death penalty is very high, players would play much more cautiously, > because a death may mean several hours of lost work. In this case, playing > slower/safer may make up for it, even with the slower exp gain. I agree with that: this is something that should be balanced carefully. But this is very difficult to do with the current exp_tables, in which the distribution of levels is not related to the amount of time spent playing. If we can measure how much exp is gained on average per unit of time (or more exactly, by which percentage the exp is increased per unit of time), then it will be easier to map the penatly to the amount of time that it represents. For example, we could discover through measurments that the average exp increase is 3% per hour for most of the exp range (the lowest and highest levels could have a different rate). Knowing this, I could set the death_penalty_percentage to 9% if I want to have a penalty that represents about 3 hours of playing time. Someone who wants to encourage a more agressive playing style could set the penalty to 5% and someone who wants players to be more careful could set it to 20% or more (=> 6 or 7 hours). Side note: encouraging a more careful playing style would also require updating some maps. Several areas can trap the player without warning (especially some "no spells" areas as I mentioned a few weeks ago) or they contain some warnings but do not mention how hard the area will be and do not indicate that there is no way back (e.g., lake country's burial ground or dark angel Hanuk). Even a careful player will probably want to explore a bit and will eventually fall into one of these traps and die. The warnings for these areas should be a bit more explicit. -Raphael From mwedel at sonic.net Mon Sep 4 16:19:23 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 04 Sep 2006 14:19:23 -0700 Subject: [crossfire] Progressive exp table and removal of a bad hack: death_penalty_levels In-Reply-To: <20060904173542.432f6fe0.raphael@gimp.org> References: <20060903005716.716b5fb9.raphael@gimp.org> <44FA2746.1060003@telus.net> <20060903232512.44a34452.raphael@gimp.org> <44FB56C8.9070601@sonic.net> <20060904173542.432f6fe0.raphael@gimp.org> Message-ID: <44FC985B.8050606@sonic.net> Rapha?l Quinet wrote: > On Sun, 03 Sep 2006 15:27:20 -0700, Mark Wedel wrote: >> Rapha?l Quinet wrote: >>> But again, that would be the wrong way to limit the number of levels >>> lost: if a server admin does not want players to lose more than 1 >>> level per death, then the admin should modify the exp curve or lower >>> the death_penalty_percentage. >> But it seems like you are deciding server policy for server admins, who may >> not agree with that policy. >> >> I agree with Alex here - keeping that option around doesn't do any harm - it >> can be set to a high value such that it effectively does nothing. But if a >> server admin does want to set it, who are we really to say that you can't? > > I don't want to prevent server admins from limiting the number of > levels that are lost when a player dies. I just want to be sure that > it is done in the right way. In other words, I don't want to decide > server policy, I just want to have a better way to implement that > policy. I agree that the exp table should be updated, and other changes should be made. I just don't see a really compelling reason for the death level loss limit to go away - it is currently in the code, and currently works fine. Sure, using it may mask broken behaviour elsewhere, and different/better tables should be used. But there are potentially many options within the settings file which change balance or could cause breakage - maybe some should be removed, maybe not. But the point is that we provide the option for server admins to use them. I suppose some of this is depend on what release this is target at. If 2.0, less an issue. However, if it is targetted at the 1.9 cycle, then I really think this option must remain - I'd expect most servers are not going to change the exp table mid stride, and at the same time, don't want to change the death loss mid stride either - after all, its not really fair for newer players to play with different rules than the older players. > > Side note: encouraging a more careful playing style would also require > updating some maps. Several areas can trap the player without warning > (especially some "no spells" areas as I mentioned a few weeks ago) or > they contain some warnings but do not mention how hard the area will > be and do not indicate that there is no way back (e.g., lake country's > burial ground or dark angel Hanuk). Even a careful player will > probably want to explore a bit and will eventually fall into one of > these traps and die. The warnings for these areas should be a bit > more explicit. I agree on those points - places that trap the player are generally poor design. And the difficulty of some places is another issue. Now some of this could perhaps be helped out if the game play is slower - if it takes 10 seconds to be killed by a monster, that is still enough time to cast word of recall and get out. The problem is some places, death is in a matter of seconds, which isn't enough time. From fuchs.andy at gmail.com Mon Sep 4 19:23:27 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon, 4 Sep 2006 20:23:27 -0400 Subject: [crossfire] Idea: class has an effect on the amout of experience gained from certian skills Message-ID: I came up with an idea that would add significance to a player's choice of class, and be an other way to tweak experience. What if skills associated with a class give the player more experience when they are used? This could also be taken in the other direction by limiting the experience players gain with skills not associated with their class. For example, an evoker will level up more quickly if they use evocation, than if they used sorcery, bows, or melee attacks. -- Andrew Fuchs From mwedel at sonic.net Mon Sep 4 23:29:58 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 04 Sep 2006 21:29:58 -0700 Subject: [crossfire] Idea: class has an effect on the amout of experience gained from certian skills In-Reply-To: References: Message-ID: <44FCFD46.8010304@sonic.net> Andrew Fuchs wrote: > I came up with an idea that would add significance to a player's > choice of class, and be an other way to tweak experience. What if > skills associated with a class give the player more experience when > they are used? This could also be taken in the other direction by > limiting the experience players gain with skills not associated with > their class. For example, an evoker will level up more quickly if > they use evocation, than if they used sorcery, bows, or melee attacks. > This has been discussed before. IMO, it is a good idea. The previous discussion actually had it more general, in that there maybe multiple levels of skill gain. Best way to handle this is by using a field in the skill itself to denote extra gain/penalty (as a percentage). In this way, there could also be special questions, etc, that perhaps give you a better version of the skill, etc. From nicolas.weeger at laposte.net Wed Sep 6 15:09:39 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Wed, 6 Sep 2006 22:09:39 +0200 Subject: [crossfire] Idea: class has an effect on the amout of experience gained from certian skills In-Reply-To: References: Message-ID: <200609062209.39283.nicolas.weeger@laposte.net> Le Mardi 05 Septembre 2006 02:23, Andrew Fuchs a ?crit?: > I came up with an idea that would add significance to a player's > choice of class, and be an other way to tweak experience. What if > skills associated with a class give the player more experience when > they are used? This could also be taken in the other direction by > limiting the experience players gain with skills not associated with > their class. For example, an evoker will level up more quickly if > they use evocation, than if they used sorcery, bows, or melee attacks. Agreed. It would make class more significant. Of course, need to balance all that :) Nicolas From lalo.martins at gmail.com Wed Sep 6 16:13:23 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 07 Sep 2006 05:13:23 +0800 Subject: [crossfire] The Kirby project: Valkyrie, goddess of war Message-ID: I'm working occasionally on porting the "new gods" I wrote years ago to the current crossfire codebase, then fixing them for balance. I call it "the Kirby project" ;-) The easiest one was one of my favourites: Valkyrie, goddess of war and warriors, which I just committed. It's far from perfect balance-wise right now, but it's good enough to get other people test and suggest how to fine-tune it. Valkie calls for a different gameplay style; or alternatively, it legitimates the style of not using magic. She hates all kinds of magic, and "slays" creatures strong in magic. On the other hand, she denies all magic to her followers as well. In exchange, she gives strong protection against magic. Wait a minute; if there's no magic, then what's the point of the slaying thing? And more importantly, how do you level up? The slaying thing will only affect enchanted weapons, and she gives them rather frequently (as weapons are sacred to her). As for levelling up, that's the fun part. The reason I started with Valkie is that I figured this one out, after a recent irc chat about classes. Valkyrie will accept sacrifices on her altar; you should pick up flesh, bring it to the altar, and then pray. You'll gain praying exp depending on the difference between your level and the dead creature's, and on the flesh resistances. Head and heart are worth slightly more. This is not very fine-tuned yet; as the values are more or less fixed, I'm afraid it would take horrendous piles of flesh to climb a really really high level. One alternative idea is to change the flesh code to fill the exp field of flesh objects with the exp of the originating monster; would that have any unexpected side-effects? Then of course the altar wouldn't give the whole exp, just a fraction depending on some factors yet to be defined. (On an unrelated note, if I do change the flesh code, I'd like to add the archetype of the original monster in the other_arch field, for the purpose of a spell I'm thinking about; any problem with that?) For the sake of testing, I put an altar on the last basement of the abandoned church north of Mostrai in Scorn. This is *NOT* where I intend it to be in the long term, I just want people to help me test it, and that seemed like a good temporary place for it. If you want to test it, have fun, and have a nice carnage! ;-) 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 Thu Sep 7 00:49:54 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 06 Sep 2006 22:49:54 -0700 Subject: [crossfire] The Kirby project: Valkyrie, goddess of war In-Reply-To: References: Message-ID: <44FFB302.8090805@sonic.net> Lalo Martins wrote: > The slaying thing will only affect enchanted weapons, and she gives them > rather frequently (as weapons are sacred to her). Does she give arrows out a lot? That could help give these character some form of range attack. > > One alternative idea is to change the flesh code to fill the exp field of > flesh objects with the exp of the originating monster; would that have any > unexpected side-effects? Then of course the altar wouldn't give the whole > exp, just a fraction depending on some factors yet to be defined. I'm not sure if there would be any side effects of filling in the exp field. I doubt it, but I'm not 100% sure that exp isn't overloaded with some extra meaning. > > (On an unrelated note, if I do change the flesh code, I'd like to add the > archetype of the original monster in the other_arch field, for the purpose > of a spell I'm thinking about; any problem with that?) probably not. The issue may be that the archetype may not be entirely useful - custom monsters on high level maps vary quite a bit from the archetype, so you'd have to be careful what fields you use and what you use them for. From lalo.martins at gmail.com Thu Sep 7 06:53:47 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 07 Sep 2006 19:53:47 +0800 Subject: [crossfire] The Kirby project: Valkyrie, goddess of war References: <44FFB302.8090805@sonic.net> Message-ID: On Wed, 06 Sep 2006 22:49:54 -0700, Mark Wedel wrote: > Lalo Martins wrote: >> The slaying thing will only affect enchanted weapons, and she gives them >> rather frequently (as weapons are sacred to her). > > Does she give arrows out a lot? That could help give these character some > form of range attack. I could do that. Enchanted arrows? I think "normal" arrows are about easy enough to find already. >> One alternative idea is to change the flesh code to fill the exp field >> of flesh objects with the exp of the originating monster; would that >> have any unexpected side-effects? Then of course the altar wouldn't >> give the whole exp, just a fraction depending on some factors yet to be >> defined. > > I'm not sure if there would be any side effects of filling in the exp > field. > I doubt it, but I'm not 100% sure that exp isn't overloaded with some > extra meaning. I checked the sell code (shop.c) and the eat code (apply_food()), didn't find any. Anyone can think of another possible use? Then I made the change in my server, tried eating flesh with a dragon, selling it, and using it for alchemy, nothing unexpected seems to have happened. So I'll let it rest for a day or two just in case someone speaks up, then commit it. >> (On an unrelated note, if I do change the flesh code, I'd like to add >> the archetype of the original monster in the other_arch field, for the >> purpose of a spell I'm thinking about; any problem with that?) > > probably not. The issue may be that the archetype may not be entirely > useful > - custom monsters on high level maps vary quite a bit from the > archetype, so you'd have to be careful what fields you use and what you > use them for. I don't care so much. The idea is a "raise dead" or somesuch spell, that turns corpses into (pet) zombies, and heads/hearts into wraiths. It would use the arch of the original monster to set attributes and resists, then apply modifications for undead. Yeah, that would leave them weaker than you'd expect for custom monsters, but I find that perfectly acceptable. Anyway, I'm not writing the spell today or tomorrow, so there's time to figure it out :-) I just thought, if I'm changing flesh to have exp, might as well put in the other_arch in the same commit. 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 subs at eracc.com Thu Sep 7 09:26:53 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Thu, 7 Sep 2006 09:26:53 -0500 Subject: [crossfire] The Kirby project: Valkyrie, goddess of war In-Reply-To: <44FFB302.8090805@sonic.net> References: <44FFB302.8090805@sonic.net> Message-ID: <200609070926.54689.subs@eracc.com> On Thursday 07 September 2006 12:49 am Mark Wedel wrote: > > (On an unrelated note, if I do change the flesh code, I'd like to add the > > archetype of the original monster in the other_arch field, for the > > purpose of a spell I'm thinking about; any problem with that?) > > ? probably not. ?The issue may be that the archetype may not be entirely > useful - custom monsters on high level maps vary quite a bit from the > archetype, so you'd have to be careful what fields you use and what you use > them for. For example take a look at Irritable Zorn (/brest/brest.scrolls.right) as he is heavily modified from the standard merchant NPC (IIRC). Thinking on this, what mechanism is used to tell the system that dragon flesh from a custom monster is high level? Perhaps that could be adapted to your flesh altar. This also brings up the argument for female player graphics. Valkyrie, being a minor female deity (see http://en.wikipedia.org/wiki/Valkyrie), would seem to me to be one to which girls would gravitate. I'm not a graphics maker or I would look at making some myself. Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 09:18:40 up 5 days, 37 min, 16 users, load average: 0.29, 0.21, 0.16 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From mwedel at sonic.net Thu Sep 7 23:07:37 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 07 Sep 2006 21:07:37 -0700 Subject: [crossfire] The Kirby project: Valkyrie, goddess of war In-Reply-To: <200609070926.54689.subs@eracc.com> References: <44FFB302.8090805@sonic.net> <200609070926.54689.subs@eracc.com> Message-ID: <4500EC89.2040907@sonic.net> ERACC Subscriptions wrote: > On Thursday 07 September 2006 12:49 am > Mark Wedel wrote: > >>> (On an unrelated note, if I do change the flesh code, I'd like to add the >>> archetype of the original monster in the other_arch field, for the >>> purpose of a spell I'm thinking about; any problem with that?) >> probably not. The issue may be that the archetype may not be entirely >> useful - custom monsters on high level maps vary quite a bit from the >> archetype, so you'd have to be careful what fields you use and what you use >> them for. > > For example take a look at Irritable Zorn (/brest/brest.scrolls.right) as he > is heavily modified from the standard merchant NPC (IIRC). Thinking on this, > what mechanism is used to tell the system that dragon flesh from a custom > monster is high level? Perhaps that could be adapted to your flesh altar. I think for flesh items, the level of the creature is stored away, and that is what is used for comparison on getting resistances. As said, what it comes down to is what you want to do with the information - if the arch info is 'good enough', not a big deal. If accurate data was really needed, then you'd probably have to make a copy of the monster, and perhaps put it in the inventory of the object. From mwedel at sonic.net Thu Sep 7 23:09:44 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 07 Sep 2006 21:09:44 -0700 Subject: [crossfire] The Kirby project: Valkyrie, goddess of war In-Reply-To: References: <44FFB302.8090805@sonic.net> Message-ID: <4500ED08.1000907@sonic.net> Lalo Martins wrote: > On Wed, 06 Sep 2006 22:49:54 -0700, Mark Wedel wrote: >> Lalo Martins wrote: >>> The slaying thing will only affect enchanted weapons, and she gives them >>> rather frequently (as weapons are sacred to her). >> Does she give arrows out a lot? That could help give these character some >> form of range attack. > > I could do that. Enchanted arrows? I think "normal" arrows are about > easy enough to find already. I was thinking that if you could get magical arrows of slaying, or even better, arrows of assassinating, those could be really nice. And would perhaps make using a bow more interesting. From alex_sch at telus.net Thu Sep 7 23:57:27 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 07 Sep 2006 22:57:27 -0600 Subject: [crossfire] Proposal: Unified event system Message-ID: <4500F837.5010101@telus.net> These things that exist or are planned all use some event-type constructs: -the plugin system -the callbacks from common to server -the proposed refactoring to have "method-like" function pointers for objects and/or object types. All three of those things could be set up to use a unified event/callback system, which would: -benefit plugins by making it more flexible -get rid of ugly stub hacks -reduce repeated effort on the "method-like" system for objects. I propose that an event system be implemented that would work well for all three purposes efficiently: -Event hooks however can be: global, per-map, per-arch, and per-object. -All events can be hooked as a global event -Events pertaining to a map or an object in a map can be hooked per-map -Events pertaining to objects can be hooked as per-arch or per-object Essentially meaning, everything that can be hooked per-object or per-arch, can be hooked per-map, and everything that can be hooked per-map can be hooked globally. -Event hooks can be given priority, with 0 reserved for core server callbacks. Priority stored in an SINT8, so it can range from -127 to 127, and negative means it happens first. -This allows useful things such as setting hooks to run after a player is teleported, or before -The return type of calling an event depends on the event, and some events don't return a value; events act as callbacks of sorts, however multiple callbacks can be assigned to an event. -For events that return a value, hooks may or may not return a value. Hooks can be set to active or passive, active ones have a chance of returning a value whereas passive will not. When an active hook returns a value, active hooks of lower priority will not be run, though passive ones still will be. -This is to in principal allow hooks that may override the default return of a callback, while also allowing passive hooks to still run both before and after. -Events with no return value only allow passive hooks -For events without return values, hooks may at runtime opt to force priority 0 (default server internal) or lower, not to run. -This is to allow hooks for events without return values, to stop default server code from running. This achieves the same purpose as only the first active event that returns a value, running for events that return a value. I believe this type of event system could make a more solid event architecture to base the plugin system off of, replace callbacks from common/ to server/, and act as a base refactoring of type-specific code on. Does anyone have any objections or suggestions (or better ideas for a unified event system)? Alex Schultz From lalo.martins at gmail.com Fri Sep 8 03:36:49 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri, 08 Sep 2006 16:36:49 +0800 Subject: [crossfire] The Kirby project: Valkyrie, goddess of war References: <44FFB302.8090805@sonic.net> <200609070926.54689.subs@eracc.com> <4500EC89.2040907@sonic.net> Message-ID: On Thu, 07 Sep 2006 21:07:37 -0700, Mark Wedel wrote: > I think for flesh items, the level of the creature is stored away, and that is > what is used for comparison on getting resistances. Just because I've been reading this code recently, let's explore it a bit. When a flesh item is created, it stores these pieces of info: - name of the owner (as in "orc's head") - weight of item is adjusted according to owner (the value of weight in the flesh archetype is actually the percentage of owner's weight) - value is adjusted a bit (item->value *= isqrt(donor->level*2)) - food value gets some bonus from owner hp and Con - all resistances are set to half that of the owner's - level on the owner (on its own level field) my change adds other_arch and exp as discussed before. Code is at common/treasure.c. So for dragons eating flesh, the chance of gaining a resist point depends on the flesh resists, its level, and dragon's level. At server/living.c. 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 elmex at ta-sa.org Fri Sep 8 06:04:42 2006 From: elmex at ta-sa.org (Robin Redeker) Date: Fri, 8 Sep 2006 13:04:42 +0200 Subject: [crossfire] Proposal: Unified event system In-Reply-To: <4500F837.5010101@telus.net> References: <4500F837.5010101@telus.net> Message-ID: <20060908110442.GA4291@elmex> Hi! On Thu, Sep 07, 2006 at 10:57:27PM -0600, Alex Schultz wrote: > These things that exist or are planned all use some event-type constructs: [.snip.] This all sounds similiar to what we implemented in Crossfire+, where the plugin/extension (Perl) API was completly rewritten (mostly in Perl and C++). And it works like this (long mail ahead!): You can "attach" extensions to global events, to type/subtypes, to specifix objects, to players and to maps. On top of that a extension can implement new user commands. If a extension for example wants to attach itself to all jeweler skills it has to attach itself like this: cf::attach_to_type cf::SKILL, cf::SK_JEWELER, on_use_skill => sub { ... handling code here ... }; This function attaches itself to the type SKILL with the subtype SK_JEWELER. And everytime someone uses the skill the callback registered as 'on_use_skill' is called. Multiple extensions can attach themself to this type, and they can specify a priority with 'prio => -100' to be executed earlier. You can also attach a Perl package to the skill like this: cf::attach_to_type cf::SKILL, cf::SK_JEWELER, package => 'Crossfire::JewelerSkill'; cf::attach_to_objects will attach handlers for events on _all_ objects in the game, this is mainly for debugging purposes, as it will produce a high load. The map attachments work like this: If a extension wants to attach itself to the 'trigger' event (this is the event that is generated when a connection is activated (pushed or released)), it has to do this: cf::attach_to_maps on_trigger => sub { my ($map, $connection, $state) = @_; print "CONNECITON TRIGGERED: $connection : $state\n"; for ($map->get_connection ($connection)) { print "connected obj: " . $_->name . "\n"; } }; This small attachment dumps all connection activations and the connected objects. If this attachment now decides to overwrite connection 10, so that nothing happens if it is triggered, it has to do this: cf::attach_to_maps on_trigger => sub { my ($map, $connection, $state) = @_; if ($connection == 10) { cf::override; return; # the idiom 'return cf::override;' is quite common in our code # but i want to empasize that cf::override is just a functioncall } }; The call of cf::override sets a flag in the event system that will prevent any execution of further code that handles this event. This way all attachments with 'lower' priority and the C/C++ code is inhibited/overridden. Here is a longer code snippet that logs all interesting events to our IRC channel irc.schmorp.de #cf: http://www.ta-sa.org/files/txt/38c2f5e803590d04866c1b3cc889d315.txt The attachments are not limited to 'an extension attaches itself to <...>', a map or an objects itself can attach to a 'registered' attachment. For example our nice cat which runs around in scorn and heals people at random has following line in it's archetype: Object nekosan ... attach [["Nekosan"]] end The value of the attach field is a 2 dimensional array in JSON (JavaScript Object Notation) is a array of arrays which contain following fields: [ , { }] The code side of this looks like this: cf::register_attachment "Nekosan", package => __PACKAGE__; This registeres an attachment under the name/key 'Nekosan' so that objects like our cat can attach itself. Where the package defines for example this function: sub on_monster_move { my ($self, $enemy) = @_; ... } $self is a mostly empty object, the attachment object, which is initalized with the arguments that are given in the 'attach' value, if nekosan would have an attach field like this: attach [["Nekosan", {"foo":"bar"}]] The attached function can access the value of the key "foo" like this: $self->{Nekosan}->{foo} This way multiple different attachments have a seperate field for storing their arguments. If a extension wants to redefine a user command it does it like this: cf::register_command invite => 10, sub { my ($who, $args) = @_; ... } This registers the 'invite' command with the execution time of 10. The arguments to the function are ($who, $args), where $who is the player and $args the argument string to the command. This is what was implemented in Crossfire+ and works very well, from time to time we find missing events, which are added very quickly to the (now) C++ code: Here an example for move_trigger in move_apply (): Add a line to doc/events.pod with documentation looking like this: =head3 move_trigger (object victim originator -- ) Invoked whenever a trap-like B has been activated, usually by moving onto it. This includes not just traps, but also buttons, holes, signs and similar stuff. And put some lines like this to move_apply: if (INVOKE_OBJECT (MOVE_TRIGGER, trap, ARG_OBJECT (victim), ARG_OBJECT (originator))) goto leave; This invokes all attachments that are interested in the object event MOVE_TRIGGER, with the object being 'trap' and the arguments victim and originator. This is all C++ code that has to be added when one wants to add an event. 'make' will update include/eventinc.h from the events.pod automatically when building. Here is the documentation for all this, partly unfinished, but there are many examples: A very unfinished reference for all this can be found at http://cf.schmorp.de/doc/development/cf.pm.html. A reference for all possible events can be found at http://cf.schmorp.de/doc/development/events.html. Examples can be found in http://cvs.schmorp.de/cf.schmorp.de/maps/perl/. The NPC dialogue system might also be interesting: http://cf.schmorp.de/doc/development/NPC_Dialogue.html If there are any questions feel free to ask. I hope this small guide through the plugin/extension system in Crossfire+ helps a bit (it maybe shows the way you don't want to go) when redesigning the plugin system for Crossfire. cheers, Robin (part of the Crossfire+ development team) From alex_sch at telus.net Fri Sep 8 08:05:34 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 08 Sep 2006 07:05:34 -0600 Subject: [crossfire] Proposal: Unified event system In-Reply-To: <20060908110442.GA4291@elmex> References: <4500F837.5010101@telus.net> <20060908110442.GA4291@elmex> Message-ID: <45016A9E.7060900@telus.net> Robin Redeker wrote: > Hi! > > On Thu, Sep 07, 2006 at 10:57:27PM -0600, Alex Schultz wrote: > >> These things that exist or are planned all use some event-type constructs: >> > [.snip.] > > This all sounds similiar to what we implemented in Crossfire+, where > the plugin/extension (Perl) API was completly rewritten (mostly in Perl and C++). > And it works like this (long mail ahead!): > > Yes, it does sound similar to me as well, main differences being, that it's not integrated with any one scripting language, is not intended to completely replace the existing plugin system, is just as much for internal server use (particularly for the refactoring I mentioned) as plugin use, and not using C++ (IMHO C++ may encourage some good code organization, however C code can be organized equally well with proper planning). > I hope this small guide through the plugin/extension system in Crossfire+ helps a bit > (it maybe shows the way you don't want to go) when redesigning the plugin system for Crossfire. > As I noted above, I'm not intending on this to replace the plugin system, but am separating the event system from the plugin system, and making the event system more complete, and eventually extending the plugin system to take advantage of it, while also using the event system in some other parts of the server code than plugins. Alex Schultz From alex_sch at telus.net Fri Sep 8 08:48:02 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 08 Sep 2006 07:48:02 -0600 Subject: [crossfire] The Kirby project: Valkyrie, goddess of war In-Reply-To: References: Message-ID: <45017492.80004@telus.net> Lalo Martins wrote: > Valkie calls for a different gameplay style; or alternatively, it > legitimates the style of not using magic. She hates all kinds of magic, > and "slays" creatures strong in magic. On the other hand, she denies all > magic to her followers as well. In exchange, she gives strong protection > against magic. One note about how it works currently: the current draft in CVS gives magic immunity, however one should note that if one has negative resistance to something like cold, one will still take some damage from spells that do cold damage, despite 100% magic resistance. Alex Schultz From alex_sch at telus.net Fri Sep 8 08:54:36 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 08 Sep 2006 07:54:36 -0600 Subject: [crossfire] Idea: class has an effect on the amout of experience gained from certian skills In-Reply-To: <44FCFD46.8010304@sonic.net> References: <44FCFD46.8010304@sonic.net> Message-ID: <4501761C.3030206@telus.net> Mark Wedel wrote: > Andrew Fuchs wrote: > >> I came up with an idea that would add significance to a player's >> choice of class, and be an other way to tweak experience. What if >> skills associated with a class give the player more experience when >> they are used? >> >> > IMO, it is a good idea. The previous discussion actually had it more general, > in that there maybe multiple levels of skill gain. > > Best way to handle this is by using a field in the skill itself to denote > extra gain/penalty (as a percentage). In this way, there could also be special > questions, etc, that perhaps give you a better version of the skill, etc. This seems like a good idea to me too, and Mark's proposed method of implementation also makes sense to me. Also, one might want to consider giving small negative bonuses for certain skills to certain classes. For example, perhaps give warlocks a small negative bonus to one/two-handed-weapons skills, and barbarians a small negative bonus to literacy and/or spellcasting when they obtain those skills. Alex Schultz From fuchs.andy at gmail.com Fri Sep 8 17:07:13 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri, 8 Sep 2006 18:07:13 -0400 Subject: [crossfire] The Kirby project: Valkyrie, goddess of war In-Reply-To: <45017492.80004@telus.net> References: <45017492.80004@telus.net> Message-ID: On 9/8/06, Alex Schultz wrote: > One note about how it works currently: the current draft in CVS gives > magic immunity, however one should note that if one has negative > resistance to something like cold, one will still take some damage from > spells that do cold damage, despite 100% magic resistance. The possible role playing description being that, the spell is affecting the player's surroundings, which in turn are damaging the player. I don't see any reason to change this since it helps balance the cult, its just something players might not realize. -- Andrew Fuchs From mwedel at sonic.net Sat Sep 9 01:34:04 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 08 Sep 2006 23:34:04 -0700 Subject: [crossfire] Idea: class has an effect on the amout of experience gained from certian skills In-Reply-To: <4501761C.3030206@telus.net> References: <44FCFD46.8010304@sonic.net> <4501761C.3030206@telus.net> Message-ID: <4502605C.2080702@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> Andrew Fuchs wrote: >> >>> I came up with an idea that would add significance to a player's >>> choice of class, and be an other way to tweak experience. What if >>> skills associated with a class give the player more experience when >>> they are used? >>> >>> >> IMO, it is a good idea. The previous discussion actually had it more general, >> in that there maybe multiple levels of skill gain. >> >> Best way to handle this is by using a field in the skill itself to denote >> extra gain/penalty (as a percentage). In this way, there could also be special >> questions, etc, that perhaps give you a better version of the skill, etc. > This seems like a good idea to me too, and Mark's proposed method of > implementation also makes sense to me. Also, one might want to consider > giving small negative bonuses for certain skills to certain classes. For > example, perhaps give warlocks a small negative bonus to > one/two-handed-weapons skills, and barbarians a small negative bonus to > literacy and/or spellcasting when they obtain those skills. But that gets messy, as how do you know what race/class coincide with what skills for bonuses? the best way would be to have a file someplace that dictates it - you really don't want to have to try and hardcode those. However, IMO, the better way would be to do it in-game. First, different classes start with different skills - some better than others. Spellcasters would generally have 'good' versions of the spellcasting skills, and poor versions of the combat skills. Some of the classes may have mediocre versions of all the skills. Of course, characters don't start with all the skills in the game, so there are still skill scrolls to find. Random skill scrolls you find in dungeons/shops would generally be 'poor' in that you don't get a lot of exp when using the skills. Very rarely, you may find a mediocre one. I'd actually say that you should never be able to find good ones (as good as the best starting one for a class). Perhaps there could be quest tie-ins, but the problem is then at some point, everyone goes on the quest and get the good one. A better method would be prerequisite + a quest. Eg, to get a good version in 1-handed weapon for a mage, they need to be level 40 in the skill and do a quest - if they have put that much effort into the skill, could give them something for it. From nicolas.weeger at laposte.net Sat Sep 9 07:20:33 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 9 Sep 2006 14:20:33 +0200 Subject: [crossfire] Client-side scripting In-Reply-To: <200608261927.52478.nicolas.weeger@laposte.net> References: <200608261927.52478.nicolas.weeger@laposte.net> Message-ID: <200609091420.33078.nicolas.weeger@laposte.net> Hello. Since no one replied, I guess no one objects too much :) So I'll implement that client-side engine someday ^_- Nicolas From subs at eracc.com Sat Sep 9 12:26:11 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Sat, 9 Sep 2006 12:26:11 -0500 Subject: [crossfire] Dragon bite attack Message-ID: <200609091226.12483.subs@eracc.com> I have proposed a bite attack for dragons on sf tracker. Please see the details here: http://sourceforge.net/tracker/index.php?func=detail&aid=1555431&group_id=13833&atid=363833 Discussion? Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 12:24:34 up 7 days, 3:43, 16 users, load average: 0.23, 0.21, 0.18 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From alex_sch at telus.net Sun Sep 10 00:08:23 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 09 Sep 2006 23:08:23 -0600 Subject: [crossfire] Proposal: Alchemy spell changes Message-ID: <45039DC7.8050408@telus.net> The alchemy spell has so long as I can remember been a rather useless spell, and since the shop system change has become increasingly so after the shop system change. I propose that gold nuggets be changed to count as a gem, and hence give their true value in shops just like diamonds, and then reduce the amount of nuggets the alchemy spell makes, from 9/10 of the value, to range from 1/2 to 9/10 value depending on the casting level of alchemy (only getting to 9/10 at level 115 or so). This would make nuggets from the alchemy spell give a way to get decent money for items while not having to look around for the best place to sell as much, but give worse value than what one could get if one searches around, and if one gets very high level sorcery one could get close to the best store value by creating nuggets and selling them. Alex Schultz From mwedel at sonic.net Sun Sep 10 00:14:15 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 09 Sep 2006 22:14:15 -0700 Subject: [crossfire] And the winner is: Message-ID: <45039F27.3000403@sonic.net> And the winner is: SVN The vote was fairly close, but pretty much for any counting method used, the results where basically, SVN, CVS, Mercurial. I'll give a few days for these results to be digested before making the switch to SVN, just in case there are errors. I'll send out a separate e-mail about that change. Voters & Votes: Names Developer BZR CVS Darcs Merc SVN Other Mark Wedel/mwedel F 5 3 4 1 2 Rednaxela/qal21 F 5 3 4 1 2 Ryo/Nicolas Weeger F 5 2 4 3 1 David Delbecq/tchize F 5 2 5 5 1 Gros/Yan Chackhoff I 2 4 5 1 3 Raphael Quinet I 4 1 3 6 2 5 (SVK) Andrew Fuchs/techolous I 2 1 4 5 3 lalo I 1 6 3 2 5 4 (GIT) Andreas Kirschbaum I 3 2 5 4 1 Christian Hujer (cher) RO 4 3 2 5 1 kbulgrien, Rayvin RO 3 1 4 2 5 Rick Tanner/leaf RO 2 1 4 5 3 Note - in many cases, I condensed the names so they would fit in the table - if anyone has questions on names, let me know and I can go back and send out full names Developer types: F = Frequent (average more than once a week) committer I = Infrequent committer (at least once a year, but less than 4/month) RO = Read only access (keep server/client up to date, etc) To use the votengine software that someone pointed out, the above table had to be converted to a ranked choice table. I wrote a quick script to do that - here is that table you can feed to votengine if you want: -cands BZR CVS Darcs Merc SVN Other # Frequent devs Merc SVN CVS Darcs BZR Merc SVN CVS Darcs BZR SVN CVS Merc Darcs BZR SVN CVS # Start of infrequent devs Merc BZR SVN CVS Darcs CVS SVN Darcs BZR Other Merc CVS BZR SVN Darcs Merc BZR Merc Darcs Other SVN CVS SVN CVS BZR Merc Darcs # start of read only access SVN Darcs CVS BZR Merc CVS Merc BZR Darcs SVN CVS BZR SVN Darcs Merc From alex_sch at telus.net Sun Sep 10 00:55:39 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 09 Sep 2006 23:55:39 -0600 Subject: [crossfire] Proposal: Unified event system In-Reply-To: <4500F837.5010101@telus.net> References: <4500F837.5010101@telus.net> Message-ID: <4503A8DB.2070603@telus.net> Alex Schultz wrote: > -For events that return a value, hooks may or may not return a value. > Hooks can be set to active or passive, active ones have a chance of > returning a value whereas passive will not. When an active hook returns > a value, active hooks of lower priority will not be run, though passive > ones still will be. > > -Events with no return value only allow passive hooks > > -For events without return values, hooks may at runtime opt to force > priority 0 (default server internal) or lower, not to run. > I'm a bit uncertain of the rules for active/passive hooks, and of when to not run other hooks, that I proposed here; It just seems a bit arbitrary to me, but it seems like the best idea to me right now, but I'm not comfortable with it. Anyone have any comments on those parts of my proposal? Alex Schultz From nicolas.weeger at laposte.net Sun Sep 10 04:05:38 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 10 Sep 2006 11:05:38 +0200 Subject: [crossfire] Proposal: Unified event system In-Reply-To: <4500F837.5010101@telus.net> References: <4500F837.5010101@telus.net> Message-ID: <200609101105.38774.nicolas.weeger@laposte.net> Hello. I support this proposal. As you say in a later mail, though, the "active/passive" distinction may be unnecessary. But the idea to have hooks in as many places as possible does make sense, so we can have many small plugins doing fun things :) Nicolas From nicolas.weeger at laposte.net Sun Sep 10 04:08:36 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 10 Sep 2006 11:08:36 +0200 Subject: [crossfire] And the winner is: In-Reply-To: <45039F27.3000403@sonic.net> References: <45039F27.3000403@sonic.net> Message-ID: <200609101108.36996.nicolas.weeger@laposte.net> Thanks Mark for handling that poll so nicely :) Nicolas From subs at eracc.com Sun Sep 10 13:15:37 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Sun, 10 Sep 2006 13:15:37 -0500 Subject: [crossfire] Thief player - feature requests Message-ID: <200609101315.38180.subs@eracc.com> The details are here: http://sourceforge.net/tracker/index.php?func=detail&aid=1555884&group_id=13833&atid=363833 http://sourceforge.net/tracker/index.php?func=detail&aid=1555887&group_id=13833&atid=363833 Discussion? Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 13:12:39 up 13:32, 14 users, load average: 0.26, 0.13, 0.17 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From mwedel at sonic.net Sun Sep 10 17:45:25 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 10 Sep 2006 15:45:25 -0700 Subject: [crossfire] Proposal: Alchemy spell changes In-Reply-To: <45039DC7.8050408@telus.net> References: <45039DC7.8050408@telus.net> Message-ID: <45049585.1080408@sonic.net> Alex Schultz wrote: > The alchemy spell has so long as I can remember been a rather useless > spell, and since the shop system change has become increasingly so after > the shop system change. I propose that gold nuggets be changed to count > as a gem, and hence give their true value in shops just like diamonds, > and then reduce the amount of nuggets the alchemy spell makes, from 9/10 > of the value, to range from 1/2 to 9/10 value depending on the casting > level of alchemy (only getting to 9/10 at level 115 or so). This would > make nuggets from the alchemy spell give a way to get decent money for > items while not having to look around for the best place to sell as > much, but give worse value than what one could get if one searches > around, and if one gets very high level sorcery one could get close to > the best store value by creating nuggets and selling them. That seems reasonable to me. And it shouldn't be that hard to make. One of the current issues with alchemy may be at moderate to high levels, the weight of the nuggets created is also too much to reasonably carry. I wonder if it may be worthwhile to make different nugget types (platinum nuggets?) Having a higher denomination nugget doesn't help out if the weight is also higher, which is why going to a different material is needed. OTOH, perhaps the weight of the nuggets should be seen as a way of limiting amount of wealth removed from dungeons From cher at riedquat.de Sun Sep 10 17:50:14 2006 From: cher at riedquat.de (Christian Hujer) Date: Mon, 11 Sep 2006 00:50:14 +0200 Subject: [crossfire] Removing font setting from CFJavaEditor Message-ID: <200609110050.19537.cher@riedquat.de> Hi dear co-devs, I want to remove the feature that allows setting a custom font for CFJavaEditor - at least for a while. Currently it hinders more than it helps, it's kludgy and imo not really worth bothering much. If nobody complains seriously, I'll remove it. You got 8 days to object ;-) (If I'm in the mood of being an axe in the forrest, I'll remove it earlier). Cher -- 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/20060911/542113ae/attachment.pgp From mwedel at sonic.net Sun Sep 10 18:11:03 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 10 Sep 2006 16:11:03 -0700 Subject: [crossfire] CVS -> SVN conversion Message-ID: <45049B87.3050803@sonic.net> As noted in anothe e-mail, SVN won the vote for the source code system for use on crossfire. Next step is to actually switch over. Looking on sourceforge docs, I notice a few things: 1) They don't have a conversion utility, but rather directions (using cvs2svn) to make the change. 2) The CVS respository does not appear it will go away, so after the conversion, both SVN and CVS access will be available. However, only updates should be done to SVN, so CVS will go out of date (but is still probably useful as a reference for older releases). Given this, these are my thoughts: 1) A date for the switchover needs to be chosen. My personal inclination is sooner vs later, yet at the same time, want to give enough time in case people have work in progress that is almost ready to commit (so they don't have to resync/copy into SVN). The flip side of this is that if this is too far away, this could delay people starting working (don't want to be halfway done and then have to sync up again). I'm thinking maybe 9/18 (monday) as the date to switch over? Give people a week to commit their changes, etc. 2) Since CVS will remain on-line, I think the safest thing to do there is revoke everyones read/write access to CVS at said date, since there shouldn't be any reason for anyone to do commits. 3) Since we can decide what files to import or not import, it may be a reasonable time to clean up some of the directories in the CVS root tree right now (eg, not move them to SVN), particularly: alternate_images: These have been merged into the main arch tree long ago. cfclient_sdl: I don't think has been updated in many years - I have a feeling daimonin probably has a more up to date version that should be examined if we're serious about this. client/gnome: hasn't been supported in a long time iso_arch: Like cfclient_sdl above - really not used since daimonin. maps: Been replaced by maps-bigworld. All of these will remain in the Read-only cvs repository, so won't be lost. It just doesn't seem like there is any active development on these, so no reason to have them in SVN. 4) I don't believe the SVN by default provides support for the $Id$ string version control at the top of files. I thik there may be modules that support it, but sourceforge is very particular in what modules they support (short list being ones that provide e-mail notification, and another that checkes file names for reasonable compliance). There may be client side scripts that could be used, but then that seems a little more problematic (some developers forget to use/install them, so their commits are not updated, etc). Does it just make sense to pull the $Id strings out of the files then? 5) I might try uploading a converted repository before the 9/18 date to find any issues - in this case, it could be used for testing, but would be blown away on 9/18 when actual conversion is done. I think that is it - anyone have any other issues/comments? From mwedel at sonic.net Sun Sep 10 18:22:21 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 10 Sep 2006 16:22:21 -0700 Subject: [crossfire] Thief player - feature requests In-Reply-To: <200609101315.38180.subs@eracc.com> References: <200609101315.38180.subs@eracc.com> Message-ID: <45049E2D.5040004@sonic.net> ERACC Subscriptions wrote: > The details are here: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1555884&group_id=13833&atid=363833 > http://sourceforge.net/tracker/index.php?func=detail&aid=1555887&group_id=13833&atid=363833 > > Discussion? Will discuss it here instead of the tracker, since I think discussions work better here: In terms of hide exp - yes, it does seem broken. Looking at the code, it seems there are many things that determine chance of success, yet when it comes to give out exp, we don't look at those modifiers. That doesn't seem right, and is the reason hide exp doesn't go up much (in particular, if there is no specific target to get a level from, it uses the map difficulty, but map difficulties go up much slower than levels do). In terms of items of town portal, one thought I had when discussing classes elsewhere as to have per class guilds. Just like there is the dragon guild, which only dragons can go in, have guilds only for thieves, mages, etc. And in these guilds, perhaps sell such items. However, for this to really work, there has to be some extension to the code, like allowing only certain classes to use certain items. Otherwise, a guild that sells scrolls of town portal isn't really much different than having them in dungeons - thief goes in, buys a bunch, give them to his non thief friends. Also, I'm not sure, but I think mages could currently inscribe such scrolls for his friends. IIRC, there isn't any mechanism for players to make wands or rods however. I personally don't see any issue with giving thieves bargaining by default. And, if we go with some discussions about some classes starting with better versions of the skills than others, I'd think that thieves should actually get one of the better versions of bargaining. From maxdamage at aladin.ro Sun Sep 10 19:28:42 2006 From: maxdamage at aladin.ro (Eduard-Gabriel Munteanu) Date: Mon, 11 Sep 2006 03:28:42 +0300 Subject: [crossfire] (PATCH) GTK2 client v1.9.1 crash on Client->Configure Message-ID: <4504ADBA.1040901@aladin.ro> This a quick, but effective fix. The client dies with SIGSEGV upon entering Client->Configure dialog because it does strcasecmp() on a NULL pointer. I think the client, when first installed and unconfigured, has no want_faceset chosen. Anyway, the bugfix is attached and works like a charm. I hope I didn't miss something. Sorry if it's already in CVS, I didn't have much time to look through already reported/fixed bugs. -------------- next part -------------- A non-text attachment was scrubbed... Name: gtk2_configure_faceset.patch Type: text/x-patch Size: 577 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20060911/fa4cc5eb/attachment.bin From stefan at huehner.org Sun Sep 10 19:31:43 2006 From: stefan at huehner.org (Stefan Huehner) Date: Mon, 11 Sep 2006 02:31:43 +0200 Subject: [crossfire] [patch] cleanup of archetypes 1 Message-ID: <20060911003143.GU13773@pro4u.org> Hi, the attached patch works on the 'Objects using the old spell number instead of having a spell object in their inventory' issue mentioned in [1]. In case of type = 62 aka FIREWALL, the dam field was used before to denote the number of the spell to be cast. This has been replaced by 'other_arch' containing the name of the spell. the attached patch removes some of the dam fields, where the arch already contained the 'other_arch' field. Please double check and consider applying. Regards, Stefan -------------- next part -------------- ? arch.diff Index: wall/firewall/firewall.arc =================================================================== RCS file: /cvsroot/crossfire/arch/wall/firewall/firewall.arc,v retrieving revision 1.7 diff -u -c -1 -5 -u -r1.7 firewall.arc --- wall/firewall/firewall.arc 23 Jul 2006 17:47:59 -0000 1.7 +++ wall/firewall/firewall.arc 11 Sep 2006 00:27:32 -0000 @@ -1,173 +1,164 @@ Object firewall other_arch spell_small_fireball alive 1 level 1 type 62 activate_on_push 1 activate_on_release 1 face earthwall.111 color_fg grey color_bg yellow speed -0.02 hp 250 maxhp 250 -dam 1 ac 3 exp 50 resist_fire 100 blocksview 1 editable 32 visibility 100 end Object firewall_1 other_arch spell_small_fireball name firewall type 62 activate_on_push 1 activate_on_release 1 level 1 face firewall_1.111 color_fg grey color_bg yellow sp 1 -dam 1 speed -0.02 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 end Object firewall_2 other_arch spell_small_fireball name firewall type 62 activate_on_push 1 activate_on_release 1 level 1 face firewall_2.111 color_fg grey color_bg yellow sp 2 -dam 1 speed -0.02 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 end Object firewall_3 other_arch spell_small_fireball name firewall type 62 activate_on_push 1 activate_on_release 1 level 1 face firewall_3.111 color_fg grey color_bg yellow sp 3 -dam 1 speed -0.02 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 end Object firewall_4 other_arch spell_small_fireball name firewall type 62 activate_on_push 1 activate_on_release 1 level 1 face firewall_4.111 color_fg grey color_bg yellow sp 4 -dam 1 speed -0.02 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 end Object firewall_5 other_arch spell_small_fireball name firewall type 62 activate_on_push 1 activate_on_release 1 level 1 face firewall_5.111 color_fg grey color_bg yellow sp 5 -dam 1 speed -0.02 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 end Object firewall_6 other_arch spell_small_fireball name firewall type 62 activate_on_push 1 activate_on_release 1 level 1 face firewall_6.111 color_fg grey color_bg yellow sp 6 -dam 1 speed -0.02 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 end Object firewall_7 other_arch spell_small_fireball name firewall type 62 activate_on_push 1 activate_on_release 1 level 1 face firewall_7.111 color_fg grey color_bg yellow sp 7 -dam 1 speed -0.02 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 end Object firewall_8 other_arch spell_small_fireball name firewall type 62 activate_on_push 1 activate_on_release 1 level 1 face firewall_8.111 color_fg grey color_bg yellow sp 8 -dam 1 speed -0.02 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 end Index: wall/lbulletwall/lbull_wall.arc =================================================================== RCS file: /cvsroot/crossfire/arch/wall/lbulletwall/lbull_wall.arc,v retrieving revision 1.5 diff -u -c -1 -5 -u -r1.5 lbull_wall.arc --- wall/lbulletwall/lbull_wall.arc 23 Jul 2006 17:47:59 -0000 1.5 +++ wall/lbulletwall/lbull_wall.arc 11 Sep 2006 00:27:32 -0000 @@ -9,173 +9,164 @@ anim lbull_wall.111 lbull_wall.121 lbull_wall.131 lbull_wall.141 lbull_wall.151 lbull_wall.161 lbull_wall.171 lbull_wall.181 mina is_animated 0 color_bg yellow speed -0.16 no_pick 1 no_pass 1 -dam 29 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lbulletwall_1 other_arch spell_lg_magic_bullet name large bulletwall type 62 activate_on_push 1 activate_on_release 1 level 1 face lbull_wall.111 color_bg yellow sp 1 -dam 29 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lbulletwall_2 other_arch spell_lg_magic_bullet name large bulletwall type 62 activate_on_push 1 activate_on_release 1 level 1 face lbull_wall.121 color_bg yellow sp 2 -dam 29 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lbulletwall_3 other_arch spell_lg_magic_bullet name large bulletwall type 62 activate_on_push 1 activate_on_release 1 level 1 face lbull_wall.131 color_bg yellow sp 3 -dam 29 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lbulletwall_4 other_arch spell_lg_magic_bullet name large bulletwall type 62 activate_on_push 1 activate_on_release 1 level 1 face lbull_wall.141 color_bg yellow sp 4 -dam 29 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lbulletwall_5 other_arch spell_lg_magic_bullet name large bulletwall type 62 activate_on_push 1 activate_on_release 1 level 1 face lbull_wall.151 color_bg yellow sp 5 -dam 29 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lbulletwall_6 other_arch spell_lg_magic_bullet name large bulletwall type 62 activate_on_push 1 activate_on_release 1 level 1 face lbull_wall.161 color_bg yellow sp 6 -dam 29 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lbulletwall_7 other_arch spell_lg_magic_bullet name large bulletwall type 62 activate_on_push 1 activate_on_release 1 level 1 face lbull_wall.171 color_bg yellow sp 7 -dam 29 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lbulletwall_8 other_arch spell_lg_magic_bullet name large bulletwall type 62 activate_on_push 1 activate_on_release 1 level 1 face lbull_wall.181 color_bg yellow sp 8 -dam 29 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Index: wall/lightningwall/light_wall.arc =================================================================== RCS file: /cvsroot/crossfire/arch/wall/lightningwall/light_wall.arc,v retrieving revision 1.5 diff -u -c -1 -5 -u -r1.5 light_wall.arc --- wall/lightningwall/light_wall.arc 23 Jul 2006 17:47:59 -0000 1.5 +++ wall/lightningwall/light_wall.arc 11 Sep 2006 00:27:32 -0000 @@ -1,23 +1,22 @@ Object lightningwall other_arch spell_sm_lightning name lightningwall type 62 activate_on_push 1 activate_on_release 1 level 1 -dam 5 face light_wall.101 color_bg yellow speed -0.1 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lightningwall_t other_arch spell_sm_lightning name lightningwall type 62 activate_on_push 1 @@ -25,177 +24,168 @@ level 1 face light_wall.111 anim light_wall.111 light_wall.121 light_wall.131 light_wall.141 light_wall.151 light_wall.161 light_wall.171 light_wall.181 mina color_bg yellow sp 1 maxsp 1 -dam 5 is_animated 0 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lightningwall_1 other_arch spell_sm_lightning name lightningwall type 62 activate_on_push 1 activate_on_release 1 level 1 face light_wall.111 color_bg yellow sp 1 -dam 5 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lightningwall_2 other_arch spell_sm_lightning name lightningwall type 62 activate_on_push 1 activate_on_release 1 level 1 face light_wall.121 color_bg yellow sp 2 speed -0.04 no_pick 1 no_pass 1 -dam 5 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lightningwall_3 other_arch spell_sm_lightning name lightningwall type 62 activate_on_push 1 activate_on_release 1 level 1 face light_wall.131 color_bg yellow sp 3 -dam 5 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lightningwall_4 other_arch spell_sm_lightning name lightningwall type 62 activate_on_push 1 activate_on_release 1 level 1 face light_wall.141 color_bg yellow sp 4 -dam 5 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lightningwall_5 other_arch spell_sm_lightning name lightningwall type 62 activate_on_push 1 activate_on_release 1 level 1 face light_wall.151 color_bg yellow sp 5 -dam 5 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lightningwall_6 other_arch spell_sm_lightning name lightningwall type 62 activate_on_push 1 activate_on_release 1 level 1 face light_wall.161 color_bg yellow sp 6 -dam 5 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lightningwall_7 other_arch spell_sm_lightning name lightningwall type 62 activate_on_push 1 activate_on_release 1 level 1 face light_wall.171 color_bg yellow sp 7 -dam 5 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end Object lightningwall_8 other_arch spell_sm_lightning name lightningwall type 62 activate_on_push 1 activate_on_release 1 level 1 face light_wall.181 color_bg yellow sp 8 -dam 5 speed -0.04 no_pick 1 no_pass 1 blocksview 1 editable 32 visibility 100 magicmap yellow end From alex_sch at telus.net Sun Sep 10 20:12:51 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 10 Sep 2006 19:12:51 -0600 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <45049B87.3050803@sonic.net> References: <45049B87.3050803@sonic.net> Message-ID: <4504B813.7070100@telus.net> Mark Wedel wrote: > 2) The CVS respository does not appear it will go away, so after the conversion, > both SVN and CVS access will be available. However, only updates should be done > to SVN, so CVS will go out of date (but is still probably useful as a reference > for older releases). IMHO it's not worth doing, but in theory it would be possible to use a tool like tailor to incrementally update the CVS copy every so often. I don't think it would be awfully useful, however just pointing this out in case someone does think something like that would be useful. > > 3) Since we can decide what files to import or not import, it may be a > reasonable time to clean up some of the directories in the CVS root tree right > now (eg, not move them to SVN), particularly: > > alternate_images: These have been merged into the main arch tree long ago. > cfclient_sdl: I don't think has been updated in many years - I have a feeling > daimonin probably has a more up to date version that should be examined if we're > serious about this. > client/gnome: hasn't been supported in a long time > iso_arch: Like cfclient_sdl above - really not used since daimonin. > maps: Been replaced by maps-bigworld. > > This seems like a good idea to me. Also, perhaps we shouldn't move CFJavaEditor, and instead use 'svn:externals' (See http://svnbook.red-bean.com/en/1.0/ch07s03.html) to link to Gridarta's copy of CFJavaEditor in their SVN repository. To do so would be something along the lines of this inside of a new empty CFJavaEditor svn repository: svn propset svn:externals 'https://svn.sourceforge.net/svnroot/gridarta/trunk/crossfire' . Which would effectively redirect svn clients to that url to download it if they would try something like a "svn checkout https://svn.sourceforge.net/svnroot/crossfire/CFJavaeditor". This makes sense to me because active CFJavaEditor development is happening in the Gridarta project, and if the old history is needed for historical reasons we have the cvs repository of it around. > 4) I don't believe the SVN by default provides support for the $Id$ string > version control at the top of files. I thik there may be modules that support > it, but sourceforge is very particular in what modules they support (short list > being ones that provide e-mail notification, and another that checkes file names > for reasonable compliance). There may be client side scripts that could be > used, but then that seems a little more problematic (some developers forget to > use/install them, so their commits are not updated, etc). Does it just make > sense to pull the $Id strings out of the files then? > Well, the $Id strings have never seemed terribly useful to me (it was often more convenient for me to just check the timestamp of the build and/or source directory if I wanted to know when in CVS it was built from), however if anyone has any use for them, probably wouldn't be difficult to make a script to generate a .h file containing macros of that data, and put that in as part of the build system. > 5) I might try uploading a converted repository before the 9/18 date to find any > issues - in this case, it could be used for testing, but would be blown away on > 9/18 when actual conversion is done. > Would be be nice to have a testing one uploaded a bit early. For one, this would give people a chance to fiddle around with how various svn things (branches, svk local branches, bzr-svn local branches, etc.) would work on on the crossfire tree ahead of time. Alex Schultz From alex_sch at telus.net Sun Sep 10 20:26:15 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 10 Sep 2006 19:26:15 -0600 Subject: [crossfire] (PATCH) GTK2 client v1.9.1 crash on Client->Configure In-Reply-To: <4504ADBA.1040901@aladin.ro> References: <4504ADBA.1040901@aladin.ro> Message-ID: <4504BB37.1050203@telus.net> Eduard-Gabriel Munteanu wrote: > This a quick, but effective fix. The client dies with SIGSEGV upon > entering Client->Configure dialog because it does strcasecmp() on a NULL > pointer. I think the client, when first installed and unconfigured, has > no want_faceset chosen. > > Anyway, the bugfix is attached and works like a charm. I hope I didn't > miss something. Sorry if it's already in CVS, I didn't have much time to > look through already reported/fixed bugs. I discovered this bug a while back and another developer fixed it in CVS a month or two ago. Thanks anyways. Alex Schultz From alex_sch at telus.net Sun Sep 10 20:28:52 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 10 Sep 2006 19:28:52 -0600 Subject: [crossfire] Thief player - feature requests In-Reply-To: <45049E2D.5040004@sonic.net> References: <200609101315.38180.subs@eracc.com> <45049E2D.5040004@sonic.net> Message-ID: <4504BBD4.8090105@telus.net> Mark Wedel wrote: > Also, I'm not sure, but I think mages could currently inscribe such scrolls > for his friends. IIRC, there isn't any mechanism for players to make wands or > rods however. Just to confirm, yes one can inscribe town portal scrolls currently, I have done it numerous times and it's rather helpful :) Alex Schultz From lalo.martins at gmail.com Sun Sep 10 21:40:00 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 11 Sep 2006 10:40:00 +0800 Subject: [crossfire] Proposal: Alchemy spell changes References: <45039DC7.8050408@telus.net> <45049585.1080408@sonic.net> Message-ID: On Sun, 10 Sep 2006 15:45:25 -0700, Mark Wedel wrote: > One of the current issues with alchemy may be at moderate to high levels, the > weight of the nuggets created is also too much to reasonably carry. I wonder if > it may be worthwhile to make different nugget types (platinum nuggets?) ... > OTOH, perhaps the weight of the nuggets should be seen as a way of > limiting > amount of wealth removed from dungeons IMO that's a non-issue, on such a high level you'll probably have town portal. 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 Sep 10 22:26:33 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 10 Sep 2006 21:26:33 -0600 Subject: [crossfire] Proposal: Alchemy spell changes In-Reply-To: <45049585.1080408@sonic.net> References: <45039DC7.8050408@telus.net> <45049585.1080408@sonic.net> Message-ID: <4504D769.7080707@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> The alchemy spell has so long as I can remember been a rather useless >> spell, and since the shop system change has become increasingly so after >> the shop system change. I propose that gold nuggets be changed to count >> as a gem, and hence give their true value in shops just like diamonds, >> and then reduce the amount of nuggets the alchemy spell makes, from 9/10 >> of the value, to range from 1/2 to 9/10 value depending on the casting >> level of alchemy (only getting to 9/10 at level 115 or so). This would >> make nuggets from the alchemy spell give a way to get decent money for >> items while not having to look around for the best place to sell as >> much, but give worse value than what one could get if one searches >> around, and if one gets very high level sorcery one could get close to >> the best store value by creating nuggets and selling them. >> > > That seems reasonable to me. And it shouldn't be that hard to make. Ok, I'll probably have it implemented in the next 48 hours or so :) Btw, does anyone have any objections to renaming it to "gold touch" (was thinking of "transmute to gold" but that seems too long), to avoid current confusion with the alchemy skill? Alex Schultz From mwedel at sonic.net Sun Sep 10 23:37:51 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 10 Sep 2006 21:37:51 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <4504B813.7070100@telus.net> References: <45049B87.3050803@sonic.net> <4504B813.7070100@telus.net> Message-ID: <4504E81F.309@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> 2) The CVS respository does not appear it will go away, so after the conversion, >> both SVN and CVS access will be available. However, only updates should be done >> to SVN, so CVS will go out of date (but is still probably useful as a reference >> for older releases). > IMHO it's not worth doing, but in theory it would be possible to use a > tool like tailor to incrementally update the CVS copy every so often. I > don't think it would be awfully useful, however just pointing this out > in case someone does think something like that would be useful. Not sure about tailor, but IIRC, one of the issues with most of these conversion tools is they do not deal with branches very well (probably because the branch methods vary wildly - in the case of SVN, branches are basically new copies of the repository). I forgot to mention in my previous e-mail, one of the first things I'll do once we move to SVN is to make a branch for the 1.x releases (with the main/head branch being for 2.x). > >> >> 3) Since we can decide what files to import or not import, it may be a >> reasonable time to clean up some of the directories in the CVS root tree right >> now (eg, not move them to SVN), particularly: >> >> alternate_images: These have been merged into the main arch tree long ago. >> cfclient_sdl: I don't think has been updated in many years - I have a feeling >> daimonin probably has a more up to date version that should be examined if we're >> serious about this. >> client/gnome: hasn't been supported in a long time >> iso_arch: Like cfclient_sdl above - really not used since daimonin. >> maps: Been replaced by maps-bigworld. >> >> > This seems like a good idea to me. Also, perhaps we shouldn't move > CFJavaEditor, and instead use 'svn:externals' (See > http://svnbook.red-bean.com/en/1.0/ch07s03.html) to link to Gridarta's > copy of CFJavaEditor in their SVN repository. To do so would be > something along the lines of this inside of a new empty CFJavaEditor svn > repository: > > svn propset svn:externals 'https://svn.sourceforge.net/svnroot/gridarta/trunk/crossfire' . > Which would effectively redirect svn clients to that url to download it if they would try something like a "svn checkout https://svn.sourceforge.net/svnroot/crossfire/CFJavaeditor". This makes sense to me because active CFJavaEditor development is happening in the Gridarta project, and if the old history is needed for historical reasons we have the cvs repository of it around. > could do that. But then I wonder if that makes sense, or if whatever docs should just be updated to point to the gridarta repository. One reason here is developer permissions - if it is in the crossfire SVN root, people may expect that since they have crossfire SVN write permissions, they should be able to make updates to it - however, if it is a link, they won't. All that said, if CFJavaEditor has been superseded by gridarta, then it doesn't make sense to have a copy in the crossfire tree - so the question more becomes should a redirection be done, or just nothing at all? >> 4) I don't believe the SVN by default provides support for the $Id$ string >> version control at the top of files. I thik there may be modules that support >> it, but sourceforge is very particular in what modules they support (short list >> being ones that provide e-mail notification, and another that checkes file names >> for reasonable compliance). There may be client side scripts that could be >> used, but then that seems a little more problematic (some developers forget to >> use/install them, so their commits are not updated, etc). Does it just make >> sense to pull the $Id strings out of the files then? >> > Well, the $Id strings have never seemed terribly useful to me (it was > often more convenient for me to just check the timestamp of the build > and/or source directory if I wanted to know when in CVS it was built > from), however if anyone has any use for them, probably wouldn't be > difficult to make a script to generate a .h file containing macros of > that data, and put that in as part of the build system. The client had been modified at one point to provide that information, just to be more helpful in bug reports. That said, I agree that the header in each file probably isn't necessary. It might be nice to include the svn commit number in a header file, so that could be displayed, eg, the client could say something like: Crossfire Client 1.10 build 8963 Such that if a user reports a bug, we can easily check that global revision number and see if the bug may have been fixed, etc. From mwedel at sonic.net Mon Sep 11 01:36:46 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 10 Sep 2006 23:36:46 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <45049B87.3050803@sonic.net> References: <45049B87.3050803@sonic.net> Message-ID: <450503FE.5000604@sonic.net> Another question for everyone: It has been commented/asked several times in the past whether the automatically generated files should be in the repository, or if it should be up to the developer to rebuild them. There are several types of files, and my general thoughts: flex files that generate .c (loader.c) - not a big space user, yet at the same time, pretty trivial for most people to generate (probably any system that has gcc can pretty easily install flex if not already there). The flex files do not change very often. The one question might be windows (can they easily be regenerated there?). Given these are small files, I'm sort of mixed on these. The version of flex used to generate these files really doesn't have any impact on performance - I don't think we've ever had an issue where someone had a bad version of flex installed that caused problems. autoconf/automake generated files: These change less frequently, and aclocal/automake/autoconf may not be installed as frequently. OTOH, autoconf is re-run for each release, since that is where the version number is stored, so it is not like having these in the repository helps out a whole bunch (what really counts is the version of those tools on the person who makes the release). It's also a bit nicer to be able to checkout a repository and run the 'standard' configure/make and get a working product, and not have to run autoconf/automake/autowhatever. rebuilt lib files (Archetypes, images, etc): These are the files I'm most inclined to leave out of SVN. The images tend to be quite big (slowing down updates). Plus, the updates are rather inconsistent - they are not updated after every change is made to an arch, but rather when someone remembers to or is some critical need. Within SVN, we can set up lib/arch to point to the actual arch tree, so an update of the server also gets updated arches. Plus, we already have all the tools in place to collect them (the collect.pl script), so this doesn't add any additional software dependencies. If anything, this may actually help people use the updated archs. The only thing which I'm not sure if there is any way to do is have some file, ideally automatically created, that sits in the arch tree so that the server can know that the archs have changed and it should do a collect. One can manually run the command now, and there is a hidden timestamp file, but that file doesn't do any good if it never changes. As a note, for any files that we automatically generate that are not normally in SVN (if we so decide) yet are in the distributions we ship out, I'd expect they would be in the release branch of the SVN repository for that release (so you can go to the 1.10 branch and see what the archetypes file had, or see what the makefile looked like, etc). Although, maybe even that is useless - could always just download the old releases. From lalo.martins at gmail.com Mon Sep 11 04:44:14 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 11 Sep 2006 17:44:14 +0800 Subject: [crossfire] cosmologic theory of the evolution of a crossfire hero Message-ID: Heroes are measured in levels, which are a measure of his experience and skill. Levels started out in the Old Empire as a system to determine what spells a magic-user was able to use, but were later formalised trough tests and theories to all other skills, from jumping to literacy. There is also an "overall level", known by some as "heroic level"; heroes of higher level seem to be able to withstand more damage, and control more powerful artifacts. According to the priest-scholars of the Occidental Schools, each hero goes potentially trough five stages: Chaos (up to level 23) is when the hero becomes a hero; there will be only a few developed skills, and they deal mostly with weak monsters. This does mean, however, these are the heroes we see the most, as they're constantly saving our homes for goblins or undead. Discord (up to level 46) is typically when heroes die the most, while trying to figure what kinds of quests and monster they can handle best, and what are the techniques best suited to them. Confusion (up to level 69) is a stage where the heroes start developing so quick, they often don't see the levels going by, and sometimes don't even know very clearly what they're doing. Bureaucracy (up to level 92) is an extreme reaction to Confusion; the heroes decide to put some method to their evolution, up to the point that it gets almost boring. Aftermath is when they overgrow Bureaucracy and start on the path to demigodhood. It is believed that demigods have level 115. And blessed be the Many-Named in Her perfect work. 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 tchize at myrealbox.com Mon Sep 11 04:17:24 2006 From: tchize at myrealbox.com (Tchize) Date: Mon, 11 Sep 2006 11:17:24 +0200 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <4504E81F.309@sonic.net> References: <45049B87.3050803@sonic.net> <4504B813.7070100@telus.net> <4504E81F.309@sonic.net> Message-ID: <450529A4.1010901@myrealbox.com> Mark Wedel a ?crit : >>> 4) I don't believe the SVN by default provides support for the $Id$ string >>> version control at the top of files. I thik there may be modules that support >>> it, but sourceforge is very particular in what modules they support (short list >>> being ones that provide e-mail notification, and another that checkes file names >>> for reasonable compliance). There may be client side scripts that could be >>> used, but then that seems a little more problematic (some developers forget to >>> use/install them, so their commits are not updated, etc). Does it just make >>> sense to pull the $Id strings out of the files then? >>> >>> >> Well, the $Id strings have never seemed terribly useful to me (it was >> often more convenient for me to just check the timestamp of the build >> and/or source directory if I wanted to know when in CVS it was built >> from), however if anyone has any use for them, probably wouldn't be >> difficult to make a script to generate a .h file containing macros of >> that data, and put that in as part of the build system. >> > > The client had been modified at one point to provide that information, just to > be more helpful in bug reports. > > That said, I agree that the header in each file probably isn't necessary. It > might be nice to include the svn commit number in a header file, so that could > be displayed, eg, the client could say something like: > > Crossfire Client 1.10 build 8963 > > Such that if a user reports a bug, we can easily check that global revision > number and see if the bug may have been fixed, etc. > > Yes client has been modified in past to provide id of different modules. However those were made because CVS had no notion of global version numbers and it was the most easy way to find out which cvs version the user was using when reporting bug. Using the global svn revision number + branch can replace this Crossfire gtk client 2.1.0 (/branches/XYZW/client revision 1234) Branch name is important to include in bug report as well as revision number :-) From alex_sch at telus.net Mon Sep 11 11:26:33 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 11 Sep 2006 16:26:33 +0000 (UTC) Subject: [crossfire] CVS -> SVN conversion References: <45049B87.3050803@sonic.net> <4504B813.7070100@telus.net> <4504E81F.309@sonic.net> <450529A4.1010901@myrealbox.com> Message-ID: Tchize writes: > Crossfire gtk client 2.1.0 (/branches/XYZW/client revision 1234) > Branch name is important to include in bug report as well as revision > number This seems like a good idea to me. A couple notes though: -I think version number should have "-dev" appended if it's from svn, only removed for releases. -If it's from the trunk branch, probably would be good to make the message just like: Crossfire gtk client 2.1.0-dev (trunk revision 1234) as opposed to including the full branch path. -If it's from an unofficial (not on sf.net) branch, it should make the message like: Crossfire gtk client 2.1.0-dev (http://foo.bar.baz/svnroot/crossfire revision 1234) using the full path/url to the svn repository in place of "branches/XYZW/client" -Would it be a good idea to also put support for some other version control systems in the script to make the revision strings? I think it would be a good idea if it isn't too difficult, because making local branches of an svn repository can be easy with svk and bzr-svn, both of which can pull and push with normal svn repositories. Alex Schultz From subs at eracc.com Mon Sep 11 12:18:53 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 11 Sep 2006 12:18:53 -0500 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <45049B87.3050803@sonic.net> References: <45049B87.3050803@sonic.net> Message-ID: <200609111218.54290.subs@eracc.com> On Sunday 10 September 2006 06:11 pm Mark Wedel wrote: > 1) A date for the switchover needs to be chosen. ?My personal inclination > is sooner vs later, yet at the same time, want to give enough time in case > people have work in progress that is almost ready to commit (so they don't > have to resync/copy into SVN). ?The flip side of this is that if this is > too far away, this could delay people starting working (don't want to be > halfway done and then have to sync up again). ?I'm thinking maybe 9/18 > (monday) as the date to switch over? ?Give people a week to commit their > changes, etc. I have put work on all my map edits on hold until the conversion. I have no clue how to use SVN to download updates and commit updates. Do we have a simple FAQ on how to do this using ssh/id/password? (I hate using keys) I specifically need command line usage information for SVN as relates to sourceforge.net. IOW what is the equivalent of: cvs -z3 -d:ext:eracc at crossfire.cvs.sourceforge.net:/cvsroot/crossfire co maps-bigworld ... and ... cvs -d:ext:eracc at crossfire.cvs.sourceforge.net:/cvsroot/crossfire commit If I have developer download and commit access in CVS will that automagically be included in SVN? TIA, Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 12:09:25 up 1 day, 12:28, 14 users, load average: 0.43, 0.29, 0.25 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From stefan at huehner.org Mon Sep 11 12:30:16 2006 From: stefan at huehner.org (Stefan Huehner) Date: Mon, 11 Sep 2006 19:30:16 +0200 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <200609111218.54290.subs@eracc.com> References: <45049B87.3050803@sonic.net> <200609111218.54290.subs@eracc.com> Message-ID: <20060911173015.GV13773@pro4u.org> On Mon, Sep 11, 2006 at 12:18:53PM -0500, ERACC Subscriptions wrote: > On Sunday 10 September 2006 06:11 pm > Mark Wedel wrote: > > I have put work on all my map edits on hold until the conversion. I have no > clue how to use SVN to download updates and commit updates. Do we have a > simple FAQ on how to do this using ssh/id/password? (I hate using keys) I > specifically need command line usage information for SVN as relates to > sourceforge.net. IOW what is the equivalent of: > > cvs -z3 -d:ext:eracc at crossfire.cvs.sourceforge.net:/cvsroot/crossfire co maps-bigworld svn co https://eracc at svn.sourceforge.net/svnroot/crossfire/trunk/maps-bigworld where trunk specifies the HEAD branch, instead of a specific branch for i.e. 1.x development > > cvs -d:ext:eracc at crossfire.cvs.sourceforge.net:/cvsroot/crossfire commit When you are working inside your working copy, svn already has all of the information regarding to the repo-location so it is simply: 'svn ci' or 'svn commit' More info can be found at 'http://sourceforge.net/docs/E09' Regards, Stefan From lalo.martins at gmail.com Mon Sep 11 14:06:41 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 12 Sep 2006 03:06:41 +0800 Subject: [crossfire] CVS -> SVN conversion References: <45049B87.3050803@sonic.net> Message-ID: I don't know if you were even planning to, but for the record, don't bother converting my pupland branch. It's easier for me to do it manually (or rather, from the existing bzr branch), since the conversion will be lossless -- Subversion and bzr understand file and directory moves, while CVS doesn't, and lots of the work I've done is directory moves. 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 Mon Sep 11 15:09:40 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon, 11 Sep 2006 16:09:40 -0400 Subject: [crossfire] Proposal: Alchemy spell changes In-Reply-To: <4504D769.7080707@telus.net> References: <45039DC7.8050408@telus.net> <45049585.1080408@sonic.net> <4504D769.7080707@telus.net> Message-ID: On 9/10/06, Lalo Martins wrote: > On Sun, 10 Sep 2006 15:45:25 -0700, Mark Wedel wrote: ... > > OTOH, perhaps the weight of the nuggets should be seen as a way of > > limiting > > amount of wealth removed from dungeons > > IMO that's a non-issue, on such a high level you'll probably have town > portal. Thus the desire of some developers to add an attributes to regions, that disable spells like town portal, and word of recall. On 9/10/06, Alex Schultz wrote: ... > Ok, I'll probably have it implemented in the next 48 hours or so :) > Btw, does anyone have any objections to renaming it to "gold touch" (was > thinking of "transmute to gold" but that seems too long), to avoid > current confusion with the alchemy skill? Renaming it is probably a good idea. IIRC, players have used the spell on cauldrons before. -- Andrew Fuchs From leaf at real-time.com Mon Sep 11 15:23:42 2006 From: leaf at real-time.com (Rick Tanner) Date: Mon, 11 Sep 2006 15:23:42 -0500 Subject: [crossfire] Proposal: Alchemy spell changes In-Reply-To: References: <45039DC7.8050408@telus.net> <45049585.1080408@sonic.net> <4504D769.7080707@telus.net> Message-ID: <4505C5CE.5090208@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Fuchs wrote: > > On 9/10/06, Alex Schultz wrote: > ... >> Ok, I'll probably have it implemented in the next 48 hours or so :) >> Btw, does anyone have any objections to renaming it to "gold touch" (was >> thinking of "transmute to gold" but that seems too long), to avoid >> current confusion with the alchemy skill? > > Renaming it is probably a good idea. IIRC, players have used the > spell on cauldrons before. - From what I have seen, that's mostly due to out of date documentation or similar information. That's one way how alchemy was used in the past. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFBcXOhHyvgBp+vH4RAntsAJ9d1srk6cqvHpRbKg6uHfAW4vyRVACgoqwX 1coPREYiQYxuyxCEKN+QW88= =zdHp -----END PGP SIGNATURE----- From cher at riedquat.de Mon Sep 11 17:10:28 2006 From: cher at riedquat.de (Christian Hujer) Date: Tue, 12 Sep 2006 00:10:28 +0200 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <45049B87.3050803@sonic.net> References: <45049B87.3050803@sonic.net> Message-ID: <200609120010.34828.cher@riedquat.de> Hi all, Am Montag, 11. September 2006 01:11 schrieb Mark Wedel: > 1) They don't have a conversion utility, but rather directions (using > cvs2svn) to make the change. Well, they used to have a conversion utility: https://sourceforge.net/project/admin/svn_migration.php?group_id=nnnnnn (Replace nnnnnn with the project id of crossfire) Instructions: https://sourceforge.net/docs/E09#import But actually I never got that migration tool working, it always failed for me. > 2) The CVS respository does not appear it will go away, so after the > conversion, both SVN and CVS access will be available. However, only > updates should be done to SVN, so CVS will go out of date (but is still > probably useful as a reference for older releases). Yep. > 1) A date for the switchover needs to be chosen. Yes. > 2) Since CVS will remain on-line, I think the safest thing to do there is > revoke everyones read/write access to CVS at said date, since there > shouldn't be any reason for anyone to do commits. Yes. And remove the CVS link from the project page after a while. It's possible to disable the CVS link on the admin page. > 4) I don't believe the SVN by default provides support for the $Id$ string > version control at the top of files. It does. It only has to be switched on for each file individually. It's done via svn propset svn:keywords Id filename For instance: cd sandbox ; find -type f -print0 | xargs -0 svn propset svn:keywords Id or if it's not that many files, especially none with whitespace in their name cd sandbox ; svn propset svn:keywords Id $(find -type f) On the svn:externals issue for Gridarta: Actually, if somebody uses Subversion, from a Subversion point of view I'd say it's expected that some parts of the repository actually might be read only, either because it's configured that way (it's possible with Subversion in general, though not available at SourceForge), or because it's an external. I think the svn:externals is a nice feature worth using it. I see the following Pros: * It won't change much for existing developers. * If somebody wants to change something and hasn't write access on Gridarta, we can put him on the project. * When thinking of Ragnor, I assume he'd really like the svn:externals solution. * Server side, svn:externals is nothing but a file property. No overhead. I also see the following Cons: * It's something not every CF developer automatically has write access to. * Developers not interested in Gridarta would still be forced to checkout Gridarta. (Afaik svn:externals are fetched automatically during update) What I know for sure is that we (Gridarta) will use svn:externals quite a lot in future, not only for accessing Crossfire. Cu all :) -- 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/20060912/796b51e5/attachment.pgp From alex_sch at telus.net Mon Sep 11 18:22:12 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 11 Sep 2006 17:22:12 -0600 Subject: [crossfire] Proposal: Alchemy spell changes In-Reply-To: <4505C5CE.5090208@real-time.com> References: <45039DC7.8050408@telus.net> <45049585.1080408@sonic.net> <4504D769.7080707@telus.net> <4505C5CE.5090208@real-time.com> Message-ID: <4505EFA4.2020901@telus.net> Rick Tanner wrote: > Andrew Fuchs wrote: > >> On 9/10/06, Alex Schultz wrote: > >> ... > >>> Ok, I'll probably have it implemented in the next 48 hours or so :) > >>> Btw, does anyone have any objections to renaming it to "gold > touch" (was > >>> thinking of "transmute to gold" but that seems too long), to avoid > >>> current confusion with the alchemy skill? > >> Renaming it is probably a good idea. IIRC, players have used the > >> spell on cauldrons before. > > - From what I have seen, that's mostly due to out of date documentation or > similar information. That's one way how alchemy was used in the past. It probably is, though it seems to me like it would better to make them named different, even if documentation isn't out of date saying to use the alchemy spell on cauldrons anymore. At very least, it avoids the ambiguity in conversation when players say "alchemy" which out saying which. Alex Schultz From subs at eracc.com Mon Sep 11 18:29:11 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 11 Sep 2006 18:29:11 -0500 Subject: [crossfire] Broken show invisible - scrolls, wands, staves and rods Message-ID: <200609111829.12488.subs@eracc.com> Show invisible scrolls, wands, staves and rods appear to be broken (at least on current metalforge). Details here: http://sourceforge.net/tracker/index.php?func=detail&aid=1556723&group_id=13833&atid=113833 Please fix it. Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 18:27:14 up 1 day, 18:46, 14 users, load average: 1.37, 0.44, 0.26 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From alex_sch at telus.net Mon Sep 11 19:28:20 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 11 Sep 2006 18:28:20 -0600 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <200609120010.34828.cher@riedquat.de> References: <45049B87.3050803@sonic.net> <200609120010.34828.cher@riedquat.de> Message-ID: <4505FF24.1050808@telus.net> Christian Hujer wrote: >> 4) I don't believe the SVN by default provides support for the $Id$ string >> version control at the top of files. >> > It does. It only has to be switched on for each file individually. > It's done via > svn propset svn:keywords Id filename > For instance: > cd sandbox ; find -type f -print0 | xargs -0 svn propset svn:keywords Id > or if it's not that many files, especially none with whitespace in their name > cd sandbox ; svn propset svn:keywords Id $(find -type f) > Oh, didn't know that. Well I think we may want to use the globl revision number instead of each file as stated in the other section of the thread anyways. (looking at the docs for svn:keywords, we would probably want to use something like $Rev$) > > On the svn:externals issue for Gridarta: > > > * Developers not interested in Gridarta would still be forced to checkout > Gridarta. (Afaik svn:externals are fetched automatically during update) > Well, that's assuming that developers do a checkout of the maps, client, server, archetypes, etc. in one checkout, as opposed to checking each out separately (though SVN doesn't have modules, one can always check out the server directory without the map directory) Alex Schultz From mwedel at sonic.net Tue Sep 12 00:02:14 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 11 Sep 2006 22:02:14 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: References: <45049B87.3050803@sonic.net> Message-ID: <45063F56.5020208@sonic.net> Lalo Martins wrote: > I don't know if you were even planning to, but for the record, don't > bother converting my pupland branch. It's easier for me to do it manually > (or rather, from the existing bzr branch), since the conversion will be > lossless -- Subversion and bzr understand file and directory moves, while > CVS doesn't, and lots of the work I've done is directory moves. Can you provide more info on what should be exclude (branch-tag?) It is easy enough to exclude it in the conversion. From alex_sch at telus.net Tue Sep 12 00:19:31 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 11 Sep 2006 23:19:31 -0600 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <45063F56.5020208@sonic.net> References: <45049B87.3050803@sonic.net> <45063F56.5020208@sonic.net> Message-ID: <45064363.6070808@telus.net> Mark Wedel wrote: > Lalo Martins wrote: > >> I don't know if you were even planning to, but for the record, don't >> bother converting my pupland branch. It's easier for me to do it manually >> (or rather, from the existing bzr branch), since the conversion will be >> lossless -- Subversion and bzr understand file and directory moves, while >> CVS doesn't, and lots of the work I've done is directory moves. >> > > Can you provide more info on what should be exclude (branch-tag?) It is easy > enough to exclude it in the conversion. I believe he means the branch by the name "lalo-pupland". Alex Schultz From mwedel at sonic.net Tue Sep 12 00:22:35 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 11 Sep 2006 22:22:35 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <200609120010.34828.cher@riedquat.de> References: <45049B87.3050803@sonic.net> <200609120010.34828.cher@riedquat.de> Message-ID: <4506441B.60000@sonic.net> Christian Hujer wrote: > Hi all, > > Am Montag, 11. September 2006 01:11 schrieb Mark Wedel: >> 1) They don't have a conversion utility, but rather directions (using >> cvs2svn) to make the change. > Well, they used to have a conversion utility: > https://sourceforge.net/project/admin/svn_migration.php?group_id=nnnnnn > (Replace nnnnnn with the project id of crossfire) > > Instructions: > https://sourceforge.net/docs/E09#import > > But actually I never got that migration tool working, it always failed for me. That's what I used, but it doesn't do the conversion for you - running cvs2svn still has to be done by the end user, etc. Given that, whatever files we care about can be removed from the copy of the CVS data before it being converted, so we can clear out any data we want to. If this was 100% automatic, we wouldn't really be able to do that. >> 4) I don't believe the SVN by default provides support for the $Id$ string >> version control at the top of files. > It does. It only has to be switched on for each file individually. > It's done via > svn propset svn:keywords Id filename > For instance: > cd sandbox ; find -type f -print0 | xargs -0 svn propset svn:keywords Id > or if it's not that many files, especially none with whitespace in their name > cd sandbox ; svn propset svn:keywords Id $(find -type f) Ah - very good. Looking at the docs, I see that SVN uses the global version number in the $Id$ strings, which is fine. What I'm not sure of is if there is some way to have a file that automatically gets updated with the latest version string. For example, it would be nice for the version.h file to get updated on every commit that is done, so that it always contains the latest commit ID. If that was done, there really isn't any need to have the $Id$ in each file - just print that global number. sure, there can be the odd cases of a person updating only portions of the tree and getting out of sync revision numbers. But if someone does that, they are really asking for broken behaviour anyways (who is to say that there isn't some interaction related to this - a file that isn't updated needs to be updated to properly work with other files) From mwedel at sonic.net Tue Sep 12 00:37:04 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 11 Sep 2006 22:37:04 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <45064363.6070808@telus.net> References: <45049B87.3050803@sonic.net> <45063F56.5020208@sonic.net> <45064363.6070808@telus.net> Message-ID: <45064780.1000704@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> Lalo Martins wrote: >> >>> I don't know if you were even planning to, but for the record, don't >>> bother converting my pupland branch. It's easier for me to do it manually >>> (or rather, from the existing bzr branch), since the conversion will be >>> lossless -- Subversion and bzr understand file and directory moves, while >>> CVS doesn't, and lots of the work I've done is directory moves. >>> >> Can you provide more info on what should be exclude (branch-tag?) It is easy >> enough to exclude it in the conversion. > I believe he means the branch by the name "lalo-pupland". What I think I'll probably do is only import the main trunk from CVS. There really isn't any reason to import any of the branches - those will still exist in CVS, and I don't think any of them are active. From mwedel at sonic.net Tue Sep 12 00:35:30 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 11 Sep 2006 22:35:30 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <4505FF24.1050808@telus.net> References: <45049B87.3050803@sonic.net> <200609120010.34828.cher@riedquat.de> <4505FF24.1050808@telus.net> Message-ID: <45064722.10004@sonic.net> Alex Schultz wrote: > Well, that's assuming that developers do a checkout of the maps, > client, server, archetypes, etc. in one checkout, as opposed to checking > each out separately (though SVN doesn't have modules, one can always > check out the server directory without the map directory) Actually, from what I gather, it seems unlikely someone would do a svn checkout at the top of the repository. The reason being is that if you do that, you'll also get all the branches, which would amount to a pretty huge amount of data. I doubt people would even checkout out all the trunks, but maybe wrong on that. So that probably isn't as much an issue. From mwedel at sonic.net Tue Sep 12 00:51:20 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 11 Sep 2006 22:51:20 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: References: <45049B87.3050803@sonic.net> <4504B813.7070100@telus.net> <4504E81F.309@sonic.net> <450529A4.1010901@myrealbox.com> Message-ID: <45064AD8.8070902@sonic.net> Alex Schultz wrote: > Tchize writes: >> Crossfire gtk client 2.1.0 (/branches/XYZW/client revision 1234) >> Branch name is important to include in bug report as well as revision >> number > This seems like a good idea to me. A couple notes though: > -I think version number should have "-dev" appended if it's from svn, only > removed for releases. I'm not sure if that is really necessary. From the global revision number, you can sort of know the status. But this may be more an issue for how the branches are handled. What I'd probably say is something like this: When a release is made, a branch is done. In that branch, the version would be changed to match the release (1.10, 1.11, etc). In the main branch (rel-1-x), the version gets updated to be something like 1.10-CVS, 1.11-CVS, etc, to denote that portion is CVS. That is basically what you are saying, just clarifies how it is done. It is also completely possible that what is in main branch of CVS is same as last release. EG, if a release is done, with the branch, and the tag is updated in the main head, and you do a checkout, it will still say 1.11-CVS, even though there are no practical changes of it from the release. But that is probably fine. > -If it's from the trunk branch, probably would be good to make the message just > like: > Crossfire gtk client 2.1.0-dev (trunk revision 1234) > as opposed to including the full branch path. > -If it's from an unofficial (not on sf.net) branch, it should make the message > like: > Crossfire gtk client 2.1.0-dev (http://foo.bar.baz/svnroot/crossfire revision > 1234) > using the full path/url to the svn repository in place of "branches/XYZW/client" svn has a HeadURL property. It doesn't distinguish what the URL is. I think it is reasonable to use that. That way, when brances are done, it is automatically up to date. And of course, if someone makes a branch outside of sourceforge, at that time, it is sort of out of our control. However, if we use the SVN properly for HeadURL, unless the person doing that branch intentionally changes/resets something, it should get updated properly. > -Would it be a good idea to also put support for some other version control > systems in the script to make the revision strings? I think it would be a good > idea if it isn't too difficult, because making local branches of an svn > repository can be easy with svk and bzr-svn, both of which can pull and push > with normal svn repositories. This isn't a script we are using, but rather built in feature of the svn server. I don't believe it is possible for us to add server side SVN scripts (sourceforge limits that), and client side scripts are sure to have issues (some people don't have the scripts, etc), unless the script is part of the SVN repository itself. From alex_sch at telus.net Tue Sep 12 01:16:14 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 12 Sep 2006 00:16:14 -0600 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <45064AD8.8070902@sonic.net> References: <45049B87.3050803@sonic.net> <4504B813.7070100@telus.net> <4504E81F.309@sonic.net> <450529A4.1010901@myrealbox.com> <45064AD8.8070902@sonic.net> Message-ID: <450650AE.5060300@telus.net> Mark Wedel wrote: >> -Would it be a good idea to also put support for some other version control >> systems in the script to make the revision strings? I think it would be a good >> idea if it isn't too difficult, because making local branches of an svn >> repository can be easy with svk and bzr-svn, both of which can pull and push >> with normal svn repositories. >> > This isn't a script we are using, but rather built in feature of the svn > server. I don't believe it is possible for us to add server side SVN scripts > (sourceforge limits that), and client side scripts are sure to have issues (some > people don't have the scripts, etc), unless the script is part of the SVN > repository itself. I posted that message before it was mentioned that SVN could do this. Also, I didn't mean a "client side" or "server side" script in the way you mean, I meant as part of the build system, but anyways that doesn't matter as SVN does support revision strings. Alex Schultz From alex_sch at telus.net Tue Sep 12 01:26:50 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 12 Sep 2006 00:26:50 -0600 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <4506441B.60000@sonic.net> References: <45049B87.3050803@sonic.net> <200609120010.34828.cher@riedquat.de> <4506441B.60000@sonic.net> Message-ID: <4506532A.5030901@telus.net> Mark Wedel wrote: > Ah - very good. > > Looking at the docs, I see that SVN uses the global version number in the $Id$ > strings, which is fine. > > What I'm not sure of is if there is some way to have a file that > automatically gets updated with the latest version string. > I don't believe there is. That difficulty is mentioned on the subversion FAQ (http://subversion.tigris.org/faq.html#version-value-in-source) and it's solution is to integrate the "svnversion" command where available into the build process for the program, and to me that seems a more reasonable method than using $Id$ strings, given this issue of only certain files getting $Id$ or $Revision$ keywords replaced when updating the checkout Alex Schultz From lalo.martins at gmail.com Tue Sep 12 11:34:01 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 13 Sep 2006 00:34:01 +0800 Subject: [crossfire] CVS -> SVN conversion References: <45049B87.3050803@sonic.net> <45063F56.5020208@sonic.net> <45064363.6070808@telus.net> <45064780.1000704@sonic.net> Message-ID: On Mon, 11 Sep 2006 22:37:04 -0700, Mark Wedel wrote: > What I think I'll probably do is only import the main trunk from CVS. There > really isn't any reason to import any of the branches - those will still exist > in CVS, and I don't think any of them are active. That's what I figured. 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 Tue Sep 12 12:21:55 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 12 Sep 2006 19:21:55 +0200 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <450503FE.5000604@sonic.net> References: <45049B87.3050803@sonic.net> <450503FE.5000604@sonic.net> Message-ID: <200609121921.55458.nicolas.weeger@laposte.net> > flex files that generate .c (loader.c) - not a big space user, yet at the > same time, pretty trivial for most people to generate (probably any system > that has gcc can pretty easily install flex if not already there). The > flex files do not change very often. The one question might be windows > (can they easily be regenerated there?). Given these are small files, I'm > sort of mixed on these. The version of flex used to generate these files > really doesn't have any impact on performance - I don't think we've ever > had an issue where someone had a bad version of flex installed that caused > problems. Windows users can generate loader.c with flex, already done that. Just need to ensure the right flags are used (iirc case-insensitivity, for instance). > rebuilt lib files (Archetypes, images, etc): These are the files I'm most > inclined to leave out of SVN. The images tend to be quite big (slowing > down updates). Plus, the updates are rather inconsistent - they are not > updated after every change is made to an arch, but rather when someone > remembers to or is some critical need. Within SVN, we can set up lib/arch > to point to the actual arch tree, so an update of the server also gets > updated arches. Plus, we already have all the tools in place to collect > them (the collect.pl script), so this doesn't add any additional software > dependencies. If anything, this may actually help people use the updated > archs. The only issue with that is that archs would now be part of the whole "crossfire" module. Thus changing an arch will make a new server version. Unless i'm wrong? BTW, while we're at messing with stuff, shouldn't "crossfire" be renamed to "server"? > As a note, for any files that we automatically generate that are not > normally in SVN (if we so decide) yet are in the distributions we ship out, > I'd expect they would be in the release branch of the SVN repository for > that release (so you can go to the 1.10 branch and see what the archetypes > file had, or see what the makefile looked like, etc). Although, maybe even > that is useless - could always just download the old releases. As a remark, I'd say to automate stuff as much as possible in that case. That is make a nice script building everything, collecting archetypes, generating tarballs, all this stuff. Even if it only takes 15m to do by hand, that becomes a pain fast :) (talking from Windows experience, where i should definitely automate things!) Nicolas From cher at riedquat.de Tue Sep 12 12:58:37 2006 From: cher at riedquat.de (Christian Hujer) Date: Tue, 12 Sep 2006 19:58:37 +0200 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <45064722.10004@sonic.net> References: <45049B87.3050803@sonic.net> <4505FF24.1050808@telus.net> <45064722.10004@sonic.net> Message-ID: <200609121958.42870.cher@riedquat.de> On Tuesday 12 September 2006 07:35 Mark Wedel wrote: > Actually, from what I gather, it seems unlikely someone would do a svn > checkout at the top of the repository. > > The reason being is that if you do that, you'll also get all the > branches, which would amount to a pretty huge amount of data. > > I doubt people would even checkout out all the trunks, but maybe wrong on > that. So that probably isn't as much an issue. Did you already think about how to organize the repository? The main question is: Do you want to apply ttb to maps, client, server etc. independently or one for all? Module-Individual ttb: //trunk //tags //branches Global ttb: /trunk/ /tags/ /branches/ Technically, I'd usually prefer the Module-individual ttb. If so, it would be a good idea to provide a virtual module named complete (or something better, I'll just assume the name "complete" for this example), probably with trunk only, where trunk has svn:externals set to include the trunks of the other modules: cd complete; svn propset svn:externals "maps https://subversion.sourceforge.net/svnroot/crossfire/maps/trunk client https://subversion.sourceforge.net/svnroot/crossfire/client/trunk" etc.. 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/20060912/ace14c7f/attachment.pgp From alex_sch at telus.net Tue Sep 12 17:25:05 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 12 Sep 2006 16:25:05 -0600 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <200609121921.55458.nicolas.weeger@laposte.net> References: <45049B87.3050803@sonic.net> <450503FE.5000604@sonic.net> <200609121921.55458.nicolas.weeger@laposte.net> Message-ID: <450733C1.4030005@telus.net> Nicolas Weeger (Laposte) wrote: >> rebuilt lib files (Archetypes, images, etc): These are the files I'm most >> inclined to leave out of SVN. The images tend to be quite big (slowing >> down updates). Plus, the updates are rather inconsistent - they are not >> updated after every change is made to an arch, but rather when someone >> remembers to or is some critical need. Within SVN, we can set up lib/arch >> to point to the actual arch tree, so an update of the server also gets >> updated arches. Plus, we already have all the tools in place to collect >> them (the collect.pl script), so this doesn't add any additional software >> dependencies. If anything, this may actually help people use the updated >> archs. >> > > The only issue with that is that archs would now be part of the > whole "crossfire" module. Thus changing an arch will make a new server > version. > Unless i'm wrong? > SVN doesn't have a concept of modules, instead it would simply be directories containing each, but one can check out an individual directory just as easily as if it was a module, and acts for most intents as a module. Due to that, a the revision number would increment as you say, regardless of if we leave the collected archetypes out or not. IMHO that's not a bad thing, as much as simply the way things are. > BTW, while we're at messing with stuff, shouldn't "crossfire" be renamed > to "server"? > Or perhaps "cfserver" instead and make the client "cfclient"? Alex Schultz From alex_sch at telus.net Tue Sep 12 17:31:16 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 12 Sep 2006 16:31:16 -0600 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <450733C1.4030005@telus.net> References: <45049B87.3050803@sonic.net> <450503FE.5000604@sonic.net> <200609121921.55458.nicolas.weeger@laposte.net> <450733C1.4030005@telus.net> Message-ID: <45073534.4060606@telus.net> Alex Schultz wrote: > SVN doesn't have a concept of modules, instead it would simply be > directories containing each, but one can check out an individual > directory just as easily as if it was a module, and acts for most > intents as a module. Due to that, a the revision number would increment > as you say, regardless of if we leave the collected archetypes out or > not. IMHO that's not a bad thing, as much as simply the way things are. > Ok, I'm a fool, ignore most of what I just said there, it depends on how we have the "ttb" set up (see Christian Hujer's mail on that), but either way I don't think whether we leave collected archetypes of not will affect it Alex Schultz From alex_sch at telus.net Tue Sep 12 17:41:16 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 12 Sep 2006 16:41:16 -0600 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <450503FE.5000604@sonic.net> References: <45049B87.3050803@sonic.net> <450503FE.5000604@sonic.net> Message-ID: <4507378C.8090204@telus.net> Mark Wedel wrote: > Another question for everyone: > > It has been commented/asked several times in the past whether the > automatically generated files should be in the repository, or if it should be up > to the developer to rebuild them. There are several types of files, and my > general thoughts: > > Seems like good ideas to me. > The only thing which I'm not sure if there is any way to do is have some file, > ideally automatically created, that sits in the arch tree so that the server can > know that the archs have changed and it should do a collect. One can manually > run the command now, and there is a hidden timestamp file, but that file doesn't > do any good if it never changes. > I don't think there's a way to automatically update such a file, unless we could get special permission from sf.net to use a custom serverside hook, however I doubt they would allow it. However, if we store the arch tree and server tree with separate "ttb" as mentioned in Christian Hujer's mail, we might be able to use svn revision numbers to determine if it's been updated. > As a note, for any files that we automatically generate that are not normally > in SVN (if we so decide) yet are in the distributions we ship out, I'd expect > they would be in the release branch of the SVN repository for that release (so > you can go to the 1.10 branch and see what the archetypes file had, or see what > the makefile looked like, etc). Although, maybe even that is useless - could > always just download the old releases. Seems like a good idea. As noted by Nicolas it would probably be nice to automate that process to some degree as well. Alex Schultz From mwedel at sonic.net Wed Sep 13 00:46:20 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 12 Sep 2006 22:46:20 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <200609121958.42870.cher@riedquat.de> References: <45049B87.3050803@sonic.net> <4505FF24.1050808@telus.net> <45064722.10004@sonic.net> <200609121958.42870.cher@riedquat.de> Message-ID: <45079B2C.2060709@sonic.net> Christian Hujer wrote: > On Tuesday 12 September 2006 07:35 Mark Wedel wrote: >> Actually, from what I gather, it seems unlikely someone would do a svn >> checkout at the top of the repository. >> >> The reason being is that if you do that, you'll also get all the >> branches, which would amount to a pretty huge amount of data. >> >> I doubt people would even checkout out all the trunks, but maybe wrong on >> that. So that probably isn't as much an issue. > Did you already think about how to organize the repository? > > The main question is: Do you want to apply ttb to maps, client, server etc. > independently or one for all? > > Module-Individual ttb: > //trunk > //tags > //branches > > Global ttb: > /trunk/ > /tags/ > /branches/ > > Technically, I'd usually prefer the Module-individual ttb. > If so, it would be a good idea to provide a virtual module named complete (or > something better, I'll just assume the name "complete" for this example), > probably with trunk only, where trunk has svn:externals set to include the > trunks of the other modules: > cd complete; > svn propset svn:externals "maps > https://subversion.sourceforge.net/svnroot/crossfire/maps/trunk > client https://subversion.sourceforge.net/svnroot/crossfire/client/trunk" > etc.. It will be module individual ttb - that is the default, and I think the best way to go - keeps things like branches and what not a bit more managable. This also matches the current CVS setup - there are different top level entries that can be checked out. SVN does present some more options, since external references can be done, etc. I'm not sure how much use an ability to check out all the main trunks would get used - maybe for the home hacker. But I imagine for most public servers, they probably don't want the editor or client, etc. But I suppose there is no real harm to add something like that, whether or not people use it or not. From mwedel at sonic.net Wed Sep 13 00:59:50 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 12 Sep 2006 22:59:50 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <200609121921.55458.nicolas.weeger@laposte.net> References: <45049B87.3050803@sonic.net> <450503FE.5000604@sonic.net> <200609121921.55458.nicolas.weeger@laposte.net> Message-ID: <45079E56.9010804@sonic.net> Nicolas Weeger (Laposte) wrote: >> flex files that generate .c (loader.c) - not a big space user, yet at the >> same time, pretty trivial for most people to generate (probably any system >> that has gcc can pretty easily install flex if not already there). The >> flex files do not change very often. The one question might be windows >> (can they easily be regenerated there?). Given these are small files, I'm >> sort of mixed on these. The version of flex used to generate these files >> really doesn't have any impact on performance - I don't think we've ever >> had an issue where someone had a bad version of flex installed that caused >> problems. > > Windows users can generate loader.c with flex, already done that. Just need to > ensure the right flags are used (iirc case-insensitivity, for instance). Ok - so maybe leave out the flex generated files then. > >> rebuilt lib files (Archetypes, images, etc): These are the files I'm most >> inclined to leave out of SVN. The images tend to be quite big (slowing >> down updates). Plus, the updates are rather inconsistent - they are not >> updated after every change is made to an arch, but rather when someone >> remembers to or is some critical need. Within SVN, we can set up lib/arch >> to point to the actual arch tree, so an update of the server also gets >> updated arches. Plus, we already have all the tools in place to collect >> them (the collect.pl script), so this doesn't add any additional software >> dependencies. If anything, this may actually help people use the updated >> archs. > > The only issue with that is that archs would now be part of the > whole "crossfire" module. Thus changing an arch will make a new server > version. > Unless i'm wrong? If my understanding correct, the revision number will be unique for each of the different modules (arch, client, etc). Even if it isn't, that really isn't much different than if we have the collected ones - then when you collect the archetypes and check them in, that is updating the revision number, even though nothing in the server really changed. Right now, the archetypes file is not updated every time and arch file is updated, but in theory it could be. If anything, not having the collected files in the server tree would mean less server revisions. Maybe 1 out of 10 (or 20) commits to the server is just a recollection of the archetypes, etc, and those wouldn't be needed anymore > > BTW, while we're at messing with stuff, shouldn't "crossfire" be renamed > to "server"? There is really two issues here: 1) What is the module called within SVN. In this case, I agree we should rename it server. 2) What is the executable that module makes is called. This is really independent of the point above. It should be renamed crossfire-server of cf-server of the like, but that is a change that should be made in the main head branch for the 2.0 release. > >> As a note, for any files that we automatically generate that are not >> normally in SVN (if we so decide) yet are in the distributions we ship out, >> I'd expect they would be in the release branch of the SVN repository for >> that release (so you can go to the 1.10 branch and see what the archetypes >> file had, or see what the makefile looked like, etc). Although, maybe even >> that is useless - could always just download the old releases. > > As a remark, I'd say to automate stuff as much as possible in that case. That > is make a nice script building everything, collecting archetypes, generating > tarballs, all this stuff. Even if it only takes 15m to do by hand, that > becomes a pain fast :) > (talking from Windows experience, where i should definitely automate things!) The makefiles will already recollect archetypes and build the flex files as needed. So in a sense, the only extra work is to add those files in the repository. But that part can certainly be in a script. From mwedel at sonic.net Wed Sep 13 01:09:51 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 12 Sep 2006 23:09:51 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <45079B2C.2060709@sonic.net> References: <45049B87.3050803@sonic.net> <4505FF24.1050808@telus.net> <45064722.10004@sonic.net> <200609121958.42870.cher@riedquat.de> <45079B2C.2060709@sonic.net> Message-ID: <4507A0AF.2000008@sonic.net> > > It will be module individual ttb - that is the default, and I think the best > way to go - keeps things like branches and what not a bit more managable. > Actually, it isn't the default, but easy enough to do it that way. From mwedel at sonic.net Wed Sep 13 01:59:29 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 12 Sep 2006 23:59:29 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <4507A0AF.2000008@sonic.net> References: <45049B87.3050803@sonic.net> <4505FF24.1050808@telus.net> <45064722.10004@sonic.net> <200609121958.42870.cher@riedquat.de> <45079B2C.2060709@sonic.net> <4507A0AF.2000008@sonic.net> Message-ID: <4507AC51.5060508@sonic.net> Mark Wedel wrote: >> It will be module individual ttb - that is the default, and I think the best >> way to go - keeps things like branches and what not a bit more managable. >> > Actually, it isn't the default, but easy enough to do it that way. Except I can't see a way to do it in sourceforge. To do it, you would need multiple repositories. However, best I can tell, with sourceforge, 1 project == 1 repository. So to do this on sourceforge would entail having multiple projects, which gets into other administrative issues (each project would have its own developer lists with permissions, etc). From mwedel at sonic.net Wed Sep 13 02:31:33 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 13 Sep 2006 00:31:33 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <45049B87.3050803@sonic.net> References: <45049B87.3050803@sonic.net> Message-ID: <4507B3D5.7070101@sonic.net> A copy of the crossfire data is now in svn. Note: This is only a test copy for experimentation, and will be blown away on Monday Sept 18. Do not commit any real changes - still put those in CVS. to check it out: svn co https://svn.sourceforge.net/svnroot/crossfire/trunk/{client|arch|crossfire, etc} edit files. To commit: svn commit I had some issues getting the commit to work, but now that it is working, it seems to cache the data. I think the issue may be that while the developer permissions within sourceforge show that everyone has SVN access (everyone that is a developer), things started working better when I unchecked that for myself, updated it, then checked it again, and updated. Probably a matter of it having to put some files in the svn tree. I haven't gone through and updated everyones permissions for that - it'd be curious if this is the real fix, or in my mucking of other things, I fixed the problem. From alex_sch at telus.net Thu Sep 14 23:10:04 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 14 Sep 2006 22:10:04 -0600 Subject: [crossfire] Proposal: Alchemy spell changes In-Reply-To: <45039DC7.8050408@telus.net> References: <45039DC7.8050408@telus.net> Message-ID: <450A279C.6070206@telus.net> Alex Schultz wrote: > from 9/10 > of the value, to range from 1/2 to 9/10 value depending on the casting > level of alchemy (only getting to 9/10 at level 115 or so). I have done some tests, and found that when nuggets are gems, that is far too generous. Here are the results of my tests: ------- type: Amulet real: 200 plat reckon: 136 plat Cha: 30 Bargaining: No cost at scorn (gem): 505 plat Best selling location per-town: red town: 14 plat (general) scorn: 28 plat (magic) navar 41 plat (magic) wolfsburg (department: weapon/armor) lone town: 43 plat (magic) nurnburg: 45 plat (gem) port joseph: 53 plat (general) santo: 73 plat (magic) stoneville: 97 plat (adventerous) new alchemy: ratio * 194 plat (when nuggets count as gems, sell for 97% of set nugget value. ratio being whatever ratio of value the alchemy spell will be set to use) ------- So based on these tests, I believe that instead of 1/2 to 9/10 over levels 3 to 115 as I first proposed, it would be best to make it from 5% to 40% over casting level 3 to 33. Does this seem reasonable to others? Alex Schultz From alex_sch at telus.net Thu Sep 14 23:30:12 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 14 Sep 2006 22:30:12 -0600 Subject: [crossfire] Dragon bite attack In-Reply-To: <200609091226.12483.subs@eracc.com> References: <200609091226.12483.subs@eracc.com> Message-ID: <450A2C54.5090100@telus.net> ERACC Subscriptions wrote: > I have proposed a bite attack for dragons on sf tracker. Please see the > details here: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1555431&group_id=13833&atid=363833 > > Discussion? > > Gene Alexander > Hmm, a bite attack as you propose would be good IMHO, except I'm not sure paralyze would be a good choice. I'm mainly thinking this because paralyze that is part of melee can tend to be overpowered due to the opponent being near-constantly paralyzed (yes, IMO clamity is somewhat overpowered, though the difficulty of getting it offsets that a bit). That said, if the biting was rare enough (i.e. less than 1% of hits), or paralyze attacktype was only in the bite a very small amount of the time (10% of bites), then a paralyze bite would be more reasonable. Alex Schultz From alex_sch at telus.net Thu Sep 14 23:46:31 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 14 Sep 2006 22:46:31 -0600 Subject: [crossfire] The Kirby project: Valkyrie, goddess of war In-Reply-To: References: <45017492.80004@telus.net> Message-ID: <450A3027.2060209@telus.net> Andrew Fuchs wrote: > On 9/8/06, Alex Schultz wrote: > >> One note about how it works currently: the current draft in CVS gives >> magic immunity, however one should note that if one has negative >> resistance to something like cold, one will still take some damage from >> spells that do cold damage, despite 100% magic resistance. >> > > The possible role playing description being that, the spell is > affecting the player's surroundings, which in turn are damaging the > player. I don't see any reason to change this since it helps balance > the cult, its just something players might not realize. Agreed, I don't think it should be changed either, just pointing that out as it's something that many might not realize. Alex Schultz From alex_sch at telus.net Sat Sep 16 15:25:20 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 16 Sep 2006 14:25:20 -0600 Subject: [crossfire] Proposal: Alchemy spell changes In-Reply-To: <450A279C.6070206@telus.net> References: <45039DC7.8050408@telus.net> <450A279C.6070206@telus.net> Message-ID: <450C5DB0.8080305@telus.net> Alex Schultz wrote: > Alex Schultz wrote: > >> from 9/10 >> of the value, to range from 1/2 to 9/10 value depending on the casting >> level of alchemy (only getting to 9/10 at level 115 or so). >> > I have done some tests, and found that when nuggets are gems, that is > far too generous. Here are the results of my tests: > > > So based on these tests, I believe that instead of 1/2 to 9/10 over > levels 3 to 115 as I first proposed, it would be best to make it from 5% > to 40% over casting level 3 to 33. Does this seem reasonable to others? Since there seems to be no objections, I've implemented this in CVS. (also, because it makes things simpler, I made the range from 3 to 38 instead of to 33 formula simpler) Alex Schultz From edler at heydernet.de Sat Sep 16 19:28:38 2006 From: edler at heydernet.de (Bernd Edler) Date: Sun, 17 Sep 2006 02:28:38 +0200 (CEST) Subject: [crossfire] Proposal: Alchemy spell changes In-Reply-To: <450A279C.6070206@telus.net> References: <45039DC7.8050408@telus.net> <450A279C.6070206@telus.net> Message-ID: On Thu, 14 Sep 2006, Alex Schultz wrote: > Alex Schultz wrote: > real: 200 plat > reckon: 136 plat > > Cha: 30 > Bargaining: No > > Best selling location per-town: > santo: 73 plat (magic) ---> 2nd > stoneville: 97 plat (adventerous) ---> best price > new alchemy: ratio * 194 plat (when nuggets count as gems, sell for 97% > of set nugget value. ratio being whatever ratio of value the alchemy > spell will be set to use) With a max ratio of 0.4 this is still far too generous imo. 0.4 * 194 = 77.6 --> only one town gives a better price! And one would have to lug the item back and through the shops to find this optimal price. Bargaining does not make much of a difference. And if one has only Cha 28 or so... While with gems neither charisma nor bargaining are relevant. And any shop will do. At least change the formula from 1% point per level to 1 every 3 levels. Then it would take spell level 3 to 108. Else, every mid-level caster can make more money with the alchemy spell than with a lengthy sales tour. From alex_sch at telus.net Sat Sep 16 21:07:39 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 16 Sep 2006 20:07:39 -0600 Subject: [crossfire] Proposal: Alchemy spell changes In-Reply-To: References: <45039DC7.8050408@telus.net> <450A279C.6070206@telus.net> Message-ID: <450CADEB.3020906@telus.net> Bernd Edler wrote: > With a max ratio of 0.4 this is still far too generous imo. > > 0.4 * 194 = 77.6 > --> only one town gives a better price! > > And one would have to lug the item back and through the shops to find > this optimal price. > Bargaining does not make much of a difference. > And if one has only Cha 28 or so... > While with gems neither charisma nor bargaining are relevant. > And any shop will do. > > At least change the formula from 1% point per level to > 1 every 3 levels. Then it would take spell level 3 to 108. > > Else, every mid-level caster can make more money with the > alchemy spell than with a lengthy sales tour. Hmm, true. I think I'll make it a max ratio of 0.35, but I will leave it at 1% point per level, because I want the effect of leveling to be noticeable before one starts getting very high level summoning. (besides, by the time most characters have level 33 summoning, they are at least level 50 overall usually, and already can get to most shops easily.) Alex Schultz From mwedel at sonic.net Sat Sep 16 23:27:53 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 16 Sep 2006 21:27:53 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <45049B87.3050803@sonic.net> References: <45049B87.3050803@sonic.net> Message-ID: <450CCEC9.10506@sonic.net> Just a note/reminder of this change: Crossfire will switch from CVS to SVN this onday, Sept 18. What will happen: - Current CVS repository will remain available for read-only access, but no future changes will be made to that repository. The CVS repository will purely be for historical reasons (want to see what 1.6 looked like, etc.) Developer permissions will be updated to remove CVS write permissions. The crossfire page on sourceforge will also be updated so that CVS info will not appear. - The SVN repository will only import the head trunk, and not the tags or branches of the CVS repository. Future tags and branches will be made of course. - Only actively developed portions from CVS will be moved over. - Instead of having a copy of the editor in crossfire, we will link to the Gridarta project. - Some amount of cleanup in the repositories will be done - mainly, this means that some automatically generated files will not be included (flex files, collected archetypes/images/etc). The autoconf/automake files will stay in the repository, as it is general practice that code can be downloaded and then a simple configure run. - The server portion will be renamed from 'crossfire' to 'server' to more accurately describe what portion it is. - The organization will be server/trunk, client/trunk, client/branches, etc. After the fact: - The server and client will need some updating to get the version number so they can print that out as a build revision (instead of showing revision of each file). - Branches for 1.x will be made for the different components. - Likely some other cleanup will be necessary. From nicolas.weeger at laposte.net Sun Sep 17 02:59:05 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 17 Sep 2006 09:59:05 +0200 Subject: [crossfire] Client-side scripting In-Reply-To: <200608261927.52478.nicolas.weeger@laposte.net> References: <200608261927.52478.nicolas.weeger@laposte.net> Message-ID: <200609170959.05139.nicolas.weeger@laposte.net> Hello. I've finished a first basic version. Patch is available on tracker at https://sourceforge.net/tracker/index.php?func=detail&aid=1560052&group_id=13833&atid=313833 Feel free to test, comment, flame, whatever :) I plan to commit that at some point if no objection. I may add some stuff, and mess with makefiles, but i could use some help maybe :) Nicolas From nicolas.weeger at laposte.net Sun Sep 17 03:19:46 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 17 Sep 2006 10:19:46 +0200 Subject: [crossfire] Client-side scripting In-Reply-To: <200609170959.05139.nicolas.weeger@laposte.net> References: <200608261927.52478.nicolas.weeger@laposte.net> <200609170959.05139.nicolas.weeger@laposte.net> Message-ID: <200609171019.46325.nicolas.weeger@laposte.net> Small note: you need to do LIBS="-llua -llualib -lm -ldl" ./configure to correctly make it work (missing libs else) Nicolas From mwedel at sonic.net Sun Sep 17 03:23:58 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 17 Sep 2006 01:23:58 -0700 Subject: [crossfire] New crossfire todo list Message-ID: <450D061E.9020505@sonic.net> I've taken a bit of time to go through and make a new todo list of most things that need to be done: http://wiki.metalforge.net/doku.php/dev_todo_new There is still more stuff to add. It's unclear at what complexity level something should be there, vs a bug on the tracker or just go and do it, but I'll think more about that later. I also see that as becoming the definitive TODO list, replacing the one in the server directory which is always out of date, and doesn't really provide much in the way of tracking. I've added comments to a fair number of the items there. In no way does that mean that is the definitive, or even correct, way of doing it. I was mostly just trying to gather the useful bits from past mails, etc, and put it there vs sitting in my mailbox. I'd also suggest that it is generally better to actually pull out the useful bits of the conversation and put them in the wiki vs referring to the mailing list - too often, it may be a thread of 50 messages, with most not providing much useful info - its a bit more handy to just be able to see the main points. A few notes/questions. In looking through the TODO list in the server, some questions about these points: If a shop is placed in a random map (special map), the objects below the shop wall stick around - normally not much a problem, unless it is placed in a glory hole (treasure level), in which case coins are now beneath the wall. (I seem to recall seeing a recent commit that may have fixed this?) Change code so that if a player kills another player, he gets no exp (I recall seeing discussions about this, but don't see anything in the settings to suggest that this has been done?) Allow possibility of one players magic not harming another player (isn't this what the friendly fire option does, so this should be removed?) Ability for stores to set different prices for goods (The shopitems code only affects how much you can sell stuff for, not buy stuff, correct? If so, this is still valid) - Change inscription - instead of looking at range field of the player, have the spell to be inscribed part of the inscription command, eg 'inscribe scroll of identify' (is this still something that needs to be done?) - Generalize the code better - split between 'rules' and 'engine' (see TODO for more info - wonder if we really want to go that route - the code re-orgs as suggested is different from this, so maybe it just goes away as something TODO?) From alex_sch at telus.net Sun Sep 17 09:34:06 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 17 Sep 2006 08:34:06 -0600 Subject: [crossfire] New crossfire todo list In-Reply-To: <450D061E.9020505@sonic.net> References: <450D061E.9020505@sonic.net> Message-ID: <450D5CDE.9020304@telus.net> Mark Wedel wrote: > - Change inscription - instead of looking at range field of the player, > have the spell to be inscribed part of the inscription command, eg > 'inscribe scroll of identify' > (is this still something that needs to be done?) > Yes. When inscribing spell scrolls, one needs to do something along the lines of "mark scroll-to-inscribe-over; cast meteor swarm; use_skill inscription". The change suggested there would make it so one would use something like "mark scroll-to-inscribe-over; use_skill inscription meteor swarm" instead. > - Generalize the code better - split between 'rules' and 'engine' > (see TODO for more info - wonder if we really want to go that route - the code > re-orgs as suggested is different from this, so maybe it just goes away as > something TODO?) Personally I don't think we want to go that route, however the suggested code re-orgs such as what I proposed a while back in the mailing list, would as a side affect make splitting the 'rules' and 'engine' easier, if at any point we decided we wanted to. IMHO we should do the code re-orgs and decide if we want to split the 'rules' and 'engine' after. Alex Schultz From mwedel at sonic.net Sun Sep 17 18:32:28 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 17 Sep 2006 16:32:28 -0700 Subject: [crossfire] New crossfire todo list In-Reply-To: <450D5CDE.9020304@telus.net> References: <450D061E.9020505@sonic.net> <450D5CDE.9020304@telus.net> Message-ID: <450DDB0C.60707@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> - Change inscription - instead of looking at range field of the player, >> have the spell to be inscribed part of the inscription command, eg >> 'inscribe scroll of identify' >> (is this still something that needs to be done?) >> > Yes. When inscribing spell scrolls, one needs to do something along the > lines of "mark scroll-to-inscribe-over; cast meteor swarm; use_skill > inscription". The change suggested there would make it so one would use > something like "mark scroll-to-inscribe-over; use_skill inscription > meteor swarm" instead. This should probably be taken to the next step, with the client providing some nicer dialogue for this, eg, a menu item like 'inscribe scroll'. The client would then present list of possible items (based on client type attribute) and list of spells, and player chooses. Of course, the client still has to send the actual request to the server, and the server would still have to validate if it works. Thinking about this, the logic for this on the server side could actually do most of the work with very little changes. Eg, client does something like: C->S: inscribe The server side command for that could find the object of scroll tag, save away current marked object, mark the scroll object, store away current ready spell, ready new spell, call inscribe code, and then put back the marked object and ready spell. OTOH, would probably be better for the inscribe code to take the inscribe to object and spell object and just go from that, as that would be cleaner. I am really thinking, however, that having the client handle most of the presentation of this is the better way to go. > >> - Generalize the code better - split between 'rules' and 'engine' >> (see TODO for more info - wonder if we really want to go that route - the code >> re-orgs as suggested is different from this, so maybe it just goes away as >> something TODO?) > Personally I don't think we want to go that route, however the suggested > code re-orgs such as what I proposed a while back in the mailing list, > would as a side affect make splitting the 'rules' and 'engine' easier, > if at any point we decided we wanted to. IMHO we should do the code > re-orgs and decide if we want to split the 'rules' and 'engine' after. And I'm not sure how much reason there is to split the rules and engine in any case. But if it is easy to do that, that could help in the testing actions perhaps. From alex_sch at telus.net Sun Sep 17 22:25:44 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 17 Sep 2006 21:25:44 -0600 Subject: [crossfire] New crossfire todo list In-Reply-To: <450DDB0C.60707@sonic.net> References: <450D061E.9020505@sonic.net> <450D5CDE.9020304@telus.net> <450DDB0C.60707@sonic.net> Message-ID: <450E11B8.2050604@telus.net> Mark Wedel wrote: > This should probably be taken to the next step, with the client providing some > nicer dialogue for this, eg, a menu item like 'inscribe scroll'. The client > would then present list of possible items (based on client type attribute) and > list of spells, and player chooses. > > Of course, the client still has to send the actual request to the server, and > the server would still have to validate if it works. Thinking about this, the > logic for this on the server side could actually do most of the work with very > little changes. Eg, client does something like: > > C->S: inscribe > > The server side command for that could find the object of scroll tag, save > away current marked object, mark the scroll object, store away current ready > spell, ready new spell, call inscribe code, and then put back the marked object > and ready spell. > > OTOH, would probably be better for the inscribe code to take the inscribe to > object and spell object and just go from that, as that would be cleaner. > > I am really thinking, however, that having the client handle most of the > presentation of this is the better way to go. > Actually, I'd be inclined to do something such as a more general skill-usage protocol. Something like: C->S: client_use_skill [ob1:] [ob2:] [spell:] [message:] Which could be used to make clientside menus for other skills and such things. Alex Schultz From mwedel at sonic.net Sun Sep 17 23:06:02 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 17 Sep 2006 21:06:02 -0700 Subject: [crossfire] Client Skill Handling, Re: New crossfire todo list In-Reply-To: <450E11B8.2050604@telus.net> References: <450D061E.9020505@sonic.net> <450D5CDE.9020304@telus.net> <450DDB0C.60707@sonic.net> <450E11B8.2050604@telus.net> Message-ID: <450E1B2A.505@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> This should probably be taken to the next step, with the client providing some >> nicer dialogue for this, eg, a menu item like 'inscribe scroll'. The client >> would then present list of possible items (based on client type attribute) and >> list of spells, and player chooses. >> >> Of course, the client still has to send the actual request to the server, and >> the server would still have to validate if it works. Thinking about this, the >> logic for this on the server side could actually do most of the work with very >> little changes. Eg, client does something like: >> >> C->S: inscribe >> >> The server side command for that could find the object of scroll tag, save >> away current marked object, mark the scroll object, store away current ready >> spell, ready new spell, call inscribe code, and then put back the marked object >> and ready spell. >> >> OTOH, would probably be better for the inscribe code to take the inscribe to >> object and spell object and just go from that, as that would be cleaner. >> >> I am really thinking, however, that having the client handle most of the >> presentation of this is the better way to go. >> > Actually, I'd be inclined to do something such as a more general > skill-usage protocol. Something like: > > C->S: client_use_skill [ob1:] > [ob2:] [spell:] [message: length>] > > Which could be used to make clientside menus for other skills and such > things. But can all skills be generalized to that regard? Most skills probably don't have any use for spell information, etc. It may be possible to abstract that a bit, and have a bitmask type of thing which denotes what data it is sending along (marked object, apply object, spell name, etc) But for that to work, all the actual skill code must have same semantics/calling structure. And the problem right now, is that there is no real way to do this - for the server to take that arbitrary skill/object data, the best it could do now is fill various fields in the player structure (marked object, ready spell, etc), and then invoke a general 'use_skill ...' - that would work, but would probably have some bad side effects. In particular, I think that the player/client would see messages like 'switched to spell ..', 'switched to skill ..', etc. And then the use_skill code and the like is basically undoing/redoing a fair amount of work. IT would be cleaner and more efficient for the dispatch code to call inscribe, bowery, etc, with the target parameters, so we can save the work of updating the player structures. That logic could get pulled from the existing code, with manual use_skill using those same functions, but passing in the normal defaults (marked object, etc) But what would probably the best first step is to identify all the different skill usages and what parameters they may take and how they should act. That way, things can be properly examined and determined, like 'this skill would ideally use 3 objects, etc'. Aside from inscriptions, I can actually think of many/any of the skills that take optional parameters. The item identification skills just do the entire inventory. And I thought the item creation skills basically look at the players surroundings to figure out what to do (player is on a bench, this is the junk on the bench, he is trying to make ...). Or do the item creation skills actually require the player to state what he is trying to create? From mwedel at sonic.net Sun Sep 17 23:14:48 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 17 Sep 2006 21:14:48 -0700 Subject: [crossfire] current plugins with python 2.2? In-Reply-To: <200608292243.47053.nicolas.weeger@laposte.net> References: <44F3D525.5060302@sonic.net> <200608292243.47053.nicolas.weeger@laposte.net> Message-ID: <450E1D38.4060604@sonic.net> Nicolas Weeger (Laposte) wrote: >> 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) That fixed the problem. I take it there is no bad effect of doing this for newer versions of python, so it should probably be committed by someone? > > Nicolas > > > ------------------------------------------------------------------------ > > ? python.diff > Index: cfpython.c > =================================================================== > RCS file: /cvsroot/crossfire/crossfire/plugins/cfpython/cfpython.c,v > retrieving revision 1.37 > diff -u -r1.37 cfpython.c > --- cfpython.c 27 Aug 2006 14:11:34 -0000 1.37 > +++ cfpython.c 29 Aug 2006 20:42:42 -0000 > @@ -840,8 +840,11 @@ > int value; > } CFConstant; > > +static PyMethodDef CFConstantsMethods[] = { { NULL, NULL, 0 } }; > + > static void addConstants(PyObject* module, const char* name, CFConstant* constants) > { > + > int i = 0; > char tmp[1024]; > PyObject* new; > @@ -850,7 +853,7 @@ > strncpy(tmp, "Crossfire_", 1024); > strncat(tmp, name, 1024 - strlen(tmp)); > > - new = Py_InitModule(tmp, NULL); > + new = Py_InitModule(tmp, CFConstantsMethods); > dict = PyDict_New(); > > while ( constants[i].name != NULL) > > > ------------------------------------------------------------------------ > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From eallan4 at verizon.net Mon Sep 18 00:20:36 2006 From: eallan4 at verizon.net (ERIC ALLAN) Date: Sun, 17 Sep 2006 22:20:36 -0700 (PDT) Subject: [crossfire] I cant figure out how to get this program to work. Message-ID: <20060918052036.25048.qmail@web84009.mail.mud.yahoo.com> I did everything the help file says and I cant get crossfire to work on linux . What am i doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.metalforge.org/pipermail/crossfire/attachments/20060917/7fef6f09/attachment.htm From leaf at real-time.com Mon Sep 18 00:43:41 2006 From: leaf at real-time.com (Rick Tanner) Date: Mon, 18 Sep 2006 00:43:41 -0500 Subject: [crossfire] I cant figure out how to get this program to work. In-Reply-To: <20060918052036.25048.qmail@web84009.mail.mud.yahoo.com> References: <20060918052036.25048.qmail@web84009.mail.mud.yahoo.com> Message-ID: <450E320D.9070102@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ERIC ALLAN wrote: > I did everything the help file says and I cant get crossfire to work on linux . What am i doing wrong? Are you referring to the client or the server or both? What distribution of Linux are you using? Did you install from a package (apt, rpm, etc.) or compile it (client/server) from source? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFDjINhHyvgBp+vH4RAgsyAKDIraPKRYA9zAdXc2RewPYB6QQtbACeM9WB 7N9z35sD2O5BorDh5tGYFDY= =+2hc -----END PGP SIGNATURE----- From nicolas.weeger at laposte.net Mon Sep 18 16:37:56 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 18 Sep 2006 23:37:56 +0200 Subject: [crossfire] current plugins with python 2.2? In-Reply-To: <450E1D38.4060604@sonic.net> References: <44F3D525.5060302@sonic.net> <200608292243.47053.nicolas.weeger@laposte.net> <450E1D38.4060604@sonic.net> Message-ID: <200609182337.56238.nicolas.weeger@laposte.net> > That fixed the problem. I take it there is no bad effect of doing this > for newer versions of python, so it should probably be committed by > someone? Committing it when i get the time, then. Thanks for testing. Nicolas From eallan4 at verizon.net Mon Sep 18 18:20:26 2006 From: eallan4 at verizon.net (ERIC ALLAN) Date: Mon, 18 Sep 2006 16:20:26 -0700 (PDT) Subject: [crossfire] How to connect Message-ID: <20060918232026.8937.qmail@web84006.mail.mud.yahoo.com> I tied both accept the client I dont think even did anything. The server I had uncompiled and womewhat working but when I used make a ton of error messages popped up. Anyways Im not good at hunting resources and installling programs to linux but I wanna see what your muds about. I use suse linux 3.1 and I tried get both programs running. You guys got a copy of your program with everything you need to run it off of suse linux 10.1? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.metalforge.org/pipermail/crossfire/attachments/20060918/ef247784/attachment.htm From cher at riedquat.de Mon Sep 18 18:31:52 2006 From: cher at riedquat.de (Christian Hujer) Date: Tue, 19 Sep 2006 01:31:52 +0200 Subject: [crossfire] How to connect In-Reply-To: <20060918232026.8937.qmail@web84006.mail.mud.yahoo.com> References: <20060918232026.8937.qmail@web84006.mail.mud.yahoo.com> Message-ID: <200609190131.55091.cher@riedquat.de> Hi, On Tuesday 19 September 2006 01:20 ERIC ALLAN wrote: > I tied both accept the client I dont think even did anything. The server I > had uncompiled and womewhat working but when I used make a ton of error > messages popped up. Anyways Im not good at hunting resources and > installling programs to linux but I wanna see what your muds about. > > I use suse linux 3.1 and I tried get both programs running. > You guys got a copy of your program with everything you need to run it off > of suse linux 10.1? your error message is pretty unhelpful. Read http://www.catb.org/~esr/faqs/smart-questions.html Probably you lack several "-devel"-packages. But this is just a guess. Without providing a copy of the significant parts of the error messages that you get during your ./configure and make run it's impossible to provide any further help. It's even impossible to tell whether you're really missing packages or whether you just did something wrong because you didn't provide detailed information about what exactly you did. It could even be that you made a spelling mistake. (Talking about the client thing: Sorry, I didn't understand that sentence, could you please rephrase it?) Kind regards -- 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/20060919/3a7ea678/attachment.pgp From fuchs.andy at gmail.com Mon Sep 18 21:21:28 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon, 18 Sep 2006 22:21:28 -0400 Subject: [crossfire] stat loss and highly specialized players Message-ID: As what i could skim off of I440r__'s rant on IRC, players that are highly specialized (high level) in only a few skills can loose an unreasonable amount levels in skills that they are trying to develop from low levels. His general point was that it should take longer to gain levels, but players should lose less when they die. Now, does the limit on experience lost from the death penalty apply to individual skills? If it doesn't, does anyone see any issues related to l440r__'s rant? Should the death penalty apply to individual skills? -- Andrew Fuchs From mwedel at sonic.net Mon Sep 18 23:55:04 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 18 Sep 2006 21:55:04 -0700 Subject: [crossfire] stat loss and highly specialized players In-Reply-To: References: Message-ID: <450F7828.3060004@sonic.net> Andrew Fuchs wrote: > As what i could skim off of I440r__'s rant on IRC, players that are > highly specialized (high level) in only a few skills can loose an > unreasonable amount levels in skills that they are trying to develop > from low levels. His general point was that it should take longer to > gain levels, but players should lose less when they die. > > Now, does the limit on experience lost from the death penalty apply to > individual skills? If it doesn't, does anyone see any issues related > to l440r__'s rant? Should the death penalty apply to individual > skills? > It should apply to skills as well as overall levels. So under normal circumstances, I think that means no more than 3 levels lost from any skill and overall level. However, you could lose 3 levels from several different skills - for example, pyromancy, one handed weapons, praying, so it could seem like you are lose 12 levels (3 skilsl * 3 + 3 for overall level) From mwedel at sonic.net Tue Sep 19 02:41:35 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 19 Sep 2006 00:41:35 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <450CCEC9.10506@sonic.net> References: <45049B87.3050803@sonic.net> <450CCEC9.10506@sonic.net> Message-ID: <450F9F2F.20108@sonic.net> Current status: CVS data is imported over, and I've renamed the files to be arch/trunk, client/trunk, etc. I've also made 1.x branches of the arch, client, maps, and server (at such time it becomes relevant, it could be done for jxclient and sounds). There are as arch/branches/1.x, client/branches/1.x, etc. Things that I still have yet to do, and will do tomorrow night: Use svn propset to make some virtual entries (link to gridarta for the edit, a link in server/lib/arch to link to archetypes), support for $Id$ in files. Also, should make some 'virtual' directories with links to all he relevant pieces. Eg, have a 'complete' or 'latest' directory which can get all the */trunk entries, so easy to get all those. Likewise, probably have a stable directory which links to the 1.x entries. That said, there is nothing preventing developers from checking out the SVN and actively using it - the things left to do above should not affect that. Mark Wedel wrote: > Just a note/reminder of this change: > > Crossfire will switch from CVS to SVN this onday, Sept 18. > > What will happen: > - Current CVS repository will remain available for read-only access, but no > future changes will be made to that repository. The CVS repository will purely > be for historical reasons (want to see what 1.6 looked like, etc.) Developer > permissions will be updated to remove CVS write permissions. The crossfire page > on sourceforge will also be updated so that CVS info will not appear. > > - The SVN repository will only import the head trunk, and not the tags or > branches of the CVS repository. Future tags and branches will be made of course. > > - Only actively developed portions from CVS will be moved over. > > - Instead of having a copy of the editor in crossfire, we will link to the > Gridarta project. > > - Some amount of cleanup in the repositories will be done - mainly, this means > that some automatically generated files will not be included (flex files, > collected archetypes/images/etc). The autoconf/automake files will stay in the > repository, as it is general practice that code can be downloaded and then a > simple configure run. > > - The server portion will be renamed from 'crossfire' to 'server' to more > accurately describe what portion it is. > > - The organization will be server/trunk, client/trunk, client/branches, etc. > > After the fact: > > - The server and client will need some updating to get the version number so > they can print that out as a build revision (instead of showing revision of each > file). > > - Branches for 1.x will be made for the different components. > > - Likely some other cleanup will be necessary. > > > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From alex_sch at telus.net Tue Sep 19 07:25:04 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 19 Sep 2006 06:25:04 -0600 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <450F9F2F.20108@sonic.net> References: <45049B87.3050803@sonic.net> <450CCEC9.10506@sonic.net> <450F9F2F.20108@sonic.net> Message-ID: <450FE1A0.4010000@telus.net> Mark Wedel wrote: > Current status: > > CVS data is imported over, and I've renamed the files to be arch/trunk, > client/trunk, etc. > > I've also made 1.x branches of the arch, client, maps, and server (at such > time it becomes relevant, it could be done for jxclient and sounds). There are > as arch/branches/1.x, client/branches/1.x, etc. > > So as of now, should we be committing to SVN as opposed to CVS, and using the 1.x branch and trunk as has been planned? :) Btw, one thought is it would probably be good to make some sort of clear documentation for the usage of the 1.x branch and trunk and the branching plan. Alex Schultz From raphael at gimp.org Tue Sep 19 11:54:27 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Tue, 19 Sep 2006 18:54:27 +0200 Subject: [crossfire] stat loss and highly specialized players In-Reply-To: References: Message-ID: <20060919185427.2a67d656.raphael@gimp.org> On Mon, 18 Sep 2006 22:21:28 -0400, "Andrew Fuchs" wrote: > As what i could skim off of I440r__'s rant on IRC, players that are > highly specialized (high level) in only a few skills can loose an > unreasonable amount levels in skills that they are trying to develop > from low levels. His general point was that it should take longer to > gain levels, but players should lose less when they die. As mentioned a few days ago, the default experience table is rather bad, especially near the higher levels because you only need to increase your exp by 1 or 2% to gain a level. You always lose a reasonably fair amount of experience when you die (death penalty is 15% by default) but this translates to many levels in some cases. The problem is in the mapping between experience and levels, not in the death penalty. I think that I440r__ had some valid points: levels should not be gained so easily (at least for the medium and high levels) so that the death penalty would always represent a reasonable amount of levels lost. As I stated previously, I consider death_penalty_levels to be a bad workaround that encourages server admins to keep on using a bad exp_table instead of fixing the real problem. The new exp_table used on Metalforge is a bit better, but still far from perfect. By the way, I added a link to http://wiki.metalforge.net/doku.php/dev_todo:exp_table from http://wiki.metalforge.net/doku.php/dev_todo_new but I did not assign a priority to it. Maybe Mark or someone else can prioritize this? I would like to get this fixed in 1.x, but I understand that some server admins would prefer to keep their old exp_table until the bigger changes in 2.0 so I marked it as a 2.0 feature. But if we decide on a better exp_table, I would still like to add it to the 1.x branch but commented out like the exp_tables A and C. -Rapha?l From raphael at gimp.org Tue Sep 19 12:16:24 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Tue, 19 Sep 2006 19:16:24 +0200 Subject: [crossfire] New crossfire todo list In-Reply-To: <450D061E.9020505@sonic.net> References: <450D061E.9020505@sonic.net> Message-ID: <20060919191624.25e4e813.raphael@gimp.org> On Sun, 17 Sep 2006 01:23:58 -0700, Mark Wedel wrote: > > I've taken a bit of time to go through and make a new todo list of most things > that need to be done: > > http://wiki.metalforge.net/doku.php/dev_todo_new As I just mentioned in another mail, I added a link to the exp_table discussion. It was linked from dev_todo:game_balance but not from the main dev_todo page so it was not easy to see that link. [...] > I'd also suggest that it is generally better to actually pull out the useful > bits of the conversation and put them in the wiki vs referring to the mailing > list - too often, it may be a thread of 50 messages, with most not providing > much useful info - its a bit more handy to just be able to see the main points. Agreed. > Ability for stores to set different prices for goods > (The shopitems code only affects how much you can sell stuff for, not buy stuff, > correct? If so, this is still valid) In general, I think that the shops do not give enough hints to the player about how cheap or how expensive they are compared to other shops. Even using 'use_skill baragaining' does not seem like a very good solution to provide more info. Tying together the selling and buying prices helps by giving some hints to the player. I think that we should update many of the legacy shops and force some specialization: shops should not sell stuff that they are not willing to buy. Currently, there are some shops that sell all kinds of items but only accept to buy a subset of them (e.g., magic shops selling different types of magic items and only buying potions but not wands or rods, or vice-versa). It would be better to remove the shop tiles that do not match the type of items that the shop specializes in, or to convert them to the right type. Or maybe move them to an area of the shop that is clearly marked as a place for "other stuff". Even the weapons and armour shops in Scorn do not make this obvious enough. So if a player enters a magic shop and sees only scrolls and books there, this would be a good hint that trying to drop potions or wands would not be a good idea (even if it is a magic shop). IMHO, the fact that a "shop guide" has been created (indicating what shops are better at buying what stuff) as an out-of-game wiki page is a sign that the game itself does not provide adequate information. -Rapha?l From kevin.bulgrien at gdsatcom.com Tue Sep 19 12:03:54 2006 From: kevin.bulgrien at gdsatcom.com (Kevin R. Bulgrien) Date: Tue, 19 Sep 2006 12:03:54 -0500 Subject: [crossfire] stat loss and highly specialized players References: <450F7828.3060004@sonic.net> Message-ID: > It should apply to skills as well as overall levels. So under normal > circumstances, I think that means no more than 3 levels lost from any > skill and overall level. > > However, you could lose 3 levels from several different skills - for > example, pyromancy, one handed weapons, praying, so it could seem like > you are lose 12 levels (3 skilsl * 3 + 3 for overall level) I think that it is really rough to lose of three levels for skills that are not directly related to killing monsters. Several deaths in a row could conceivably nuke several key skills that are very hard to level. Skills like hiding, literacy, find traps, disarm traps all come to mind. I believe the player whose rant spawned this thread levels overall experience in one or two skills that are directly related to killing monsters. This means his character could conceivably revert to a new player in all but one or two skills after several deaths. I think the side effect of this is death will tend to put a "virtual" cap on the possibility of getting to high levels in some skills. It is not a real cap, but one that would require hours and hours of boring practice to raise those skills back to levels that might be comparable to what could be achieved had the player not died. In skills that are directly related to monster-killing, it is far, far easier to get back what you lost. This tends to be quite discouraging to a player, and can spawn a feeling that one is weaker at level "blah" than he was at level "blah - 10". I do not know game mechanics well enough to suggest a solution, but I do understand the frustration, and experience myself from time to time. In my case, I just try harder not to die, but the game allows death so quickly some times that it just doesn't seem fair that you missed the life-saving action you already invoked on the client by less than a second. I also still believe there is an anomaly in the game with respect to overall experience at least. I have seen overall experience jump inexplicably from time to time where I cannot justify it by gameplay. An anomally like that that does not also affect individual skill experience would also tend to exaggerate the difference between one's overall level and the relative strength of the character. Rayvin From alex_sch at telus.net Tue Sep 19 14:06:18 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 19 Sep 2006 19:06:18 +0000 (UTC) Subject: [crossfire] stat loss and highly specialized players References: <20060919185427.2a67d656.raphael@gimp.org> Message-ID: Rapha?l Quinet writes: > As mentioned a few days ago, the default experience table is rather bad, > especially near the higher levels because you only need to increase your > exp by 1 or 2% to gain a level. You always lose a reasonably fair amount > of experience when you die (death penalty is 15% by default) but this > translates to many levels in some cases. The problem is in the mapping > between experience and levels, not in the death penalty. > > I think that I440r__ had some valid points: levels should not be gained > so easily (at least for the medium and high levels) so that the death > penalty would always represent a reasonable amount of levels lost. Agreed. > > By the way, I added a link to > http://wiki.metalforge.net/doku.php/dev_todo:exp_table A few notes on changing the exp table: To me, the shape of the one on that page you label "Progressive 12%" seems to have what I would consider to be the most reasonable shape for the exp curve, however one question which doesn't seem to have been considered yet, which I440r__ reminded me of by saying something to the meaning of "I wouldn't mind the exp table being scaled up 4x", is do we want the exp table to top out at the same exp value as currently like in the proposed table? I personally think we might want to consider something like "Progressive 15%" in scale, except have the last levels taper upwards like in the "Progressive 12%" one, such that the level 115 exp would be a good bit above what it is currently. I think I may look into making a proposed chart some time. Also, we may want to look at tweaking individual monster exp in some cases. (there are probably many cases that are too generous or don't give enough) Another thing, we may want to consider making exp loss for skills something other than the plain percent. Overall should be by percent IMHO, however it may be worth considering a system, which wouldn't hurt low levels skills of a high level character as much (thus making the fact that non-combat skills are hard to gain, and making death hurtfulfor them, less of an issue). Alex Schultz From nicolas.weeger at laposte.net Tue Sep 19 14:26:56 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 19 Sep 2006 21:26:56 +0200 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <450F9F2F.20108@sonic.net> References: <45049B87.3050803@sonic.net> <450CCEC9.10506@sonic.net> <450F9F2F.20108@sonic.net> Message-ID: <200609192126.56833.nicolas.weeger@laposte.net> > CVS data is imported over, and I've renamed the files to be arch/trunk, > client/trunk, etc. Thanks Mark for handling the conversion! Nicolas From raphael at gimp.org Tue Sep 19 15:38:00 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Tue, 19 Sep 2006 22:38:00 +0200 Subject: [crossfire] stat loss and highly specialized players In-Reply-To: References: <20060919185427.2a67d656.raphael@gimp.org> Message-ID: <20060919223800.2c99947b.raphael@gimp.org> On Tue, 19 Sep 2006 19:06:18 +0000 (UTC), Alex Schultz wrote: > Rapha??l Quinet writes: > > By the way, I added a link to > > http://wiki.metalforge.net/doku.php/dev_todo:exp_table > > A few notes on changing the exp table: To me, the shape of the one on that page > you label "Progressive 12%" seems to have what I would consider to be the most > reasonable shape for the exp curve, however one question which doesn't seem to > have been considered yet, which I440r__ reminded me of by saying something to > the meaning of "I wouldn't mind the exp table being scaled up 4x", is do we > want the exp table to top out at the same exp value as currently like in the > proposed table? I personally think we might want to consider something > like "Progressive 15%" in scale, except have the last levels taper upwards like > in the "Progressive 12%" one, such that the level 115 exp would be a good bit > above what it is currently. I think I may look into making a proposed chart > some time. Yes, the top level (115) could be significantly higher than it is now. Or we could use a curve that keeps it roughly at the same level and then adjust some monsters. In fact, I don't think that the amount of exp required for levels beyond 110 is very important to consider because this is not where most players should be. Those who want to reach the demigod status will do whatever is necessary to reach it anyway. :-) By the way, I made lots of other tests with other curves and I tried to figure out how these would map to my game experience. I did not put them all on the wiki because that would be abusing this nice resource, but maybe I will consider adding one or two new curves anyway. One of my favorites is similar to "Progressive 12%" but uses a 10% slope instead. It crosses the green curve (classic exp_table "B") a bit before level 100. If you want to experiment with exp curves, I can send you my Gnumeric sheet. I can probably be read by Excel or OpenOffice if you don't have Gnumeric. > Also, we may want to look at tweaking individual monster exp in some cases. > (there are probably many cases that are too generous or don't give enough) Right. As I wrote in a previous thread, we should first decide on a new exp curve and then adjust the "sources of exp" (monsters) according to that curve, not the other way round. Using a progressive curve with a constant ratio between levels should make it much easier to adjust the "sources of exp". > Another thing, we may want to consider making exp loss for skills something > other than the plain percent. Overall should be by percent IMHO, however it may > be worth considering a system, which wouldn't hurt low levels skills of a high > level character as much (thus making the fact that non-combat skills are hard > to gain, and making death hurtfulfor them, less of an issue). No, this problem is caused by the current exp_table and death_penalty_levels: it limits the death penalty to 3 levels while the exp_table "B" (current default) requires only 1% between levels around level 100. As a result, a player who is level 100+ in some skills and only about level 10 in some non-combat skills will only lose 3% of the high-level skills (max 3 levels) but will lose the full 15% of the other skills. This is what is wrong: the current system artificially limits the loss for the skills in which the player has reached a high level, but still deals the full penalty to the other skills. If the system would be fair, there would be no death_penalty_levels limit and the player should lose 10 levels or more of the high-level skills (with the current exp_table "B"). This may sound much in terms of levels, but this only represents 15% of the exp. Then it becomes obvious that levels are gained (and lost) too easily near the high levels. As I wrote several times (do I sound like a broken record yet?), the correct way to fix this is to use a progressive exp_table and get rid of artificial limit caused by death_penalty_levels. If after doing that there are still concerns about the fact that losing 15% exp hurts too much, then the right thing to do would be to change the death penalty to 10% or so. Personally, I think that a 10% death penalty would be better than 15% (at least as long as there are some "instant death" traps in the game) and an exp_table that uses a constant ratio of +10% between levels would also be better. As a result, each death would cause the loss of approx. 1 level in each skill and there would not be this unfair difference between high and low levels. -Rapha?l From raphael at gimp.org Tue Sep 19 15:51:28 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Tue, 19 Sep 2006 22:51:28 +0200 Subject: [crossfire] stat loss and highly specialized players In-Reply-To: References: <450F7828.3060004@sonic.net> Message-ID: <20060919225128.7f2f1379.raphael@gimp.org> On Tue, 19 Sep 2006 12:03:54 -0500, "Kevin R. Bulgrien" wrote: > I believe the player whose rant spawned this thread levels overall experience in one or two skills that are directly related to > killing monsters. This means his character could conceivably revert to a new player in all but one or two skills after several > deaths. See my other message. One problem is that with the current exp_table and the artificial limit introduced by death_penalty_levels, you may only lose 3% of your high-level skills when you die, while you lose a full 15% of your low-level skills. So you currently lose exp up to five times slower in the high-level skills, which increases the difference over time and keeps the high-level skills relatively high while the other ones converge towards 0. This is especially obvious after multiple deaths. It took me a while to understand this phenomenon (although I just had to look at the exp_table and it should have been obvious) but now that I saw the problems caused by the current exp_table, I am trying hard to get it changed. It's a pity that death_penalty_levels hides the real problem and causes people to report the wrong problems or to propose other workarounds. > This tends to be quite discouraging to a player, and can spawn a feeling that one is weaker at level "blah" than he was at level > "blah - 10". Sad, but not surprising if you lose exp in the low levels 5 times faster. > I also still believe there is an anomaly in the game with respect to overall experience at least. I have seen overall experience > jump inexplicably from time to time where I cannot justify it by gameplay. An anomally like that that does not also affect > individual skill experience would also tend to exaggerate the difference between one's overall level and the relative strength of > the character. Well, some monsters are worth quite a lot of exp points. If you kill them with the right skill, you can level up rather quickly. -Rapha?l From mwedel at sonic.net Wed Sep 20 01:56:38 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 19 Sep 2006 23:56:38 -0700 Subject: [crossfire] stat loss and highly specialized players In-Reply-To: <20060919223800.2c99947b.raphael@gimp.org> References: <20060919185427.2a67d656.raphael@gimp.org> <20060919223800.2c99947b.raphael@gimp.org> Message-ID: <4510E626.8060508@sonic.net> Various quick notes: The target release varies depending on the change. For exp tables, I'd say that it can be put in 1.x as a commented out value, and if desirable, make it the default in 2.0 One thing to keep in mind in all these discussions is the relation of this lost with permanent exp. I think right now, whatever permanent exp you have earned does not affect the loss - it just means you can never have less than your permanent value. But if you die several ties relatively quickly, you can get down to that value pretty quickly. One change in this area could be to to base the experience loss based on the difference between current exp and permanent exp. Thus, for practical purposes, it would be very difficult to ever get all the way down to your permanent exp. But then I'm not sure if that would make any real difference (what could be interesting is having different permanent exp ratios for different skills). I think there will always be some issues with skill inequalities. Lets presume that under a revised system, you basically loose 1 level in each skill. That is certainly a lot better than it is now, but if you are level 80 in one handed fighting and level 10 in literacy, loosing that level in literacy will seem much harsher (in terms of actual character power/importance, level 79 vs 80 in fighting won't have a huge impact (in terms of percentage of actual level less, 9 vs 10 is bigger than 79 vs 80). Not sure how to fix that. One thing to keep in mind for the original tables is that they were done before we had 64 bit experience values. This put the limit at around 2 billion, which is why the hard table has that as the max exp. When the level array was increased to 115 with 64 exp values, the last 5 levels had a lot steeper curve because it could be done and to make it hard for people to max out their character. The old values were not changed for compatibility reasons. Because of that, as far as I can see, as long as the new exp total for level 115 is above that of the old value, there doesn't really need to be a big change in the curve for the final levels. I think under a revised system, you'll actually see fewer people at max levels, since it will be just as hard to get that much exp, so you are more likely to see characters sprinkled out amongst several levels when 100+ From mwedel at sonic.net Wed Sep 20 02:02:48 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 20 Sep 2006 00:02:48 -0700 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <450FE1A0.4010000@telus.net> References: <45049B87.3050803@sonic.net> <450CCEC9.10506@sonic.net> <450F9F2F.20108@sonic.net> <450FE1A0.4010000@telus.net> Message-ID: <4510E798.9070005@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> Current status: >> >> CVS data is imported over, and I've renamed the files to be arch/trunk, >> client/trunk, etc. >> >> I've also made 1.x branches of the arch, client, maps, and server (at such >> time it becomes relevant, it could be done for jxclient and sounds). There are >> as arch/branches/1.x, client/branches/1.x, etc. >> >> > So as of now, should we be committing to SVN as opposed to CVS, and > using the 1.x branch and trunk as has been planned? :) Yes. In fact, I don't think anyone will be able to commit to CVS, as I've revoked everyones CVS access (seems only real way to prevent accidental checkins, etc) > > Btw, one thought is it would probably be good to make some sort of clear > documentation for the usage of the 1.x branch and trunk and the > branching plan. You mean like: http://wiki.metalforge.net/doku.php/crossfire_release_cycle That should probably be put someplace more prominently. From alex_sch at telus.net Wed Sep 20 02:16:35 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 20 Sep 2006 01:16:35 -0600 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <4510E798.9070005@sonic.net> References: <45049B87.3050803@sonic.net> <450CCEC9.10506@sonic.net> <450F9F2F.20108@sonic.net> <450FE1A0.4010000@telus.net> <4510E798.9070005@sonic.net> Message-ID: <4510EAD3.7000109@telus.net> Mark Wedel wrote: > You mean like: > http://wiki.metalforge.net/doku.php/crossfire_release_cycle > > That should probably be put someplace more prominently. Yes, I mean exactly like that :) To me it would make most sense to put some sort of 'official' static version on either on crossfire.real-time.com, or in doc/Developers, or both Alex Schultz From raphael at gimp.org Wed Sep 20 11:24:39 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Wed, 20 Sep 2006 18:24:39 +0200 Subject: [crossfire] CVS -> SVN conversion In-Reply-To: <4510E798.9070005@sonic.net> References: <45049B87.3050803@sonic.net> <450CCEC9.10506@sonic.net> <450F9F2F.20108@sonic.net> <450FE1A0.4010000@telus.net> <4510E798.9070005@sonic.net> Message-ID: <20060920182439.10498778.raphael@gimp.org> On Wed, 20 Sep 2006 00:02:48 -0700, Mark Wedel wrote: [...] > Yes. In fact, I don't think anyone will be able to commit to CVS, as I've > revoked everyones CVS access (seems only real way to prevent accidental > checkins, etc) Just a little note about that: those who used the developer access to CVS (over SSH) will find that operations like "cvs update", "cvs status" or "cvs diff" do not work anymore. You have to change the CVS root and use the anonymous access instead of the developer access if you still want to check the status of your files or do a diff. I discovered this problem because although I had updated most of my checked out CVS trees last week, I saw yesterday that I forgot one of them. I wanted to do a "cvs update" or "cvs status" to check if I had any locally modified files or if I could just delete this tree, but the commands failed because the CVS access is now blocked for developers ("cvs update" fails because it cannot create the required lock file, so both the read and write access are effectively disabled). In case anyone here runs into the same problem and is unable to check the status of some old cvs trees, there is a simple solution: use a tool such as "changecvsroot" or "changecvsroot.py" (Python version handling subtrees in a better way) and replace :ext:username at crossfire.cvs.sourceforge.net:/cvsroot/crossfire by :pserver:anonymous at crossfire.cvs.sourceforge.net:/cvsroot/crossfire in one go for your whole tree. This will now allow you to quickly check the status of your tree as an anonymous user and be sure that you can delete it without losing any locally modified files. -Rapha?l From mwedel at sonic.net Wed Sep 20 23:53:56 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 20 Sep 2006 21:53:56 -0700 Subject: [crossfire] New crossfire todo list In-Reply-To: <20060919191624.25e4e813.raphael@gimp.org> References: <450D061E.9020505@sonic.net> <20060919191624.25e4e813.raphael@gimp.org> Message-ID: <45121AE4.4010702@sonic.net> Rapha?l Quinet wrote: > In general, I think that the shops do not give enough hints to the player about > how cheap or how expensive they are compared to other shops. Even using > 'use_skill baragaining' does not seem like a very good solution to provide more > info. Tying together the selling and buying prices helps by giving some hints > to the player. True - if a shop isn't paying much for an item, it is probably because it doesn't want it, so would also sell it for not a lot of money. I think it might also be interested in having more specialized shop lists than right now. Every weapon shop basically has the same stuff, every armor shop basically has the same stuff, etc. It might be more interesting that based on location and other factors for this to vary. An example could be a town that is far from any iron mines - in such a town, iron (steel) armor and weapons would be pretty rare, but the wooden and leather ones would be quite common. That can be done just by some new treasure lists. I think it would be a bit too much of a pain to try and adjust prices in all these shops - IIRC, the shop code deals in meta types right now (armor, weapons, etc). Having to have a list which lists out all the different objects and price variance would be a real pain, and also prone to get out of data. But such changes would also be interesting - if looking for really good bows, your best bet may be the shop at ... which doesn't have a lot of weapons, but does have a whole bunch of bows, arrows, etc. Some people may say 'wait - that means a player can go to some town, buy the equipment their cheaply, travel to another, and sell money'. Of which I basically say 'fine'. It's not like there isn't lots of ways to make money anymore (wait, they can go into a dungeon, kill some monsters, ...). As long as this cycle isn't circular (they can't take the same objects back again, resell, etc) I don't see a problem with it. If some players want to play traders, who are we to prevent them. > > I think that we should update many of the legacy shops and force some > specialization: shops should not sell stuff that they are not willing to buy. > Currently, there are some shops that sell all kinds of items but only accept to > buy a subset of them (e.g., magic shops selling different types of magic items > and only buying potions but not wands or rods, or vice-versa). It would be > better to remove the shop tiles that do not match the type of items that the > shop specializes in, or to convert them to the right type. Or maybe move them > to an area of the shop that is clearly marked as a place for "other stuff". > Even the weapons and armour shops in Scorn do not make this obvious enough. > So if a player enters a magic shop and sees only scrolls and books there, this > would be a good hint that trying to drop potions or wands would not be a good > idea (even if it is a magic shop). Yes - the old scorn shops have several tiles for items not of their type - that never made a whole bunch of sense - those should be updated to have the correct item types. I think in the big towns, it would be completely reasonable for a shop to not deal in types it doesn't like - give a value of zero for them. In some sense this is better - then you know to sell it someplace else, vs getting completely shafted on price and having to pay quite a bit more to buy it back. Another point which has sometimes been discussed is the idea to 'unsell' items. EG, you accidentally drop something you didn't want to sell. Problem is, to buy it back costs a lot more than you sold it for, and you can't afford to buy it back. One way this could perhaps be done is like this: If you drop items, it sells you how much money you will get for selling it, but doesn't do the actual transaction. When you move off the space, it then does the transaction, selling all the remaining items there, identifying them, and marking them as unpaid. I think that can be done pretty easily by using the move_off flags (I think it has to be done when the player moves off and not when they use the shop map, as if you have multiple players in the store, there is a fair danger of getting confused on who is selling what, and/or a player could move onto a stack of not yet sold objects before the player gets to the shop map, and thus take items, etc). Interesting though related to this - maybe not all shops can identify all items sold, so you could actually find interesting unidentified items in shops once in a while. > > IMHO, the fact that a "shop guide" has been created (indicating what shops > are better at buying what stuff) as an out-of-game wiki page is a sign that the > game itself does not provide adequate information. Arguably, any game player data on the wiki is a sign that there isn't enough in game help for that purpose. IMO, you shouldn't really need to go to a wiki to find information you need to just play the game (OTOH, hints vs playing is tricky.) From fuchs.andy at gmail.com Thu Sep 21 15:37:40 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Thu, 21 Sep 2006 16:37:40 -0400 Subject: [crossfire] Making maps easier to maintain, by creating custom archetypes for duplicated objects. Message-ID: There are several instances in the maps, where custom objects where copied and pasted from other maps. An example to this is the guidebooks in the post offices. Recently the guide books in Scorn's post office where modified, but not the ones in other post offices. This lead me to think about what requirements have to be met for it to become practical to replace duplicated custom objects with new archetypes. I'm thinking that having two or more of similar objects that appear on separate maps would be enough warrant a new archetype. Anyone want to write a script to find duplicate custom objects in maps, or intergrate it into a map checking script? -- Andrew Fuchs From alex_sch at telus.net Thu Sep 21 16:44:54 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 21 Sep 2006 15:44:54 -0600 Subject: [crossfire] Making maps easier to maintain, by creating custom archetypes for duplicated objects. In-Reply-To: References: Message-ID: <451307D6.5050605@telus.net> Andrew Fuchs wrote: > There are several instances in the maps, where custom objects where > copied and pasted from other maps. An example to this is the > guidebooks in the post offices. Recently the guide books in Scorn's > post office where modified, but not the ones in other post offices. > This lead me to think about what requirements have to be met for it to > become practical to replace duplicated custom objects with new > archetypes. > Seems like a good idea to me. > I'm thinking that having two or more of similar objects that appear on > separate maps would be enough warrant a new archetype. I don't think that's good criteria, for one, what about floors set to no_magic? IMHO that isn't worth making new archetypes for. (However perhaps the editor should give an option to automatically set no_magic when placing floors? but that's another matter.). We would need to define how different the archetype would need to be from it's original arch, to trigger the map check warning. IMHO some good criteria would be highly similar objects being used on two or more maps, and at these criteria scoring at least 5: Score Criteria 4 Objects have the same message, which is over 10 characters long and different than the archetype. 2 Objects have same name, which is different than the archetype. 1 Objects have the same in some other attribute, different than the archetype Or perhaps something similar to that table. In any case it seems we would need some sort of scoring system for how similar objects are, and how different from the archetype they are. Alex Schultz From mwedel at sonic.net Thu Sep 21 22:48:03 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 21 Sep 2006 20:48:03 -0700 Subject: [crossfire] Making maps easier to maintain, by creating custom archetypes for duplicated objects. In-Reply-To: <451307D6.5050605@telus.net> References: <451307D6.5050605@telus.net> Message-ID: <45135CF3.9050700@sonic.net> Alex Schultz wrote: > Andrew Fuchs wrote: >> There are several instances in the maps, where custom objects where >> copied and pasted from other maps. An example to this is the >> guidebooks in the post offices. Recently the guide books in Scorn's >> post office where modified, but not the ones in other post offices. >> This lead me to think about what requirements have to be met for it to >> become practical to replace duplicated custom objects with new >> archetypes. >> > Seems like a good idea to me. > >> I'm thinking that having two or more of similar objects that appear on >> separate maps would be enough warrant a new archetype. > I don't think that's good criteria, for one, what about floors set to > no_magic? IMHO that isn't worth making new archetypes for. (However > perhaps the editor should give an option to automatically set no_magic > when placing floors? but that's another matter.). We would need to > define how different the archetype would need to be from it's original > arch, to trigger the map check warning. > IMHO some good criteria would be highly similar objects being used on > two or more maps, and at these criteria scoring at least 5: > Score Criteria > 4 Objects have the same message, which is over 10 > characters long and different than the archetype. > 2 Objects have same name, which is different than the > archetype. > 1 Objects have the same in some other attribute, different > than the archetype > > Or perhaps something similar to that table. In any case it seems we > would need some sort of scoring system for how similar objects are, and > how different from the archetype they are. I agree it gets complicated. Keep in mind in many cases, what probably happens is someone puts a modified object on a map - the first version of that object. In that case, it should pretty clearly not be an archetype. Then someone else decides to copy it. At that point, it may make sense to become an archetype, maybe not. My general thought was always that archetypes should be somewhat generic objects - in other words, objects that map makers would likely find use for in all sorts of maps. Thus, even a highly complex object (that scored really high in the above criteria) probably shouldn't be an archetype if there is very limited places they would be used. I'd think the criteria for something being an archetype would perhaps mean 5 instances of such objects in the maps - that starts to suggest that there is some general value for those objects. 2 instances may not suggest much. How complex the object is is certainly somewhat reasonable - very complex objects would have more reason to be archetypes than simple objects (the no magic floor example). If we do have scripts to find equivalent objects in maps, I wonder if instead making archetypes that could/should be put in the map directory (tools directory or something), and thus could be used to find such duplicates. So we don't necessarily need them to be archetypes, we just need to be able to easily find them. Making this archetypes could have unintended consequences. Map maker A designs the object in just such a way for various reason (maybe for slaying fields, maybe to kill a specific monster in the dungeon, whatever). If that is turned into an archetype, and at some point people go through and start adjusting balance of objects, you now get the danger of that object changing and thus not meeting its designed purpose anymore (maybe people say 'instead of attacktype A, it should have B', not realizing that the original instance had attacktype A becuase that would kill the monster in the dungeon, etc). From lalo.martins at gmail.com Fri Sep 22 07:10:50 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri, 22 Sep 2006 20:10:50 +0800 Subject: [crossfire] Making maps easier to maintain, by creating custom archetypes for duplicated objects. References: <451307D6.5050605@telus.net> <45135CF3.9050700@sonic.net> Message-ID: on the other hand, there are a few other things that would make something an archetype. For example, you can't customise an object in a treasure list, so you have to make an archetype. And the most well-known one, a custom face. I'd argue there are things in the game that *shouldn't* be archetypes and currently are; Lord Eureca is supposed to be unique, but instead he can come out of your cauldron (wtf?) 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 Fri Sep 22 07:52:51 2006 From: raphael at gimp.org (=?ISO-8859-1?Q?Rapha=EBl?= Quinet) Date: Fri, 22 Sep 2006 14:52:51 +0200 Subject: [crossfire] Making maps easier to maintain, by creating custom archetypes for duplicated objects. In-Reply-To: <45135CF3.9050700@sonic.net> References: <451307D6.5050605@telus.net> <45135CF3.9050700@sonic.net> Message-ID: <20060922145251.57f28d8d.raphael@gimp.org> On Thu, 21 Sep 2006 20:48:03 -0700, Mark Wedel wrote: > My general thought was always that archetypes should be somewhat generic > objects - in other words, objects that map makers would likely find use for in > all sorts of maps. > > Thus, even a highly complex object (that scored really high in the above > criteria) probably shouldn't be an archetype if there is very limited places > they would be used. I agree. Although the idea of converting some things to archetypes sounds good, I would also like to keep archetypes as relatively generic things. If some object that is a modified version of an archetype appears in several maps, then this would be a good candidate to be put in a picker for all crossfire editors, but this does not necessarily mean that it should become a new archetype. Collecting new candidates for pickers in the map editors could be done semi-automatically. > If we do have scripts to find equivalent objects in maps, I wonder if instead > making archetypes that could/should be put in the map directory (tools directory > or something), and thus could be used to find such duplicates. So we don't > necessarily need them to be archetypes, we just need to be able to easily find them. Right. I prefer to be able to identify quickly where these customized objects are used so that I can decide on a case-by-case basis which ones should be updated, instead of using an archetype that causes immediate changes to all instances when it is updated (even in places where the original version should have been kept). One more reason for me to come back to my map checking script that collects statistics about all objects. I haven't touched it since a long time... -Rapha?l From kbulgrien at worldnet.att.net Thu Sep 21 22:12:55 2006 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu, 21 Sep 2006 22:12:55 -0500 Subject: [crossfire] Making maps easier to maintain, by creating custom archetypes for duplicated objects. References: Message-ID: Andrew Fuchs wrote: > There are several instances in the maps, where custom objects where > copied and pasted from other maps. An example to this is the > guidebooks in the post offices. Recently the guide books in Scorn's > post office where modified, but not the ones in other post offices. Heh, heh, you spotted it before I had a chance to fix that eh? Yeah, I remembered this morning on the way to work that I had forgotten to check the rest of the maps for those patterns. > Anyone want to write a script to find duplicate custom objects in > maps, or intergrate it into a map checking script? The script thing interests me, but I'd have to get a bit more wise about map structure parsing to run with it, though I have started to look at a similar type thing already. I have a crude script that I put together to spell check the maps. It knows a bit about the map structure to try to avoid flagging certain words as misspelled. I imagine a duplicate object processing script could use the same type of parser that a script like spell checker might. If nobody else jumps on it, I may look at it a bit. The IPO thing, though, illustrates a bit of a problem with assuming too much about copy/pasted custom objects. One ofthe mods I made would not have been detected in other IPOs if certain assumptions were made. The person to ask for help is named Colette in Scorn, but in other towns the person was named Betina, Babs, postmaster, etc. The fix in the other IPO's had to be customized to match the environment. Also, even though the object was basically copy/pasted, it may have been renamed. It would be easy to assume the script was doing a good job and still miss edits, or the script might be more flexible, but also more prone to flagging items that weren't really the same. Of course, there is the other side too, that ironically, the instructions were copy/pasted and told the reader to ask Colette for help even though there was no Colette in that IPO, so a real fix needed to change the name of Colette to match the actual person in that map. Really, grep -r "borken sentence frag" . | grep -v ".svn/text-base" works about as well as anything, though a good script might actually let you auto-edit the located items once you checked each one out to be sure it was legitimate. -- Kevin R. Bulgrien From mwedel at sonic.net Fri Sep 22 23:51:35 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 22 Sep 2006 21:51:35 -0700 Subject: [crossfire] SVN notes/thoughts Message-ID: <4514BD57.8050202@sonic.net> Been a few days since we moved to SVN. With the transition, there are some changes that can be made. One point is automatically rebuilding the archetypes when the arch tree changes. My thought here is that lib/Makefile can run svnversion and puts that in a state file (.collect.svn.new). Then, the process compares that file with the old one (.collect.svn) - if different, it runs the collect and moves the file over. If the same, it just doesn't do anything. In this way, a collect would automatically be done whenever the archetypes are updated. One minor issues is that svnversion reports the version the respective tree is updated to. Given that all of crossfire is in the same crossfire repository, you do get the case where the number of svnversion can be different, but for the actual component, there haven't been any changes made. This is because svnversion returns the version that the tree is at, relative to last update. Real life example below: [hugin:/export/home/crossfire/crossfire-SVN/arch/trunk] (591) % svnversion . 4963 [hugin:/export/home/crossfire/crossfire-SVN/arch/trunk] (592) % svn update At revision 4969. [hugin:/export/home/crossfire/crossfire-SVN/arch/trunk] (593) % svnversion . As you can see, there were no changes in the arch tree relative to the versions, yet svnversion returns a different value. What this really means is that such a method would result in archetypes being recollected more often than strictly necessary. OTOH, unless you update the arch tree, this isn't an issue. I think similar logic could also be used to embed the version number into the client and server binaries. That way, when someone reports a bug, it is very clear what version they are running. By using a state file, it means we don't need to recompile and relink everytime (if we just used svnversion to blindly write a .c/.h file, then everytime it would recompile and relink that component). In both of these cases, we also need to handle the case for the official releases, where there will not be any SVN information in the downloaded source code, and the user may not even have svn tools installed. Configure can easily enough be updated to look for svnversion to cover that case. In the case of lacking the svn data itself, I'd think the makefiles could just check for .svn files - I'd rather not have to reconstruct the makefiles for the official versions. In terms of the version string, I think the file that inclues it would have to be part of the distributed version so that it is there for the compiled in. Including the SVN version in officially released distributions shouldn't cause any problems IMO. thoughts/comments? From alex_sch at telus.net Sun Sep 24 00:46:55 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 23 Sep 2006 23:46:55 -0600 Subject: [crossfire] "Jesus weeping" map Message-ID: <45161BCF.5040108@telus.net> The issue of the naming of the "Jesus weeping" map was brought up before but nothing was really done. Does anyone have any objections if I change the name of the map to "Valriel weeping"? Alex Schultz From mwedel at sonic.net Sun Sep 24 03:05:39 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 24 Sep 2006 01:05:39 -0700 Subject: [crossfire] draw_ext_info/message update/redo Message-ID: <45163C53.8010501@sonic.net> I'm going through the server and updating the new_draw_info calls with the draw_ext_info calls. I had done a few files several weeks back, but decided I should just go through and do them all so that it is consistent and we can then get rid of the old new_draw_info function (at the protocol level, the old drawinfo will continue to stick around for some time). The main advantages I see of the drawextinfo is this: - Support for the media tags (bold text, different fonts, etc). I'd expect these to be infrequently used, as in general the global tag/attribute should be used. But I think use in NPC messages giving clues what can be discussed with them by doing bold or underline would be very good (we should probalby decide what the form for that syntax highlighting it is, so that it is consistent accross all the maps/NPCs) - Instead of the server telling the client the color to use and the client blindly following it, the client now knows the type of messages. So with some extra logic, I could decide that I want the level gain message to be in a specific font in bright green, even though the server says those should be in red. It would also allow for easier filtering (if chat/say/shout have their own types, easier to have a conversation pane, etc). The gtk1 client was modified to support the extended types with popup windows with graphics of signs and other things. From what I've generally heard, this generally didn't seem very popular (you end up having a bunch of popups, and if you want to keep the info around, you need to keep the popup around, etc). OTOH, it seems the general idea of pop up windows in the gtk1 client itself was never very popular, so the dislike may not be directly related to the content (otoh, you do get a lot more with the readable code) I modified the gtk2 client not to do that - instead, it just takes the text message, applies the tags, and puts it into the normal text windows. This lets things like who, maps, etc, actually look nice, since it uses a fixed width font. A hybrid approach could be done - the GtkTextBuffer of the gtk2 client does support child widgets, so the graphic with text could be rendered in the text buffer. This fixes the problem of having popup windows, but would mean such messages use up a lot more space in the text buffer than just the text (this could be controlled by a config option, but to keep adding config options gets a little excessive at some point). The other problem is that the graphic themselves have a certain size, which may/probably do not match the width of the text window (given that players can resize it, there is of course no 'correct' size for this). The images could be resized, but we'll probably run into problems at some point, like the text not fitting in the image, etc. I think we need to sort out what exactly how we want to handle this. As of now, with the changes I've made so far, there are probably 150+ different message subtypes. This is obvious way too many to have a user ever be able to configure them. But it also leads to some points: If we don't plan/want to render graphics, we can reduce the number of subtypes by a fair number - for the readable objects, there is basically 1 message subtype/object - if we don't want to do graphics, those can be made more general (book, scroll, letter, etc). One current problem here is that text is different - For a book, it would normally say something like 'the book says ...'. However, in the gtk1 client, since the text is put in a book image, the server doesn't send the 'the book says ...' part, it just sends the message. This means that for the gtk2 client (and maybe even the gtk1 client in non popup mode), you just get the message of the book, with no preface where that message came from. I suppose the client could re-inject the 'the books says' line for the appropriate messages, but depending on how the messages are done/rendered, maybe the answer is that the server shouldn't be stripping/modifying the output text) In any case, a large number of message types will never have any graphics displayed with them. Chat messages, level gain/loss will always just be plainly printed. By the same token, how to exactly qualify the overall type gets tricky - I'm generally putting them in broad categories (attack, skill, apply, commands). But there is even trouble here - for buildable map code, do I put those under apply type, buildable subtype? Do I make a new buildable type, etc. Probably no good answer, but if anyone has thoughts, I'd be interested in hearing them (there are some which would seem to go in multiple categories also) One thing I see in a fair amount of places while doing this is some idea of common subtypes/states (error messages) - it gets odd in those cases - do you have an error subtype, or you return the subtype related to the action being tried, etc). I suppose on the plus side, fixing any msg types/subtypes will be easier once the calls are converted over, as a sed command could perhaps be used - given that draw_ext_info has more parameters, one sort of has to do through the programs by hand to have meaningful results. IMO, having the number of type/subtypes be as small as possible yet still distinctive is a nice goal - in that way, it is a manageable number for the player to actual choose selections on, yet meaningful in that the selections mean something. We may also want to revisit what messages are printed world wide. For example, in attack.c, if you are casting a spell, are hit, and lose the spell, it would be printed to everyone in the game. That seems a bit odd to me - I'd be more inclined that it be limited to the map or maybe party members (that message would only be generated if casting time config option is set, which is probably why you don't see it very often, but just struck me as odd). On a broader scale, there is a problem with most of the msg/endmsg in maps/objects. They are pre-formatted for a certain width. If your text window is wider, it isn't terrible - it just doesn't use the full width. If your window is a bit smaller, it gets really ugly, as it will display a full line, then perhaps 1 word, then another full line, etc. Ideally, I think most of the newlines from the msg/endmsg structures should be removed - the client is plenty smart enough to do proper wrapping. There are also a few messages which should have the '[fixed]' tag added, since they are maps or diagrams, and just don't look right when printed with the proportional font. But of a long rambling message, but just various thoughts. From kbulgrien at att.net Sun Sep 24 22:38:00 2006 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Sun, 24 Sep 2006 22:38:00 -0500 Subject: [crossfire] msg/endmsg in maps/objects References: <45163C53.8010501@sonic.net> Message-ID: Mark Wedel wrote: > On a broader scale, there is a problem with most of the msg/endmsg in > maps/objects. They are pre-formatted for a certain width. If your text window > is wider, it isn't terrible - it just doesn't use the full width. If your > window is a bit smaller, it gets really ugly, as it will display a full line, > then perhaps 1 word, then another full line, etc. > > Ideally, I think most of the newlines from the msg/endmsg structures should be > removed - the client is plenty smart enough to do proper wrapping. There are > also a few messages which should have the '[fixed]' tag added, since they are > maps or diagrams, and just don't look right when printed with the proportional font. I have been wondering about this for some time. I agree the formatting needs to go in general. The formatting is not consistent and so one never knows how to format or reformat content. It is good to know that it is okay to string the paragraphs on the same line. "Most" newlines is right, considering that some should be left in order to separate paragraphs and/or allow certain lines of text to be rendered on a line by itself. I'd ask also for some clarification of whether there is a common practice to follow with respect to whitespace between sentences. There is a variation in that one space is used much of the time, but two spaces also exists. How about blank lines? Is this discouraged in order to consume less vertical space, or is it seen to be acceptable for improving readability for longer multi-paragraph output? Is there an advantage to using leading whitespace acceptable to inset example text? I think so, but wonder what others might think. Is there a document anywhere that might be used to help map editors know how to write these messages? If not, a wiki page might be in order. These topics are of special interest to me since I have an interest in working on grammatical, spelling, and conversation improvements on maps as I play them. Kevin From kbulgrien at att.net Sun Sep 24 23:45:49 2006 From: kbulgrien at att.net (Kevin R. Bulgrien) Date: Sun, 24 Sep 2006 23:45:49 -0500 Subject: [crossfire] Gridarta CFJavaEditor Jar? Message-ID: Could someone make a jar file from the CFJavaEditor sources on the Gridarta project? I have so far been unable to get a working build environment. I get errors when I try the command-line build instructions in INSTALL.txt, and I am having great difficultly getting ant installed. $ javac -d class -classpath lib/png.jar:lib/visualtek.jar:lib/jdom.jar:lib/crimson.jar src/cfeditor/*.java src/cfeditor/textedit/textarea/*.java src/cfeditor/textedit/scripteditor/*.java src/cfeditor/JFontChooser.java:355: unclosed character literal new_msg = new_msg.replace('??', '\n'); ^ src/cfeditor/JFontChooser.java:355: illegal character: \167 new_msg = new_msg.replace('??', '\n'); ^ src/cfeditor/JFontChooser.java:355: unclosed character literal new_msg = new_msg.replace('??', '\n'); ^ src/cfeditor/JFontChooser.java:355: ')' expected new_msg = new_msg.replace('??', '\n'); ^ error: cannot read: src/cfeditor/textedit/textarea/*.java 5 errors Thanks, Kevin From mwedel at sonic.net Mon Sep 25 02:31:07 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 25 Sep 2006 00:31:07 -0700 Subject: [crossfire] msg/endmsg in maps/objects In-Reply-To: References: <45163C53.8010501@sonic.net> Message-ID: <451785BB.3050500@sonic.net> Kevin R. Bulgrien wrote: > Mark Wedel wrote: > >> On a broader scale, there is a problem with most of the msg/endmsg in >> maps/objects. They are pre-formatted for a certain width. If your text window >> is wider, it isn't terrible - it just doesn't use the full width. If your >> window is a bit smaller, it gets really ugly, as it will display a full line, >> then perhaps 1 word, then another full line, etc. >> >> Ideally, I think most of the newlines from the msg/endmsg structures should be >> removed - the client is plenty smart enough to do proper wrapping. There are >> also a few messages which should have the '[fixed]' tag added, since they are >> maps or diagrams, and just don't look right when printed with the proportional font. > > I have been wondering about this for some time. I agree the formatting needs > to go in general. The formatting is not consistent and so one never knows how > to format or reformat content. It is good to know that it is okay to string > the paragraphs on the same line. > > "Most" newlines is right, considering that some should be left in order to > separate paragraphs and/or allow certain lines of text to be rendered on a > line by itself. > > I'd ask also for some clarification of whether there is a common practice to > follow with respect to whitespace between sentences. There is a variation in > that one space is used much of the time, but two spaces also exists. I'd be tempted to say that for simplicity, we use whatever is most prevalent right now. So if the most prevalent is 1 space after the period, that is what we should use. I'm not sure if it is worth it to go through all the maps and update just for that. But if doing it as part of a newline conversion, etc it could make sense to fix those. And a lot of these changes also need to be made in the server, in terms of the messages it prints. In cases where there are several draw_infos() strung together, in many cases I've been changing that to just one draw_info on the basis to let the client wrap the text. In some cases, this doesn't work because there is specific formatting, but not that often. > > How about blank lines? Is this discouraged in order to consume less vertical > space, or is it seen to be acceptable for improving readability for longer > multi-paragraph output? I'd say they should be there for readability. Without a blank line, it can be very difficult to really see where the paragraph breaks are. In addition, this really only comes up with NPC messages - generally, I'd say those are a relatively small portion of the total text output (things like attack messages being much more prevalant), and I can't imagine a couple extra newlines being that big a deal. > > Is there an advantage to using leading whitespace acceptable to inset example > text? I think so, but wonder what others might think. Depends on what you mean by example text. Also, look at the server/doc/mediaTags file - it supports a limited number of HTML like tags. What this really means is that within a message itself, you can change various attributes (like make the text italic, or change the color, use fixed width fonts, etc). Using those tags is probably better than using indentation. > > Is there a document anywhere that might be used to help map editors know how > to write these messages? If not, a wiki page might be in order. These topics > are of special interest to me since I have an interest in working on grammatical, > spelling, and conversation improvements on maps as I play them. I don't think there is a document on indentation, punctuation, etc. So one should probably be written. From subs at eracc.com Mon Sep 25 09:58:12 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 25 Sep 2006 09:58:12 -0500 Subject: [crossfire] "Jesus weeping" map In-Reply-To: <45161BCF.5040108@telus.net> References: <45161BCF.5040108@telus.net> Message-ID: <200609250958.13701.subs@eracc.com> On Sunday 24 September 2006 12:46 am Alex Schultz wrote: > The issue of the naming of the "Jesus weeping" map was brought up before > but nothing was really done. Does anyone have any objections if I change > the name of the map to "Valriel weeping"? Go for it. The "Jesus weeping" map is incongruous with the rest of crossfire since the decision was made a long time ago to rename the deity YHWH to Valriel. Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 09:53:54 up 3 days, 2:25, 14 users, load average: 0.22, 0.19, 0.17 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From subs at eracc.com Mon Sep 25 10:05:21 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 25 Sep 2006 10:05:21 -0500 Subject: [crossfire] Gridarta CFJavaEditor Jar? In-Reply-To: References: Message-ID: <200609251005.22154.subs@eracc.com> On Sunday 24 September 2006 11:45 pm Kevin R. Bulgrien wrote: > Could someone make a jar file from the CFJavaEditor sources on the > Gridarta project? I have so far been unable to get a working > build environment. I get errors when I try the command-line build > instructions in INSTALL.txt, and I am having great difficultly > getting ant installed. [...] I was provided with a working copy by one of the Gridarta developers and have it availalble here: . The same developer has been given FTP access to that directory to keep an up to date copy of CFJavaEditor.jar available. I was unable to use the arch directory from SVN and thought it was my build of Gridarta at fault but that turned out not to be the case. Apparently the problem was with many of the graphics being converted to text during the migration from CVS to SVN. I understand Mark Wedel has now fixed this problem(?). Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 09:59:10 up 3 days, 2:30, 14 users, load average: 0.26, 0.20, 0.18 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales From nicolas.weeger at laposte.net Mon Sep 25 16:09:30 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 25 Sep 2006 23:09:30 +0200 Subject: [crossfire] SVN notes/thoughts In-Reply-To: <4514BD57.8050202@sonic.net> References: <4514BD57.8050202@sonic.net> Message-ID: <200609252309.30281.nicolas.weeger@laposte.net> > One point is automatically rebuilding the archetypes when the arch tree > changes. > > My thought here is that lib/Makefile can run svnversion and puts that in > a state file (.collect.svn.new). Then, the process compares that file with > the old one (.collect.svn) - if different, it runs the collect and moves > the file over. If the same, it just doesn't do anything. > > In this way, a collect would automatically be done whenever the > archetypes are updated. Sounds like a good idea to me, if possible :) > I think similar logic could also be used to embed the version number into > the client and server binaries. That way, when someone reports a bug, it > is very clear what version they are running. By using a state file, it > means we don't need to recompile and relink everytime (if we just used > svnversion to blindly write a .c/.h file, then everytime it would recompile > and relink that component). Agreed, having the exact revision number would be really nice to see the exact issue. > In both of these cases, we also need to handle the case for the official > releases, where there will not be any SVN information in the downloaded > source code, and the user may not even have svn tools installed. Well, that's what tags/branches are for, i guess :) > In the case of lacking the svn data itself, I'd think the makefiles could > just check for .svn files - I'd rather not have to reconstruct the > makefiles for the official versions. In terms of the version string, I > think the file that inclues it would have to be part of the distributed > version so that it is there for the compiled in. Including the SVN version > in officially released distributions shouldn't cause any problems IMO. No issue for me either. Nicolas From fuchs.andy at gmail.com Mon Sep 25 17:14:34 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon, 25 Sep 2006 18:14:34 -0400 Subject: [crossfire] draw_ext_info/message update/redo In-Reply-To: <45163C53.8010501@sonic.net> References: <45163C53.8010501@sonic.net> Message-ID: On 9/24/06, Mark Wedel wrote: ... > The main advantages I see of the drawextinfo is this: > - Support for the media tags (bold text, different fonts, etc). I'd expect > these to be infrequently used, as in general the global tag/attribute should be > used. But I think use in NPC messages giving clues what can be discussed with > them by doing bold or underline would be very good (we should probalby decide > what the form for that syntax highlighting it is, so that it is consistent > accross all the maps/NPCs) Or we could make a new tag like "[triggerword]". The server then could decide on it's formatting. Also, if it is passed to the client, the client could make the hilighted phrase clickable. > - Instead of the server telling the client the color to use and the client > blindly following it, the client now knows the type of messages. So with some > extra logic, I could decide that I want the level gain message to be in a > specific font in bright green, even though the server says those should be in > red. It would also allow for easier filtering (if chat/say/shout have their own > types, easier to have a conversation pane, etc). Very useful in my opinion. I really like the colors that "me chats: " uses. Though that could be considered a bug. -- Andrew Fuchs From fuchs.andy at gmail.com Mon Sep 25 17:20:22 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon, 25 Sep 2006 18:20:22 -0400 Subject: [crossfire] The keeping of documents regarding policy decisions (was Re: "Jesus weeping" map) Message-ID: On 9/25/06, ERACC Subscriptions wrote: ... > Go for it. The "Jesus weeping" map is incongruous with the rest of crossfire > since the decision was made a long time ago to ... IMO, we really need to start writing this stuff down somewhere. Possibly the wiki, but preferably somewhere that limits who can modify it. (could be done with making a namespace on the wiki and limiting editing to only a few trusted users) -- Andrew Fuchs From mwedel at sonic.net Mon Sep 25 23:24:14 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 25 Sep 2006 21:24:14 -0700 Subject: [crossfire] draw_ext_info/message update/redo In-Reply-To: References: <45163C53.8010501@sonic.net> Message-ID: <4518AB6E.7030000@sonic.net> Andrew Fuchs wrote: > On 9/24/06, Mark Wedel wrote: > ... >> The main advantages I see of the drawextinfo is this: >> - Support for the media tags (bold text, different fonts, etc). I'd expect >> these to be infrequently used, as in general the global tag/attribute should be >> used. But I think use in NPC messages giving clues what can be discussed with >> them by doing bold or underline would be very good (we should probalby decide >> what the form for that syntax highlighting it is, so that it is consistent >> accross all the maps/NPCs) > > Or we could make a new tag like "[triggerword]". The server then > could decide on it's formatting. Also, if it is passed to the client, > the client could make the hilighted phrase clickable. That could be reasonable. However, I think that should just get passed to the client, and the client decides what to do with it, not the server. My general philosophy is to try to offload those decisions/that work to the client - in a sense, we should try not to hold preferences on the server unless they are a per character type of issue. And if passed to the client, it could of course make it clickable (just generated the appropriate say command). A possible interesting extension could be something like [img=sword.111] or the like. The image itself being one of the images in the arch directory. Then you actually could have pictures of monsters with the scroll that describes them, etc. And from a more complex level, you could actually have real maps to places, not the ascii maps. The map would have to be put in the arch tree, and a the images collected, but that is certainly better than anything we have now. > >> - Instead of the server telling the client the color to use and the client >> blindly following it, the client now knows the type of messages. So with some >> extra logic, I could decide that I want the level gain message to be in a >> specific font in bright green, even though the server says those should be in >> red. It would also allow for easier filtering (if chat/say/shout have their own >> types, easier to have a conversation pane, etc). > > Very useful in my opinion. I really like the colors that "me chats: " > uses. Though that could be considered a bug. To me, the filter/font is less desirable than the filtering. With this change, it will now be possible to really have a tab just for chat related messages, etc. I think to actually be able to set colors/fonts, we may need to trim down the number of subtypes, and/or make some common values. From mwedel at sonic.net Mon Sep 25 23:25:43 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 25 Sep 2006 21:25:43 -0700 Subject: [crossfire] Gridarta CFJavaEditor Jar? In-Reply-To: <200609251005.22154.subs@eracc.com> References: <200609251005.22154.subs@eracc.com> Message-ID: <4518ABC7.8030604@sonic.net> ERACC Subscriptions wrote: > On Sunday 24 September 2006 11:45 pm > Kevin R. Bulgrien wrote: > >> Could someone make a jar file from the CFJavaEditor sources on the >> Gridarta project? I have so far been unable to get a working >> build environment. I get errors when I try the command-line build >> instructions in INSTALL.txt, and I am having great difficultly >> getting ant installed. > [...] > > I was provided with a working copy by one of the Gridarta developers and have > it availalble here: . > The same developer has been given FTP access to that directory to keep an up > to date copy of CFJavaEditor.jar available. > > I was unable to use the arch directory from SVN and thought it was my build of > Gridarta at fault but that turned out not to be the case. Apparently the > problem was with many of the graphics being converted to text during the > migration from CVS to SVN. I understand Mark Wedel has now fixed this > problem(?). Yes, the conversion switched many to ascii (most likely, CVS thought of them as ascii, but didn't do any mangling of them). The arch trees should all be OK now - I committed updated images about 24 hours ago. From alex_sch at telus.net Fri Sep 29 20:58:50 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 29 Sep 2006 19:58:50 -0600 Subject: [crossfire] Pupland Monunent Service Message-ID: <451DCF5A.2050406@telus.net> Currently, the hall of fame in pupland just sits there static, so I'm thinking that perhaps I should make a python script replacement for the monument service, to inscribe the names of those who have beat the evil masters if they want it inscribed. Anyone have any objections to replacing the monument with a 'magical' python based one? Alex Schultz From subs at eracc.com Sat Sep 30 10:55:39 2006 From: subs at eracc.com (ERACC Subscriptions) Date: Sat, 30 Sep 2006 10:55:39 -0500 Subject: [crossfire] Pupland Monunent Service In-Reply-To: <451DCF5A.2050406@telus.net> References: <451DCF5A.2050406@telus.net> Message-ID: <200609301055.41003.subs@eracc.com> On Friday 29 September 2006 08:58 pm Alex Schultz wrote: > Currently, the hall of fame in pupland just sits there static, so I'm > thinking that perhaps I should make a python script replacement for the > monument service, to inscribe the names of those who have beat the evil > masters if they want it inscribed. Anyone have any objections to > replacing the monument with a 'magical' python based one? No objection here. Sounds like a decent idea to me. Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 10:54:47 up 8 days, 3:26, 14 users, load average: 0.23, 0.23, 0.13 ERA Computers & Consulting - http://www.eracc.com/ <- get VOIP here! eComStation, Linux, FreeBSD, OpenServer & UnixWare preloads & sales