From alex_sch at telus.net Sun Jul 1 00:05:15 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 30 Jun 2007 23:05:15 -0600 Subject: [crossfire] Organizing efforts, was Re: Project: New Intro In-Reply-To: <4686FA14.8020105@sonic.net> References: <46855F98.1090908@telus.net> <4686FA14.8020105@sonic.net> Message-ID: <4687360B.6030208@telus.net> Mark Wedel wrote: > The original mail in question had what I really two different topics - one for > the idea of redoing what players see when they connect, and a second about group > efforts to get things done in a timely fashion. This mail more focuses on how > to do group efforts - ideally to come up with some scheme that can be used as a > model, because as Ryo pointed out, there are lots of big projects on the list > beyond just a new starting village. > Indeed I did have those two topics combined in there. Indeed there are lots of other big projects, but I was just trying to pitch what seemed most reasonable to me to be a starting place :) Perhaps I may have been somewhat hasty in rushing to trying to suggest one particular project, however I was rather anxious to see things happen and I was, and still am, concerned that the decision making process could be too slow or even stall. > Some projects/changes may have dependency issues (rebalancing spells should > likely be done after redoing classes/races as an example). Those need to be > identified and ordering sorted out. > Perhaps map out all proposed big projects in including their dependencies, and create a sort of vague roadmap which could be posted on the site somewhere, which would be revised to include a marker for what is the current project once it's been agreed on. Perhaps this may sound a touch overengineered, however I think that such a roadmap could be made quick and simple with Graphviz and would make it easy to see what priorities and possible future priorities may be including dependencies. Anyways, this little paragraph of mine is getting a little off topic into the technical implementation details which are of relatively lesser importance. > In this particular case, I agree that a new intro should be something at the > top of the list. But going forward, I think we need some way to decide what is > done. > > In the context above, developer is anyone that is willing to help out to get > the project done - doesn't mean coder, could be map maker, artist, person > writing documentation. but someone that just plays the game probably shouldn't > be included, as that isn't going to help get the project done - my idea here is > that you want the project decided on by those actually going to do the work. > One the project is decided on, all are welcome to pitch in ideas, etc. > Yes, this makes sense: That the project would be decided on by those who feel committed to trying to do what they can for the project that is decided on. > So after the project is decided, there needs to be a project leader. In some ways, it may make sense to have project leaders decided before the project, in that each proposed project prior to deciding which one would have a developer assigned to the project who feels competent with the project at hand and comfortable with the leadership role, which may often be whoever had the biggest hand in proposing that particular project. This might shave a little time off of deciding on a project leader and avoid disputes, though it may not, but just a thought. > Depending on the project, what that means may vary. But I would say that the > leader should come up with a plan detailed enough that it can be divided into > work by several people. An example would be maps - having broad outlines of > what should be done is a good starting point, but having a 1 or 2 line > description of what is needed on the maps then provides folks enough detail to > work on it. For coordination, putting this chart on the wiki, and people > signing up for parts of it is probably a good way to go. > Yes, agreed. And just as a little note/tip/plug, dependency charts of tasks within the project could also be done quick n' dirty with Graphviz in a clear format if the project leader believes it would be useful :) > I tend to think that it is best of the project lead starts by sending out a > fairly detailed document - the reason I say this is that a fair number of > developers have been around a long time, and can probably come up with a fairly > complete starting plan without a lot of input. They should still send that out > and get input, but having a good starting point may trim a week or two off the > discussion, and also provide a clearer picture to everyone what the idea is. > Some of the basis here is also that some points have already been extensively > discussed in the past - new points are welcome, but we don't necessarily need to > fully discuss all the issues again. > Yes, this makes sense to me > Once the plan is more or less agreed to (hard to get 100% agreement), people > start working. In fact, work may start before this, as there may be some points > which everyone is in agreement on, and it may be more adding new points/details > to the plan. > > The role of the project lead/coordinator is to take the pieces and make sure > they all work. In the case of the map example, look over the maps, make sure > they meet various standards, basic idea behind the map, and link up the exits, > etc (possible that some maps completed before the ones they link to). > Indeed, this type of role is important (and is some ways something I feel we've been lacking to an extent in the project in general) > All projects should be worked on until fully done. If a new NPC speech method > is done that requires modifying the NPCs, it isn't sufficient to put that new > support in and modify the NPCs in scorn and say 'it is ready' - that project > isn't done until all the NPC's on all the maps are updated. Otherwise, past > experience shows that those other NPCs probably won't get updated. > Yes, we often get too much in the way of sparsely used features and this policy may help avoid that (hopefully). Alex Schultz From crossfire at kahnert.de Sun Jul 1 01:43:46 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sun, 1 Jul 2007 08:43:46 +0200 Subject: [crossfire] Organizing efforts, was Re: Project: New Intro In-Reply-To: <4686FA14.8020105@sonic.net> Message-ID: <20070701064346.GA869@cthulhu.desy.de> On Sat, Jun 30, 2007 at 05:49:24PM -0700, Mark Wedel wrote: > This mail more focuses on how to do group efforts - ideally to come up > with some scheme that can be used as a model, Is there a list of deciders? Who needs to nod, before something could be implemented? If there is no such list, create it. Or better extend the developer list with the responsibilities. > there are lots of big projects on the list beyond just a new starting > village. On the CF 2 todo list are a few high priority projects. Most of them are independent (without dependencies to the other projects). "Character Creation" and "Game Balance" have a strong dependency by each other. Those two needs the highest priority for CF 2, and it has to be clear what's the goal before a single line of code is written for it. > Some projects/changes may have dependency issues (rebalancing spells > should likely be done after redoing classes/races as an example). > Those need to be identified and ordering sorted out. Exactly. Touching this part of the game means, you have to abandon old characters. Everybody has to start over with a level 1 character. You can't change the game balance and keep the old unbalanced characters. This has to be clear and stated. > But for any volunteer project, it is difficult to force people to do > anything. It's not necessary to force someone. It's finished when it's finished. You don't have to pay a contract penalty if you can't keep your timeline. > My thought here is that each month (or maybe more/less frequently, > based on how long it takes to do the different things), the developers > should decide what is the most important thing to change/add/fix. If one project is finished, than there are free capacities and that's the time you have to decide what's made next. Should they help others to finish their project faster or is there another project needs to be done? There is no need for peridical polls about the priority. > In this particular case, I agree that a new intro should be something > at the top of the list. But going forward, I think we need some way > to decide what is done. See beginning, who are the decision makers? > but someone that just plays the game probably shouldn't be included, I don't think so. They can help testing. If you like to rebalance and reorganize the world, you need player who likes to test it. I think about a set of standard characters on different levels. How does it feel to solve the map as a sorcerer on level 5 compared to a warrior on level 5. Is it possible with a fireborn, what's the challenge for a dragon, ...? Create a standard character for each class on different levels. Don't say this is a level 5 map if not all the level 5 standard characters classes passed through it. Maybe you'll see that this map is a level 1 dragon warrior map but a level 8 fireborn sorcerer one. Yes, this needs extensible testing and this will only be able with a lot of players. You'll need a "game balance coordinator / leader " which will collect the player comments and discuss this with the developers. > I tend to think that it is best of the project lead starts by sending > out a fairly detailed document - the reason I say this is that a fair > number of developers have been around a long time, and can probably > come up with a fairly complete starting plan without a lot of input. And I think that you should develop the idea with the others. Out of the discussion the leader has to make a detailed concept. Creating a detailed document and nobody likes the idea is a waste of time. > Some of the basis here is also that some points have already been > extensively discussed in the past - new points are welcome, but we > don't necessarily need to fully discuss all the issues again. Instead of discuss it all over again, send the link to the archive. > Once the plan is more or less agreed to (hard to get 100% agreement), And again, who has to agree before the work should be started? > but lots of things has been extensively discussed, and all the > discussions in the world don't really make it so that the project gets > done any faster. That's the coders point of view: "need to code", "can be changed later", ... ;) If something is already extensively discussed, than there has to be a summary and a concept for the work plan. If this is missing, the discussion is not finished, yet. J?rgen From nicolas.weeger at laposte.net Sun Jul 1 03:45:10 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 1 Jul 2007 10:45:10 +0200 Subject: [crossfire] classes & guilds, was Re: class guild map In-Reply-To: <4686EDDC.9060203@sonic.net> References: <20070630183324.GA15855@cthulhu.desy.de> <4686EDDC.9060203@sonic.net> Message-ID: <200707011045.14482.nicolas.weeger@laposte.net> > One problem with this approach is that skill scrolls now become value for > all classes and all levels (until such point as you've minimized the > affinity for all your skills). Which I'm not positive is a good thing - > we've had things like this before (in particular, scrolls of identify) - > the 'fix' for that was to add identify tables so that low level characters, > or those not first to run to the mage shop after it reset, could identify > their items. > > I have no problem with the general idea, but I think that any reduction > in affinity should be done through quests (guildmaster teaches you > something after completing quest, or some quest item reduces it). I don't > think having it changed on the whim of random treasure showing is that > good. What about we simply remove skill scrolls? Or seriously reduce their frequency? I think one could acquire a skill either "randomly" (drop in water a few times, you start knowing how to basically swim - but you can't progress much), or through some masters (want to learn karate? then find a dojo where to train, and acquire basic skills, and when you're somehow higher level you can train for higher level access). Of course not all skills would necessarily work like that (how do you train woodsman without really using it?) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070701/c0805d9a/attachment.pgp From nicolas.weeger at laposte.net Sun Jul 1 03:57:52 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 1 Jul 2007 10:57:52 +0200 Subject: [crossfire] Organizing efforts, was Re: Project: New Intro In-Reply-To: <4686FA14.8020105@sonic.net> References: <46855F98.1090908@telus.net> <4686FA14.8020105@sonic.net> Message-ID: <200707011057.55792.nicolas.weeger@laposte.net> > My thought here is that each month (or maybe more/less frequently, based > on how long it takes to do the different things), the developers should > decide what is the most important thing to change/add/fix. My rationale > here is that if the developers agree that some issue is most important, > they are much more likely to help out. If the general developer response > is 'that isn't very important', then you could pretty much figure they > probably aren't going to put much effort in. Note it may be reasonable to > do less frequent votes, on the basis that after the top priority is done, > whatever was #2 probably makes sense to be the next top priority, etc. But > new projects may pop up, or the completion of one may spawn a new one > (before such and such feature was added, no one thought of something or it > wasn't feasible). No, not developers. Developers *and* players. I'm afraid developers deciding will lead back to current situation, focused on the code and not contents. For us it's sometimes sexier to document the whole code than fix a messy complex bug that isn't too important (but still bothers players) :) One important thing, though, is documentation. We should clearly document things, so we have 1) reference when something seems strange 2) detailed explanation non coders can understand and comment on (example: bracers will add armour, but only if it's the "best" armour bonus - thus if you cast a spell giving armour+5 your bracer armour+2 won't have any effect ; or how resistances / immunities work). > In the context above, developer is anyone that is willing to help out to > get the project done - doesn't mean coder, could be map maker, artist, > person writing documentation. but someone that just plays the game > probably shouldn't be included, as that isn't going to help get the project > done - my idea here is that you want the project decided on by those > actually going to do the work. One the project is decided on, all are > welcome to pitch in ideas, etc. Player feedback is important. I would even say that's the critical thing, else we end with a developers-only game. > I tend to think that it is best of the project lead starts by sending out > a fairly detailed document - the reason I say this is that a fair number of > developers have been around a long time, and can probably come up with a > fairly complete starting plan without a lot of input. They should still > send that out and get input, but having a good starting point may trim a > week or two off the discussion, and also provide a clearer picture to > everyone what the idea is. Some of the basis here is also that some points > have already been extensively discussed in the past - new points are > welcome, but we don't necessarily need to fully discuss all the issues > again. Again, developers will focus on code, whereas we need also players. Once something is decided, yes we can start doing code / preparing for coding tasks. Not before. > The role of the project lead/coordinator is to take the pieces and make > sure they all work. In the case of the map example, look over the maps, > make sure they meet various standards, basic idea behind the map, and link > up the exits, etc (possible that some maps completed before the ones they > link to). No, the role of the coordinator is to make sure the work is done, he's not necessarily the only one working :) > I don't mean to have draconian policies in place in the above - in fact, > just the opposite. What I really want is something in place so that > projects can be decided fast, what needs to be done decided fast, and that > broken down into pieces so that it can be completed rapidly. That's not to > mean without thought, but lots of things has been extensively discussed, > and all the discussions in the world don't really make it so that the > project gets done any faster. We do need a draconian policy on some things, though. IMO, we should reject things if they don't bring anything to the game, or are messing with other things. As an example, I'd say my logger and newspaper plugins shouldn't have been committed in their current state - they are basically useless for now, and didn't really correspond to any needed feature. So we should forbid some commits sometimes, else the code will go astray. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070701/1cd1228b/attachment-0001.pgp From crossfire at kahnert.de Sun Jul 1 07:27:36 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sun, 1 Jul 2007 14:27:36 +0200 Subject: [crossfire] classes & guilds In-Reply-To: <4686EDDC.9060203@sonic.net> Message-ID: <20070701122736.GB869@cthulhu.desy.de> On Sat, Jun 30, 2007 at 04:57:16PM -0700, Mark Wedel wrote: > Juergen Kahnert wrote: > > Doesn't show the level itself the knowledge about a skill? Is having a > > "master level 1" better than "basic level 50"? > > No. If you are master level 10, and basic level 10, the skill > operates the same. I would say, no, the master should be better. How? Just use the "affinity" value to modify the effect of a skill. A warrior with a high affinity to one handed weapons should be able to do more and "better" damage than a clumsy one. You could use it as a divisor for the damage. The lower the affinity value the higher the damage and vice versa. This won't work for every skill, but most. If not the damage, than the chance like for alchemy. Or the duration like hiding. > The difference is that it may take a character 4 times as much exp to > get to basic level 10 as it takes a character to get to master level > 10. For example, if you compare two karate black belt fighter, both have the same level (black belt), but they could have a totally different skill, because of the natural talent / ability (here called "affinity value"). Someone who trained really hard may be able to beat someone with a high natural ability who spent less time training. > Reducing the exp gain is a very easy way to add some difference to the > classes/skills. Level caps would be another way (I know that this may > not be liked, but if you instead say 'this class just doesn't get a > skill', that is basically the same as a level cap of 0). I don't say to deny a class a specific skill. Just make it harder to master and without advice of the guild masters, no chance to discover the deepest knowledge. This is because the guild masters have access to the studies of generations. If someone has to learn it all by himself, he has to live very, very long. ;) > > Every skill level you're able to read one skill scroll to decrease > > the "affinity" value. And make skill scrolls a rare item. > > > > Only the class skills will be allowed to decrease below 1. And > > skills unlikely to the class not below 2. > > > > This could be fine tuned if you like the idea. > > One problem with this approach is that skill scrolls now become > value for all classes and all levels (until such point as you've > minimized the affinity for all your skills). Which I'm not positive > is a good thing Ok, no problem. Use a marker on every skill. This marker will keep the xp of the skill a character has by reaching a new overall level. Now calculate how much [overall] xp was gained through which skill. And those skills above e.g. 15% will decrease the affinity value. This needs some tuning as well, and is independent from skill scrolls. > I have no problem with the general idea, but I think that any > reduction in affinity should be done through quests (guildmaster > teaches you something after completing quest, or some quest item > reduces it). This could be also done. Add a flag which will decrease the affinity value after reaching a new value. Either by reaching a new overall level or after reaching a new level of the skill. This flag could be set by the guild master, quest reward or whatever. > I don't think having it changed on the whim of random treasure showing > is that good. As always, I just offer options how it could look like. I'll never say it has to be like this. ;) Hopefully we're able to find a good solution for more fun with CF. :) > So it is a matter of modify the treasurelists as needed to have > different sets of skills for different classes. Right now, there is > something like a 'basic skill' treasurelist, which contains all of the > basic skill everyone starts with (search, disarm, melee weapons, etc). > Those need to get altered, so fighters get good versions of the combat > skills, and mages get the bad versions, instead of everyone getting > the same. Or just stack them. For example, if a fireborn gets 20 advances of the skill pyromancy and the pyromancer also 20, stack them together and advance the skill 40 times. Starting with an affinity value of 5 with an reduction of 0.04 * affinity value per advance, you end up with a starting affinity level of ~1 for pyromancy as a fireborn pyromancer. > I don't see any reason that every character should be able to learn > every skill. And in fact, right now there are a few special class > limited skills (meditation comes to mind as one that can not be > learned later) Good example. I've no idea why meditation shouldn't be learnable. Even if you never meditated so far, you'll be able to learn it (in the real world). Same for other things. You're able to join a karate club and learn karate, ... Only because other role playing games have hard limits for races and classes doesn't mean you also have to implement them. Yes, copying things is easier than develop new ones and may be more safe, but it's not the case that it has to be always the same. Same for weapon / armor restrictions. Extend the bonus malus system on weapons and armor. A mage shouldn't like to use heavy armor because this makes him fumble the spells more often and heavily reduces the spell points regeneration. A fighter wouldn't care nor notice the malus, but a mage. > The idea of skill/class reform in terms of archetypes doesn't > need/have to conflict with the idea of guilds. With all the changes > above, there is nothing to prevent there from being fighters guild - > but instead of it being based on class, it is really based on your > skill level. Sure, I thought we already agreed with that. A guild will be based on the skill level (way of living) instead of an initial class. With the initial class you are a member of the specific guild of that class, but that doesn't mean you can't change if you follow the rules of another guild(s). Do you like to see me writing a summary / draft concept of the new skill / class / guild system? Or do we need more discussions about specific parts? J?rgen From nicolas.weeger at laposte.net Sun Jul 1 16:51:28 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 1 Jul 2007 23:51:28 +0200 Subject: [crossfire] classes & guilds In-Reply-To: <20070701122736.GB869@cthulhu.desy.de> References: <20070701122736.GB869@cthulhu.desy.de> Message-ID: <200707012351.32009.nicolas.weeger@laposte.net> > Good example. I've no idea why meditation shouldn't be learnable. Even > if you never meditated so far, you'll be able to learn it (in the real > world). Same for other things. You're able to join a karate club and > learn karate, ... One game I saw worked by "skill spots". I don't remember the values or the details, but the general idea was: characters had like 20 spots, which could be filled by skills, with 1 spot for basic skills, 2 for advanced ones, and 3 for master ones. There was a "graph" dependancy, some skills required other skills at a certain level. Players could "drop" skills, or reduce their spot, to use other ones. Not totally sure about the way that was done, though (didn't play, just saw someone play). As for the general idea for skills, I think it's nice to be able to learn all skills (except intrinsec skills, like levitation or clawing - though with nails? ). But we definitely need to balance that somehow, through maluses/bonuses, things like that. And I wouldn't oppose to skill restriction, either :) > Do you like to see me writing a summary / draft concept of the new skill > / class / guild system? Or do we need more discussions about specific > parts? I'd say you can write a first quick summary, preferably on the wiki (http://wiki.metalforge.net just create a page somewhere, maybe linked from another - which one, not sure) :) Doesn't mean it's set in stone, but would be nice to have a full summary, I think :) Of course we can still go on discussing on the list. Thanks for all ideas :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070701/f4b561b6/attachment.pgp From nicolas.weeger at laposte.net Sun Jul 1 16:53:25 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 1 Jul 2007 23:53:25 +0200 Subject: [crossfire] reorganizing the entire world In-Reply-To: <20070629194924.GE11217@cthulhu.desy.de> References: <20070629194924.GE11217@cthulhu.desy.de> Message-ID: <200707012353.25879.nicolas.weeger@laposte.net> > > 3) Like point #1 for scrolls in maps, also extend it to NPCs. So the > > various NPCs in scorn could also talk about the goblins around the > > area, and perhaps other things. > > Yes, similar to my idea of giving every NPC knowledge about the world. > Give them extra knowledge about the region, and this will be perfect. Related, even if not totally what you meant: we should definitely use the lore from the wiki, and/or expand it to cover the world. So places have historic facts, some background stories, which have consequences (Brest is isolated from the rest of the world, do you know why? check the wiki :p) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070701/0ff35485/attachment.pgp From mwedel at sonic.net Sun Jul 1 23:53:13 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 01 Jul 2007 21:53:13 -0700 Subject: [crossfire] classes & guilds In-Reply-To: <200707012351.32009.nicolas.weeger@laposte.net> References: <20070701122736.GB869@cthulhu.desy.de> <200707012351.32009.nicolas.weeger@laposte.net> Message-ID: <468884B9.4000105@sonic.net> To quickly follow up on some points: I am not adverse to all races/classes starting with all skills (save those intrinsic ones like Nicolas mentions), but with a fair number being really poor versions. For example, the fighter would have good versions of things like melee weapons, bow, perhaps smithery, and really bad versions of the wizard ones (pyromancy, evocation, etc). This also does cover the place - everyone can in theory swim, but those with bad versions may have a very hard time to get exp in it, and thus can never swim very well. It seems that there is a fair amount of debate exactly how the different versions of the skills operate. The basic division seems to be: 1) skills operate the same, just harder to get levels in ones you are not good at. So a person with crappy version of evocation at level 10 casts the same spells just as effectively a person with a good version of the evocation skill at level 10. It is just that crappy version took a lot more work to get to level 10. 2) Skills operate different. A person with the good version of evocation at level 10 casts spells much more effectively than a person with crappy evocation at level 10. I'd think that in this model, the exp gain should be the same - that is to say that the crappy version needs the same exp total as the good version to get to level 10. The difference here is that it becomes harder with the bad version, because the spells don't do as much damage, so you need more of them, etc. I say that level gain should be the same, or close, as otherwise you are really punishing those with poor versions of the skills - not only is the skill not as effective, but you need more exp. You can of course do that, but then at some point, it is almost what is the point of offering such skills in the first place. Note also that in many cases, point #2 really looks like point #1. For example, for disarm traps, you basically either disarm the trap or don't, and those odds are based on level, difficulty of trap, etc. Presumably with method #2, the character with the bad version gets less benefit from their skill level, so effectively this just means that the bad version of level 10 is the same as the good version at level 3. So you don't really gain much in this case, except for guilds that look at minimum level (but then the question comes up, should they also take the version of the skill into account? A person with the poor version at level 10 should be treated differently than a person with the good version at level 10. At some level, it almost seems that a bunch of complexity is being added, and internal at some level, everything is getting adjusted skill level, and using method #1 in that case is a lot easier. The original point of redoing skills/classes was the general complaint that at higher levels, all classes look alike, becuase all classes/races have the same skills at high levels. From some of the discussions here, I'm not sure if everyone actually thinks that is an issue, and instead of fixing the classes/skills, the idea is to enforce/add differentation by guilds and special perks. In that case, this could be the easiest: 3) There is no classes - every starts with same version of all the skills, and what they become is based on what skills they use. A person using magic would be in the mages guild, a person using melee skills in the fighter, etc. This becomes a pure case of you are what you practice. Characters may look the same at higher level, OTOH, if the guilds do offer special benefits, maybe not. This doesn't require any code changes - the real change that would be needed is some new way for characters to get starting equipment (as that is one of the big differences between classes right now - mages start with spellbooks, fighters with arms and armor). From mwedel at sonic.net Mon Jul 2 00:22:27 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 01 Jul 2007 22:22:27 -0700 Subject: [crossfire] Organizing efforts, was Re: Project: New Intro In-Reply-To: <4686FA14.8020105@sonic.net> References: <46855F98.1090908@telus.net> <4686FA14.8020105@sonic.net> Message-ID: <46888B93.2060705@sonic.net> Quickly catching up with followups: I'm not sure we really need graphs to track dependencies - I'm not sure they are that complex (there are not that many). What is really needed is to just note what the dependencies are, so we can know there is no reason to bring spell reform to the table until class/race/skill changes are done. Having project leaders before the project is worked on/voted on makes sense. And as I think about it more, it would generally be good to have the detailed project plan before voting, so people actually know what they are voting on. OTOH, writing up project plans for all the potential things to do is a daunting task. The flip side is that if someone is willing to write up the plan, there is probably at least one person willing to work on the problem. I'd expect in most cases the vote to be pretty clear cut. I think each vote would have to be limited to the top 5 (or so) most important projects, which is probably decided by the person running the vote (but once again, I think the seasoned developers would have a pretty good idea). Certainly anything that has a dependency on it should almost always be on that list. And certainly opinions could be solicited for what should be on the voting list. As stated in my original message: The reason that only the developers vote on the next project to work on is because it is the developers doing the work. The testers are important, but for the most part, they are not going to help get the project get done. Likewise for the players. A big concern I have is that if it is opened up to non developers, we'll get a vote that basically none of the developers (or too few to for meaningful team) agree with. So the players say 'foo should be done first', and developers say 'I could care less about foo'. End result, foo is never done, and this system fails completely - if the vote has no meaning, why do a vote? I didn't really state it, but my expectation is that for the top priority project, as many developers as needed work on it. I'd think that in most cases, that would probably top out at 4-6. If only 1-2 people are going to work on each project, there really isn't any point to this process - the person working on the project would just go an do it, and can coordinate with that other person (can probably find 1 other person that agrees with that project) My hope is that by concerted effort, things get completed in a timely fashion (I think also working as a group may make people work harder/finish things up, because in some sense, people are depending on them. If I individually choose to work on foo, no one is really harmed/waiting for me if it takes 6 months to complete). The current process is basically the individuals work on projects, and they sometimes get completed. That really isn't working if our goal is to complete the stuff on that list. The idea behind the lead sending out a project detail isn't a 'this is how I'm going to do it, tough luck', but rather provide everyone on the list with a detail on what/how they think it should be done. That doesn't stop further discussion. I just think it will save time for the person to do something like 'I think skills should be redone. Here is my list on how they should be redone - opinions' vs a 'skill should be redone. Any thoughts?' Both solicit opinions, but in the first case, you provide some starting ideas. In a sense, the person writing that is probably putting his opinions down first, rather than waiting for feedback, and then putting his plan down. Another reason for this is that the person leading/working on the project is more likely to do so if the plan is one he likes. If the idea/plans that come out of discussion are such that the lead developer things 'this is idiotic', how likely do you really think it is he is going to spend much work on that? He doesn't think it is the right direction. ---- I've said it before, and I'll say it again: Crossfire is a volunteer project. There really isn't any way to force anyone to do anything. So the point here is to try and get something in place so that people will want to do the work, and the best way to do that is to make sure those doing the work have as much say into what is going to be done as possible. That certainly doesn't mean that others opinions are ignored, but there are lots of considerations to take into account - complexity of suggested changes, other side effects, willingness to do those changes. And last point: For quite some time, the mode of operation has been long and varied discussion about all sorts of points, with developers going off working on what they want to work on. The end result of that is very few of the 'important' projects on the TODO list get done. so I would hardly say the current method is working especially well. From mwedel at sonic.net Mon Jul 2 00:30:59 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 01 Jul 2007 22:30:59 -0700 Subject: [crossfire] Project: New Intro In-Reply-To: <46855F98.1090908@telus.net> References: <46855F98.1090908@telus.net> Message-ID: <46888D93.90105@sonic.net> Going back to original topic now Alex Schultz wrote: >I propose that we focus on what content the player sees first > in the game because after all, it not only is the first part to leave an > impression, but also how effective it is at teaching the player impacts > all of their other experiences while new to the game. I believe we > should redesign the intro of crossfire, and expand it beyond the newbie > house and such we have now, I believe into it's own island or walled > town. Scorn was in some ways intended to be a newbie town, but really > many areas of it require level 10 or higher to be effective and it has > become a transportation nexus. Scorn certainly needs reorganization, but > instead of turning it into a newbie town I believe it would be more > effective to make a brand new one of the first two or three levels in > which the player would be taught alot about how the world works and how > to play. First question on this: It has been suggested that the character creation get completely redone, with spiffy interface, etc, instead of the the current 'in game' method. Does this proposal address this at all, or is this more based on what the player does once the character is created, and leaves the creation aspect itself still on a TBD list? > > On the maps mailing list one new newbie house was created though didn't > really finish being polished: This could be used as part of it but much > more would certainly be needed. We should create a checklist of things > to do for this new introduction to CF and should have a clear listing of > who is working on what. Teamwork and organization would be key in > achieving this. I propose the following as a checklist to start with > though it would be expanded as things go along: > > -Decide on what newbies need to learn before getting into the game > -Decide how to sort this into the different maps, and add each of these > maps to the checklist > -Decide how to lay the maps out in a small isolated (island or walled) town > -Integrate with the CF world. That all looks good to me. A small town on an island works out really good. A few questions remain: Is this just an island for tutorial purposes (this is how you cast a spell, this is how you search for a trap, etc), or is this more designed as a low level area? In both cases, does one see a 'ship to mainland' type thing which is a one way ticket off the island to scorn (or perhaps other towns? Maybe replace the nexus with this town, and experienced players can hop right over to the ship to navar city if they really want to). From alex_sch at telus.net Sun Jul 1 23:57:56 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 01 Jul 2007 22:57:56 -0600 Subject: [crossfire] Organizing efforts, was Re: Project: New Intro In-Reply-To: <46888B93.2060705@sonic.net> References: <46855F98.1090908@telus.net> <4686FA14.8020105@sonic.net> <46888B93.2060705@sonic.net> Message-ID: <468885D4.8090305@telus.net> Mark Wedel wrote: > Having project leaders before the project is worked on/voted on makes sense. > And as I think about it more, it would generally be good to have the detailed > project plan before voting, so people actually know what they are voting on. > OTOH, writing up project plans for all the potential things to do is a daunting > task. The flip side is that if someone is willing to rite up the plan, there > is probably at least one person willing to work on the problem. > Well, I would say perhaps not the full detailed plan, but at least some sort of outline of what would need to be done. I wouldn't want this requirement to make the process too much effort really. > I'd expect in most cases the vote to be pretty clear cut. I think each vote > would have to be limited to the top 5 (or so) most important projects, which is > probably decided by the person running the vote (but once again, I think the > seasoned developers would have a pretty good idea). Certainly anything that has > a dependency on it should almost always be on that list. And certainly opinions > could be solicited for what should be on the voting list. > > As stated in my original message: The reason that only the developers vote on > the next project to work on is because it is the developers doing the work. The > testers are important, but for the most part, they are not going to help get the > project get done. Likewise for the players. A big concern I have is that if it > is opened up to non developers, we'll get a vote that basically none of the > developers (or too few to for meaningful team) agree with. So the players say > 'foo should be done first', and developers say 'I could care less about foo'. > End result, foo is never done, and this system fails completely - if the vote > has no meaning, why do a vote? > Well, so far as I can see, two valid concerns have come up on both sides of this: 1) Only developers vote and the interests of what makes the game fun and what players want is lost 2) Both developers and players vote and that tips the scale to a project that developers are highly disinterested in and thus little gets done about the 'chosen' project Because of these issues, I don't believe we can simply have just developers, or just developers and players as the voting pools. The way I believe this could be solved to satisfy both concerns would be by making this "Top 5" list to vote on, heavily influenced by polling players about what interests them of the larger list of projects. This way, what players are interested in will be remembered and will influence the process, but the selected project will not end up being one that will disenchant developers. > And last point: For quite some time, the mode of operation has been long and > varied discussion about all sorts of points, with developers going off working > on what they want to work on. The end result of that is very few of the > 'important' projects on the TODO list get done. so I would hardly say the > current method is working especially well. Agreed. :) Alex Schultz From nicolas.weeger at laposte.net Mon Jul 2 15:42:22 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 2 Jul 2007 22:42:22 +0200 Subject: [crossfire] Organizing efforts, was Re: Project: New Intro In-Reply-To: <20070701064346.GA869@cthulhu.desy.de> References: <20070701064346.GA869@cthulhu.desy.de> Message-ID: <200707022242.25614.nicolas.weeger@laposte.net> > Is there a list of deciders? Who needs to nod, before something could > be implemented? > > If there is no such list, create it. Or better extend the developer > list with the responsibilities. There is no formal decision process. The closest is this list, I guess. > Creating a detailed document and nobody likes the idea is a waste of > time. Indeed. But sometimes it's useful to sum up a long discussion :) > Instead of discuss it all over again, send the link to the archive. For that you need someone to find the link, or copy conversation to the wiki - and most of the time no one does that... Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070702/5a0fd38b/attachment.pgp From nicolas.weeger at laposte.net Mon Jul 2 16:39:54 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 2 Jul 2007 23:39:54 +0200 Subject: [crossfire] Items blocking view In-Reply-To: <200706112334.49514.nicolas.weeger@laposte.net> References: <200706112334.49514.nicolas.weeger@laposte.net> Message-ID: <200707022339.54446.nicolas.weeger@laposte.net> Hello. > I'm wondering the reason of the blockview behaviour. Is there a compelling > reason for that? Since I had no reply, and considering map_layer makes stacking checks kind of obsolete, I removed the 'keep blocksview items on top' logic, thus fixing the bug :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Mon Jul 2 17:02:47 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 02 Jul 2007 15:02:47 -0700 Subject: [crossfire] Organizing efforts, was Re: Project: New Intro In-Reply-To: <468885D4.8090305@telus.net> References: <46855F98.1090908@telus.net> <4686FA14.8020105@sonic.net> <46888B93.2060705@sonic.net> <468885D4.8090305@telus.net> Message-ID: <46897607.6020700@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> Having project leaders before the project is worked on/voted on makes sense. >> And as I think about it more, it would generally be good to have the detailed >> project plan before voting, so people actually know what they are voting on. >> OTOH, writing up project plans for all the potential things to do is a daunting >> task. The flip side is that if someone is willing to rite up the plan, there >> is probably at least one person willing to work on the problem. >> > Well, I would say perhaps not the full detailed plan, but at least some > sort of outline of what would need to be done. I wouldn't want this > requirement to make the process too much effort really. Yeah, outline would be fine. Something more than 'spells should be rebalanced', but less than a final plan. As said, once the project is decided, there would be more discussions, so you probably don't want to spend a large amount of time on a detailed plan that may have lots of changes/additions. So I'd probably say two levels of plans: Brief overview - used in the voting stage, maybe about a paragraph long. Can be informal. Details plan: Used to divide up work - I'd note that this plan may be more functional (maps of this nature is needed), because that may be easier to divide work parts into, where as the overview may be a broader design goal. Note that I'd tend to expect that most discussions would be more in the nature of broader design guidelines, and the lead would then have to take those discussions and form it into the more functional plan of what changes are needed to get there. The reason I think this is the case that in order to really be able to have many people work on one project, they need to have somewhat detailed idea of what is expected/needed. To use the beginning map discussion as an example - right now, discussions are broadly based on type of maps and the like needed. But at some point, that needs to get transformed into a list of the maps needed with a brief description, so that I, or other people, could sign up to make some of those maps and know what is needed. > Well, so far as I can see, two valid concerns have come up on both sides > of this: > 1) Only developers vote and the interests of what makes the game fun and > what players want is lost > 2) Both developers and players vote and that tips the scale to a project > that developers are highly disinterested in and thus little gets done > about the 'chosen' project > > Because of these issues, I don't believe we can simply have just > developers, or just developers and players as the voting pools. The way > I believe this could be solved to satisfy both concerns would be by > making this "Top 5" list to vote on, heavily influenced by polling > players about what interests them of the larger list of projects. This > way, what players are interested in will be remembered and will > influence the process, but the selected project will not end up being > one that will disenchant developers. One thought here might be to do something similar to what was done with the voting for versioning control system. Use a form of selective voting, open it up to everyone, but categorize the different vote takers, eg, developers, testers, players. thus, if developers vote foo as #1, and bar as #4, and players vote bar as #4 but foo as #5, but both developers and players vote qubit as #2, then maybe qubit is done instead, as it has general support from both sides. I agree that we want the players involved. I just think that if the players drove the process, things may not work. I expect that there are a lot more players than developers, so their votes if taken individually could swamp the results (if only 25% of the players agreed on something, that could still be more votes than all the developers if they agreed on a single thing). So I'd probably say now that the vote should be open to everyone, but the person running the vote (most likely me) can weigh the input from different groups of people in different ways. Probably one list of preferences from developers, and another from non developers, and hope something on that list coincides. From nicolas.weeger at laposte.net Mon Jul 2 17:11:15 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 3 Jul 2007 00:11:15 +0200 Subject: [crossfire] Unused features Message-ID: <200707030011.18556.nicolas.weeger@laposte.net> Hello. I started a wiki page at http://wiki.metalforge.net/doku.php/dev_todo:functions_implemented_but_not_yet_used to list features that aren't used. Probably some are missing. Just so map makers, archetype makers, coders have some ideas or free time :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070703/d076dbc9/attachment.pgp From alex_sch at telus.net Mon Jul 2 19:09:03 2007 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 02 Jul 2007 18:09:03 -0600 Subject: [crossfire] Organizing efforts, was Re: Project: New Intro In-Reply-To: <46897607.6020700@sonic.net> References: <46855F98.1090908@telus.net> <4686FA14.8020105@sonic.net> <46888B93.2060705@sonic.net> <468885D4.8090305@telus.net> <46897607.6020700@sonic.net> Message-ID: <4689939F.7080403@telus.net> Mark Wedel wrote: > One thought here might be to do something similar to what was done with the > voting for versioning control system. Use a form of selective voting, open it > up to everyone, but categorize the different vote takers, eg, developers, > testers, players. > > thus, if developers vote foo as #1, and bar as #4, and players vote bar as #4 > but foo as #5, but both developers and players vote qubit as #2, then maybe > qubit is done instead, as it has general support from both sides. > > I agree that we want the players involved. I just think that if the players > drove the process, things may not work. I expect that there are a lot more > players than developers, so their votes if taken individually could swamp the > results (if only 25% of the players agreed on something, that could still be > more votes than all the developers if they agreed on a single thing). > > So I'd probably say now that the vote should be open to everyone, but the > person running the vote (most likely me) can weigh the input from different > groups of people in different ways. Probably one list of preferences from > developers, and another from non developers, and hope something on that list > coincides. One thought about this, if we want a decent amount of player involvement, there should probably be a web-based system (integrated with forum logins or wiki logins?), or in-game system, to collect votes. If this is agreed on I could see if I could quickly get something together as it should be very trivial to code something simple for this task. Alex Schultz From lalo.martins at gmail.com Tue Jul 3 11:08:15 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 3 Jul 2007 16:08:15 +0000 (UTC) Subject: [crossfire] On the software side of "reorganizing the world" Message-ID: I've been busy, so I have mostly lurked through this discussion, although it's very interesting to me. This week I have some time, so I'm writing a detailed braindump that I should post later. Meanwhile, here's an idea I had when working on Pupland; I didn't pursue it, but it could be very useful if this proposal really goes forward. What I think we need is a "world editor". Editing the world right now is very messy and hard (which is why nobody merged Pupland yet, after what, getting close to 10 years of Bigworld). It's difficult to do, the tools are sub-optimal, and the most obvious ways mess up elevation. (The discussion of whether the current elevation values are even useful belongs elsewhere, in the discussion about weather). Ideally, I'd like an UI on at least the magicmap scale, maybe farther, where I can lay mountains, rivers, forests, marshes, sea/land, and preferably copy large chunks right out of an older map (say, Lone Town) and paste into the world. Also control elevation by hand, using an interface similar to map editors in god games (eg, Sim City). And define things like regions right there, too. If someone wants to pursue that, either as a separate tool or a mode for the new editor, I'd be happy to contribute, although I don't know where to start if I were to write it myself. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Tue Jul 3 21:42:05 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 4 Jul 2007 02:42:05 +0000 (UTC) Subject: [crossfire] classes & guilds References: <4686EDDC.9060203@sonic.net> <20070701122736.GB869@cthulhu.desy.de> Message-ID: Ok, here's my take on the whole thing; this is a description of a scenario that would attract me as a player and a contributor, and by no way the Only Single Truth. I should also say I'm an RPG (pen-and-paper) player and author, and this certainly puts some bias into my point of view (for the better, I hope). Skill proficiency ================= I'm really happy about this idea. May I suggest these names: - Dabbler, amateur, or untrained - Professional, advanced, or trained - Master I could even like it if examining a player reveals her "master" skills -- which usually won't be more than a few anyway. In defense of Mark's view of how it works (levels are effective the same way, but need more exp), I'd like to say: Crossfire levels are not a function of experience. They are just that: a measure of how effective a skill is due to experience. So pitching a self-taught amateur that took years to get to level 20 against a professional who got to this level before "graduating", should get an approximately even match. The comparison with an untalented black-belt vs. a talented one is IMO not fair. A better way to think about it is comparing two fighters who were given black belts by the same, rigorous master, in which case they should have more or less the same skill. Then again, maybe by "talented" you actually mean (in game terms) that one has better Dexterity or Strength; this would obviously make a difference and is unrelated to level. That said, I'd put a cap on levels. If we retain the current level system (110/115), I'd cap amateurs at 40 and professionals at 90. (Master is of course uncapped, or capped by the system's own limits, currently 110). It would also be interesting to introduce "difficult" items; for example, weapons that require pro level in their skills. Despite appearances, it's just not possible to fight with a longsword or a battle axe if you've never been trained on it. (You can self-train, but you'll probably hurt yourself a lot in the process, and it would take ages.) Training to increase proficiency should take time. A way to represent that could be: - The system only considers the proficiency for the "instance" of the skill with highest level; so if you're amateur archer 20 and pro archer 18, you're still amateur. - But new experience goes entirely to the higher proficiency. - Upon acquiring a new version of the skill, it's initialized to the exp corresponding to N levels below the current version, where N might be hardcoded, or might be defined by the object that gave you the skill (the mentor). For fighting skills I'd say 2 to 5, for magic possibly more. So the time required to train yourself into a pro is represented by the experience required to "catch up" to you previous level. Character creation ================== Get rid of classes entirely, moving that stage to in-game. During creation, you choose species and, let's say, nationality. The combination of those defines your starting town and initial skills. As far as weapons go, for example, I'd give amateur two-handed weapons to all humanoids (everyone can wield a club or chair), amateur clawing to whoever has claws. Then you can optionally pass through a tutorial area in your home town (probably impossible to enter again after you leave). I'm uncertain whether this area should give any exp at all. Then you are free to roam your chosen home town, get the lay of the land, buy booze, talk on the tavern, whatever. Or even go adventuring if you're crazy enough. (There should be some kind of benefit for these characters -- maybe societies charge membership fees?) To do this well, we should add a few more towns. It has been exhaustively discussed to add an underground city for dragons somewhere (near the Hatchery would be appropriate), and maybe one for dwarves. There's at least one elven village that could be expanded for that purpose. One thing I'd like to see is a "wild" village somewhere, where we could put the current northman, barbarian and swashbuckler concepts. Acquiring a profession ====================== On each starting town there would be a number of buildings where you'd find professional guilds. This is maybe overloading the meaning of guilds we already have in the game, but it's closer to the traditional meaning. An alternative is not to call them guilds -- call them societies, or better, something more class-relevant, like "academies" for magic and "monasteries" for priests and paladins. (Even then, the thieves society is probably still "The Thieves Guild" in at least one town :-P) Here we can add some flavor. Some of those would admit only some species, some only natives. And they could/should be all different. For example, to become a "fighter" equivalent in Scorn, you join the Royal Order of Chivalry, where you get professional one-handed and two-handed weapons but no archery; in Navar, you'd instead join the Citizens Guard Corps, getting one-handed and archery. More obviously, each magical academy would only offer two skills, which if I remember my maths correctly, gives us 6 possibilities currently, up to 10 if we implement necromancy as suggested. Joining a society should have a cost, probably in money, although that would be a problem if it's the first thing you do in the game. How hard would it be to implement debt? It should also have some ongoing cost. One idea I like is: to actually enter the premises, you need to pay your fee, which then lets you in and out for some time (a week?) before you have to pay again. This value could be tied to level (overall level? Sum of relevant skills? Highest relevant skill?). I'd also like to make them more or less social, so it would be reasonable to have savebeds in them, and "lounge areas" like the Scorn dragon guild does. It would be interesting to add bulletin boards to them; even better, one inside (for members) and one outside. More importantly, your application to join should be rejected if you have "conflicting" skills. On the starting societies, these would be any skills at pro level at all. Oh, only tangentially related: I'd take that opportunity to "regionalize" the choices of gods. One possibility is that praying at an altar doesn't "convert" you, you need be "converted" on that god's society (although it shouldn't be required to be a member; probably a chapel on a separate entrance). So even though you could still have small "representative" temples of all gods in the major cities, you can't become a follower there. Learning new skills =================== New skills, at amateur level, should be IMO taught at a relevant society. The Royal Order of Chivalry can teach you amateur archery and smithery, and the Arcane Academy of Scorn has alchemy and one spell type it doesn't teach at pro. For a price, of course; probably very high. Advancing ========= Then at other places in the world, preferably far from the starting towns, you get other societies that teach you more. I'd even be happy to partially reuse existing maps. To get pro alchemy, you go to the Nurnberg Alchemy Society (existing map, but unfinished); to join, you're required to have amateur level alchemy, which is only learnable in magic academies, so fighters are barred. The Tower of Demonology could reasonably have a new section added, where someone who has amateur summoning can learn it up to pro. These further societies are still societies in all senses, including recurring costs if you want to go back there (and we should think up some perks to encourage that). In terms of RPG, they are similar to "prestige classes". Some current classes could be available only this way. The "warlock" could be replaced by one academy somewhere that teaches fighters to do amateur magic, and another elsewhere (Lake Country comes to mind) that teaches mages to fight. A similar logic goes for the "devotee". Ninjas could be an "improvement" over thieves. Maybe even paladins... Rationales and arguments ======================== This gives characters more "involvement" with their, er, "classes". It also, on a crowded server (which we hope to get if we make CF2 cool enough), facilitates characters meeting others of the same society and forming parties. Conversely, if you need one mage for you party of fighters, you know where to go; just stand in front of the Academy for a while. Or if you want to "hire" one, post on the Academy's bulletin board. It also opens the field to even zanier ideas and gaming styles. Merchants Guild anyone? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From crossfire at kahnert.de Wed Jul 4 03:25:11 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Wed, 4 Jul 2007 10:25:11 +0200 Subject: [crossfire] classes & guilds In-Reply-To: <468884B9.4000105@sonic.net> Message-ID: <20070704082511.GA18372@cthulhu.desy.de> On Sun, Jul 01, 2007 at 09:53:13PM -0700, Mark Wedel wrote: > I am not adverse to all races/classes starting with all skills (save > those intrinsic ones like Nicolas mentions), but with a fair number > being really poor versions. Sure, I don't want to see flying dwarfs doing flame touchs, either. ;-) > 1) skills operate the same, just harder to get levels in ones you are > not good at. This will end up with all characters having the same skill level, just takes longer to get some of them. > 2) Skills operate different. A person with the good version of > evocation at level 10 casts spells much more effectively than a person > with crappy evocation at level 10. I'd think that in this model, the > exp gain should be the same - that is to say that the crappy version > needs the same exp total as the good version to get to level 10. Could be made, it's a bit easier to implement. > The difference here is that it becomes harder with the bad version, > because the spells don't do as much damage, so you need more of them, > etc. I say that level gain should be the same, or close, as otherwise > you are really punishing those with poor versions of the skills Sure, it's intended to be a punishment. Stay with your class if you like the easy way. ;) > - not only is the skill not as effective, but you need more exp. You > can of course do that, but then at some point, it is almost what is > the point of offering such skills in the first place. Having the skill from the very first beginning just means, that they're able to gain xp in them. This offers the possibilty to eventually master them - after long and hard working on them. This doesn't mean that you have to train them, it's just the natural ability of an intelligent being to learn something new. ;) > Note also that in many cases, point #2 really looks like point #1. I don't think so. > so effectively this just means that the bad version of level 10 is the > same as the good version at level 3. So you don't really gain much in > this case, except for guilds that look at minimum level (but then the > question comes up, should they also take the version of the skill into > account? No, definitely just the level, because the "affinity value" of the level will become better through the guidance of the guild masters. The level is only checked to proof that you life the guild rules. > At some level, it almost seems that a bunch of complexity is being > added, and internal at some level, everything is getting adjusted > skill level, and using method #1 in that case is a lot easier. Method #1 won't give you the chance of fine tuning the classes. They will become the same sooner or later, but not with method #2. > The original point of redoing skills/classes was the general complaint > that at higher levels, all classes look alike, Not only higher levels. This equality is reached pretty fast. > becuase all classes/races have the same skills at high levels. From > some of the discussions here, I'm not sure if everyone actually thinks > that is an issue, It is an issue for sure. If the high level human warrior decides to learn magic and will even outclass the fireborn sorcerer, because the human warrior is also able to wear rings and amulets AND magical armour to become a much more powerfull mage then the fireborn, than the system is extremely unbalanced. What's the point of playing a magical creature like fireborn, if every barbarian is able to get the power up with items to the same value (30) of a fireborn? Out of the fireborn description: Their insubstantial nature makes them both very weak and very quick. Their minds are agile, and they are able to commune well with the gods. However, their area of excellence is magic. They spellcast more powerfully than any other race, and mana flows into them readily. They can even cast cold spells with devastating effectiveness. They all know a basic fire spell. I can't confirm that. Fireborns are probably the weakest mages of all. > and instead of fixing the classes/skills, the idea is to enforce/add > differentation by guilds and special perks. Both will do the job. > In that case, this could be the easiest: > > 3) There is no classes - every starts with same version of all the > skills, and what they become is based on what skills they use. A > person using magic would be in the mages guild, a person using melee > skills in the fighter, etc. So far it's fine. > This becomes a pure case of you are what you practice. Characters may > look the same at higher level, OTOH, if the guilds do offer special > benefits, maybe not. The guilds have to play a central role of the concept, or it ends up the same. > This doesn't require any code changes - the real change that would be > needed is some new way for characters to get starting equipment (as > that is one of the big differences between classes right now - mages > start with spellbooks, fighters with arms and armor). I don't think that this will change anything. I'll explain my idea (with the modifications out of the discussion) in detail in an extra mail. Hopyfully this will give the big picture. J?rgen From crossfire at kahnert.de Wed Jul 4 03:25:59 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Wed, 4 Jul 2007 10:25:59 +0200 Subject: [crossfire] classes & guilds In-Reply-To: <468884B9.4000105@sonic.net> Message-ID: <20070704082559.GB18372@cthulhu.desy.de> Race / Class / Skill / Guild 1) Races primary set the max stat value and adds some intrinsic skills like levitation, clawing, flame touch, ... Problem here is the maximum (magic improved) hard limit of stats to 30. Why should an elf or gnome be able to get the same con value as a dragon? Just remove this hard limit. The limit will be reached with body slots and item power. For example, the maximum natural con value for an elf would still be 18 and for a dragon 26. But with weared items giving a sum of +12 con the elf would reach 30 but the dragon a con value of 38. About the stat potion issue. It's easy to give a character with xp 0 a perfect body by drinking a lot of stat potions. This could be changed, if only one stat increases by reaching a new level. Which stat will be random as long as you didn't used a stat potion. If you've drunk a stat potion, the last quaffed stat potion will overwrite the random selection. An additional effect of the stat potion will be, that this stat will increase by 1 as long as you don't drink another one. Than the old effect vanishes and the new one will take effect. For example. str 16, con 15, now you drink a strength stat potion, you will get str 17. After that, you drink a constitution stat potion, your str will drop back to 16 and your con rises to 16. Another con stat potion will have no effect, your con stays at 16. Now you reach a new overall level and your con will be permanent set to 16. And the races needs more balance of the advantages / disadvantages. For example the fireborns are far to weak. Levitation isn't that useful and nothing special - everybody is able to levitate by spell or items if not already an intrinsic leviation is available. Flame touch does only fire damage, so no chance to break doors or walls or usable against fire immune creatures. The dragon clawing also do physical damage, too. That's much better. And besides that, everybody is able to use weapons doing fire damage and much more. Every body slot missing needs some real compensation. Being unable to use weapons is a real disadvantage, because all those weapon improvement - either selfmade, god given or just by the weapon - aren't available. What's the bonus for that for a fireborn? Other races may need some tuning, too. Removing 2 con and giving 2 cha isn't the same, so the "netto skill change" of 0 is somewhat misleading. Balancing the race attributes needs more discussion. 2) Classes don't have any distinctions at the moment. Just remove them as an attribute of the character and replace it by something like a title. "You are what you do" will be the new motto. Classes as a concept will still exists, but won't be a fixed attribute of the character - see guilds. 3) Skills needs bigger changes to work well with the "classes via guilds" system. The goal is to have real distinctions between high level character; not those uniform ones we have right now (everybody can do everything on the same level). For that we introduce different versions of skills (up to master degree). The pitfall is to create complexity without effect. If a master skill of level 10 is the same as novice on the same level, you end up again with everyone having everything on the same level. Or you deny classes to learn some skills which are not likely for the class. This will work good in party oriented game engines, but not so well with CF. That's why I prefer a more sophisticated skill system. This is based on the gained experience (xp) which defines the level of a skill; nothing new so far. And another skill "capability value" (I formerly called it "affinity value"). The capability value will be a range between 5 and 0.2 and is used as an divisor for the xp gain and also for the effect of the skill. Having a capability value below 1 means, you gain faster xp and makes more impact. The level of the skill is used for guild rule checking and still for all the other checks e.g. ability to learn a new spell. But I also think it would be a good idea to use it for item usage (weapons, rods, ...) instead of item power or in combination with it. This is a different topic, so I won't extend it here. The capability value can be improved after reaching a new overall level. The capability value of the five skills where the character gains most xp between two levels will become reduced by the following formula: Cn - new capability value Co - old capability value Cn = Co - Co * 0.04 Starting with the capability value of 5 you'll get this grades after x advances: capability grade advances ----------------------------------- 5.0 - 3.4 Unskilled 1 - 10 3.4 - 2.3 Novice 11 - 20 2.3 - 1.5 Apprentice 21 - 30 1.5 - 1.0 Amateur 31 - 40 1.0 - 0.65 Adept 41 - 50 0.65 - 0.44 Expert 51 - 60 0.44 - 0.29 Master 61 - 70 0.29 - 0.20 Grand Master 71 - 80 After 80 advances you reached the lowest possible value of 0.2. That's not the same with level 80 of that skill! For example, between level 4 and 5 (8000 xp needed) a player used skill A to get 500 xp of those 8000, skill B 1500, skill C 750, skill D 2000, skill E 250, skill F 1000 and skill G 2000. The five best skills (D, G, B, F and C) will be reduced by the formula above. The other two skills won't - not enough training to become better there (see guilds for exceptions). If the character just used a single skill to get those 8000 xp for the new level, only this skill will get one advance. The other four advances are lost. This system can be tuned by having more or less skills which will become better after level gain. Or by using percentages, like all skills above 5% of the xp gain for the new level will be improved. We also need to change the xp table because it's now much harder to gain levels than before (for low level characters). In combination with the guilds this will result into a clear distinction between members of different class guilds. 4) Guilds play a central role in this concept. After character generation, in the HallOfSelection, the player won't choose the class for the character, but the class guild to join. The difference is, you're able to leave a guild to join another one, to learn a new profession. Changing the guild is not as easy as it sounds. The character has to fulfill the guild rules. For example members of the warrior guild have to make sure that the fighting skills are much higher than all others. A warrior having a higher skill in magic than fighting won't be accepted or even become ostracized. Guilds will have a bunch of skills they teach. Without a teacher you never ever get a chance to advance over amateur grade of the skill (lowest capability value of 1.0). So you have to be member of the guild to reach the "adept" up to "grand master" grade. The choice of the profession will limit the capability but not the skill level. Think about the skill level as a measurment of how much time you spent for the skill. And the capability is how good you master it. The "guild skills" will advance every [overall] level as long as you got a few xp in them. If the top 5 skills (where the character got most xp between two levels) aren't guild skills, but there are also xp gains in guild skills, more than 5 skills will be advanced. That's because the guild masters are able to teach the skills and offers deeper knowlegde. If the character just uses one "guild skill", only this one skill will advance. Without using a skill / training no learn effect at all. This can't be abused, because if a fighter kills just one monster each with one handed weapons, two handed weapons, missile weapons and karate and gaining most xp with magic, than the fighter will become ostracized of the guild after a few levels, because the fighter no longer follows the guild rules. The guild rules for the warrior guild could look like this. The skills missile weapons, one handed weapons and two handed weapons has to be at least twice as high as magic skills. Also at least one of clawing, flame touch and / or karate (depending on the race) has to be twice as high as the magic skills. For example a warrior with karate 9 one handed weapons 12 two handed weapons 11 missile weapons 7 will be rejected to enter the guild and getting advantages over the guild if at least one of the magic skills evocation, praying, pyromancy, sorcery, summoning or use magic item is 4 or higher. Maybe we also add alchemy, inscription, literacy, sense curse, sense magic and probalby more or all other skills, to make a more clear distinction between the guilds. Needs to be balanced between all the possible class guilds. The guild will offer an "apartment" for the player. A uniq room for the character to place stuff. This room will also be extentable after solving some quests for the guild. For example teleporters to other regions, a magic box like in the extended scorn apartment, ... This extensions of the "apartment" (should be called a room if it's part the guild) are fixed to the guild the character solved the quests for. Don't make the rewards like teleporters moveable it the character changes the guild. Betraying the way of living of the guild should be a punishment. Enforce more role play gaming. Also good class items are also available through the guild. For example the pyromancer will be able to get meteor swarm once the level is high enough and the quest is solved for it. No other than the pyromancer as a member of the pyromancer guild will get access to this powerful spell. From crossfire at kahnert.de Wed Jul 4 08:16:11 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Wed, 4 Jul 2007 15:16:11 +0200 Subject: [crossfire] classes & guilds In-Reply-To: Message-ID: <20070704131611.GA19250@cthulhu.desy.de> On Wed, Jul 04, 2007 at 02:42:05AM +0000, Lalo Martins wrote: > I could even like it if examining a player reveals her "master" > skills -- which usually won't be more than a few anyway. Do you have an idea how it could looks like? Maybe by clicking on the character, extending the equipment list. > So pitching a self-taught amateur that took years to get to level 20 > against a professional who got to this level before "graduating", > should get an approximately even match. I don't think so. Having a master able to teach you the deepest knowledge (which was gained over generations) is something else than practicing by your own for years. > The comparison with an untalented black-belt vs. a talented one is IMO > not fair. A better way to think about it is comparing two fighters > who were given black belts by the same, rigorous master, in which case > they should have more or less the same skill. I can't confirm that. They won't have the same skill. In fact there can be huge differences between them, even with the same master teaching them at (and over) the same time. It's a matter of fact that there are different natural talents for skills. > Then again, maybe by "talented" you actually mean (in game terms) that > one has better Dexterity or Strength; this would obviously make a > difference and is unrelated to level. Nope, even with nearly same physical appearance, they will differ. > That said, I'd put a cap on levels. If we retain the current level > system (110/115), I'd cap amateurs at 40 and professionals at 90. > (Master is of course uncapped, or capped by the system's own limits, > currently 110). I don't think that this will change much. Check out the characters running around. Do you think they have much skills over 40? Fighters tend to stop training sorcery after reaching town portal. A level cap of 40 won't change that... > It would also be interesting to introduce "difficult" items; for > example, weapons that require pro level in their skills. I like that idea. But didn't you said level 20 should be level 20 no matter of the version of the skill? ;) I would simply check the level, not the grade of the skill. > Despite appearances, it's just not possible to fight with a longsword > or a battle axe if you've never been trained on it. That would mean you need a lot of skills. For every weapon type a new skill. And to stay fair, each spell needs to get an own skill level, too. I consider that as an overkill. Just check the level of e.g. one handed weapons and assume that they owner trained other weapons as well. > (You can self-train, but you'll probably hurt yourself a lot in > the process, and it would take ages.) That's what I try to introduce with capability values of the skills. It should take long and the best grade should be amateur. > Training to increase proficiency should take time. A way to > represent that could be: > > - The system only considers the proficiency for the "instance" > of the skill with highest level; so if you're amateur archer > 20 and pro archer 18, you're still amateur. I don't get that. How could you be level 20 and simultaneous level 18 of the same skill? > - But new experience goes entirely to the higher proficiency. > > - Upon acquiring a new version of the skill, it's initialized to > the exp corresponding to N levels below the current version, > where N might be hardcoded, or might be defined by the object > that gave you the skill (the mentor). For fighting skills I'd > say 2 to 5, for magic possibly more. You lost me on the first point. I can't follow your train of thoughts. > Character creation > ================== > > Get rid of classes entirely, moving that stage to in-game. Agreed. > During creation, you choose species and, let's say, nationality. The nationality aspect is nice. Maybe hard to combine with the idea of having regions of the same level niveau. > The combination of those defines your starting town and initial > skills. I would like to see regions for players of the same level. You either need much more of those regions (for every nationalty an own beginning region) or stay with mixed maps. But mixed maps lead newbies into death. Having a cave of goblins next to one with dragons won't urge newbies recommending this game to others... > I'd take that opportunity to "regionalize" the choices of gods. One > possibility is that praying at an altar doesn't "convert" you, you > need be "converted" on that god's society On the one hand you're saying, that you should be able to master every skill by your own to the same level as others with a teacher. On the other hand you deny that for the praying skill. I think that's inconsistent. > New skills, at amateur level, should be IMO taught at a relevant > society. How do you learn magic skills if you're a warrior? Or are you allowed to enter all societies? Or won't you ever get a chance to learn magic skills as a warrior? > It also, on a crowded server (which we hope to get if we make CF2 cool > enough), facilitates characters meeting others of the same society and > forming parties. Conversely, if you need one mage for you party of > fighters, you know where to go; just stand in front of the Academy for > a while. Wouldn't it be much easier to use "chat" instead of camping in front of a guild? ;) Besides that, I think CF needs much more party support to make this work well - if ever on a tiled 2D map. I don't see much parties going deeper at raffle2 after the trolls are dead. A CF party is just used to level up a character fast, nothing more. J?rgen From alex_sch at telus.net Wed Jul 4 09:01:12 2007 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 04 Jul 2007 08:01:12 -0600 Subject: [crossfire] Max State Cap (was: Re: classes & guilds) In-Reply-To: <20070704082559.GB18372@cthulhu.desy.de> References: <20070704082559.GB18372@cthulhu.desy.de> Message-ID: <468BA828.9070808@telus.net> Juergen Kahnert wrote: > Problem here is the maximum (magic improved) hard limit of stats to 30. > Why should an elf or gnome be able to get the same con value as a dragon? > Just remove this hard limit. The limit will be reached with body slots > and item power. > > For example, the maximum natural con value for an elf would still be 18 > and for a dragon 26. But with weared items giving a sum of +12 con the > elf would reach 30 but the dragon a con value of 38. One quick note about this, is that removing that hard limit isn't so simple as "just" removing it. There is an issue that a notable number of areas in the code do assume a max of 30 or give unreasonable bonuses if stats are over 30. I would agree the stat cap of 30 should be removed, but just noting, it would also require reworking most of the formulas that give bonuses based on stats. Alex Schultz From crossfire at kahnert.de Wed Jul 4 10:15:09 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Wed, 4 Jul 2007 17:15:09 +0200 Subject: [crossfire] Max State Cap (was: Re: classes & guilds) In-Reply-To: <468BA828.9070808@telus.net> Message-ID: <20070704151509.GB19250@cthulhu.desy.de> On Wed, Jul 04, 2007 at 08:01:12AM -0600, Alex Schultz wrote: > One quick note about this, is that removing that hard limit isn't so > simple as "just" removing it. I didn't looked into the code. I just wrote down what I think will improve gameplay. I wouldn't consider this hard limit as critical which needs to be fixed asap. Anyway, it can't be wrong to put some more priorities on gameplay instead of "what's easy to code". ;) J?rgen From alex_sch at telus.net Wed Jul 4 09:21:54 2007 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 04 Jul 2007 08:21:54 -0600 Subject: [crossfire] classes & guilds In-Reply-To: <20070704082511.GA18372@cthulhu.desy.de> References: <20070704082511.GA18372@cthulhu.desy.de> Message-ID: <468BAD02.6060409@telus.net> Juergen Kahnert wrote: >> 1) skills operate the same, just harder to get levels in ones you are >> not good at. >> > > This will end up with all characters having the same skill level, just > takes longer to get some of them. > >> 2) Skills operate different. A person with the good version of >> evocation at level 10 casts spells much more effectively than a person >> with crappy evocation at level 10. I'd think that in this model, the >> exp gain should be the same - that is to say that the crappy version >> needs the same exp total as the good version to get to level 10. >> > > Could be made, it's a bit easier to implement. Both of the above two points would work well in conjunction IMHO. >> The original point of redoing skills/classes was the general complaint >> that at higher levels, all classes look alike, >> > > Not only higher levels. This equality is reached pretty fast. > In my experience, this tends to occur between levels 30 to 50 normally, but sometimes a little earlier and sometimes a little later depending on the player's style and how those levels are gained. >> becuase all classes/races have the same skills at high levels. From >> some of the discussions here, I'm not sure if everyone actually thinks >> that is an issue, >> > > It is an issue for sure. If the high level human warrior decides to > learn magic and will even outclass the fireborn sorcerer, because the > human warrior is also able to wear rings and amulets AND magical armour > to become a much more powerfull mage then the fireborn, than the system > is extremely unbalanced. > Actually, it is an issue for sure, as at high levels indeed races and classes get good at things with too similar difficulty, however your example of this is quite flawed: Rings and amulets are often much more powerful for spellcasting than armour or swords. Thus the fact that fireborn can wear up to 4 rings and 2 amulets at a time far outweighs their lack of armour and swords so far as spellcasting is concerned. Of course, this advantage of Fireborns becomes smaller after hitting stat caps (30) because then the additional rings/amulets can only help by attunement or mana regeneration bonuses. > What's the point of playing a magical creature like fireborn, if every > barbarian is able to get the power up with items to the same value (30) > of a fireborn? Out of the fireborn description: > > Their insubstantial nature makes them both > very weak and very quick. Their minds are > agile, and they are able to commune well with > the gods. However, their area of excellence > is magic. They spellcast more powerfully than > any other race, and mana flows into them > readily. They can even cast cold spells with > devastating effectiveness. They all know a > basic fire spell. > > I can't confirm that. Fireborns are probably the weakest mages of all. > Well actually, though classes are indistinct often, Fireborn are not at all. Yes every barbarian could get 30 power as well, but in this particular case: the amount of items it would take to achieve that would be rather high. Also, Fireborn DO have a unique bonus besides stats: they do have an intrinsic mana regeneration bonus that is independent of stats, and while it well known it does help Fireborn notably. >> and instead of fixing the classes/skills, the idea is to enforce/add >> differentation by guilds and special perks. >> > > Both will do the job. > Agreed Alex Schultz From alex_sch at telus.net Wed Jul 4 09:48:43 2007 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 04 Jul 2007 08:48:43 -0600 Subject: [crossfire] Max State Cap (was: Re: classes & guilds) In-Reply-To: <20070704151509.GB19250@cthulhu.desy.de> References: <20070704151509.GB19250@cthulhu.desy.de> Message-ID: <468BB34B.4090404@telus.net> Juergen Kahnert wrote: > On Wed, Jul 04, 2007 at 08:01:12AM -0600, Alex Schultz wrote: > >> One quick note about this, is that removing that hard limit isn't so >> simple as "just" removing it. >> > > I didn't looked into the code. I just wrote down what I think will > improve gameplay. > > I wouldn't consider this hard limit as critical which needs to be fixed > asap. Anyway, it can't be wrong to put some more priorities on gameplay > instead of "what's easy to code". ;) Yep, just thought I'd make note of what else would be affected by it and would need tweaking as to make sure that won't be forgotten. I agree it would help gameplay, though not something with asap priority indeed :) Alex Schultz From lalo.martins at gmail.com Wed Jul 4 13:11:38 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Wed, 4 Jul 2007 18:11:38 +0000 (UTC) Subject: [crossfire] classes & guilds References: <20070704131611.GA19250@cthulhu.desy.de> Message-ID: Also spracht Juergen Kahnert (Wed, 04 Jul 2007 15:16:11 +0200): > On Wed, Jul 04, 2007 at 02:42:05AM +0000, Lalo Martins wrote: >> I could even like it if examining a player reveals her "master" skills >> -- which usually won't be more than a few anyway. > > Do you have an idea how it could looks like? Maybe by clicking on the > character, extending the equipment list. Yes, that's what I thought. >> So pitching a self-taught amateur that took years to get to level 20 >> against a professional who got to this level before "graduating", >> should get an approximately even match. > > I don't think so. Having a master able to teach you the deepest > knowledge (which was gained over generations) is something else than > practicing by your own for years. This is represented by the caps. "The deepest knowledge" is the highest levels. Also, you're missing a point. Read the preceding part again. "Crossfire levels are not a function of experience. They are just that: a measure of how effective a skill is due to experience." Levels are a measure of effectiveness; that's what they mean, at least in this game. So two people of level 20 have the same ability, because that's what level 20 means; if one of them had less, then he wouldn't have level 20. >> The comparison with an untalented black-belt vs. a talented one is IMO >> not fair. A better way to think about it is comparing two fighters who >> were given black belts by the same, rigorous master, in which case they >> should have more or less the same skill. > > I can't confirm that. They won't have the same skill. In fact there > can be huge differences between them, even with the same master teaching > them at (and over) the same time. Then I'm sorry, we seem to have a fundamental difference of philosophy wrt. the real life. I don't believe in that. Bear in mind, I'm not talking about two people training for the same time. I'm talking about two people being awarded the same degree by the same (rigorous) master. The person who's talented will get there faster. The not-very-talented will take a long time. The untalented will never get there. I've seen it happen myself many times on martial arts schools. >> That said, I'd put a cap on levels. If we retain the current level >> system (110/115), I'd cap amateurs at 40 and professionals at 90. >> (Master is of course uncapped, or capped by the system's own limits, >> currently 110). > > I don't think that this will change much. Check out the characters > running around. Do you think they have much skills over 40? Fighters > tend to stop training sorcery after reaching town portal. A level cap > of 40 won't change that... Er, do you really play on the servers? I routinely see people with skills of levels above 100, because that's the only way you can level up at that point. Besides, it still does make a huge difference for things like weapon skills. Finally, there has been talk of redistributing spell levels, and I'm taking for granted that this *will* be done for 2.0. The current spell levels are artifacts from when the highest level was, I don't remember exactly, 40 or 50. >> It would also be interesting to introduce "difficult" items; for >> example, weapons that require pro level in their skills. > > I like that idea. But didn't you said level 20 should be level 20 no > matter of the version of the skill? ;) > > I would simply check the level, not the grade of the skill. You got me there :-) But what I meant to represent here is that someone who had formal training is likely to have more breadth than the self- taught. The examples I use below -- longsword and battle axe -- are really though, and it's unlikely someone will ever bother to spend the time to learn them, if they have to actually live their lives as an active adventurer. Other weapons go beyond that into the barroque: I think someone would have to be really incredibly skilled already before they could self-teach a kusari, for example, without dying in the process. >> Despite appearances, it's just not possible to fight with a longsword >> or a battle axe if you've never been trained on it. > > That would mean you need a lot of skills. For every weapon type a new > skill. And to stay fair, each spell needs to get an own skill level, > too. > > I consider that as an overkill. Oh no, sorry, I'm not proposing different skills. I'm just saying, an untrained person will use the tools (weapons in this case) that are easier to grasp, while someone with formal training will have more breadth. >> Training to increase proficiency should take time. A way to represent >> that could be: >> >> - The system only considers the proficiency for the "instance" >> of the skill with highest level; so if you're amateur archer 20 and >> pro archer 18, you're still amateur. > > I don't get that. How could you be level 20 and simultaneous level 18 > of the same skill? From nicolas.weeger at laposte.net Wed Jul 4 17:26:59 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 5 Jul 2007 00:26:59 +0200 Subject: [crossfire] Players in transports Message-ID: <200707050027.02699.nicolas.weeger@laposte.net> Hello. Should the players in a transport appear in the 'maps' output? Should they count as players in the map the transport is in? Currently they don't, so there is an issue: potentially a map could be reset with a player in a transport on it. So either players in transport should count as players on a map, or the reset test should include players in transports :) I think both options are fun, btw: not counting players let them "hide" somewhere, counting ensures the count on the map is correct. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070705/d87c2212/attachment.pgp From mwedel at sonic.net Wed Jul 4 19:18:43 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 04 Jul 2007 17:18:43 -0700 Subject: [crossfire] Players in transports In-Reply-To: <200707050027.02699.nicolas.weeger@laposte.net> References: <200707050027.02699.nicolas.weeger@laposte.net> Message-ID: <468C38E3.6060609@sonic.net> Nicolas Weeger wrote: > Hello. > > Should the players in a transport appear in the 'maps' output? Should they > count as players in the map the transport is in? yes and yes. > > Currently they don't, so there is an issue: potentially a map could be reset > with a player in a transport on it. > > So either players in transport should count as players on a map, or the reset > test should include players in transports :) > > > I think both options are fun, btw: not counting players let them "hide" > somewhere, counting ensures the count on the map is correct. But that wasn't really the point of transports - it wasn't a mechanism for them to hide. But the output of the maps command is really an out of game command (if one were to think of the people living the the crossfire world, they don't really have any command like that, so normally would not know where people are). So what exactly it should and should not show could be a matter of debate. That said, someone riding a horse should hardly be hidden. Passengers on a ship, perhaps yes. OTOH, in the later case, what does 'who' say? If it just points them back at the map, then to some extent, they are not really hidden - it just depends on what command you use, and IMO, both commands should say the same thing. A more relevant question may be what to do about hidden wizes. Should they show up in the maps command? Probably not, but for consistency perhaps, the map->players count has to accurately reflect them (Swapping out a map with a wiz on it would be bad). From mwedel at sonic.net Wed Jul 4 19:27:13 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 04 Jul 2007 17:27:13 -0700 Subject: [crossfire] Max State Cap (was: Re: classes & guilds) In-Reply-To: <468BB34B.4090404@telus.net> References: <20070704151509.GB19250@cthulhu.desy.de> <468BB34B.4090404@telus.net> Message-ID: <468C3AE1.5000709@sonic.net> Alex Schultz wrote: > Juergen Kahnert wrote: >> On Wed, Jul 04, 2007 at 08:01:12AM -0600, Alex Schultz wrote: >> >>> One quick note about this, is that removing that hard limit isn't so >>> simple as "just" removing it. >>> >> I didn't looked into the code. I just wrote down what I think will >> improve gameplay. >> >> I wouldn't consider this hard limit as critical which needs to be fixed >> asap. Anyway, it can't be wrong to put some more priorities on gameplay >> instead of "what's easy to code". ;) > Yep, just thought I'd make note of what else would be affected by it and > would need tweaking as to make sure that won't be forgotten. I agree it > would help gameplay, though not something with asap priority indeed :) changing the cap isn't that hard. However, this has been done before - cap raised from 25 to 30, with a lot of the same discussions (too easy for any class to max out stats, etc). the basic problem is that unless the cap is really high (50+), it may not make much difference if better and better items show up. Perhaps related to that is a change that raised the max level - when that happened, then it made sense for those really high level quests to give out some good items that balanced with it, so you now got better items, and so getting that max stat became easier again. This can not be taken one piece at a time - the entire character life cycle needs to be examined, in particular: - Is there a max level in the game? If so, what should be it? - Is there a max stat value in the game? If so, what should it be? - What should be the highest stat adjustment any single item in the game should give out? Last question is somewhat important. IF the answer is say 5, then you probably at minimum need the stat cap at least 25 higher than max natural stats (get 4 rings of that and it is 20. Or 2 rings, sword, amulet, etc). From mwedel at sonic.net Wed Jul 4 20:09:26 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 04 Jul 2007 18:09:26 -0700 Subject: [crossfire] classes & guilds In-Reply-To: <20070704082511.GA18372@cthulhu.desy.de> References: <20070704082511.GA18372@cthulhu.desy.de> Message-ID: <468C44C6.8090906@sonic.net> Juergen Kahnert wrote: >> 1) skills operate the same, just harder to get levels in ones you are >> not good at. > > This will end up with all characters having the same skill level, just > takes longer to get some of them. But it would be easy enough to put in level caps for some skills. I know some people don't like level caps that are less than max stats. By in my mind, if you have different quality of skills, such that amateur, advanced, and master all can get to level 110, but amateur level 110 = master level 30, I'd maintain you are effectively doing level caps, your just implementing it in a different way. So maybe the question is more for those against level caps: Why? If the idea is you want to be able to get any skill up to equivalent proficieny as other classes (but maybe it takes 10 times as long, whatever), then pretty much all of the proposed systems don't allow that. >> so effectively this just means that the bad version of level 10 is the >> same as the good version at level 3. So you don't really gain much in >> this case, except for guilds that look at minimum level (but then the >> question comes up, should they also take the version of the skill into >> account? > > No, definitely just the level, because the "affinity value" of the level > will become better through the guidance of the guild masters. But IMO, you have to be very careful how well the affinity value can get adjusted. Otherwise, you get the same case of bunches of classes maybe looking the same. Maybe they get broken down into 3 or 4 major classes - fighter, mage, cleric, thief. But if all the fighters look the same at high level, is that OK? Maybe it is, but one complaint is that all characters look the same at high level. Having all the characters look the same out of 3 or 4 classes is some improvement, but is that what the goal is, or something different. From mwedel at sonic.net Wed Jul 4 20:29:55 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 04 Jul 2007 18:29:55 -0700 Subject: [crossfire] classes & guilds In-Reply-To: References: <4686EDDC.9060203@sonic.net> <20070701122736.GB869@cthulhu.desy.de> Message-ID: <468C4993.7000802@sonic.net> Just a note - I go into pretty much all discussions with some thought on the code involved. Maybe people don't think that is quite the right approach. But my thought is that the greatest designed system in the world is meaningless if it is too complicated to code in a timely fashion. Lalo Martins wrote: > > In defense of Mark's view of how it works (levels are effective > the same way, but need more exp), I'd like to say: Crossfire > levels are not a function of experience. They are just that: a > measure of how effective a skill is due to experience. So > pitching a self-taught amateur that took years to get to > level 20 against a professional who got to this level before > "graduating", should get an approximately even match. Fine by me. It sounds like from that description, amateurs gain exp more slowly than professionals, but if both are level 10 in the same skill, they are effectively equivalent? This sounds like one of the models I put out - in this case, the skill names just make it easier to know what skill version you have? > That said, I'd put a cap on levels. If we retain the current > level system (110/115), I'd cap amateurs at 40 and professionals > at 90. (Master is of course uncapped, or capped by the system's > own limits, currently 110). Also reasonable. Ideally, the caps could be set by skill, so for some skills, maybe amateur cap is 30, for others, amateur cap is 50. Either way, that isn't hard to do. > > It would also be interesting to introduce "difficult" items; for > example, weapons that require pro level in their skills. > Despite appearances, it's just not possible to fight with a > longsword or a battle axe if you've never been trained on it. > (You can self-train, but you'll probably hurt yourself a lot in > the process, and it would take ages.) It has been suggested that there be class or racial items (something only a dwarf can wear, or a ring only a mage can put on). But with all these discussions, class based items are a bit meaningless, so skill level items makes more sense. Question then is - do we care what version of the skill the person has? Eg, is it sorcery level 20 (amateur, professional, or master), or master sorcery level 20 only? That could make a big difference. > > Training to increase proficiency should take time. A way to > represent that could be: > > - The system only considers the proficiency for the "instance" > of the skill with highest level; so if you're amateur archer > 20 and pro archer 18, you're still amateur. > > - But new experience goes entirely to the higher proficiency. > > - Upon acquiring a new version of the skill, it's initialized to > the exp corresponding to N levels below the current version, > where N might be hardcoded, or might be defined by the object > that gave you the skill (the mentor). For fighting skills I'd > say 2 to 5, for magic possibly more. > > So the time required to train yourself into a pro is represented > by the experience required to "catch up" to you previous level. This gets a bit messier to code, as now you have multiple versions of effectively the same skill. If I do the skills command (or just the output in the client), does it now show two different archery skills? Making such a change is quite a bit more widespread in the code, since each skill is differentiated by a subtype number - things would have to get changed to resolve to basically different subtypes (3 subtypes for each skill). Experience also gets a little trickier. It'd be a lot easier to just convert (or add/remove) the amateur and replace it with the professional version. The problem of course is now you are lower skill level, so may not be able to cast some spells, weapon to hit could go down, hp go down, etc, which would seem odd. I wonder if instead, it could be recorded something like 'player was level 20 in this skill before it got updated', and things look at that for min casting level, etc. I'd have to think about if that is easier to do than multiple skills. > > Character creation > ================== > > Get rid of classes entirely, moving that stage to in-game. Interesting ideas, but my quick thoughts/notes: - Alex recently started another topic about redoing the intro/low level area. I thinking having 1 intro area is much better than 5-6 different intro areas. - While maybe not everyone would use it, I would guess some people would want an expedited creation method (I just want to player a fighter - I don't want to wander around a village for for 10 minutes talking to folks to get the skills I need) - I might put this as a part of phase 2 - I don't see that this is actually a requirement related to any of the changes above. It would seem to be a lot of work, and I'm not sure I'd put it at the same priority as redoing the skills/classes/races themselves. > Learning new skills > =================== > > New skills, at amateur level, should be IMO taught at a relevant > society. The Royal Order of Chivalry can teach you amateur > archery and smithery, and the Arcane Academy of Scorn has > alchemy and one spell type it doesn't teach at pro. For a > price, of course; probably very high. Or maybe even a quest (bring me a ....). But yes, that seems reasonable. You don't say so, but I take it that skillscrolls then disappear from the game? > > Advancing > ========= > > Then at other places in the world, preferably far from the > starting towns, you get other societies that teach you more. > I'd even be happy to partially reuse existing maps. To get pro > alchemy, you go to the Nurnberg Alchemy Society (existing map, > but unfinished); to join, you're required to have amateur level > alchemy, which is only learnable in magic academies, so fighters > are barred. The Tower of Demonology could reasonably have a new > section added, where someone who has amateur summoning can learn > it up to pro. > > These further societies are still societies in all senses, > including recurring costs if you want to go back there (and we > should think up some perks to encourage that). That all seems fine. From alex_sch at telus.net Wed Jul 4 21:19:16 2007 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 04 Jul 2007 20:19:16 -0600 Subject: [crossfire] Max State Cap (was: Re: classes & guilds) In-Reply-To: <468C3AE1.5000709@sonic.net> References: <20070704151509.GB19250@cthulhu.desy.de> <468BB34B.4090404@telus.net> <468C3AE1.5000709@sonic.net> Message-ID: <468C5524.7000108@telus.net> Mark Wedel wrote: > changing the cap isn't that hard. > > However, this has been done before - cap raised from 25 to 30, with a lot of > the same discussions (too easy for any class to max gmout stats, etc). > > the basic problem is that unless the cap is really high (50+), it may not make > much difference if better and better items show up. Perhaps related to that is > a change that raised the max level - when that happened, then it made sense for > those really high level quests to give out some good items that balanced with > it, so you now got better items, and so getting that max stat became easier again. > My thought on this issue with raising the cap, is that if better and better items show up, THAT is the problem. Given the current state of things, we could lower item bonuses and natural starting stats instead, however I believe that it would be easier to change or remove the caps AND be strict about not having too powerful items. > This can not be taken one piece at a time - the entire character life cycle > needs to be examined, in particular: > > - Is there a max level in the game? If so, what should be it? > - Is there a max stat value in the game? If so, what should it be? > - What should be the highest stat adjustment any single item in the game should > give out? > > Last question is somewhat important. IF the answer is say 5, then you > probably at minimum need the stat cap at least 25 higher than max natural stats > (get 4 rings of that and it is 20. Or 2 rings, sword, amulet, etc). What I'm pondering right now, is why should we need artificial caps on level or stats at all really? Why not instead just make the items and bonus calculations balanced with eachother? I think that caps are unnecessary if that is done right really. Alex Schultz From alex_sch at telus.net Wed Jul 4 23:18:17 2007 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 04 Jul 2007 22:18:17 -0600 Subject: [crossfire] Organizational Infrastructure (was: Re: Organizing efforts) In-Reply-To: <4689939F.7080403@telus.net> References: <46855F98.1090908@telus.net> <4686FA14.8020105@sonic.net> <46888B93.2060705@sonic.net> <468885D4.8090305@telus.net> <46897607.6020700@sonic.net> <4689939F.7080403@telus.net> Message-ID: <468C7109.5030802@telus.net> Hi, Well that the discussion on organizing efforts seems to have died down a bit I'll sum up that the consensus seems to be from what I have seen here: -The idea of organizing and focusing on a mini-project is good -Some kind of procedure for selecting mini-projects to focus on would be good -Projects should have a leader responsible for setting out the direction of it (and perhaps other duties for it) -The idea of some form of vote deciding which project seems good, so long as it avoids either players or developers drowning out the other's interests -Projects should have a leader and outline before being on the voting list, and if selected should have the leader create a detailed plan shortly afterwards So therefore, the main points that need to be decided are: -How exactly should the voting/decision process work? -What infrastructure should be used to coordinate the project after it has been selected? -What infrastructure should be used for the decision making process? On the first point, of how the voting process should work, well that's already been touched on a little bit, with one favorable option looking like taking a poll similar to what was done with the switch away from SVN, keeping track of both developer and player views and trying to select that which appeals to both sides. On the the infrastructure used to coordinate projects, I think that the usual of the wiki, IRC, and mailing list should serve the job fine. If different infrastructure should be used for a project for some reason or another that could be dealt with on a per-project basis, not a big deal at all. The third issue though, of what infrastructure should be used for deciding what project, is a tricker question I believe. It could be handled manually on the mailing list like with the version control vote, however there are two issues with that IMHO: 1) It isn't of sufficient accessibility to players and 2) it takes notable manual effort to set up each time (not a critical issue, but it would be nice to make future attempts at deciding a project as effortless as possible). I believe that due to both of those issues would be solved by a dedicated but simple web based interface for this, however perhaps that would be overkill or someone else has a better idea. So what infrastructure should we use to plan/decide? Alex Schultz From crossfire at kahnert.de Thu Jul 5 00:25:02 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Thu, 5 Jul 2007 07:25:02 +0200 Subject: [crossfire] classes & guilds In-Reply-To: <468C44C6.8090906@sonic.net> Message-ID: <20070705052502.GA14332@cthulhu.desy.de> On Wed, Jul 04, 2007 at 06:09:26PM -0700, Mark Wedel wrote: > But it would be easy enough to put in level caps for some skills. I bet it will. ;) > I know some people don't like level caps that are less than max stats. > By in my mind, if you have different quality of skills, such that > amateur, advanced, and master all can get to level 110, but amateur > level 110 = master level 30, I'd maintain you are effectively doing > level caps, your just implementing it in a different way. Basically, yes, I do the level cap on the grade - without a master earlier with one later. The result is technical similar, but not the same for the gameplay. > So maybe the question is more for those against level caps: Why? If you have a level cap of 30 in a skill, this becomes a boring skill once reached this limit. Splitting the skill into two values (xp and grade) without limiting xp, there is always something to do. Savvy? ;) People love to form their characters, and after reaching a limit it's all done. Nothing more to do. That's it. Boredom. Stagnancy. Having xp open end will change that. And maybe even after level 100 you're able to increase your grade by your own (without a master) will add another good feeling. It wouldn't make a big difference, because at this high levels you can't form much, but the feeling stays, there is no end. > But IMO, you have to be very careful how well the affinity value can > get adjusted. Otherwise, you get the same case of bunches of classes > maybe looking the same. Sure, but reducing the amount of classes to sharpen the remaining ones won't be bad. If you introduce new roles (classes), make sure that this new class is something new. Or make it a special subject of an existing class. For example we could make the mage guild with different schools inside. There are masters for pyromancy, for sorcery, ... Or for each of the schools a new guild and just say that this is a different area of expertise for mages. It's also possible to have similar guilds teaching up to different grades. A mage guild with a grand master in sorcery, but only expert in pyromance, a master in evocation, ... > Maybe they get broken down into 3 or 4 major classes - fighter, mage, > cleric, thief. But if all the fighters look the same at high level, > is that OK? There is no chance to avoid that; without disproportional lot of work. But if you have a system allowing you to define a class which will definitely differ from others, you still have the option to add new classes. We need to avoid to create 3 or 4 general classes not allowing us to add new ones without letting them look a bad choice compared with the older ones. As long as there is enough space for new classes which will add real benefits, we won't end up with 3 or 4 classes looking all the same. J?rgen From crossfire at kahnert.de Thu Jul 5 00:34:53 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Thu, 5 Jul 2007 07:34:53 +0200 Subject: [crossfire] Max State Cap (was: Re: classes & guilds) In-Reply-To: <468C3AE1.5000709@sonic.net> Message-ID: <20070705053453.GB14332@cthulhu.desy.de> On Wed, Jul 04, 2007 at 05:27:13PM -0700, Mark Wedel wrote: > changing the cap isn't that hard. > > However, this has been done before - cap raised from 25 to 30, with a > lot of the same discussions (too easy for any class to max out stats, > etc). > > the basic problem is that unless the cap is really high (50+), Why always the same value? Just make the cap for example +10 on the stat value. Or max +50% on it. Whatever. This way you keep the race modifiers without making all the same. For example an elf with con of 10 is allowed to increase it with a +50% cap up to 15. After reaching the maximum con for this race (18), the maximum will be +50% = 27 con. A dragon will achieve a maximum con of 26 * 1.5 = 39. Only for the humans there won't be any changes, because natural max 20 +50% will result into all 30. J?rgen From crossfire at kahnert.de Thu Jul 5 00:52:13 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Thu, 5 Jul 2007 07:52:13 +0200 Subject: [crossfire] unbalanced races (was: classes & guilds) In-Reply-To: <468BAD02.6060409@telus.net> Message-ID: <20070705055213.GC14332@cthulhu.desy.de> On Wed, Jul 04, 2007 at 08:21:54AM -0600, Alex Schultz wrote: > however your example of this is quite flawed: Rings and amulets are > often much more powerful for spellcasting than armour or swords. Often, but not always. Just to list some: - Wizard Hat - cloak of the Magi - Staff of the Magi - bracers of magical power > Thus the fact that fireborn can wear up to 4 rings and 2 amulets at a > time far outweighs their lack of armour and swords so far as > spellcasting is concerned. Yes, 4 rings and 2 amulets sound much. But in fact it's just 2 more rings and 1 more amulet. And this should compensate the lack of 8(!) body parts? Someone with feets just need to take on Idaten boots and is faster than a fireborn. Still leaving enough slots for other stuff... > Also, Fireborn DO have a unique bonus besides stats: they do have an > intrinsic mana regeneration bonus that is independent of stats, and > while it well known it does help Fireborn notably. Sure, this will compensate another slot, see above of the list with magical items. Nobody said that all races should have the same power. But a bit more balance could help. Especially if there are parts of the game some races can't participate like making their own weapons. J?rgen From crossfire at kahnert.de Thu Jul 5 01:18:30 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Thu, 5 Jul 2007 08:18:30 +0200 Subject: [crossfire] classes & guilds In-Reply-To: Message-ID: <20070705061830.GD14332@cthulhu.desy.de> On Wed, Jul 04, 2007 at 06:11:38PM +0000, Lalo Martins wrote: > Also spracht Juergen Kahnert (Wed, 04 Jul 2007 15:16:11 +0200): > >> The comparison with an untalented black-belt vs. a talented one is > >> IMO not fair. A better way to think about it is comparing two > >> fighters who were given black belts by the same, rigorous master, > >> in which case they should have more or less the same skill. > > > > I can't confirm that. They won't have the same skill. In fact > > there can be huge differences between them, even with the same > > master teaching them at (and over) the same time. > > Then I'm sorry, we seem to have a fundamental difference of philosophy > wrt. the real life. I don't believe in that. Maybe you don't see that with karate. Than look into education institutes. There are people learing all the same, writing the same exam, getting the same mark. But as soon as they encounter something new, they never saw / learnt before, some of them (with the natural talent) are able to combine the learnt stuff and solve the problems, the others not. I'd once a professor who said an exam is just another lesson to learn something. Lot of students complained about that it's far to hard, because they never learnt to solve such kind of problems. That was wrong. It just separated the wheat from the chaff... There was, there are and there will be always people doing better than others on the same [education] level. > Finally, there has been talk of redistributing spell levels, and I'm > taking for granted that this *will* be done for 2.0. The current > spell levels are artifacts from when the highest level was, I don't > remember exactly, 40 or 50. Yes, this needs to get fixed, too. > I'm just saying, an untrained person will use the tools (weapons in > this case) that are easier to grasp, while someone with formal > training will have more breadth. Agreed, I also think that a level on items would be a good thing. > > On the one hand you're saying, that you should be able to master > > every skill by your own to the same level as others with a teacher. > > On the other hand you deny that for the praying skill. I think > > that's inconsistent. > > Er, no, I never said that, where did I? In fact, you never said that, it just sounds like that. I can't see the special thing why changing the cult needs help from others... Just watch your steps if you're running around in valriel or gorokh before you pray. ;-P > Only by joining an "advanced" society as I described later, one that > only admits you if you are a warrior and then teaches you some magic > -- making you the equivalent of today's "warlock". And you end up with characters looking all the same, because they will make a tour through all the guilds to achieve all the skills... > > Besides that, I think CF needs much more party support to make this > > work well - if ever on a tiled 2D map. I don't see much parties > > going deeper at raffle2 after the trolls are dead. A CF party is > > just used to level up a character fast, nothing more. > > That is at least partially true, maybe completely. But I'm assuming > we'll address that for 2.0 as well. Even if we don't, it's worth > making it easier to party, if the cost isn't very high, because then > we're more encouraged to improve partying later, in 2.x :-) But how? I've no good ideas how to improve the party support on a tiled 2D map game that it will really work. Which doesn't mean that it can't be what I can't imagine. ;-) J?rgen From lalo.martins at gmail.com Thu Jul 5 01:41:47 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 5 Jul 2007 06:41:47 +0000 (UTC) Subject: [crossfire] classes & guilds References: <4686EDDC.9060203@sonic.net> <20070701122736.GB869@cthulhu.desy.de> <468C4993.7000802@sonic.net> Message-ID: Also spracht Mark Wedel (Wed, 04 Jul 2007 18:29:55 -0700): > Just a note - I go into pretty much all discussions with some thought on > the code involved. Maybe people don't think that is quite the right > approach. But my thought is that the greatest designed system in the > world is meaningless if it is too complicated to code in a timely > fashion. It's good to have different perspectives. I'm clearly going as a pen-and- paper author, shooting for both flavor and game balance. Juergen is coming from some other perspective which I won't try to guess. And since the code needs to get written eventually, of course it's useful to have a code perspective ;-) > Lalo Martins wrote: >> >> In defense of Mark's view of how it works (levels are effective the >> same way, but need more exp), I'd like to say: ... > > Fine by me. It sounds like from that description, amateurs gain exp > more > slowly than professionals, but if both are level 10 in the same skill, > they are effectively equivalent? This sounds like one of the models I > put out - in this case, the skill names just make it easier to know what > skill version you have? In fact it's exactly the model you put out. You'll notice the paragraph starts with "In defense of Mark's view" -- last I checked you're the only Mark here ;-) I'm not really proposing a new idea in this paragraph, rather, I'm exposing my understanding of the *current* meaning of levels in the Crossfire rule system. Which, IMO, supports your model. Sure, it could be changed; but I see no compelling reason to change, since the desired effects can be achieved with your model. >> That said, I'd put a cap on levels... > > Also reasonable. Ideally, the caps could be set by skill, so > for some skills, I think so, yeah. Maybe put the values on the actual archetypes. >> Training to increase proficiency should take time. A way to represent >> that could be: (...) > > This gets a bit messier to code, as now you have multiple versions of > effectively the same skill. If I do the skills command (or just the > output in the client), does it now show two different archery skills? Presumably just the "active" one. Yeah, messy :-( > It'd be a lot easier to just convert (or add/remove) the amateur and > replace it with the professional version. The problem of course is > now you are lower skill level, so may not be able to cast some spells, > weapon to hit could go down, hp go down, etc, which would seem odd. > > I wonder if instead, it could be recorded something like 'player was > level 20 in this skill before it got updated', and things look at > that for min casting level, etc. I'd have to think about if that is > easier to do than multiple skills. Hmm, I like this idea, from what I remember of the code. There is already some similar logic: dragons record the highest level they ever reached, for purposes of atunement "gifts". > > > Interesting ideas, but my quick thoughts/notes: > > - Alex recently started another topic about redoing the intro/low level > area. I thinking having 1 intro area is much better than 5-6 different > intro areas. Er, but I put the intro before the character goes to the "home town" :-) > - While maybe not everyone would use it, I would guess some people would > want an expedited creation method (I just want to player a fighter - I > don't want to wander around a village for for 10 minutes talking to > folks to get the skills I need) Well, this is the kind of thing I'm trying to get rid of :-P Then again, if you're an experienced player and you know exactly what you're doing, getting a "fighter" won't be much slower than it is now, except the distance walked will be a little longer. Ok, I want a human knight. Select Human... select attributes... select Scorn... skip intro... walk South to the Royal Order of Chivalry... ignore the NPC that could give instructions... ignore the magic mouth that says "step here to apply to the Royal Order of Chivalry"... step on the admission mat... there, ready to play. The process was at most twice as long, and it was more fun and enticing, IMHO. > - I might put this as a part of phase 2 - I don't see that this is > actually a requirement related to any of the changes above. It would > seem to be a lot of work, and I'm not sure I'd put it at the same > priority as redoing the skills/classes/races themselves. In fact, for me, this is the *point* of all the changes above :-) >> Learning new skills >> =================== >> >> New skills, at amateur level, should be IMO taught at a relevant >> society. The Royal Order of Chivalry can teach you amateur archery and >> smithery, and the Arcane Academy of Scorn has alchemy and one spell >> type it doesn't teach at pro. For a price, of course; probably very >> high. > > Or maybe even a quest (bring me a ....). But yes, that seems > reasonable. You don't say so, but I take it that skillscrolls > then disappear from the game? Yes. I meant "taught ONLY at a relevant society", but skipped the word. Of course you have a good point -- quests for skills would be cool too. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Thu Jul 5 01:55:14 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 5 Jul 2007 06:55:14 +0000 (UTC) Subject: [crossfire] classes & guilds References: <20070705061830.GD14332@cthulhu.desy.de> Message-ID: Also spracht Juergen Kahnert (Thu, 05 Jul 2007 08:18:30 +0200): > I can't see the > special thing why changing the cult needs help from others... In real life, I guess you can just decide you are Budhist or Shamanist, but you can't become Catholic, Muslim, Mormon, traditional Wiccan, or join most of the Christian branches, without special dispensation from a priest. Try "becoming" Jewish :-) >> Only by joining an "advanced" society as I described later, one that >> only admits you if you are a warrior and then teaches you some magic -- >> making you the equivalent of today's "warlock". > > And you end up with characters looking all the same, because they will > make a tour through all the guilds to achieve all the skills... That's a risk, yes. But I hope we can weave things to avoid it. The way I see it a warlock will always be a worse mage than a mage and a worse fighter than a fighter, and it's not hard to enforce that with skill limits. I'd say, for example: The society that teaches magic to fighters only teaches two magic types at amateur level. Even if there are more than one society -- and I envision only one -- it's impossible to join more than once. So if you're serious about it, you can raise one of those to pro by means of a specialized society, like the Tower of Demonology as used in my original post. But I'd put restrictions to keep you from raising both to pro, or raising even one of them to master. (Maybe to be master in a magic skill you need to have all four of them at at least amateur? This would of course be enforced by the maps, not the code.) And of course similar mechanisms to keep mages and priests and thieves from reaching pro in all of one-handed/two-handed/archery. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Thu Jul 5 01:59:53 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Thu, 5 Jul 2007 06:59:53 +0000 (UTC) Subject: [crossfire] classes & guilds References: <4686EDDC.9060203@sonic.net> <20070701122736.GB869@cthulhu.desy.de> <468C4993.7000802@sonic.net> Message-ID: Also spracht Lalo Martins (Thu, 05 Jul 2007 06:41:47 +0000): >> Sorry to reply to myself, but... I thought I should say, part of the motivation for this idea was code, too. It cuts the work of the new character creation UI by about 20 to 30% in my estimate. It basically keeps the class picking mechanics exactly like they are in CF 1.x: using player changers in-game. Then it would only require writing maps, and I'm much better at that than code. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From crossfire at kahnert.de Thu Jul 5 05:53:03 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Thu, 5 Jul 2007 12:53:03 +0200 Subject: [crossfire] classes & guilds In-Reply-To: Message-ID: <20070705105303.GA15133@cthulhu.desy.de> On Thu, Jul 05, 2007 at 06:41:47AM +0000, Lalo Martins wrote: > Also spracht Mark Wedel (Wed, 04 Jul 2007 18:29:55 -0700): > It's good to have different perspectives. Of course, it is. :) > I'm clearly going as a pen-and- paper author, shooting for both flavor > and game balance. That's the point. Crossfire is not a pen-and-paper RPG, it's a computer game. There is no need to simplify calculations, because they're made by the computer, not the player with the pen and paper... A level cap is fine for pen-and-paper based games, also class restrictions like mages are not allowed to wear heavy armour, ... But CF is computer based. There is no need to take care for easy pen and paper realisations. Use the computer instead of reimplementing pen-and-paper systems. > Juergen is coming from some other perspective which I won't try to guess. Just make a better [computer based] role playing game out of crossfire. That's why we should put new features up for discussion instead of quickly implemting easy ones. > And since the code needs to get written eventually, of course it's useful > to have a code perspective ;-) It shouldn't be hard to implement the capability values. It's maybe more time consuming to talk about it than to implement it. But it's important to talk about it instead of adding an unbalanced feature. > > - I might put this as a part of phase 2 - I don't see that this is > > actually a requirement related to any of the changes above. It would > > seem to be a lot of work, and I'm not sure I'd put it at the same > > priority as redoing the skills/classes/races themselves. > > In fact, for me, this is the *point* of all the changes above :-) Same for me. I would even go a step further than Lalo, and reorganize the world map to get regions for same level. And if this means we'll have only a beginner region which needs to be extended later on, fine, call it beta testing for CF2. If you ask me, everybody needs to start a new character (or more than one) for CF2. The more player are able to test the new beginning region, the better it will be. After we finished the next region, all characters could explore this one. And so on. As I said, beta testing for CF2. Yes, it doesn't only sound like lots of work, it is. If the result is an addictive game from the beginning, than it's worth doing the work. And than we may find some people who likes to make better graphics. ;) J?rgen From crossfire at kahnert.de Thu Jul 5 05:56:56 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Thu, 5 Jul 2007 12:56:56 +0200 Subject: [crossfire] classes & guilds In-Reply-To: Message-ID: <20070705105656.GB15133@cthulhu.desy.de> On Thu, Jul 05, 2007 at 06:59:53AM +0000, Lalo Martins wrote: > It basically keeps the class picking mechanics exactly like they are > in CF 1.x: using player changers in-game. Then it would only require > writing maps, and I'm much better at that than code. Agreed. From nicolas.weeger at laposte.net Thu Jul 5 15:09:12 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 5 Jul 2007 22:09:12 +0200 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <200706100016.32359.nicolas.weeger@laposte.net> References: <200706100016.32359.nicolas.weeger@laposte.net> Message-ID: <200707052209.15913.nicolas.weeger@laposte.net> Hello. Kind of resurrecting this thread, but well :) I was wondering what people would think of "centralizing" the documentation in the doxygen format. Not necessarily to make links to the code, but merely to have one big (server-side) reference documentation. The pros I see for this are: * only one format to handle, doxygen converting to html / latex / chm /... * only one generation process - run eg make doc in root, will generate all the documentation including handbook / plabook / spoilers * easy to point to technical documentation if needed (example: "armours are thus and thus - see this file for technical details) * easy to create dot schemas if wanted * can integrate archetype pics (possibly from arch, which is hopefully linked from /lib anyway for make collect) without too much duplication and the cons: * requires doxygen * no text-only output - doxygen apparently doesn't do that * probably other things I'm missing :) Opinions & suggestions welcome :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070705/92b2437e/attachment.pgp From mwedel at sonic.net Thu Jul 5 22:21:07 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 05 Jul 2007 20:21:07 -0700 Subject: [crossfire] Max State Cap (was: Re: classes & guilds) In-Reply-To: <468C5524.7000108@telus.net> References: <20070704151509.GB19250@cthulhu.desy.de> <468BB34B.4090404@telus.net> <468C3AE1.5000709@sonic.net> <468C5524.7000108@telus.net> Message-ID: <468DB523.3000101@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> changing the cap isn't that hard. >> >> However, this has been done before - cap raised from 25 to 30, with a lot of >> the same discussions (too easy for any class to max gmout stats, etc). >> >> the basic problem is that unless the cap is really high (50+), it may not make >> much difference if better and better items show up. Perhaps related to that is >> a change that raised the max level - when that happened, then it made sense for >> those really high level quests to give out some good items that balanced with >> it, so you now got better items, and so getting that max stat became easier again. >> > My thought on this issue with raising the cap, is that if better and > better items show up, THAT is the problem. Given the current state of > things, we could lower item bonuses and natural starting stats instead, > however I believe that it would be easier to change or remove the caps > AND be strict about not having too powerful items. Right. But you need to figure that out. If the cap is raised to say 40, that doesn't make much difference if there are +10 str items out there. So at that point, you have to say a +10 str item is out of balance. But it would be much better to have some idea what are reasonable max values, so that you have some idea what a maximum reasonable stat is. > >> This can not be taken one piece at a time - the entire character life cycle >> needs to be examined, in particular: >> >> - Is there a max level in the game? If so, what should be it? >> - Is there a max stat value in the game? If so, what should it be? >> - What should be the highest stat adjustment any single item in the game should >> give out? >> >> Last question is somewhat important. IF the answer is say 5, then you >> probably at minimum need the stat cap at least 25 higher than max natural stats >> (get 4 rings of that and it is 20. Or 2 rings, sword, amulet, etc). > What I'm pondering right now, is why should we need artificial caps on > level or stats at all really? Why not instead just make the > items and bonus calculations balanced with eachother? I think that caps > are unnecessary if that is done right really. Not sure I follow what you mean balanced with each other. Certainly, things could get changed so that there is no item cap and no stat cap (or at least effectively so - a 16 bit stat value is 32000, so for all purposes, would never be reached). And that is perhaps one solution. However, it changes the game a bit - right now, the stats tend to get increasing better bonuses as you go higher (the mana gain from 29 to 30 is more than 28 to 29). For there not to be stat limits, you'd have to make all the bonuses linear. Which to some extent is a good thing I think. Right now, if you're a spell caster, you really want to get that 30 power because of the mana it gives you, and if that means your strength is 24 and not 25, pretty easy tradeoff, as that 30 power is a lot more useful than a 25 strength. However, if the bonuses were linear, this becomes less clear cut - yes, you get more mana for that 30 power, but you also get some bonuses for a 25 strength. I would tend to think that players would still have a somewhat varied set of stat bonuses they use - they wouldn't pile it all into one or two stats, because the bonus from other stats becomes worthwhile - the con (hp) to survive, etc. From mwedel at sonic.net Thu Jul 5 22:36:28 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 05 Jul 2007 20:36:28 -0700 Subject: [crossfire] classes & guilds In-Reply-To: References: <4686EDDC.9060203@sonic.net> <20070701122736.GB869@cthulhu.desy.de> <468C4993.7000802@sonic.net> Message-ID: <468DB8BC.80309@sonic.net> Lalo Martins wrote: > Also spracht Lalo Martins (Thu, 05 Jul 2007 06:41:47 +0000): >>> > > Sorry to reply to myself, but... > > I thought I should say, part of the motivation for this idea was code, > too. It cuts the work of the new character creation UI by about 20 to > 30% in my estimate. It basically keeps the class picking mechanics > exactly like they are in CF 1.x: using player changers in-game. Then it > would only require writing maps, and I'm much better at that than code. Yeah - I can see that. One problem I have with the current in game method is some disconnected between choosing your stats, choosing your race, and then choosing your class (through whatever method). Because for lack of better term, there is no going back, I can certainly see situations where player makes the first two choices, and then realize that those were not good for the class they want to play. while doing a UI is a bit more complicated, it also lets the player see the effect of all options at once - pick the stats, pull the class from a list, see how that effects things, pull race from a list, be able to see spell points - re-arrange stats some, see how that changes mana, etc. In a sense, less gaming, especially for new players, on choosing correct stat/race/class combos. That said, combining the race & stat into nice selection would work fine - after all, the skills (and class) doesn't really affect things like hp, mana, grace, so one could still see what those values would be, even if they don't have the skills to use them yet. But if this was done, I'd also suggest, at least for a first pass, maybe concentrate and just one starting city - that is a lot easier, and while perhaps a little odd for all the guilds to be there, if it is the capital/biggest city, that would make sense. Also, if multiplayer play/partying is a goal, then I think starting characters in the same place is a good thing. It'd be pretty annoying for a couple friends to start playing, and then learn that because of selections, their two characters are in different cities, and who knows how to get to each other. And until there is such time that there are so many new players showing up on the servers, the other risk is spreading the new players apart in these different cities. You'd have better odds for partying if the 10 new characters are in the same town, vs 2 characters in one town, 3 in another, etc. There is the problem then that if/when things do get busy enough, you maybe have too many characters in one town. But I think we'd also need to have better idea on level gain rate, as well as players joining. As of right now, a level 5 person probably wouldn't want to adventure with a level 2 (or vice versa), and it doesn't take that long to get to level 5. Even if it is slowed down so that it takes several days of playing, for things to be useful, you'd probably need to have 5-10 new/active characters a day joining per each starting city on the map (and even that number may be load - I'm basing those numbers on that most servers have some time zone affinity, so you have busy times and less busy times on the server). From mwedel at sonic.net Thu Jul 5 22:54:54 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 05 Jul 2007 20:54:54 -0700 Subject: [crossfire] Organizational Infrastructure In-Reply-To: <468C7109.5030802@telus.net> References: <46855F98.1090908@telus.net> <4686FA14.8020105@sonic.net> <46888B93.2060705@sonic.net> <468885D4.8090305@telus.net> <46897607.6020700@sonic.net> <4689939F.7080403@telus.net> <468C7109.5030802@telus.net> Message-ID: <468DBD0E.2020001@sonic.net> Alex Schultz wrote: > Hi, > > Well that the discussion on organizing efforts seems to have died down a > bit I'll sum up that the consensus seems to be from what I have seen here: > -The idea of organizing and focusing on a mini-project is good > -Some kind of procedure for selecting mini-projects to focus on > would be good > -Projects should have a leader responsible for setting out the > direction of it (and perhaps other duties for it) > -The idea of some form of vote deciding which project seems good, so > long as it avoids either players or developers drowning out the other's > interests > -Projects should have a leader and outline before being on the > voting list, and if selected should have the leader create a detailed > plan shortly afterwards For the last point, I'd say that projects should ideally have a leader, and not make that a hard requirement - otherwise, to some extent, the developers can basically drive what projects are being worked on in any case, by only choosing to be leaders of projects they want - in a sense, the developers would pre-select the possible voting choices. But my thought is more that I could see some projects (or todo items at least) already have pretty good information - enough to vote on, but no one signed up to be a leader. > > So therefore, the main points that need to be decided are: > -How exactly should the voting/decision process work? Quick thoughts: - For each vote, 5 (or so) projects are voted on - The #2 vote getter for previous vote is always on the next ballot (and maybe #3 also). #1 should be done, so no need to vote on that again. - Remaining ballot entries decided by vote gatherer - based on discussions on mailing list, perceived importance/dependencies of project, etc. If the just completed project now opens up the way for other projects (clear dependency), those could go on the list. In terms of actual votes, I'd suggest the same type of method used for source code control - some form of ranked choice voting, so you don't get ties (in the case of a tie, or very close vote, perhaps the second item automatically becomes the next one to do, without a vote. For counting of actual votes, I'd do two counts - one of developers, one of non developers. Thus, you'd get a list of top choice for developers, and a list of top choice for non developers, and hopefully they correspond. I'd probably keep a fairly quick voting time (about a week) - that should be enough time for active people to vote - sure, someone could be on vacation, whatever, but it would seem a vote here and there isn't going to be the end of the world - its not like a lost vote is going to result in the mini project getting canceled - it just means it won't be done this month. > > The third issue though, of what infrastructure should be used for > deciding what project, is a tricker question I believe. It could be > handled manually on the mailing list like with the version control vote, > however there are two issues with that IMHO: 1) It isn't of sufficient > accessibility to players and 2) it takes notable manual effort to set up > each time (not a critical issue, but it would be nice to make future > attempts at deciding a project as effortless as possible). > I believe that due to both of those issues would be solved by a > dedicated but simple web based interface for this, however perhaps that > would be overkill or someone else has a better idea. So what > infrastructure should we use to plan/decide? Taking votes shouldn't be that hard - it wasn't for me. While mailing list may not be as accessible, the flip side is that perhaps even for player input, we care more about those players that are on the mailing list, and thus, for lack of better term, more serious players? A problem with a web based tool is that I think you may need some form of authentication - otherwise, with the vote totals I'd expect, I think it would be pretty easy for the vote to get manipulated - one person stuffing 5 votes into the tool might be a enough. And ideally, you don't want to have to do revotes because of suspicious results, etc - ideally, you want to decide that fairly quickly so work can start - if we spend a month voting, that doesn't really help anything. Now certainly, the vote for the next project could be started as the previous is finishing up. But I'm be reluctant to do it too early - the risk there is that if the current one is 50% done, and the vote is done for the next one, and it is really cool, you may end up loosing interest (or perhaps people even looking at what to do for the next one), so that the current one tends to languish. If you don't really know what the next one is, I think you may avoid that to some extent. From mwedel at sonic.net Thu Jul 5 23:01:48 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 05 Jul 2007 21:01:48 -0700 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <200707052209.15913.nicolas.weeger@laposte.net> References: <200706100016.32359.nicolas.weeger@laposte.net> <200707052209.15913.nicolas.weeger@laposte.net> Message-ID: <468DBEAC.8000607@sonic.net> Nicolas Weeger wrote: > Hello. > > Kind of resurrecting this thread, but well :) > > > I was wondering what people would think of "centralizing" the documentation in > the doxygen format. > Not necessarily to make links to the code, but merely to have one big > (server-side) reference documentation. Can you effectively do a handbook/spoiler doc with doxygen? It seems that doxygen is aimed really for extracting information from code to make guide data, less so for freestanding documents. > > The pros I see for this are: > * only one format to handle, doxygen converting to html / latex / chm /... > * only one generation process - run eg make doc in root, will generate all the > documentation including handbook / plabook / spoilers In theory, make doc is supposed to do that now. By default, it doesn't do the spoiler and playbook I think, because there is no good way for make doc to know if they changed (since a lot of data is based on archetypes, it is really if the archetypes change). > * easy to point to technical documentation if needed (example: "armours are > thus and thus - see this file for technical details) > * easy to create dot schemas if wanted > * can integrate archetype pics (possibly from arch, which is hopefully linked > from /lib anyway for make collect) without too much duplication One issue/complication you would run into, which currently exists for playbook and spoiler, is multipart images. There are scripts in the spoiler which know how to reassemble the small multipart pictures into the single large picture. The ideal fix for this is to make it so that there are no multipart images out there - everything is in big image format, since that is now supported. If that is done, then the extra code/complication of having to do multipart image handling is removed. > > and the cons: > * requires doxygen > * no text-only output - doxygen apparently doesn't do that > * probably other things I'm missing :) And maybe: To make changes, use would need to know doxygen formatting commands, which if you're a coder, is probably fine. But if you just want to write documents, html editors are pretty common (or lots more people probably know how to write in html) From kirschbaum at myrealbox.com Fri Jul 6 02:19:22 2007 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri, 6 Jul 2007 09:19:22 +0200 Subject: [crossfire] On the software side of "reorganizing the world" In-Reply-To: References: Message-ID: <20070706071922.GA422@kirschbaum.myrealbox.com> Lalo Martins wrote: > What I think we need is a "world editor". [...] > Ideally, I'd like an UI on at least the magicmap scale, maybe farther, > where I can lay mountains, rivers, forests, marshes, sea/land, and > preferably copy large chunks right out of an older map (say, Lone > Town) and paste into the world. Some of the features I plan to add to the editor: - Allow to shrink the map window. This affects only the map window but still allows all edit operations. I think this will help editing (untiled) maps that are (much) larger than the available screen space. - Add tiling support to map windows. That is, seamlessly display tiled map files in the map window. Though, don't expect these features to be implemented too soon since there are still a few unsolved issues. For example: loading all 900 world map files into the editor would need about 1.3GB RAM. This is way too much. OTOH, limiting the zoom feature to less then the whole world map seems not correct to me... > Also control elevation by hand, using an interface similar to map > editors in god games (eg, Sim City). For now, the editor mostly ignores elevation values. It tries to retain the elevation values when editing the map but I didn't add more support since I don't think elevation values are a sensible feature. (OK, I'll stop now because it's not the weather discussion...) > And define things like regions right there, too. If you think the editor needs improvements, feel free to add your ideas to https://sourceforge.net/tracker/?group_id=166996&atid=841185 I do not promise to implement all features, but not knowing about a feature, I cannot implement it. > If someone wants to pursue that, either as a separate tool or a mode > for the new editor, I'd be happy to contribute, although I don't know > where to start if I were to write it myself. Generally speaking, I think almost all tools for map editing should be included into the editor. This makes it much easier for users to use them (no need to install yet another application/library/whatever and the feature is easily accessible though menus). It also makes it easier to maintain them (for the same reason). Also, the editor's code base now has reached a state to allow adding new features without breaking too much existing features. Andreas From bear at mrbrklyn.com Wed Jul 4 13:27:37 2007 From: bear at mrbrklyn.com (Schmuel-Leib Eliezar Safir) Date: Wed, 04 Jul 2007 12:27:37 -0600 Subject: [crossfire] Ideas for guilds Message-ID: <1183573657.8326.1.camel@stat51.mrbrklyn.com> My idea is to create guilds for certain lvls. guild lvl 1 - 30 guild lvl 31 - 70 guild lvl 71 - 100 guild lvl 101 - 115 From kirschbaum at myrealbox.com Fri Jul 6 11:13:46 2007 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri, 6 Jul 2007 18:13:46 +0200 Subject: [crossfire] Bug [ 1735459 ] Ground view missing face updates In-Reply-To: <200706271922.17735.nicolas.weeger@laposte.net> References: <467F66B7.7080406@sonic.net> <200706271922.17735.nicolas.weeger@laposte.net> Message-ID: <20070706161346.GA18941@kirschbaum.myrealbox.com> Nicolas Weeger wrote: > > At some level, it is very easy to fix - if player is on a space, and > > anything (including face) on that space change, we just send all the > > contents of that space again to the player. > > Why all items? Don't items on a space get a tag, that can be used to > simply send this item's update to clients? I agree: the server should remember which items and attributes he has sent to the client. (Which IMO already have to be implemented in order to make the item/upditem/delitem/delinv commands work right.) Using this information, the server is able to issue correct upditem commands for changed ground objects. > > Now a simple answer could be we don't really care about bandwidth, > > and I can put in my fix. I'm not sure if that is really the right > > answer. > > If it is really that costly, I'd say no. I think wasting bandwidth is ok if any other solution would be way too complex to implement. But in this case I think such a "fix" would not be the correct answer. > The bug isn't important enough to warrant the fix. I somewhat disagree here: the bug is at least (slightly) confusing. For example, go into Beginners and follow the instructions of the first handle ("Type an A to open"). This applies the handle but the ground view does not change until you move off and on. > Yes, client should handle all animation it can. Would simplify the > server code, and save some bandwidth. I also agree here. > Also, one should consider the case where the modified face is not > visible because the map layer is full (can happen if many objects). Map layer does not apply here since it is the ground view. But still: the ground view holds only a maximum of 50 objects. But this case is implicitly handled by the previously suggested solution: the server would detect that the changed object has not been sent to the client. Therefore it would not send any updates to the client. Andreas From kirschbaum at myrealbox.com Fri Jul 6 11:37:29 2007 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri, 6 Jul 2007 18:37:29 +0200 Subject: [crossfire] safe/common item stack/inventory iteration? In-Reply-To: <4680911A.2050104@sonic.net> References: <467F4FFB.1000905@sonic.net> <4680911A.2050104@sonic.net> Message-ID: <20070706163729.GB18941@kirschbaum.myrealbox.com> Mark Wedel wrote: > The only really foolproof way would be to add some flag - something > like 'FLAG_NEEDS_TO_BE_DESTROYED'. Instead of the object actually > getting destroyed, that flag is set, and then there is some other > function later that goes through and cleans these objects up. > > However, that would add a lot of processing time. [...] > But because those calls are used everywhere, that cleanup routine > would have to examine _all_ of the objects - and lots of other code > would have to be modified to be aware of these pending objects (in the > for loops above, it would need to skip over these, etc). This "huge overhead" can be reduced to a (very small) constant overhead: add all objects that get marked with FLAG_NEEDS_TO_BE_DESTROYED to a list of objects_to_be_destroyed. After the processing is done (either after the loop, or the tick, or periodically after X ticks) actually delete all objects from objects_to_be_destroyed. At this time no other processing is active, therefore nothing will break. > In any case, what I was thinking about was more trying to make macros > so that when we find cases of that loop needing different/better > processing, it is just a matter of updating the macros, not of > updating 50 different for loops in the code. Generally speaking, I don't like such macros at all: I think they make the code much harder to read. This especially holds for new developers. Besides that, they might interfere with code formatters or editors with automatic indenting. Therefore I'd suggest to add a function (or function-like macro), say ob_is_valid(), which might be used as follows: | for (ob = container->inv; ob != NULL; ob = ob->next) { | if (!ob_is_valid(ob)) | continue; | | } The function ob_is_valid() just checks whether FLAG_NEEDS_TO_BE_DESTROYED is set. IMO this solution is easier to read than hiding the loop in a macro. Besides that, it is probably not more work to change the code this way than to replace loop with a macro. Note: you might want to add more such functions to check for "item" objects (when processing player's inventories), or to check for visible objects (when processing map tiles: skip (invisible) DMs, forces, etc.) Andreas From edler at heydernet.de Fri Jul 6 11:46:56 2007 From: edler at heydernet.de (Bernd Edler) Date: Fri, 6 Jul 2007 18:46:56 +0200 (CEST) Subject: [crossfire] Max State Cap (was: Re: classes & guilds) In-Reply-To: <468DB523.3000101@sonic.net> References: <20070704151509.GB19250@cthulhu.desy.de> <468BB34B.4090404@telus.net> <468C3AE1.5000709@sonic.net> <468C5524.7000108@telus.net> <468DB523.3000101@sonic.net> Message-ID: On Thu, 5 Jul 2007, Mark Wedel wrote: > ... For there not to be stat limits, > you'd have to make all the bonuses linear. > > Which to some extent is a good thing I think. Yes, linear boni would remove the somewhat "binary" stat behaviour, where you either have 30 or crap. If one uses max stats with exponentially increasing boni, (as cf does now) it is considered a big archievement to reach max stat level. (Thus the big bonus.) Then imo an average race (human) with perfect gear,should be able to max out 1 stat, maybe 2 at most, but never 3 or 4. A race with uneven stats might max 3 stats provided these 3 are the empowered ones. This is more difficult to keep in balance than open linear stats. Regardless of the stat-effect bonus system, I'd like to keep a balace of power between intrinsic and aquired stat boni. ( race max stat vs. items + spells ). A hobbit wearing all strenght improvement items possible in the game should still be weaker than a troll or quez without any. (both having maxed natural strenght of course.) From kirschbaum at myrealbox.com Fri Jul 6 11:46:41 2007 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri, 6 Jul 2007 18:46:41 +0200 Subject: [crossfire] Materials In-Reply-To: <200706100018.50240.nicolas.weeger@laposte.net> References: <200706091452.02194.nicolas.weeger@laposte.net> <200706100018.50240.nicolas.weeger@laposte.net> Message-ID: <20070706164641.GC18941@kirschbaum.myrealbox.com> Nicolas Weeger wrote: > Le samedi 09 juin 2007 23:49, Lalo Martins a ?crit?: > > what about... keep "materialname" and lib/materials, and kill the > > "material" field? > > Err, can't for now, Gridarta (which is hopefully the "official" editor > doesn't handle this materialname field :) This should be no argument if it is just that one field is missing: adding (or changing or removing) a field to/from Gridarta is a simple change. That is, if you decide on which way to go, I can update the editor in no time. Andreas From nicolas.weeger at laposte.net Sat Jul 7 12:22:27 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 7 Jul 2007 19:22:27 +0200 Subject: [crossfire] Code factorisation Message-ID: <200707071922.31147.nicolas.weeger@laposte.net> Hello. I just committed (to trunk) a massive esrv_send_item refactoring. From now on, remove_ob() and insert_ob_in_ob() will take care of sending item to client when needed. I removed many unecessary calls to esrv_send/delete_item, and changed some esrv_send_item to esrv_update_item since this is what it was about. This should reduce bandwidth, and make the code much easier to follow - no more checks for 'is this a player?'. I didn't test everything. There may be issues, missing updates, things like that. But globally it should be ok, and I hope people will report bugs they find :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070707/e4dae963/attachment.pgp From mwedel at sonic.net Sat Jul 7 18:46:26 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 07 Jul 2007 16:46:26 -0700 Subject: [crossfire] safe/common item stack/inventory iteration? In-Reply-To: <20070706163729.GB18941@kirschbaum.myrealbox.com> References: <467F4FFB.1000905@sonic.net> <4680911A.2050104@sonic.net> <20070706163729.GB18941@kirschbaum.myrealbox.com> Message-ID: <469025D2.2040602@sonic.net> Andreas Kirschbaum wrote: > Mark Wedel wrote: >> The only really foolproof way would be to add some flag - something >> like 'FLAG_NEEDS_TO_BE_DESTROYED'. Instead of the object actually >> getting destroyed, that flag is set, and then there is some other >> function later that goes through and cleans these objects up. >> >> However, that would add a lot of processing time. > [...] >> But because those calls are used everywhere, that cleanup routine >> would have to examine _all_ of the objects - and lots of other code >> would have to be modified to be aware of these pending objects (in the >> for loops above, it would need to skip over these, etc). > > This "huge overhead" can be reduced to a (very small) constant overhead: > add all objects that get marked with FLAG_NEEDS_TO_BE_DESTROYED to a > list of objects_to_be_destroyed. After the processing is done (either > after the loop, or the tick, or periodically after X ticks) actually > delete all objects from objects_to_be_destroyed. At this time no other > processing is active, therefore nothing will break. But to do that, yet another set of object pointers is needed (or perhaps use teh objectlink structure) - you can't use the next/above/below pointers, because if you mess with those, you now have a case where the pointers don't point to expected data, which is the entire problem we are running into. From mwedel at sonic.net Sat Jul 7 18:59:07 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 07 Jul 2007 16:59:07 -0700 Subject: [crossfire] Bug [ 1735459 ] Ground view missing face updates In-Reply-To: <20070706161346.GA18941@kirschbaum.myrealbox.com> References: <467F66B7.7080406@sonic.net> <200706271922.17735.nicolas.weeger@laposte.net> <20070706161346.GA18941@kirschbaum.myrealbox.com> Message-ID: <469028CB.2090705@sonic.net> Andreas Kirschbaum wrote: > Nicolas Weeger wrote: >>> At some level, it is very easy to fix - if player is on a space, and >>> anything (including face) on that space change, we just send all the >>> contents of that space again to the player. >> Why all items? Don't items on a space get a tag, that can be used to >> simply send this item's update to clients? > > I agree: the server should remember which items and attributes he has > sent to the client. (Which IMO already have to be implemented in order > to make the item/upditem/delitem/delinv commands work right.) Using this > information, the server is able to issue correct upditem commands for > changed ground objects. The server has no memory what it has sent to the client, save for the map. To remember what it has sent to the client would require that for each player, a complete copy of the spaces contents to be recorded as last sent. Instead, the server has some idea what is has sent to the client based on current state of events. The client knows that first 50 items of a stack will be sent to the client when a player moves to a space. And so it also knows that if something changes on those items, it can just update the relevant fields. However, the server has to know what has changed - you can't simply say 'object foo has changed - send client updates'. The code has to say 'nrof in foo has changed, so update nrof in client'. Note that in some/many cases, the server may send upditem/deltim commands to the client for objects it hasn't sent. That isn't terrible - the bandwidth of the item commands, unless you are on a large stack, usually won't be that costly. >> The bug isn't important enough to warrant the fix. > > I somewhat disagree here: the bug is at least (slightly) confusing. For > example, go into Beginners and follow the instructions of the first > handle ("Type an A to open"). This applies the handle but the ground > view does not change until you move off and on. Also for things like spikes and gates, it may be hard to see that they are still moving if your character is on top, but if properly updated in the look window, becomes very clear they are still going up and down. >> Also, one should consider the case where the modified face is not >> visible because the map layer is full (can happen if many objects). > > Map layer does not apply here since it is the ground view. But still: > the ground view holds only a maximum of 50 objects. Which, just as a note, was a limit put in purely for bandwith and socket limitation issues (current max size of a socket packet server supports is 64K, so can't go more than that. You also don't want to be sending too much data at once to client, as that also then causes lag (sending 64K of data over a 1.5 mbs link (fairly typical DSL speed) would take 400 ms. Given a standard game tick is 120 ms, fixing things so that larger amount of data can be sent at once may not be a good thing). Checking to see where the object is in the stack of 50 viewable objects of the client is a costlier issue. Other than walking the object list (following the below pointers), there isn't any easy way to know if the object is in the viewable list or not. I suspect that a lot of code, including Ryo's recent changes, presume that the objects in question will always be in that stack of 50. That is simple, and doesn't waste too much bandwidth. What I'd really like to do at some point is limit number of objects on a space to 50, so this is never an issue. But with spell effects, that would likely cause problems. From nicolas.weeger at laposte.net Sun Jul 8 05:04:40 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 8 Jul 2007 12:04:40 +0200 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <468DBEAC.8000607@sonic.net> References: <200706100016.32359.nicolas.weeger@laposte.net> <200707052209.15913.nicolas.weeger@laposte.net> <468DBEAC.8000607@sonic.net> Message-ID: <200707081204.43247.nicolas.weeger@laposte.net> > Can you effectively do a handbook/spoiler doc with doxygen? It seems > that doxygen is aimed really for extracting information from code to make > guide data, less so for freestanding documents. Obviously you can, since the doxygen site itself was (apparently) done through doxygen :) http://www.stack.nl/~dimitri/doxygen/ states that, at least. Also, if you look in trunk's doxygen generated doc, you'll see a page on timers (from the 'related pages'). Granted, the generated pages will have the same look as the code-related docs. But shouldn't be too hard if we want to extract this information (or even create a second doxygen.doc file) just for the playbook. Could even be processed twice, once as part of server doc, once part of player doc :) > In theory, make doc is supposed to do that now. By default, it doesn't > do the spoiler and playbook I think, because there is no good way for make > doc to know if they changed (since a lot of data is based on archetypes, it > is really if the archetypes change). Assuming we include the doc, doxygen will handle that for us. The idea would probably be to generate a doxygen-suitable file from archetypes and such. (I'd suggest to have files named .dox for playerbook and such). > One issue/complication you would run into, which currently exists for > playbook and spoiler, is multipart images. There are scripts in the > spoiler which know how to reassemble the small multipart pictures into the > single large picture. > > The ideal fix for this is to make it so that there are no multipart > images out there - everything is in big image format, since that is now > supported. If that is done, then the extra code/complication of having to > do multipart image handling is removed. *nod* We can fix that as needed. > And maybe: > To make changes, use would need to know doxygen formatting commands, > which if you're a coder, is probably fine. But if you just want to write > documents, html editors are pretty common (or lots more people probably > know how to write in html) AFAIK you can include HTML code directly in doxygen. So for player-related doc we could put that in a doxygen-enabled HTML format (probably adding a /** @file xxx header could be enough). And people could just submit as plain text, that'd work too. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070708/c5f1f2dd/attachment.pgp From nicolas.weeger at laposte.net Sun Jul 8 12:33:03 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 8 Jul 2007 19:33:03 +0200 Subject: [crossfire] safe/common item stack/inventory iteration? In-Reply-To: <467F4FFB.1000905@sonic.net> References: <467F4FFB.1000905@sonic.net> Message-ID: <200707081933.06383.nicolas.weeger@laposte.net> > Now this construct is used to cover the case where the current object > (tmp) goes away - we have a pointer to the next object. Such operations > are not that uncommon, as the {do some work} block is more likely to > destroy tmp. Actually, you can never be sure any object stays valid, short of restarting the loop :) Remove is an event a plugin can handle, thus such a plugin could change the whole object stack. As for the core of the mail, I guess it's ok to have some shortcut macros for common things, but IMO there are too many cases depending on the processing you're doing to be able to refactore usefully. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070708/106d0db1/attachment.pgp From nicolas.weeger at laposte.net Sun Jul 8 12:57:42 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 8 Jul 2007 19:57:42 +0200 Subject: [crossfire] class guild map (was: reorganizing the entire world) In-Reply-To: <20070629055020.GB11217@cthulhu.desy.de> References: <20070629055020.GB11217@cthulhu.desy.de> Message-ID: <200707081957.45017.nicolas.weeger@laposte.net> Replying to a top-level thread, because I didn't know where to put the stuff :) What about a "balancing" mechanism, for stats and skills? A player's skill would be defined by the relative exp (or whatever) of the considered skill. Example: I'm level 30, with level 25 sorcery, level 5 one handed weapon, and other non combat skills. My "effective" sorcery level would be 25 * 30 / ( 25 + 5) so 30, my effective one handed weapon level is 5 * 30 / ( 25 + 5 ) so 5. Now if I become level 10 one handed weapon, my level becomes 21 (that is 25 * 30 / ( 25 + 10 )) sorcery , and 8 (10 * 30 / 35) one handed weapon. If we keep the max 110 level cap, you can only effectively max one skill. If you gain exp in another (combat) skill, you "decrease" in this skill. Thus you effectively become what you play. The "reducing" could be seen as "you don't train enough, so you kind of lose some stuff". This could also be true for stats: if you have ~25 everywhere, you are kind of median. If you have 30 str and ~20 to other stats, you have a big str bonus. If you are 30 str and pow and ~20 elsewhere, you have a nice str/pow bonus, but less than 30 pow alone. The "raw" skills/stats values could of course still be used for requirements, or things like that. Just my 2 cents :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070708/6b7fc6a9/attachment.pgp From kirschbaum at myrealbox.com Sun Jul 8 17:25:38 2007 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Mon, 9 Jul 2007 00:25:38 +0200 Subject: [crossfire] safe/common item stack/inventory iteration? In-Reply-To: <469025D2.2040602@sonic.net> References: <467F4FFB.1000905@sonic.net> <4680911A.2050104@sonic.net> <20070706163729.GB18941@kirschbaum.myrealbox.com> <469025D2.2040602@sonic.net> Message-ID: <20070708222537.GA24320@kirschbaum.myrealbox.com> Mark Wedel wrote: > Andreas Kirschbaum wrote: > > [collect deleted objects and defer actual deletion] > > But to do that, yet another set of object pointers is needed (or > perhaps use teh objectlink structure) - you can't use the > next/above/below pointers, because if you mess with those, you now > have a case where the pointers don't point to expected data, which is > the entire problem we are running into. Sorry, I implicitly meant a new linked list. We probably need just a plain linked list but no double linked list. Therefore an objectlink list probably is the way to go since this does not increase the object size by adding a pointer which almost always is NULL. Andreas From kirschbaum at myrealbox.com Sun Jul 8 18:15:29 2007 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Mon, 9 Jul 2007 01:15:29 +0200 Subject: [crossfire] Bug [ 1735459 ] Ground view missing face updates In-Reply-To: <469028CB.2090705@sonic.net> References: <467F66B7.7080406@sonic.net> <200706271922.17735.nicolas.weeger@laposte.net> <20070706161346.GA18941@kirschbaum.myrealbox.com> <469028CB.2090705@sonic.net> Message-ID: <20070708231529.GB24320@kirschbaum.myrealbox.com> Mark Wedel wrote: > The server has no memory what it has sent to the client, save for > the map. To remember what it has sent to the client would require that > for each player, a complete copy of the spaces contents to be recorded > as last sent. I was not aware of this. But remembering the ground view attributes should not be that much a problem (given that we have an always allocated 64K buffer for output data). The inventory view may be a problem since there is currently basically no limit for the number of inventory objects. > Note that in some/many cases, the server may send upditem/deltim > commands to the client for objects it hasn't sent. That isn't terrible > - the bandwidth of the item commands, unless you are on a large stack, > usually won't be that costly. I think this is a behavior that should be "fixed" since it makes it impossible to detect actual bugs: Until now I did add checks to all the clients I wrote/fixed (a bot, jxclient, and possibly gtk client) to print a warning whenever such an impossible condition happens. If such "violations" are actually supposed to happen, at least the protocol specification should be updated so that it explicitly allows such inconsistencies. But allowing such inconsistencies, the client-side checks do not make sense and should removed. Which in turn means that we would not be able to detect actual bugs when incorrect upditem or delitem commands are sent. > Checking to see where the object is in the stack of 50 viewable > objects of the client is a costlier issue. Other than walking the > object list (following the below pointers), there isn't any easy way > to know if the object is in the viewable list or not. One could argue that more efficient data structures could be used. But that probably is not necessary: a) The server only walks the list of 50 objects if the object is a candidate to be updated; this should not be happen too often. b) The current solution is (if I did understand it correctly) to always send all objects. In this case, both checking the remembered list and sending all objects have linear complexity. But checking the remembered list should be much less expensive than resending all. Therefore the code would become more efficient despite the linear search. > I suspect that a lot of code, including Ryo's recent changes, > presume that the objects in question will always be in that stack of > 50. That is simple, and doesn't waste too much bandwidth. > > What I'd really like to do at some point is limit number of objects > on a space to 50, so this is never an issue. But with spell effects, > that would likely cause problems. And don't forget players exploiting this for example by dropping random loop near a generator to prevent it from spawning new monsters. Andreas From kirschbaum at myrealbox.com Sun Jul 8 18:22:44 2007 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Mon, 9 Jul 2007 01:22:44 +0200 Subject: [crossfire] safe/common item stack/inventory iteration? In-Reply-To: <20070708222537.GA24320@kirschbaum.myrealbox.com> References: <467F4FFB.1000905@sonic.net> <4680911A.2050104@sonic.net> <20070706163729.GB18941@kirschbaum.myrealbox.com> <469025D2.2040602@sonic.net> <20070708222537.GA24320@kirschbaum.myrealbox.com> Message-ID: <20070708232244.GC24320@kirschbaum.myrealbox.com> Andreas Kirschbaum wrote: > Mark Wedel wrote: > > Andreas Kirschbaum wrote: > > > [collect deleted objects and defer actual deletion] > > > > But to do that, yet another set of object pointers is needed (or > > perhaps use teh objectlink structure) - you can't use the > > next/above/below pointers, because if you mess with those, you now > > have a case where the pointers don't point to expected data, which is > > the entire problem we are running into. > > Sorry, I implicitly meant a new linked list. We probably need just a > plain linked list but no double linked list. Therefore an objectlink > list probably is the way to go since this does not increase the object > size by adding a pointer which almost always is NULL. After reading Nicolas' latest mail, I realize that this solution will not work: we now could handle deleted objects but not objects moved between lists. Of course, we could use the same idea when moving objects (defer the move and actually move them afterwards). But I'm not anymore sure if this would solve all possible issues... Andreas From mwedel at sonic.net Sun Jul 8 23:07:03 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 08 Jul 2007 21:07:03 -0700 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <200707081204.43247.nicolas.weeger@laposte.net> References: <200706100016.32359.nicolas.weeger@laposte.net> <200707052209.15913.nicolas.weeger@laposte.net> <468DBEAC.8000607@sonic.net> <200707081204.43247.nicolas.weeger@laposte.net> Message-ID: <4691B467.8@sonic.net> Nicolas Weeger wrote: >> In theory, make doc is supposed to do that now. By default, it doesn't >> do the spoiler and playbook I think, because there is no good way for make >> doc to know if they changed (since a lot of data is based on archetypes, it >> is really if the archetypes change). > > Assuming we include the doc, doxygen will handle that for us. > The idea would probably be to generate a doxygen-suitable file from archetypes > and such. > (I'd suggest to have files named .dox for playerbook and such). I think you may have mis understood me. The problem with dependencies, which could be done with currently spoiler and playbook, is often time you will get false positives (the archetypes file looks newer, but in fact has no changes). Since generate docs takes a fair amount of time (have to collect images and other data), it is generally not desirable to do it all the time. Which is why there is an implicit requirement that make doc is run. The other issue is that make documentation may require tools that most users don't have, and most servers probably don't care about doc. I'd almost argue that the docs should be pulled from the server area (except those specifically related to the server, like programming and protocol information) - if anything, it'd almost make more sense for them to be in the client. This was one reason periodic doc archives were built - expecting the bulk of players to download the server and archetypes and have all the tools just to get the docs was a bit excessive. > >> One issue/complication you would run into, which currently exists for >> playbook and spoiler, is multipart images. There are scripts in the >> spoiler which know how to reassemble the small multipart pictures into the >> single large picture. >> >> The ideal fix for this is to make it so that there are no multipart >> images out there - everything is in big image format, since that is now >> supported. If that is done, then the extra code/complication of having to >> do multipart image handling is removed. > > *nod* > We can fix that as needed. another issue was that the images got converted to gif format - this was certainly needed back in the days of bmp or xpm, when few browsers could read them. PNG is standard enough, that converting them to another format probably isn't needed. However, some form of collection is still needed - you don't really want your image paths to be ../../lib/arch/../../...png, so another thing the conversion process does is copy the images over. One reason is that the ideal case here is that I can copy everything in spoiler-html to some directory on my webserver, and point people at it and have it work. So you can not do relative paths here, as that makes copying that data much more a pain. > >> And maybe: >> To make changes, use would need to know doxygen formatting commands, >> which if you're a coder, is probably fine. But if you just want to write >> documents, html editors are pretty common (or lots more people probably >> know how to write in html) > > AFAIK you can include HTML code directly in doxygen. So for player-related doc > we could put that in a doxygen-enabled HTML format (probably adding a /** > @file xxx header could be enough). > And people could just submit as plain text, that'd work too. I guess it depends on what the goal is. If the goal is to remove the extraction scripts that extract data from source files, doxygen seems a fine replacement for that. However, I'm not sure that then means that the entire doc should be redone in doxygen - that seems way overkill, and actually seems counter productive - html is a lot more well known in doxygen, and I'd rather we stick with things that are more common for documentation that go to something relatively specialized (at least as far as knowledge is concerned). the spoiler already does server sides for the html files, so that seems like that would still work fine, and not require nearly as many changes. I suppose some of this is basically the question of whether the basic format should be doxygen that includes other files, or html that includes doxygen generated data. From mwedel at sonic.net Sun Jul 8 23:13:03 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 08 Jul 2007 21:13:03 -0700 Subject: [crossfire] safe/common item stack/inventory iteration? In-Reply-To: <200707081933.06383.nicolas.weeger@laposte.net> References: <467F4FFB.1000905@sonic.net> <200707081933.06383.nicolas.weeger@laposte.net> Message-ID: <4691B5CF.1090200@sonic.net> Nicolas Weeger wrote: >> Now this construct is used to cover the case where the current object >> (tmp) goes away - we have a pointer to the next object. Such operations >> are not that uncommon, as the {do some work} block is more likely to >> destroy tmp. > > Actually, you can never be sure any object stays valid, short of restarting > the loop :) > Remove is an event a plugin can handle, thus such a plugin could change the > whole object stack. > > > As for the core of the mail, I guess it's ok to have some shortcut macros for > common things, but IMO there are too many cases depending on the processing > you're doing to be able to refactore usefully. Yes - there are always cases where the code could do something that any macro can not handle. But I'd be willing to say that there are a fair number of 'for op->inv do above' type lists that being able to modify/fix behavior if we discover a general bug might be desirable. The problem is I don't see a really clean way to do it. It could be done with functions, something like: while (ob_stack(op->inv, current, next)) { use current object as expected } Might work. Problem is that if a change is needed that requires passing another parameter in, that now requires updating all those functions. OTOH, that may be easier, as grep or cscope makes finding all the instances easy - much more so than trying to find all the for loops. And if ob_stack (better name needed) is declared as an inline function in object.h or someplace, no performance hit. I don't think I'd want that to be a non inline function because of the performance hit that might result (like was_destroyed() was before doing performance analysis). From mwedel at sonic.net Sun Jul 8 23:32:12 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 08 Jul 2007 21:32:12 -0700 Subject: [crossfire] Bug [ 1735459 ] Ground view missing face updates In-Reply-To: <20070708231529.GB24320@kirschbaum.myrealbox.com> References: <467F66B7.7080406@sonic.net> <200706271922.17735.nicolas.weeger@laposte.net> <20070706161346.GA18941@kirschbaum.myrealbox.com> <469028CB.2090705@sonic.net> <20070708231529.GB24320@kirschbaum.myrealbox.com> Message-ID: <4691BA4C.4070103@sonic.net> Andreas Kirschbaum wrote: > Mark Wedel wrote: >> The server has no memory what it has sent to the client, save for >> the map. To remember what it has sent to the client would require that >> for each player, a complete copy of the spaces contents to be recorded >> as last sent. > > I was not aware of this. But remembering the ground view attributes > should not be that much a problem (given that we have an always > allocated 64K buffer for output data). The inventory view may be a > problem since there is currently basically no limit for the number of > inventory objects. It sort of depends on the design idea. Do we try to send updates by remembering all the state of everything we sent, or do we try to send updates based on changes we know about. It was an intentional design decision for many reasons not to hold state on the server for updates sent to the client. In many ways, holding state is actually more complicated - if you try to hold all state, this also means you try send add and remove objects based on this state. And if for some reason the stack of objects the player is on gets resorted, figuring out all the changes could be O(n^2) It would be much more complicated for the server to try and figure out object state based on stored output buffer - you'd basically need to come up with a new 'mini' object type that stores the attributes we send to the client, and thus compares the values. That in itself isn't really hard, but I think adds a layer of complexity that isn't really needed. > > >> Note that in some/many cases, the server may send upditem/deltim >> commands to the client for objects it hasn't sent. That isn't terrible >> - the bandwidth of the item commands, unless you are on a large stack, >> usually won't be that costly. > > I think this is a behavior that should be "fixed" since it makes it > impossible to detect actual bugs: > > Until now I did add checks to all the clients I wrote/fixed (a bot, > jxclient, and possibly gtk client) to print a warning whenever such an > impossible condition happens. If such "violations" are actually supposed > to happen, at least the protocol specification should be updated so that > it explicitly allows such inconsistencies. > > But allowing such inconsistencies, the client-side checks do not make > sense and should removed. Which in turn means that we would not be able > to detect actual bugs when incorrect upditem or delitem commands are > sent. I agree they should probably be fixed. But there may be some cases where it is really hard to deal with, but I can't think of any off the top of my head. > > >> Checking to see where the object is in the stack of 50 viewable >> objects of the client is a costlier issue. Other than walking the >> object list (following the below pointers), there isn't any easy way >> to know if the object is in the viewable list or not. > > One could argue that more efficient data structures could be used. But > that probably is not necessary: > > a) The server only walks the list of 50 objects if the object is a > candidate to be updated; this should not be happen too often. You might be surprised how many ways could result in an object needing to get updated to the client. So this may not be as rare as you might think. > > b) The current solution is (if I did understand it correctly) to always > send all objects. In this case, both checking the remembered list and > sending all objects have linear complexity. But checking the remembered > list should be much less expensive than resending all. Therefore the > code would become more efficient despite the linear search. Except there is no remembered list, so that would all have to be new code. I'd argue that right now at least, the number of cases with 50+ objects on a space is low enough that just not trying to handle it at all is the most efficient (but perhaps somewhat buggy). If this is seen as a major bug, probably the easiest and most efficient thing to do would be to just make up an array/hash that stores the object tags for those we have sent - then it is very quick to know if we have sent a specific object or not, and is also very quick to clear (don't need to walk a list, don't need to worry about freeing name pointers, etc). But I'd rather look at ways to deal with large stacks of object, as the click here to see more/prev method to me was always really just a hack. > > >> I suspect that a lot of code, including Ryo's recent changes, >> presume that the objects in question will always be in that stack of >> 50. That is simple, and doesn't waste too much bandwidth. >> >> What I'd really like to do at some point is limit number of objects >> on a space to 50, so this is never an issue. But with spell effects, >> that would likely cause problems. > > And don't forget players exploiting this for example by dropping random > loop near a generator to prevent it from spawning new monsters. I'd put the limit on pickable objects. Say we limit 30 pickable object per space. If more than that, they fall the neighboring spaces (which is somewhat realistic - see how much junk you can make in a pile before it falls down to a neighboring space). One could expect that on any given space, the number of non pickable non spell objects would be pretty low (5 maybe?). Now there could be more than 15 spell effects on a space, but the player can not interact with them - it can be nice to see in the look window what the effect is. But saying that a character can only discern the first 10 would make perfect sense (if you're being hit by 30 things at once, you probably wouldn't be able to figure out what all of them were). It might be even nicer to try and merge those spell effects in the client view in some way (5 slows, 3 fires, etc), but that adds yet more complication, and some limit of number to send would still be necessary, as there could always be more than the defined limit on a space. The only real issue here is what happens once spaces get to their limit of objects. I should be able to drop objects on a space an fill up an entire dungeon (supposing I had enough non mergable objects) - there has to be a limit to how far they would travel - like to a neighboring space. Now for players, one could do something like 'there is no space to put that object', but what about cases where there is a monster on a pile of stuff that dies? Its stuff should go someplace. Another alternative is maybe that the player can only see the first 35 items, and print a message like 'there is more stuff on this space you can't see'. After all, that is also somewhat realistic - if you have a huge pile of stuff, you probably can't see the stuff at the bottom - you'd need to dig through it to see it. > > > Andreas > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From crossfire at kahnert.de Mon Jul 9 00:38:23 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Mon, 9 Jul 2007 07:38:23 +0200 Subject: [crossfire] class guild map (was: reorganizing the entire world) In-Reply-To: <200707081957.45017.nicolas.weeger@laposte.net> Message-ID: <20070709053823.GA27776@cthulhu.desy.de> On Sun, Jul 08, 2007 at 07:57:42PM +0200, Nicolas Weeger wrote: > What about a "balancing" mechanism, for stats and skills? > > A player's skill would be defined by the relative exp (or whatever) of > the considered skill. > > Example: I'm level 30, with level 25 sorcery, level 5 one handed weapon, > and other non combat skills. My "effective" sorcery level would be 25 * > 30 / ( 25 + 5) so 30, my effective one handed weapon level is 5 * 30 / ( > 25 + 5 ) so 5. Now if I become level 10 one handed weapon, my level > becomes 21 (that is 25 * 30 / ( 25 + 10 )) sorcery , and 8 (10 * 30 / > 35) one handed weapon. > > If we keep the max 110 level cap, you can only effectively max one > skill. If you gain exp in another (combat) skill, you "decrease" in this > skill. Having a summoner who has charmed everything all the days for the entire life; being able to charm "eternal dragon" (level 110). Now this summoner charmed those eternal dragons, is surrounded by their corpses, and hitting "use_skill sense magic; use_skill woodsman". This lets this summoner jump up a few levels in those both skills preventing him to ever charm an eternal dragon again. Years of pratice vanished in a few seconds. Much more, never ever being able to reach this grade again. I don't like this implementation, which doesn't mean that I don't like the idea. It just has to be more balanced than this. > Thus you effectively become what you play. The "reducing" could be seen > as "you don't train enough, so you kind of lose some stuff". What about reducing the xp by 5% of each skill which wasn't used for a long time? To make it easy, the "long time" is defined as the time between two overall levels. Each skill you haven't used until you reach the next level will be decreased by 5%. Or make increasing steps, first level gain without using the skill will reduce this skill by 1%, a second level gain in series without using the skill will reduce it by 2%, ... > This could also be true for stats: if you have ~25 everywhere, you are > kind of median. If you have 30 str and ~20 to other stats, you have a > big str bonus. If you are 30 str and pow and ~20 elsewhere, you have a > nice str/pow bonus, but less than 30 pow alone. A smart lady won't become dump just because she's wearing a nice evening dress, using some make-up and had a hair-do. In your system her int value will drop because the cha value rised. I don't like that at all. If you like to decrease stats, than you need to link stats to skills. And each stat you haven't used will drop. A body builder who stops injecting anabolic steroids will drop in dex (lack of handling the injection). ;) No, stops training will make him drop in str. But I don't think that this is worth linking skills to stats to make the stats dropping. Maybe if you like to remove stat potions and let stats increase which were used more often. But this will result into having all characters with cha of 1; or how often do you use bargaining, singing and oratory in relation to your combat and magic skills? :o) They're heros helping weak people against dragons and other threats. Let them look nice. ;) Just reduce the speed of stat increases. A level 1 player shouldn't be able to max out all stats just because a high level character collected a few hundred stat potions and giving away a few of them... J?rgen From mwedel at sonic.net Mon Jul 9 01:40:08 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 08 Jul 2007 23:40:08 -0700 Subject: [crossfire] On the software side of "reorganizing the world" In-Reply-To: <20070706071922.GA422@kirschbaum.myrealbox.com> References: <20070706071922.GA422@kirschbaum.myrealbox.com> Message-ID: <4691D848.8040506@sonic.net> Andreas Kirschbaum wrote: > Lalo Martins wrote: >> What I think we need is a "world editor". > [...] >> Ideally, I'd like an UI on at least the magicmap scale, maybe farther, >> where I can lay mountains, rivers, forests, marshes, sea/land, and >> preferably copy large chunks right out of an older map (say, Lone >> Town) and paste into the world. > > Some of the features I plan to add to the editor: > > - Allow to shrink the map window. This affects only the map window but > still allows all edit operations. I think this will help editing > (untiled) maps that are (much) larger than the available screen space. I take it this is really more a zoom out vs actual shrink? Wonder if it would make sense to have a couple different zoom scales (25%, 50%)? This could be useful for even large non tiled map. > > - Add tiling support to map windows. That is, seamlessly display tiled > map files in the map window. > > Though, don't expect these features to be implemented too soon since > there are still a few unsolved issues. For example: loading all 900 > world map files into the editor would need about 1.3GB RAM. This is way > too much. OTOH, limiting the zoom feature to less then the whole world > map seems not correct to me... 1.3 GB isn't that much ram :) But I'd also think the load time for loading all 900 maps would be prohibitive. I wonder if you could have a preference of something like 'how many tiled maps' to load. So some people could say 'a 5x5 map tiled area is all I need', and others could say '10x10 would be great', type of thing. What would be really cool above that is basically scroll features that save/swap out maps and load up the new ones. For example, if I have a 5x5 layout, and say scroll east, it would free up the 5 maps along the left edge (ideally asking if I want to save changes if there are any, with perhaps a cancel), and if that is done, then loads up the 5 maps along the right edge. So one could effectively move throughout the tiled window with relative ease. > > >> Also control elevation by hand, using an interface similar to map >> editors in god games (eg, Sim City). > > For now, the editor mostly ignores elevation values. It tries to retain > the elevation values when editing the map but I didn't add more support > since I don't think elevation values are a sensible feature. (OK, I'll > stop now because it's not the weather discussion...) Dealing with elevation would seem to be a complicated issue no matter what - sure, it would be nice to fill in elevations as working, but to do that would be quite tricky - what are appropriate values, how to fill them in, etc. At some point, I'd like to modify line of sight to use elevation. Mountains right now always block view, which works OK. But if you're on the highest peak, they really shouldn't - in a sense, they should only block view if they are higher than the players current altitude. But this is one of those far off/low priority things. >> If someone wants to pursue that, either as a separate tool or a mode >> for the new editor, I'd be happy to contribute, although I don't know >> where to start if I were to write it myself. > > Generally speaking, I think almost all tools for map editing should be > included into the editor. This makes it much easier for users to use > them (no need to install yet another application/library/whatever and > the feature is easily accessible though menus). It also makes it easier > to maintain them (for the same reason). Agree with that. It is also nice not having to switch to a different tool because you want to do something that one tool doesn't do, and the other tool maybe doesn't do as well (an example being a world map editor vs normal one - chances are, the world one wouldn't be as complete (because if it was, no point for gridarta), and if it isn't, think chances are, you'd be constantly switching between the two. So it really does make sense to extend the standard tool to match the needs and not come up with new ones. From antonoussik at gmail.com Mon Jul 9 02:54:01 2007 From: antonoussik at gmail.com (Anton Oussik) Date: Mon, 9 Jul 2007 08:54:01 +0100 Subject: [crossfire] Project: New Intro In-Reply-To: <46888D93.90105@sonic.net> References: <46855F98.1090908@telus.net> <46888D93.90105@sonic.net> Message-ID: On 02/07/07, Mark Wedel wrote: > Alex Schultz wrote: > >I propose that we focus on what content the player sees first > > in the game because after all, it not only is the first part to leave an > > impression > First question on this: It has been suggested that the character creation get > completely redone, with spiffy interface, etc, instead of the the current 'in > game' method. > Does this proposal address this at all, or is this more based on what the > player does once the character is created, and leaves the creation aspect itself > still on a TBD list? As I understand it this is different, and spiffy character creation interface is still wanted. > Is this just an island for tutorial purposes (this is how you cast a spell, this > is how you search for a trap, etc), or is this more designed as a low level area? Making it a tutorial island would mean new players can enjoy the temporary safety while learning to walk. > In both cases, does one see a 'ship to mainland' type thing which is a one way > ticket off the island to scorn (or perhaps other towns? Maybe replace the nexus > with this town, and experienced players can hop right over to the ship to navar > city if they really want to). Ship(s) to mainland will work well :-) From nicolas.weeger at laposte.net Mon Jul 9 12:15:05 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 9 Jul 2007 19:15:05 +0200 Subject: [crossfire] Bug [ 1735459 ] Ground view missing face updates In-Reply-To: <20070708231529.GB24320@kirschbaum.myrealbox.com> References: <467F66B7.7080406@sonic.net> <469028CB.2090705@sonic.net> <20070708231529.GB24320@kirschbaum.myrealbox.com> Message-ID: <200707091915.08785.nicolas.weeger@laposte.net> > > Note that in some/many cases, the server may send upditem/deltim > > commands to the client for objects it hasn't sent. That isn't terrible > > - the bandwidth of the item commands, unless you are on a large stack, > > usually won't be that costly. > > I think this is a behavior that should be "fixed" since it makes it > impossible to detect actual bugs: This is hopefully fixed, in trunk, by my refactoring. Hopefully all items in inventory only get updated, no item should be sent twice, no item should be deleted twice. Of course that's the goal, I may have missed some things :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070709/2f016419/attachment.pgp From nicolas.weeger at laposte.net Mon Jul 9 13:03:34 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 9 Jul 2007 20:03:34 +0200 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <4691B467.8@sonic.net> References: <200706100016.32359.nicolas.weeger@laposte.net> <200707081204.43247.nicolas.weeger@laposte.net> <4691B467.8@sonic.net> Message-ID: <200707092003.37999.nicolas.weeger@laposte.net> > The problem with dependencies, which could be done with currently spoiler > and playbook, is often time you will get false positives (the archetypes > file looks newer, but in fact has no changes). > > Since generate docs takes a fair amount of time (have to collect images > and other data), it is generally not desirable to do it all the time. > Which is why there is an implicit requirement that make doc is run. So? Put the doc in doxygen format, and require a make archive (from server root) to generate it :) > The other issue is that make documentation may require tools that most > users don't have, and most servers probably don't care about doc. This is especially true for Windows users. Doc requires awk, Perl, egrep, tools you'd need to install (and find first). > I'd almost argue that the docs should be pulled from the server area > (except those specifically related to the server, like programming and > protocol information) - if anything, it'd almost make more sense for them > to be in the client. Except then you couldn't easily link to actual server archetypes / artifacts / ... I'd argue archetypes / artifacts / ... are server-dependant. Generated doc really has 2 things: Crossfire "core" things, and "server-related" things - archetypes being in this last category, since it's easy to change/add things. It could make sense to put player-related doc into the client, of course. But maybe we want to reduce the dependancy for client to the maximum? (or it could be in its own specific project to not depend on any client) > This was one reason periodic doc archives were built - expecting the bulk > of players to download the server and archetypes and have all the tools > just to get the docs was a bit excessive. *nods* Except right now it does require the archetypes anyway, and the server. So we're stuck :) (the doc relies heavily on eg crossfire -m4 to get information to process) > However, some form of collection is still needed - you don't really want > your image paths to be ../../lib/arch/../../...png, so another thing the > conversion process does is copy the images over. Yes, but that isn't an issue - doxygen would copy too if needed. > I guess it depends on what the goal is. > > If the goal is to remove the extraction scripts that extract data from > source files, doxygen seems a fine replacement for that. The goal is to have a nice documentation for players, in various formats :) > However, I'm not sure that then means that the entire doc should be > redone in doxygen - that seems way overkill, and actually seems counter > productive - html is a lot more well known in doxygen, and I'd rather we > stick with things that are more common for documentation that go to > something relatively specialized (at least as far as knowledge is > concerned). *shrug* How often do people contribute documentation? How many who are not developers (and thus can be assumed to know enough doxygen)? Just look at the various files, feeling like updating all header numbers by hand because you added a section? :) > the spoiler already does server sides for the html files, so that seems > like that would still work fine, and not require nearly as many changes. I > suppose some of this is basically the question of whether the basic format > should be doxygen that includes other files, or html that includes doxygen > generated data. My opinion is doxygen including html, since doxygen will handle other conversions for us (chm, pdf, ...) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070709/7c8dbf14/attachment.pgp From leaf at real-time.com Mon Jul 9 15:15:15 2007 From: leaf at real-time.com (Rick Tanner) Date: Mon, 09 Jul 2007 15:15:15 -0500 Subject: [crossfire] SourceForge changes to SVN Access Message-ID: <46929753.5050408@real-time.com> FYI Announcement from SourceForge ( 2007-07-09 10:43:54 - Project Subversion (SVN) Service ) As announced, support for the deprecated subversion access method (svn.sourceforge.net) was removed. Please use the PROJECT.svn.sourceforge.net access method that is described in our docs. As suggested on IRC, this command should take care of updating your local file paths: svn switch --relocate https://svn.sourceforge.net/svnroot/crossfire https://crossfire.svn.sourceforge.net/svnroot/crossfire (careful of line wrap..) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070709/281270f0/attachment.pgp From nicolas.weeger at laposte.net Mon Jul 9 15:34:28 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 9 Jul 2007 22:34:28 +0200 Subject: [crossfire] SourceForge changes to SVN Access In-Reply-To: <46929753.5050408@real-time.com> References: <46929753.5050408@real-time.com> Message-ID: <200707092234.31613.nicolas.weeger@laposte.net> > svn switch --relocate https://svn.sourceforge.net/svnroot/crossfire > https://crossfire.svn.sourceforge.net/svnroot/crossfire Note that this only works for "anonymous" checkouts. Developers using ssh authentication will want to use: svn switch --relocate https://@svn.sourceforge.net/svnroot/crossfire https://@crossfire.svn.sourceforge.net/svnroot/crossfire :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070709/3f97522c/attachment.pgp From alex_sch at telus.net Mon Jul 9 16:12:12 2007 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 09 Jul 2007 15:12:12 -0600 Subject: [crossfire] SourceForge changes to SVN Access In-Reply-To: <200707092234.31613.nicolas.weeger@laposte.net> References: <46929753.5050408@real-time.com> <200707092234.31613.nicolas.weeger@laposte.net> Message-ID: <4692A4AC.607@telus.net> Nicolas Weeger wrote: >> svn switch --relocate https://svn.sourceforge.net/svnroot/crossfire >> https://crossfire.svn.sourceforge.net/svnroot/crossfire >> > > Note that this only works for "anonymous" checkouts. Developers using ssh > authentication will want to use: > svn switch --relocate https://@svn.sourceforge.net/svnroot/crossfire > https://@crossfire.svn.sourceforge.net/svnroot/crossfire It also works if your sf login is auto-remembered by the svn client after manual entry instead of putting the username in the url ;) Alex Schultz From subs at eracc.com Mon Jul 9 19:11:59 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 9 Jul 2007 19:11:59 -0500 Subject: [crossfire] SourceForge changes to SVN Access In-Reply-To: <4692A4AC.607@telus.net> References: <46929753.5050408@real-time.com> <200707092234.31613.nicolas.weeger@laposte.net> <4692A4AC.607@telus.net> Message-ID: <200707091912.00072.subs@eracc.com> On Monday 09 July 2007 Alex Schultz wrote: > Nicolas Weeger wrote: > >> svn switch --relocate https://svn.sourceforge.net/svnroot/crossfire > >> https://crossfire.svn.sourceforge.net/svnroot/crossfire > > > > Note that this only works for "anonymous" checkouts. Developers using ssh > > authentication will want to use: > > svn switch --relocate https:// > login>@svn.sourceforge.net/svnroot/crossfire https:// > login>@crossfire.svn.sourceforge.net/svnroot/crossfire > > It also works if your sf login is auto-remembered by the svn client > after manual entry instead of putting the username in the url ;) > > Alex Schultz Good grief! I think I will just blow away my svn tree and download it all again (when I get to the point I can do some mapping again). What a PITA. :p Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From kbulgrien at worldnet.att.net Mon Jul 9 21:27:51 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 9 Jul 2007 21:27:51 -0500 Subject: [crossfire] SourceForge changes to SVN Access In-Reply-To: <200707091912.00072.subs@eracc.com> References: <46929753.5050408@real-time.com> <4692A4AC.607@telus.net> <200707091912.00072.subs@eracc.com> Message-ID: <200707092127.51948.kbulgrien@worldnet.att.net> > Good grief! I think I will just blow away my svn tree and download it all > again (when I get to the point I can do some mapping again). What a PITA. :p > > Gene Alexander Huh? It could hardly be more painless. $ cd /home/data/svn/crossfire $ for file in arch client server sounds maps > do > cd $file > svn switch --relocate https://svn.sourceforge.net/svnroot/crossfire https://crossfire.svn.sourceforge.net/svnroot/crossfire > cd .. > done And that was for a developer checkout. From mwedel at sonic.net Tue Jul 10 00:04:56 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 09 Jul 2007 22:04:56 -0700 Subject: [crossfire] SourceForge changes to SVN Access In-Reply-To: <200707092127.51948.kbulgrien@worldnet.att.net> References: <46929753.5050408@real-time.com> <4692A4AC.607@telus.net> <200707091912.00072.subs@eracc.com> <200707092127.51948.kbulgrien@worldnet.att.net> Message-ID: <46931378.7020607@sonic.net> Kevin R. Bulgrien wrote: >> Good grief! I think I will just blow away my svn tree and download it all >> again (when I get to the point I can do some mapping again). What a PITA. :p >> >> Gene Alexander > > Huh? It could hardly be more painless. > > $ cd /home/data/svn/crossfire > $ for file in arch client server sounds maps >> do >> cd $file >> svn switch --relocate https://svn.sourceforge.net/svnroot/crossfire https://crossfire.svn.sourceforge.net/svnroot/crossfire >> cd .. >> done > > And that was for a developer checkout. A lot of people may not need to do anything. Looking at my check out, I had already done that with the crossfire. Look at .svn/entries and see what the lines at the top say you are using for the repository. From mwedel at sonic.net Tue Jul 10 00:48:13 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 09 Jul 2007 22:48:13 -0700 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <200707092003.37999.nicolas.weeger@laposte.net> References: <200706100016.32359.nicolas.weeger@laposte.net> <200707081204.43247.nicolas.weeger@laposte.net> <4691B467.8@sonic.net> <200707092003.37999.nicolas.weeger@laposte.net> Message-ID: <46931D9D.9070405@sonic.net> Nicolas Weeger wrote: >> I'd almost argue that the docs should be pulled from the server area >> (except those specifically related to the server, like programming and >> protocol information) - if anything, it'd almost make more sense for them >> to be in the client. > > Except then you couldn't easily link to actual server archetypes / > artifacts / ... > I'd argue archetypes / artifacts / ... are server-dependant. Generated doc > really has 2 things: Crossfire "core" things, and "server-related" things - > archetypes being in this last category, since it's easy to change/add things. > > It could make sense to put player-related doc into the client, of course. But > maybe we want to reduce the dependancy for client to the maximum? > (or it could be in its own specific project to not depend on any client) Maybe. But as things are right now, some docs are perhaps rightly placed in the server (those documenting functions, or more server internals). But having the player docs be in the server makes little sense to make them available to players. Now some of that player documentation has a build process involved (like the spoiler or handbook), so having it be separate causes it's own set of problems. OTOH, still using makefiles for the documentation, and having to do a configure with parameters pointing to the server and archetypes to use may not be terrible (and if those are not set/configured, it doesn't build those pieces). OR maybe already have those pieces extracted, and update them as needed. For the handbook, this probably isn't that big a deal (it isn't extracting too much data, and even that it is could probably be simplified - don't necessarily need to show an icon of every building in the game, etc). But for the spoiler, while a lot of the data doesn't change much, there is actually little static content to that - most all of it is data that is pulled out. > > >> This was one reason periodic doc archives were built - expecting the bulk >> of players to download the server and archetypes and have all the tools >> just to get the docs was a bit excessive. > > *nods* > Except right now it does require the archetypes anyway, and the server. So > we're stuck :) > (the doc relies heavily on eg crossfire -m4 to get information to process) Some of the docs do, some don't. But the distributed doc archives included all the built data, so an end user would just untar it and didn't need to do anything more. > >> However, some form of collection is still needed - you don't really want >> your image paths to be ../../lib/arch/../../...png, so another thing the >> conversion process does is copy the images over. > > Yes, but that isn't an issue - doxygen would copy too if needed. but you still need to figure out what those files are that need to be copied - I suppose doxygen could do that, but we have current tools in place that do that. > >> I guess it depends on what the goal is. >> >> If the goal is to remove the extraction scripts that extract data from >> source files, doxygen seems a fine replacement for that. > > The goal is to have a nice documentation for players, in various formats :) If that is the goal, this is then a broader discussion - it is basically asking what should the standard document format be, as even for the static data, there are at least a few different formats floating about (smooth.tex, extmessage-types.html, and then most are just plain text). I'd almost suggest that perhaps the documentation in general should be redone. What is a sensible directory layout (SVN gives us good renaming ability, so moving stuff about shouldn't be a problem). What should the standard format(s) be? text + html? text + doxygen? text + something else? In general, text seems to work fine, but there are times when something that gives a bit more formatting ability is needed, even for developer information. So we should figure that out. >> However, I'm not sure that then means that the entire doc should be >> redone in doxygen - that seems way overkill, and actually seems counter >> productive - html is a lot more well known in doxygen, and I'd rather we >> stick with things that are more common for documentation that go to >> something relatively specialized (at least as far as knowledge is >> concerned). > > *shrug* > How often do people contribute documentation? How many who are not developers > (and thus can be assumed to know enough doxygen)? I don't think that is a good rationalization - I contribute documentation (just did yesterday in fact). And I certainly know how to do fairly advanced formatting in html. I don't know how do that with doxygen. As you mention, you can embed html in doxygen, but if that is done all the time, then really, is there much point to using doxygen then? And at that point, we really have 3 formats used for documentation - text, doxygen, html - if you're not proficient in one of them, you may find that you are unable to easily update some documentation. > Just look at the various files, feeling like updating all header numbers by > hand because you added a section? :) Probably not. But if it is in html, at least I'd know how to do so. With doxygen, have no idea. > >> the spoiler already does server sides for the html files, so that seems >> like that would still work fine, and not require nearly as many changes. I >> suppose some of this is basically the question of whether the basic format >> should be doxygen that includes other files, or html that includes doxygen >> generated data. > > My opinion is doxygen including html, since doxygen will handle other > conversions for us (chm, pdf, ...) See note above. We really should stick with only 1 other formatting language beyond plain text to keep things simple and easy to update. I vote HTML since it is incredibly standardized, plus there are a large number of WYSIWIG html editors. Are there any WYSIWIG doxygen tools out there? From subs at eracc.com Tue Jul 10 14:38:01 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Tue, 10 Jul 2007 14:38:01 -0500 Subject: [crossfire] SourceForge changes to SVN Access In-Reply-To: <200707092127.51948.kbulgrien@worldnet.att.net> References: <46929753.5050408@real-time.com> <200707091912.00072.subs@eracc.com> <200707092127.51948.kbulgrien@worldnet.att.net> Message-ID: <200707101438.03085.subs@eracc.com> On Monday 09 July 2007 Kevin R. Bulgrien wrote: > > Good grief! I think I will just blow away my svn tree and download it all > > again (when I get to the point I can do some mapping again). What a PITA. > > :p > > > > Gene Alexander > > Huh? It could hardly be more painless. > > $ cd /home/data/svn/crossfire > $ for file in arch client server sounds maps > > > do > > cd $file > > svn switch --relocate https://svn.sourceforge.net/svnroot/crossfire > > https://crossfire.svn.sourceforge.net/svnroot/crossfire cd .. > > done > > And that was for a developer checkout. I only checkout portions of each tree and I use my own subdirectory structure here because I do not care to get the entirety of each tree branch. Maybe I just don't understand but I don't wish to figure out how to do this for partial tree checkouts with a custom local directory structure. I'll just kill it and get it all again using the new checkout method. I don't have anything here that is not committed at this point anyway. Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From kbulgrien at worldnet.att.net Tue Jul 10 23:20:24 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 10 Jul 2007 23:20:24 -0500 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <46931D9D.9070405@sonic.net> References: <200706100016.32359.nicolas.weeger@laposte.net> <200707092003.37999.nicolas.weeger@laposte.net> <46931D9D.9070405@sonic.net> Message-ID: <200707102320.24671.kbulgrien@worldnet.att.net> > > My opinion is doxygen including html, since doxygen will handle other > > conversions for us (chm, pdf, ...) > > See note above. We really should stick with only 1 other formatting language > beyond plain text to keep things simple and easy to update. I vote HTML since > it is incredibly standardized, plus there are a large number of WYSIWIG html > editors. Are there any WYSIWIG doxygen tools out there? For whatever it is worth, HTML is ubiquitous, and so would get my vote. As Mark, I can almost do HTML in my sleep and have no clue about doxygen. Also, FWIW, the htmldoc tool is an excellent tool for generating pdfs from html even so far as to create a collapsible tree section index. Furthermore, chm is simply a "compiled" package of html files... so HTML is absolutely a natural for sources to create a .chm. Next time you're in Windows help, poke around... there's an option to view the document URL of the topic you are looking at. Stick that URL in a browser, and you can read the .chm. (Caveat, recent security updates may have turned off opening chm in a browser by default, but I just did it yesterday at work.) In fact, simply by constructing the URL right, you can even open the .chm to a specific topic... the topic page URL file showing up as, you guessed it, an .htm file. Kevin Bulgrien From nicolas.weeger at laposte.net Sun Jul 15 05:59:15 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 15 Jul 2007 12:59:15 +0200 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <46931D9D.9070405@sonic.net> References: <200706100016.32359.nicolas.weeger@laposte.net> <200707092003.37999.nicolas.weeger@laposte.net> <46931D9D.9070405@sonic.net> Message-ID: <200707151259.15636.nicolas.weeger@laposte.net> Well, my opinion is that server / code / developer documentation should be in doxygen format, part of the sources and integrated in the doxygen-generated docs. It would be much easier to bundle everything together this way. As for handbook / playbook / spoilers, I don't really mind one way or the other :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Sun Jul 15 23:00:23 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 15 Jul 2007 21:00:23 -0700 Subject: [crossfire] Documentation revamp, was spoiler generation In-Reply-To: <200707151259.15636.nicolas.weeger@laposte.net> References: <200706100016.32359.nicolas.weeger@laposte.net> <200707092003.37999.nicolas.weeger@laposte.net> <46931D9D.9070405@sonic.net> <200707151259.15636.nicolas.weeger@laposte.net> Message-ID: <469AED57.7010503@sonic.net> Nicolas Weeger wrote: > Well, my opinion is that server / code / developer documentation should be in > doxygen format, part of the sources and integrated in the doxygen-generated > docs. > > It would be much easier to bundle everything together this way. Can you give some better examples of that? I will admit that the current layout of documentation (or maybe more specifically, the doc dir) isn't great. To find out if something is documented, one basically has to resort to grep, as what file something is documented in isn't really the most consistent. Documentation right now is basically ad hoc - as something new is added, often a new file is added. I'm not sure what the doc structure should look like, but it definitely needs to get cleaned up. One complication is that there are potentially 3 different audiences for any documentation: players, mapmakers, and coders (one could perhaps even add a fourth - script writers). Why I think this gets complicated is there is a question on how to organize it. For example, lets take some object that does something interesting but non trivial, so that you need directions for it use. For players, you'd describe how to use that item For map makers, you'd have to describe the different fields the item uses, and how it affects the object For coders, you may want to describe the internals of how the object operates, so that some other coder needs to modify the code, they have some better idea of how some tricky code may work. Now one method is to basically split that information into 3 different places - the player information may be in the help files or the client. The map maker information may be in the editor, and the developer information may be in the code itself. The problem is that makes it pretty hard to find the relevant documentation. The other way is that all of this is in one file/place. In that way, if the coder extends the code, he knows all the places he needs to update the documentation. It is also useful, as the map maker sees a description of how an item is used, and the coder sees what the fields do and how it is supposed to work. Now if doxygen can be used to somehow separate these pieces out, that would make me more willing to look at it. For example, something like **start_help_... help documentation **end_help **start_editor_... information for the editor **end_editor (rest of this is just coder information, so doesn't really need to be pulled out) And also if doxygen can pull out the ** stuff and leave the documentation, that might be nice. I'd still say that even in that case, doxygen should be used more as a documentation building tool and not a formatting tool. In fact, for the vast majority of documentation, I really like plain text - I can always view it easily, update it easily, etc. I'd think that for most of the documentation, there is actually little need for formatting in most cases. From mwedel at sonic.net Mon Jul 16 01:35:54 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 15 Jul 2007 23:35:54 -0700 Subject: [crossfire] good http library for new metaserver? Message-ID: <469B11CA.5000503@sonic.net> I'm looking/thinking about the new metaserver information, as described at: http://wiki.metalforge.net/doku.php/dev_todo:metaserver_improvements As mentioned in that page, using URL/HTTP for the metaserver would seem to be the most scalable. But we need to decide on a library to use for that. I found neon installed on my linux system - must have been installed a dependency for something - that sort of suggests that it may be on a fair number of systems. There is also libwww. I'm sure there are others. So this is really just a question to see what is out there. I'd also suggest this handling if the library is missing: For the server, this is OK, unless the user has turned on the metaserver notification setting. If that is set, then program terminates with error - either install the library, or turn of metaserver notification. For client, maybe shouldn't be a fatal error? Or maybe it is a fatal error unless something is passed into configure (configure --no-metaserver or something) - it would seem that for most people, this is pretty core functionality, but there could be some that don't need it (own server, inside company firewalls, whatever) From nicolas.weeger at laposte.net Mon Jul 16 16:33:51 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 16 Jul 2007 23:33:51 +0200 Subject: [crossfire] Documentation revamp, was spoiler generation In-Reply-To: <469AED57.7010503@sonic.net> References: <200706100016.32359.nicolas.weeger@laposte.net> <200707151259.15636.nicolas.weeger@laposte.net> <469AED57.7010503@sonic.net> Message-ID: <200707162333.54793.nicolas.weeger@laposte.net> > Can you give some better examples of that? Well, I'd say the documentation doxygen generated in the html directory could nicely be bundled. As a test I added a page for "timers", accessible from the "related pages" tab, or from the "timer.c" file page. > I will admit that the current layout of documentation (or maybe more > specifically, the doc dir) isn't great. To find out if something is > documented, one basically has to resort to grep, as what file something is > documented in isn't really the most consistent. Which is why it makes sense to put all (code-related) documentation in an organized way. > I'm not sure what the doc structure should look like, but it definitely > needs to get cleaned up. One complication is that there are potentially 3 > different audiences for any documentation: players, mapmakers, and coders > (one could perhaps even add a fourth - script writers). Yes. Which is why it's easier to be able to see all files, and organize all in a coherent way - main page, 3 sections, one for each profile :) > Now one method is to basically split that information into 3 different > places - the player information may be in the help files or the client. > The map maker information may be in the editor, and the developer > information may be in the code itself. The problem is that makes it pretty > hard to find the relevant documentation. Organisation :) > Now if doxygen can be used to somehow separate these pieces out, that > would make me more willing to look at it. For example, something like > > **start_help_... > help documentation > **end_help > **start_editor_... > information for the editor > **end_editor > (rest of this is just coder information, so doesn't really need to be > pulled out) doxygen apparently does that nicely. Check http://www.stack.nl/~dimitri/doxygen/commands.html#cmdif > I'd still say that even in that case, doxygen should be used more as a > documentation building tool and not a formatting tool. In fact, for the > vast majority of documentation, I really like plain text - I can always > view it easily, update it easily, etc. I'd think that for most of the > documentation, there is actually little need for formatting in most cases. Except for bundling purposes, of course. It's easier to have all in the same format. Note that it may be possible to just instruct doxygen to include plain text files. No formatting, but it would be part of the formatted page anyway. I guess http://www.stack.nl/~dimitri/doxygen/commands.html#cmdverbinclude would do the trick. So we could have both - plain text files for quick reference, bundled / formatted documentation. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070716/59d3fab3/attachment.pgp From mwedel at sonic.net Tue Jul 17 01:00:35 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 16 Jul 2007 23:00:35 -0700 Subject: [crossfire] Priority feature list Message-ID: <469C5B03.1050901@sonic.net> As per recent e-mail and irc discussions, we need to figure out what the priority things to work on in for the 2.0 release are. There is a very long TODO list at http://wiki.metalforge.net/doku.php/dev_todo_new which may give some people starting point. There is http://wiki.metalforge.net/doku.php/dev_todo which has some overlap. The basic idea is what gets chosen gets a concerted effort by hopefully several developers to finish, and then we work on something else (next top priority). It doesn't necessarily mean that something not voted on won't get done - it just means that it will get done later vs sooner. Another principle behind this is that whatever is decided on gets lots of attention until is fully done. If we take an example fix/revamp sound - it doesn't mean we make protocol and client changes and call it done - it also means that all the archetypes get updated as appropriate, as well as the maps for that matter, so that the task is called complete when there really isn't anything more to do. The voting for features will be open to all members of crossfire community (players + developers), but votes may be weighed in different ways. What I'm looking for right now is a list of 5-10 things to put out in the first vote. Ideally, these should be things that take some considerable effort - if it is something that someone can complete in 1 hour, doesn't make a lot of sense to spend the effort voting on it, etc, as that might take more time than making the change. That said, the effort for a fair number of things may be unknown, so if not sure, feel free to include them in this list - if nothing else, it may provide a priority list for minor things. From juolja at utu.fi Tue Jul 17 04:25:24 2007 From: juolja at utu.fi (Juha =?UTF-8?B?SsOkeWtrw6Q=?=) Date: Tue, 17 Jul 2007 12:25:24 +0300 Subject: [crossfire] Priority feature list In-Reply-To: <469C5B03.1050901@sonic.net> References: <469C5B03.1050901@sonic.net> Message-ID: <20070717122524.1875ab5e@alnitak.stiff.utu.fi> > There is a very long TODO list at > http://wiki.metalforge.net/doku.php/dev_todo_new which may give some > people starting point. There is > http://wiki.metalforge.net/doku.php/dev_todo which has some overlap. Everyone, who follows irc, knows I'm really concerned about character balance. There are several aspects to it and I'm not quite sure which point in http://wiki.metalforge.net/doku.php/dev_todo:game_balance is the correct place to put them, so I thought to advance my ideas here first. First, most quest-reward and artefact items are weapons. This makes completing quests somewhat unrewarding for monks, fireborns and dragons (I forget is someone else has no weapons and no armour). This could easily be fixed simply by changing a few items in a few maps, but I think there is a nicer solution as well. Why keep quest-rewards static? There could be a small python script picking an appropriate reward from a treasurelist - I'm not saying never reward a monk with a sword, but make it much less likely than rewarding a fighter with a sword. Of course, this does not apply to such quests where the reward-item is an integral part, consider the following. There can be a quest with a story of the evil X, who stole King Arthur's Excalibur and keeps it in his Luggage - it's pretty obvious one's going to find an excalibur and a luggage on this quest. Second, the race- and class-specific distinctions are all but lost at levels around 30 and higher. The racial differences generally affect at high levels as well, but there are exceptions: fireborn mana regen bonus, most stat-score bonuses and dark vision (this is "negated" the instant one finds a torch, i.e. very quickly).[1] I'm not saying all these are necessarily bad things, but it would be nicer if they affected the game more even at high levels. I do not know which would be the best solution to this, but I personally like the idea of making more race-specific items; add body parts like "dragon tail" and "fireborn tentacle" to the races and create objects that consume these. Class specific distinctions tend to be initial skills and stats; except for the meditation skill, all class-skills can be acquired from scrolls. There have been several ideas as to how to change this. No matter how this is solved, I think the goal must be that if a character has an initial stat/mana regen bonus/skill better than "baseline", it must be ensured that given the same amount of playing, that initial difference sticks: If I have a character Str +2 with respect to "baseline" and I go kill 10000 goblins, I should still have an Str score 2 above the baseline character who killed 10000 goblins. (Of course it may be the baseline guy found Strength potion and I did not, but I'm talking about statistics here - let's go kill a few more goblins so that I find a Str potion as well while the other guy does not and check the scores again. We must consider the equipment as well, but let's assume that doing the same amount of adventuring amounts to comparable equipment.) For the record: I dislike race- or class-based fixed stat or level limits. I've hated them ever since D&D first edition... =) Third, the maximum level limit has had some critique - this might be The Time to remove it. Just figure out a nice little formula for the required experience as a function of level and that's it. Of course this means Zorn and friends must either be bumped up a zillion levels or the some spells must cease being affected by level difference or, what's wrong if someone suddenly is able to charm Zorn? Fourth, the spell system needs rebalancing. First, meteor swarm and frost nova kill almost anything (if you can make the meteors or asteroids directly hit your opponent, even fire or cold immune creatures will die). (By the way, names comet and asteroid should be swapped: comets are cold, asteroids less so. =) ) Also, some god-speciality spells kill anything, like divine shock or red death. Now that there is frost nova, things are a little better: fire-denied characters can gain a kill-all -spell as well, but I think that either we need to reduce the effectiveness of these all-too-powerful spells OR we need to add similar spells to each category: evocation and pyromancy already have, as does praying for two gods, we're still missing one for summoning, sorcery and most gods. What I think would be the best solution is simply bump up the level required for these kill-all -spells. Make meteor swarm level 100 spell, for example, and it won't be nearly as bad any more. Same goes for the others as well. Charm monsters and Peace are a story of their own: they are balanced by the fact that they do not affect creatures of level higher than the caster, but other than that, they are deadly. Fifth, at high levels, spells are useless. It's almost always easier and more effective to simply karate chop or weapon slash everything you bump into. This ought to change. At the moment, if I had to advise someone in creating a new character, I'd probably suggest troll figther or such. Easiest to stay alive at low levels and at high levels it makes no difference - everyone just runs into monsters anyway. There probably are other things not mentioned on the wiki as well, but I don't recall any at the moment. [1] It's easy to increase mana regen bonus with good weapons, arnour etc and while there are rings and amulets for fireborns to increase theirs, it very quickly occurs that those who can use good armour and weapons, surpass fireborns' mana regeneration ability. While the bonus is still there, it is more than balanced by the no weapons and no armour hindrance. Same goes to most stat scores with respect to anyone who cannot use weapons or armour. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070717/7dca1cd5/attachment.pgp From nicolas.weeger at laposte.net Tue Jul 17 11:48:19 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 17 Jul 2007 18:48:19 +0200 Subject: [crossfire] good http library for new metaserver? In-Reply-To: <469B11CA.5000503@sonic.net> References: <469B11CA.5000503@sonic.net> Message-ID: <200707171848.22639.nicolas.weeger@laposte.net> Hello. > There is also libwww. I'm sure there are others. > > So this is really just a question to see what is out there. Here is my checklist for that: * works under Linux, Windows, Mac (ok, no Mac client for now, but well, it'll come some day). The more portable, the better * can do other things than http. There have been talks about ftp transfers for eg music. Since we're deciding on a library for http, let's decide for a library for everything :) > I'd also suggest this handling if the library is missing: > > For the server, this is OK, unless the user has turned on the metaserver > notification setting. If that is set, then program terminates with error - > either install the library, or turn of metaserver notification. I'd require the library unless a configure flag is set. It's easier to build with library and not use than don't build and need to rebuild later :) > For client, maybe shouldn't be a fatal error? Or maybe it is a fatal error > unless something is passed into configure (configure --no-metaserver or > something) - it would seem that for most people, this is pretty core > functionality, but there could be some that don't need it (own server, > inside company firewalls, whatever) Then you need to handle this case where there is no metaserver listing. And previous argument applies :) Again, I think the library is mandatory, and requires a --no-metaserver flag to bypass. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070717/b74441a2/attachment.pgp From nicolas.weeger at laposte.net Tue Jul 17 13:02:39 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 17 Jul 2007 20:02:39 +0200 Subject: [crossfire] Priority feature list In-Reply-To: <469C5B03.1050901@sonic.net> References: <469C5B03.1050901@sonic.net> Message-ID: <200707172002.42613.nicolas.weeger@laposte.net> Le mardi 17 juillet 2007 08:00, Mark Wedel a ?crit?: > As per recent e-mail and irc discussions, we need to figure out what the > priority things to work on in for the 2.0 release are. There has been some discussion on speed/combat balance (basically: reduce speed, so combats take some more time, and enable players to actually flee before getting killed easily), though it isn't on the page. Could this be added to the list, or is it something not everyone agrees on? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070717/5f9fb533/attachment.pgp From nicolas.weeger at laposte.net Tue Jul 17 13:07:36 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 17 Jul 2007 20:07:36 +0200 Subject: [crossfire] Priority feature list In-Reply-To: <20070717122524.1875ab5e@alnitak.stiff.utu.fi> References: <469C5B03.1050901@sonic.net> <20070717122524.1875ab5e@alnitak.stiff.utu.fi> Message-ID: <200707172007.36469.nicolas.weeger@laposte.net> > First, most quest-reward and artefact items are weapons. This makes Scripting, scripting. Of course need to design quests for that particular reward :) > Third, the maximum level limit has had some critique - this might be The > Time to remove it. Just figure out a nice little formula for the required There will always be a maximum level. It can be 112, it can be 200, it can be 1000000. But there will always be a maximum :) My opinion: let's keep things as they are for level, but rebalance how you gain experience, maybe. > Fourth, the spell system needs rebalancing. First, meteor swarm and frost That's part of the whole game balance. > Fifth, at high levels, spells are useless. It's almost always easier and > more effective to simply karate chop or weapon slash everything you bump My opinion is to totally rebalance combat / spells / speed. Reduce speed, add more "strategic" elements to the game. Make it so you can actually use rune/trap writing to lure monsters, and so on. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070717/45d2723b/attachment.pgp From juolja at utu.fi Tue Jul 17 13:39:18 2007 From: juolja at utu.fi (Juha =?UTF-8?B?SsOkeWtrw6Q=?=) Date: Tue, 17 Jul 2007 21:39:18 +0300 Subject: [crossfire] Priority feature list In-Reply-To: <200707172002.42613.nicolas.weeger@laposte.net> References: <469C5B03.1050901@sonic.net> <200707172002.42613.nicolas.weeger@laposte.net> Message-ID: <20070717213918.7f799ee8@alnitak.stiff.utu.fi> > There has been some discussion on speed/combat balance (basically: > reduce speed, so combats take some more time, and enable players to > actually flee before getting killed easily), though it isn't on the > page. Could this be added to the list, or is it something not everyone > agrees on? I tend to disagree. Someone pointed out that reducing speed tends to turn the game from a "real-time" one to a turn based one, which I dislike. Another way of achieving the same result is to reduce the *damage* dealt by . That way, monsters and players could still move "real-time"ish, but you could still escape. By the way, I have rarely encountered a situation I was not able to flee from. Almost all places can even be solved by simply jumping back and forth from the map (using normal exits, no spells) to gradually wear down the opponent(s). Some exceptions come to mind, but only when entering the map for the first time ever (i.e. when I do not know how to escape). The sole exception to this is Wist's Tower (or is it Twis?) in Lake Country, where, after walking all the way to the top and killing the two Balrogs, you can choose to meet a few big_wizards... That's a place I am not able to escape (by a not-high-enough character) from even if I know the map - you need a key from one of the wizards to exit the map (being entered through a trap door you cannot use that way to escape). Word of recall works there, but the delay is too much for almost any character - the wizards kill you before you are recalled. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070717/8b7691d0/attachment.pgp From juolja at utu.fi Tue Jul 17 13:51:49 2007 From: juolja at utu.fi (Juha =?UTF-8?B?SsOkeWtrw6Q=?=) Date: Tue, 17 Jul 2007 21:51:49 +0300 Subject: [crossfire] Priority feature list In-Reply-To: <200707172007.36469.nicolas.weeger@laposte.net> References: <469C5B03.1050901@sonic.net> <20070717122524.1875ab5e@alnitak.stiff.utu.fi> <200707172007.36469.nicolas.weeger@laposte.net> Message-ID: <20070717215149.72f63458@alnitak.stiff.utu.fi> > > First, most quest-reward and artefact items are weapons. This makes > Scripting, scripting. Of course need to design quests for that > particular reward :) Cannot we alter some existing ones as a first aid? Inventing dozens of new quests is quite a big task. > There will always be a maximum level. It can be 112, it can be 200, it > can be 1000000. But there will always be a maximum :) Using arbitrary precision arithmetic library (like GNU MP) makes that limit limited only by the amount of digits the server can store in its virtual memory - which will probably be growing faster than any character gains levels, so in practice there would be no limit. Even a less radical method of using 64- or 128-bit integers to represent experience, I think we could increase the "bitness" of the experience-variable faster than anyone can consume the bits. Anyway, this is not what I was after. I was after the fact that there is a hard-coded value "MAX_LEVEL" (or MAX_64BIT_INTEGER, for that matter) used in the code. Is *this* doable? In that case increasing the maximum level would be very easy, no matter how it is represented. > My opinion: let's keep things as they are for level, but rebalance how > you gain experience, maybe. That's otherwise ok, but what about old characters at 110th level? At the least we'd need to give them some new levels to achieve. Something needs to be done about generators, however. It is currently too easy to sit around, letting a generator spawn a map full of monsters, kill them but not the generator and repeat until 110th level. This is particularly easy in Hell, where the monsters give zillion XP, there is a grate behind which to recuperate and numerous generators spawning more and more cannon fodder. > > Fourth, the spell system needs rebalancing. First, meteor swarm and > That's part of the whole game balance. Isn't it all? =) I thought we were discussing specific points of concern with regards to whole game balance. > My opinion is to totally rebalance combat / spells / speed. Reduce > speed, add more "strategic" elements to the game. Make it so you can > actually use rune/trap writing to lure monsters, and so on. That's fine. It is also huge task... sounds like a challenge, I'm on! BTW, runes are essentially single-shot devices, so they might well be significantly more powerful than currently (or, rather, more powerful *compared to other spells* than currently). Traps are more difficult because they can contain arbitrary spells. But what works for traps works for runes as well - and runes still need more power imho. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070717/527f5096/attachment.pgp From mwedel at sonic.net Wed Jul 18 00:57:22 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 17 Jul 2007 22:57:22 -0700 Subject: [crossfire] Priority feature list In-Reply-To: <20070717215149.72f63458@alnitak.stiff.utu.fi> References: <469C5B03.1050901@sonic.net> <20070717122524.1875ab5e@alnitak.stiff.utu.fi> <200707172007.36469.nicolas.weeger@laposte.net> <20070717215149.72f63458@alnitak.stiff.utu.fi> Message-ID: <469DABC2.8030300@sonic.net> Juha J?ykk? wrote: >>> First, most quest-reward and artefact items are weapons. This makes >> Scripting, scripting. Of course need to design quests for that >> particular reward :) > > Cannot we alter some existing ones as a first aid? Inventing dozens of > new quests is quite a big task. I'm sort of mixed on the idea of having random quest rewards. I'm certainly for having more quest rewards that are not weapons. A problem with mixed quest rewards is this adds a definite incentive for a player to repeat the same quest over and over again, until they get all the random awards that quest may give. If it is a static reward, once you do it once, probably not much point to do it again. And from the flip side, if you're a monk, looking for the good monk item that quest gives out 10% of the time, it could be really frustrating to do that quest 10 times to get that item (or more if unlikely). So I'd rather there be static quest items, but more variety. > >> There will always be a maximum level. It can be 112, it can be 200, it >> can be 1000000. But there will always be a maximum :) > > Using arbitrary precision arithmetic library (like GNU MP) makes that > limit limited only by the amount of digits the server can store in its > virtual memory - which will probably be growing faster than any character > gains levels, so in practice there would be no limit. Even a less radical > method of using 64- or 128-bit integers to represent experience, I think > we could increase the "bitness" of the experience-variable faster than > anyone can consume the bits. > > Anyway, this is not what I was after. I was after the fact that there is > a hard-coded value "MAX_LEVEL" (or MAX_64BIT_INTEGER, for that matter) > used in the code. Is *this* doable? In that case increasing the maximum > level would be very easy, no matter how it is represented. Changing max level is actually quite easy - just modify the exp_table file. experience values are 64 bit - yes, they could overflow, but unless there were changes such that you could get 20 billion exp/monster, unlikely to ever be reached. That said, a huge number of games have some maximum level, and there are lots of good reasons for this - it is easier to balance things if the range of levels isn't so great, you don't don't need as many spells, etc. If we rebalance everything else (which includes have spells that go all the way up to level 110 or so), and a server set max level to 1000, once characters started getting to some point, they'd probably start saying the game is too easy, that there is nothing more to do - I've learned all the spells, etc So from the mainstream point of view, we have to aim at there being 100 levels (or thereabouts) in the game - different servers can change it, but like any customizations they do, that is their own choice with it's own set of consequences. > >> My opinion: let's keep things as they are for level, but rebalance how >> you gain experience, maybe. > > That's otherwise ok, but what about old characters at 110th level? At the > least we'd need to give them some new levels to achieve. When 2.0 is released, IMO characters from the 1.x series will not be compatible, so characters will need to be started anew. This is probably a good thing for many reasons. > > Something needs to be done about generators, however. It is currently too > easy to sit around, letting a generator spawn a map full of monsters, > kill them but not the generator and repeat until 110th level. This is > particularly easy in Hell, where the monsters give zillion XP, there is a > grate behind which to recuperate and numerous generators spawning more > and more cannon fodder. IMO, pretty much every generator could be removed from the game and it would probably make things better. As things stand now, only if you are very marginal at taking on the creatures the generators spawn does it provide any sort of difficulty. Once you get to the point you can kill them with little danger (which in many cases, is just a level or 2 above the point where it is marginal), it just provides a way to get lots of exp, and lots of loot. Having generators also really does make it a game where high damage rate is important - if rooms are constantly full of creatures, the only attack method is to hit them with up front damage. > >>> Fourth, the spell system needs rebalancing. First, meteor swarm and >> That's part of the whole game balance. > > Isn't it all? =) I thought we were discussing specific points of concern > with regards to whole game balance. This thread was supposed to be about very broad issues, not into specific design changes - that comes later. > >> My opinion is to totally rebalance combat / spells / speed. Reduce >> speed, add more "strategic" elements to the game. Make it so you can >> actually use rune/trap writing to lure monsters, and so on. > > That's fine. It is also huge task... sounds like a challenge, I'm on! > BTW, runes are essentially single-shot devices, so they might well be > significantly more powerful than currently (or, rather, more powerful > *compared to other spells* than currently). Traps are more difficult > because they can contain arbitrary spells. But what works for traps works > for runes as well - and runes still need more power imho. One general problem, which is really hard to sort out, is the hp disparity between players and monsters. the problem this results in is that if a rune is even marginally deadly for a monster, it is probably totally deadly for any player that happens to wander into it. From mwedel at sonic.net Wed Jul 18 00:58:42 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 17 Jul 2007 22:58:42 -0700 Subject: [crossfire] Priority feature list In-Reply-To: <200707172002.42613.nicolas.weeger@laposte.net> References: <469C5B03.1050901@sonic.net> <200707172002.42613.nicolas.weeger@laposte.net> Message-ID: <469DAC12.3090900@sonic.net> Nicolas Weeger wrote: > Le mardi 17 juillet 2007 08:00, Mark Wedel a ?crit : >> As per recent e-mail and irc discussions, we need to figure out what the >> priority things to work on in for the 2.0 release are. > > There has been some discussion on speed/combat balance (basically: reduce > speed, so combats take some more time, and enable players to actually flee > before getting killed easily), though it isn't on the page. Could this be > added to the list, or is it something not everyone agrees on? I think anything can get added to the page. I'd also note that at this point, it is probably premature to get to far into implementation details. Also, presumably stuff with no strong agreement would fail to garner any number of votes, and thus not get done. From nicolas.weeger at laposte.net Wed Jul 18 11:56:03 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 18 Jul 2007 18:56:03 +0200 Subject: [crossfire] Priority feature list In-Reply-To: <469DABC2.8030300@sonic.net> References: <469C5B03.1050901@sonic.net> <20070717215149.72f63458@alnitak.stiff.utu.fi> <469DABC2.8030300@sonic.net> Message-ID: <200707181856.03403.nicolas.weeger@laposte.net> > I'm sort of mixed on the idea of having random quest rewards. I'm > certainly for having more quest rewards that are not weapons. > > A problem with mixed quest rewards is this adds a definite incentive for > a player to repeat the same quest over and over again, until they get all > the random awards that quest may give. If it is a static reward, once you > do it once, probably not much point to do it again. > > And from the flip side, if you're a monk, looking for the good monk item > that quest gives out 10% of the time, it could be really frustrating to do > that quest 10 times to get that item (or more if unlikely). > > So I'd rather there be static quest items, but more variety. I think there is a misunderstanding, at least that's not what I meant with "scripting". I meant "you can adapt the quest reward based on the player's race / class / stats / time of day through scripting". So a monk would get a good monk item, a fireborn an item a fireborn can use, and so on. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070718/7ae3d050/attachment.pgp From huet.o at free.fr Wed Jul 18 15:59:08 2007 From: huet.o at free.fr (Olivier Huet) Date: Wed, 18 Jul 2007 22:59:08 +0200 Subject: [crossfire] gtk-v2 on MS Windows Message-ID: <000301c7c97e$7c215510$7463ff30$@o@free.fr> Hello, Some time ago, Reven did modify the gtk-v2 to make it compile for MS Windows (with MinGW) - see his post at http://forum.metalforge.net/viewtopic.php?t=1571. It was really great : slightly faster and cooler than slow (on Windows) gtk 1 client. I recently try to use again crossfire and was quite surprised that this client is still not on "officials ones", so I did try to compile actual svn sources and it didn't compile because a new use of "scandir" function that is not present in MinGW. I did wrote a little substitute for this with more standard unices functions that are present in MinGW (opendir / readdir ...). I did bracket this substitute with "#ifdef WIN32" but that should works on unix os without scandir in the same way. --> see that patch in attachment file. Now it do compile well and run but is it still a continued client ? Best Regards, Olivier (findufin & findragon on metalforge) -------------- next part -------------- A non-text attachment was scrubbed... Name: client-gtk2win-fix.diff Type: application/octet-stream Size: 1894 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070718/c6c7a522/attachment.obj From mwedel at sonic.net Wed Jul 18 23:37:14 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 18 Jul 2007 21:37:14 -0700 Subject: [crossfire] Priority feature list In-Reply-To: <20070717213918.7f799ee8@alnitak.stiff.utu.fi> References: <469C5B03.1050901@sonic.net> <200707172002.42613.nicolas.weeger@laposte.net> <20070717213918.7f799ee8@alnitak.stiff.utu.fi> Message-ID: <469EEA7A.9070903@sonic.net> Juha J?ykk? wrote: >> There has been some discussion on speed/combat balance (basically: >> reduce speed, so combats take some more time, and enable players to >> actually flee before getting killed easily), though it isn't on the >> page. Could this be added to the list, or is it something not everyone >> agrees on? > > I tend to disagree. Someone pointed out that reducing speed tends to turn > the game from a "real-time" one to a turn based one, which I dislike. > Another way of achieving the same result is to reduce the *damage* dealt > by . That way, monsters and players could still move > "real-time"ish, but you could still escape. I think the issue is more to reduce weapon speed, and less so actual speed. High level characters have weapon speed 5+ - that really isn't necessarily - at higher levels, the characters are doing more damage just on the basis of higher stats and better weapons. Reducing weapon speed reduces damage. I do have some seperate thoughts on changing speed itself - mostly to narrow the range between min and max speed - right now, min speed is 0.1 I think, which as you say, is pretty slow. But max speed is unlimited, but effectively I think charactes can get speed 2.0+ without a huge amount of difficulty, and that causes problems. Except in rare circumstances, speeds above 1.0 (which means 1 move/tick) shouldn't really be allowed. > > By the way, I have rarely encountered a situation I was not able to flee > from. Almost all places can even be solved by simply jumping back and > forth from the map (using normal exits, no spells) to gradually wear down > the opponent(s). As noted above, one reason is high player speed - certainly some monsters should have their speed increased, but one problem with increasing it too - having monsters with speed above 1.0 really isn't feasible (I think players would be somewhat upset if a monster effectively hopped 2 spaces to be next to them, which would happen with speed 1.0+). Note that speed is also subjective. If, for example, you reduced the speed of all creatures by 50%, but also decreased the tick time by 50%, things would affectively appear the same, except movement would seem smoother and bandwidth would go up. Hopping between exits is a problem - it could be changed so that monsters follow the players, but there will always be cases where even that isn't foolproof (monster too big to fit in previous map). More use of tiled maps would sort of fix this problem, but at some point, map hopping can be seen as a tactic (at higher levels, things like word of recall and town portal could effectively allow the same thing, and I think most people would agree that monsters shouldn't be able to follow that). From mwedel at sonic.net Wed Jul 18 23:44:03 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 18 Jul 2007 21:44:03 -0700 Subject: [crossfire] Priority feature list In-Reply-To: <200707181856.03403.nicolas.weeger@laposte.net> References: <469C5B03.1050901@sonic.net> <20070717215149.72f63458@alnitak.stiff.utu.fi> <469DABC2.8030300@sonic.net> <200707181856.03403.nicolas.weeger@laposte.net> Message-ID: <469EEC13.3050605@sonic.net> Nicolas Weeger wrote: > > I think there is a misunderstanding, at least that's not what I meant > with "scripting". > I meant "you can adapt the quest reward based on the player's race / class / > stats / time of day through scripting". So a monk would get a good monk item, > a fireborn an item a fireborn can use, and so on. Ok - that is a bit different. It would seem somewhat odd that quest rewards miraculously show up customized for the class - it especially depends on how many customizations you do (for example, if you do something different for fighters vs spellcasters, you could certainly see some characters that could use both). Other thing that would have to be sorted out is how to deal with parties. But further thinking, at some point, random rewards may be incentive for more player interactive - arrange trades, etc, for items. But hard to say if that is what will really happen vs people just repeating the quests. From mwedel at sonic.net Thu Jul 19 01:49:14 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 18 Jul 2007 23:49:14 -0700 Subject: [crossfire] good http library for new metaserver? In-Reply-To: <200707171848.22639.nicolas.weeger@laposte.net> References: <469B11CA.5000503@sonic.net> <200707171848.22639.nicolas.weeger@laposte.net> Message-ID: <469F096A.4030101@sonic.net> Nicolas Weeger wrote: > Hello. > >> There is also libwww. I'm sure there are others. >> >> So this is really just a question to see what is out there. > > Here is my checklist for that: > * works under Linux, Windows, Mac (ok, no Mac client for now, but well, it'll > come some day). The more portable, the better > * can do other things than http. There have been talks about ftp transfers for > eg music. Since we're deciding on a library for http, let's decide for a > library for everything :) How about curl/libcurl: http://curl.haxx.se/ http://freshmeat.net/projects/curl/ (this shows all supported OS's) It appears to meet your criteria, and is somewhat standard it seems (several other tools use it, so it is probably on a fair number of systems). It was at least on my system already, which is a hopeful sign. > >> I'd also suggest this handling if the library is missing: >> >> For the server, this is OK, unless the user has turned on the metaserver >> notification setting. If that is set, then program terminates with error - >> either install the library, or turn of metaserver notification. > > I'd require the library unless a configure flag is set. It's easier to build > with library and not use than don't build and need to rebuild later :) To be consistent, I then think that should be a standard for all libraries/features, but I'm not sure that is the correct approach if a library isn't need for operation. One of the points of configure is to find what capabilities the OS has in order to create a binary that supports as many features as the OS has easily. Somehow it seems wrong to me for configure to fail if you don't use a bunch of --disable-... options. Many current features of crossfire currently use this behavior - if library is not found, you don't get that feature, and not configure doesn't fail. I'd argue that the metaserver is least critical of these (plugins almost should be a requirement). And as a data point, there is what, 20 servers that report to the metaserver, but according to sourceforge, there has been 437 downloads of the server package. It's hard to say how many of those downloading are actually compiling, but at the same point, those numbers don't include any mirrors. All that said, configure does print out a message at the end about what features it will be building. Adding in a line about metaserver seems completely reasonable, so you're not forced to recompile. OTOH, it doesn't take too long to compile crossfire. Adding a note to the settings file in the metaserver section about making sure you're server has support could also be used as a hint. Because as of right now, the server as distributed has metaserver support turned off. So for a good number of people, they'd probably never notice/care about missing this (whether it finds the library or not would not change the behavior of their server at all). > >> For client, maybe shouldn't be a fatal error? Or maybe it is a fatal error >> unless something is passed into configure (configure --no-metaserver or >> something) - it would seem that for most people, this is pretty core >> functionality, but there could be some that don't need it (own server, >> inside company firewalls, whatever) > > Then you need to handle this case where there is no metaserver listing. And > previous argument applies :) no metaserver listing is basically the same as it is now if you can't get to the metaserver for some reason (firewall, down, whatever) - you just don't see many choices. > Again, I think the library is mandatory, and requires a --no-metaserver flag > to bypass. For client, I'd tend to agree, because not having metaserver support is likely to be more critical. And by default right now, the client tries to contact the metaserver, so there is some implied requirement for it. From mwedel at sonic.net Thu Jul 19 02:00:50 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 19 Jul 2007 00:00:50 -0700 Subject: [crossfire] gtk-v2 on MS Windows In-Reply-To: <000301c7c97e$7c215510$7463ff30$@o@free.fr> References: <000301c7c97e$7c215510$7463ff30$@o@free.fr> Message-ID: <469F0C22.9000407@sonic.net> Olivier Huet wrote: > Hello, > > > Some time ago, Reven did modify the gtk-v2 to make it compile for MS Windows > (with MinGW) - see his post at > http://forum.metalforge.net/viewtopic.php?t=1571. > > It was really great : slightly faster and cooler than slow (on Windows) gtk > 1 client. > > I recently try to use again crossfire and was quite surprised that this > client is still not on "officials ones", so I did try to compile actual svn > sources and it didn't compile because a new use of "scandir" function that > is not present in MinGW. I did wrote a little substitute for this with more > standard unices functions that are present in MinGW (opendir / readdir ...). > I did bracket this substitute with "#ifdef WIN32" but that should works on > unix os without scandir in the same way. The issue for all the binary packages of all the components (including the linux client and server) is that someone has to make them. Windows get a little trickier - most users don't expect that they need to compile their software. On the unix side, this isn't so uncommon, so the fact that there is a bsd, solaris, suse, etc on the site doesn't mean those OS's are not supported, it just means that no one on the development team compiles versions for those OS's. so I'd basically say the same is true here for windows - no one bothers to compile a gtk2 client for windows. There were never many window developers working on crossfire, so this may be explainable. Gtk2 client is IMO the most official of the clients - others may disagree. I'm tempted to spend an evening whipping up a glade configuration file for the gtk2 client that looks like the gtk1 client, just so it stops any complaints there - the question then comes how many different glade configs should there be - it is arguable if those are easier or harder to maintain than different bits of code. > > --> see that patch in attachment file. > > Now it do compile well and run but is it still a continued client ? See note above. I'll take care of your patch soon. From crossfire at kahnert.de Thu Jul 19 02:32:38 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Thu, 19 Jul 2007 09:32:38 +0200 Subject: [crossfire] Priority feature list In-Reply-To: <469C5B03.1050901@sonic.net> Message-ID: <20070719073238.GC24920@cthulhu.desy.de> On Mon, Jul 16, 2007 at 11:00:35PM -0700, Mark Wedel wrote: > As per recent e-mail and irc discussions, we need to figure out what > the priority things to work on in for the 2.0 release are. From juolja at utu.fi Thu Jul 19 07:34:36 2007 From: juolja at utu.fi (Juha =?UTF-8?B?SsOkeWtrw6Q=?=) Date: Thu, 19 Jul 2007 15:34:36 +0300 Subject: [crossfire] Priority feature list In-Reply-To: <469EEA7A.9070903@sonic.net> References: <469C5B03.1050901@sonic.net> <200707172002.42613.nicolas.weeger@laposte.net> <20070717213918.7f799ee8@alnitak.stiff.utu.fi> <469EEA7A.9070903@sonic.net> Message-ID: <20070719153436.29deb2d6@alnitak.stiff.utu.fi> > I think the issue is more to reduce weapon speed, and less so actual > speed. High level characters have weapon speed 5+ - that really isn't Ah, what I meant was to reduce damage dealt per unit of *real* time, so this is exactly the situation you described: changing weapon speed by *A and tick length by /A gives no change in damage dealt per unit of real time. The problem was "dying before able to react" and that refers to real time since it is the player who needs to react, not the character. Thus reducing weapon speed would be an excellent solution. That would immediately mean also that spells become relatively more effective. There may even be no need to alter them at all (at least not from "they are useless because sword/karate is so much faster" -perspective). > think charactes can get speed 2.0+ without a huge amount of difficulty, > and that causes problems. Except in rare circumstances, speeds above > 1.0 (which means 1 move/tick) shouldn't really be allowed. Well, outrunning magic missiles, speedballs etc is not difficult, but I think it should be, so I agree: max speed down (or spell speed up). > Hopping between exits is a problem - it could be changed so that > monsters follow the players, but there will always be cases where even > that isn't foolproof (monster too big to fit in previous map). More > use of tiled maps would sort of fix this problem, but at some point, > map hopping can be seen as a tactic (at higher levels, things like word > of recall and town portal could effectively allow the same thing, and I > think most people would agree that monsters shouldn't be able to follow I'd prefer tiling since that would be "natural" - exits as they currently work are more or less teleporters. This brings with it a myriad of game world -questions: why are there so many teleporters around? Who created them? Why? Etc. More later, J?rgen made a nice summary - I'll reply to that. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070719/eb915e84/attachment.pgp From mwedel at sonic.net Fri Jul 20 00:31:15 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 19 Jul 2007 22:31:15 -0700 Subject: [crossfire] Priority feature list In-Reply-To: <20070719073238.GC24920@cthulhu.desy.de> References: <20070719073238.GC24920@cthulhu.desy.de> Message-ID: <46A048A3.7040003@sonic.net> Juergen Kahnert wrote: > >> I'm not saying never reward a monk with a sword, but make it much less >> likely than rewarding a fighter with a sword. > > No, why should I ever start / solve a quest if the payment is worthless > for me? I don't want to get useless rubbish as a "reward". But you can never completely fix that. It may not be rubbish, but could still be something of no real value - for example, the girdle you have is better than the one you just got. Better can be a subjective term, but I think in many cases, characters will quickly be able to make those calls. There could be lots of reasons this happens - you traded with someone else to get that item, or you did some other quest to get that girdle before this quest, or maybe you just found a nice girdle in random treasure (I think that most of the quest items should be near the best for the level of the character that does them, but at the same time, I think characters should be able to find really nice equipment in random treasure now and again. This also helps give some incentive for players to do things like random dungeons, etc. > > >> There can be a quest with a story of the evil X, who stole King >> Arthur's Excalibur and keeps it in his Luggage - it's pretty obvious >> one's going to find an excalibur and a luggage on this quest. > > But Excalibur won't be the quest reward! King Arthur just wants it back. > So you have give it to King Arthur to receive your quest reward. And > this won't be Excalibur, isn't it? Good point - a lot of the quests in the game are of the nature that you talk to someone in the tavern and he says there is some nasty creature. You go kill it, and it has some unique item. It certainly makes more sense that someone in town may want that creature killed, and once you kill it and return, will give you something in return for that task. And that could even be something like 'You have a choice of 1 of these 3 items...', so the player can choose the item they want. This also works well in the "can't repeat a quest" type of thing - the above model does not prevent a character from going into that same dungeon multiple times and killing that same creature, but does prevent them from getting the nice item reward more than once. I don't think it will be feasible to prevent players from going to the same dungeon (to many ways around it), but certainly feasible to prevent them from getting rewards. And this method also works good for parties - it is unclear if a party should get more reward than a single character doing a quest. But presuming they should still only get one item, the entire party could go to that NPC, see the offerings, and try to figure something else (I'll take the sword he is offering and give you this girdle, etc). >> but I personally like the idea of making more race-specific items; add >> body parts like "dragon tail" and "fireborn tentacle" to the races and >> create objects that consume these. > > I like that idea, too. :) It's an implementation detail, but I'd rather there be some certain tags in objects for race/class/god allowability than to use the body part stuff. Otherwise, you get questions like 'the serpentman also has a tail - shouldn't he be able to put the same stuff on his tail like the dragon' and so on. I think it is better to say something like 'that item can only be used by dragons' vs "you don't have the body for that object", simply because the later would cause lots of confusions for lots of cases. And it goes beyond that - taking from other games, you often have things like armor or swords that can only be used by certain races - adding things like 'dwarf_arm' to use a weapon gets weird, or 'elven_body'. And that can lead to more complication, like people wearing two suits of armor, etc. > On Tue, Jul 17, 2007 at 08:07:36PM +0200, Nicolas Weeger wrote: >> There will always be a maximum level. It can be 112, it can be 200, it >> can be 1000000. But there will always be a maximum :) >> My opinion: let's keep things as they are for level, but rebalance how >> you gain experience, maybe. > > Sure, but you're able to make the limit unreachable as long as the > player isn't immortal. ;-) > > Make level 100 very hard to reach (like 115 now), but don't set a hard > cap. Make it all but impossible to reach. Just a note - looking at metalfore, only 2 characters have reached the high score/level limit. And I suspect even without retuning the exp table, if we re-adjust other factors (and fix bugs) it may not be possible to do that again with CF2. But as previously said, it is trivially easy right now to increase level cap, so I consider this a non issue. If a server decides to have a cap, that is their choice, if they don't, that is another choice. Yes, you have to modify the exp table, but if you don't want to fill out exp values by hand, one could easily enough write a 2-3 line program that calculates and prints out the values into the form expected. Now, for CF2, it may make sense for the level gain to start increasing dramatically after level 100 (instead of 110 like it is now), and if you had it double every level, then even if you only list to level 120, I doubt anyone could ever reach it. So yes, you have a cap, but if it no one ever gets to it, is it really a cap? > >> Also, some god-speciality spells kill anything, like divine shock or >> red death. > > Also for lower levels. Ever tried to level up praying as a level 1 > Ruggilli priest? > > Can't be the rule to be forced to change the cult just to get some > starting levels in praying. Some new spells are certainly needed, and a redistribution of existing spells (more to cover the broader level range) is also needed. There are very few spells above level 20 right now, dating back to when there were not that many levels. If we say that 100 levels is the range we aim for, then there should be a few level 90 and 100 spells. >> Fifth, at high levels, spells are useless. It's almost always easier >> and more effective to simply karate chop or weapon slash everything >> you bump into. > > Not only on high levels, especially for low levels. I'd disagree with that - I've found spells very useful at high levels. If you have the mana, and a large room full of monsters, blasting the room with spells is often a safer and faster method of killing them all than running about with a weapon. But certainly if there is just 1 or 2 monsters, certainly better to go melee. I think some of this goes into balancing the monsters, and not the spells. A lot of monsters have really high protection to magic and other attacks - basically they were designed in a sense so that the only way to kill them was with melee. That isn't the correct approach - if players are clever and can hit monsters with spells from a distance, that shouldn't be punished. The monster AI should perhaps be improved to make it harder for that to happen, but I've found that a lot of maps are designed with a 'you must kill this monster, and you must kill it this way'. > On Tue, Jul 17, 2007 at 08:07:36PM +0200, Nicolas Weeger wrote: >> My opinion is to totally rebalance combat / spells / speed. Reduce >> speed, add more "strategic" elements to the game. Make it so you can >> actually use rune/trap writing to lure monsters, and so on. > > If you rebalance the combat / spells / speed system, you need to check > every single map if it still works. If not you have to change the map. > And if this backfitting starts, I would like to remind to the > "reorganizing the entire world" thread: I see no basis on that assertion - that is almost like saying that if I add a new weapon, I need to check every map to make sure they still work. Some maps may become considerably harder - probably not a bad thing. I'd also say that the proper check would be to play every map and see how it plays - you probably would learn virtually nothing looking at the maps in an editor - you'd have to play it to see how hard it is now. And if it is a case that there may be objects/creatures in maps that need to be updated, very easy to write scripts to check for that type of thing. In fact, there are already several out there that do that. I think I've stated it previously, but IMO, the effort needed to redo the entire would could better be spent elsewhere. I'd like to see a lot more new maps/quests/etc, and those should be arranged so that it makes sense (put the tough maps in areas that already have tough maps,etc) > On Tue, Jul 17, 2007 at 10:57:22PM -0700, Mark Wedel wrote: >> I'm sort of mixed on the idea of having random quest rewards. > > Same for me. Quest rewards should be deterministic, but race / class > specific. Problem then is how many combos do you get if you do race * class - does a dwarf fighter get something different than an orc fighter? What about dwarf cleric vs dwarf fighter, etc. But the idea of there being some number of deterministic rewards that you can choose from works really well IMO. Sure, it may not be especially realstic that people would end up having 4 different things they could give you. OTOH, even if the player doesn't get the choice, effectively the NPC does have 4 different things they might give - it is just hidden from the player. Until they talk with other players and find out they got different things from the same NPC. So at that point, what not give the choice to the player. > > >> And from the flip side, if you're a monk, looking for the good monk >> item that quest gives out 10% of the time, it could be really >> frustrating to do that quest 10 times to get that item (or more if >> unlikely). > > I'm still a friend of having quests only solvable once for each > character. No rerun possible. How often will King Arthurs Excalibur be > stolen by the same crowd? See notes up a ways. But you get into the general problem of how do you explain things in a world where a map resets? Apparantly a new ogre chief constantly moves into that dungeon near scorn (you'd think they'd learn :) But it seems completely reasonable that the NPCs would remember that they gave a character a reward, and not give it again. >> IMO, pretty much every generator could be removed from the game and >> it would probably make things better. > > Yes, or make them run out of monsters. And hidden. Or how do you > explain a "monster generator" in the real world? ;-) of course, crossfire isn't the real world. I don't think making them hidden, or turn into ruined caves really fix the problem. Even a limited number of monsters isn't likely to change things - if that is the case, then it is really a waiting game (if I kill these giants one by one, eventually they'll stop coming and I can get the treasure). If that character is able to kill the giants, all you are giving him with a generator that produces 30 is a bunch more treasure and experience. If you want the room full of monsters, start the dungeon with the room full of monsters - don't rely on generators to fill it up. I think hidden generators (where the player can't get to them) doesn't fix the problem either - a general problem with generators is that it now becomes very easy to script something where the player just stands on some spot and kills anything that comes near him - hence lots of exp and treasure. IF generators get removed, it would reduce both exp and treasure, which should slow advancement in mid to low levels. Few high levels maps make use of generators, because the maps are already using custom monsters (and are probably better designed). Generators I think really date back more to when the game was an action game like gauntlet - it makes a lot less sense with the transformation into an RPG From juolja at utu.fi Fri Jul 20 04:53:19 2007 From: juolja at utu.fi (Juha =?UTF-8?B?SsOkeWtrw6Q=?=) Date: Fri, 20 Jul 2007 12:53:19 +0300 Subject: [crossfire] Priority feature list In-Reply-To: <20070719073238.GC24920@cthulhu.desy.de> References: <469C5B03.1050901@sonic.net> <20070719073238.GC24920@cthulhu.desy.de> Message-ID: <20070720125319.61345ae5@alnitak.stiff.utu.fi> Ok, so this thread was supposed to be about broad issues... I'll try to weer back to that direction. My first reply was mainly intended as "are these things I could add to the wiki", so I'll try to summarise my initial points at the end to ask again: are these something that could be added to the wiki? I hope I remember when I'm done answering... =) > > First, most quest-reward and artefact items are weapons. This makes > Not just weapons, getting e.g. a girdle as a fireborn, or boots as a > serpentman, or anything which won't be usable in any way is not really a > quest-reward but a joke. You're quite correct. I mentioned weapons only, because they dominate the rewards and they affect most characters (girdles do not affect monks and dragons, boots do not affect monks etc). > > I'm not saying never reward a monk with a sword, but make it much less > > likely than rewarding a fighter with a sword. > No, why should I ever start / solve a quest if the payment is worthless > for me? I don't want to get useless rubbish as a "reward". You misunderstood me here. I did not mean "let this quest sometimes give a sword as a reward, even to a monk", but "if some quest always gives a sword, it's ok" instead. I admit I wasn't quite explicit before. Going back to Excalibur as a reward... > But Excalibur won't be the quest reward! King Arthur just wants it back. > So you have give it to King Arthur to receive your quest reward. And > this won't be Excalibur, isn't it? What if King Arthur has been dead for little over a millennium? He won't be giving out the quest nor the reward; the evil lich (all powerful villains always seem to be lichs or wizards...) has simply kept Excalibur as a trophy over his fireplace (or, his being a lich, should that be an ice-cube pool?). In that case Excalibur would be the reward, *every* time, even for the monk. I do not see this as a bad thing - at least not when it is known beforehand that the reward will be useless *and* when this type of quest is a vanishing minority. [messing up a little with the order of discussion here] > > but I personally like the idea of making more race-specific items; add > > body parts like "dragon tail" and "fireborn tentacle" to the races and > > create objects that consume these. > I like that idea, too. :) This has actually two points why I like it: first, it allows creation of objects only fireborns, dragons, serpentmen etc can use (can items check fireborn_player_force or such when being equipped?) which is a nice feature just for gameplay and helps distiguish the races. Second, it helps balance things: consider a fireborn, who can wear 7 items (4 rings, 2 amulets and a cloak) and a human, who can wear 11 items (boots, pants, girdle, torso-armour, bracers, gloves, 2 rings, amulet, helmet and a cloak). To keep things balanced, the 7 items a fireborn can wear *and* its race-abilities must equal in power the 11 items a human can wear. With things like Carrillium apron for humans to wear, combined with some other almost as powerful items, the fireborn has no hope of matching the human. > http://mailman.metalforge.org/pipermail/crossfire/2007-July/011596.html That's a concrete proposal, I was supposed to try to stick to broad issues... I already forgot that above, so I won't go into details here. Your idea seems good, but perhaps a little confusing to beginners (and we need to be attractive to beginners to get more players). I'm sure, though, that it can be refined to a non-confusing system. I particularly like the idea of guild memberships as a requirement of high capability level of skill X ,though I never figured out why the "skill level" exists in your system at all. (Perhaps I read carelessly.) One point of stat-caps needs to be made here: I did not mean I am against fixed *natural* stat limits, they are ok. I'd say they are adamant. With natural stat limits, the absolute stat limit follows from the amount of bonuses you can equip simultaneously. I do not feel there is a need to separately limit this magically adjusted maximum. That said, I *do* favour the idea of fixing limits on the maximum bonuses items can bring about. Sword with Str +10 is too powerful, unless it has item power ~100. It would be ok to have some items with a *single* exceptional property, provided that would only be usable by players of extremely high levels *and* that even they could not simultaneously use another (even slightly) powerful item. (Note that this implies a hard cap on level OR making a distinction between how much item power a character can equip and the character level. If the item power -limit can be increased without limit, there is no point in limiting the usability of Str +10 -items by item power since eventually two exceptionally powerful items could be used anyway.) At this point, I'll advance another idea I have, which is a major change: alchemy. In the past, there was just alchemy, now there is jewellery, weaponsmithy etc in addition, this is nice. I like it. At the moment there are separate formulas for "ring ac +1" and "ring ac +2" etc. (There may not be actual formulas for these specific items, but read on, you'll get the point.) While this is fun, I think it is too restrictive. I think the "alchemy" system should work so that once you know the formula for "make this item make me stronger" or "make this item make me more one with powers of nature" (mana regen bonus), you could repeatedly use the same formula (or a simple variant, I'll return to this point soon) to get the item even stronger and stronger. Now, simply repeating the same process over and over makes it too easy to produce "ring str +10" or whatever is the maximum. There are two easy ways out of this: either make the cost of the bonus (or item power?) prohibitively expensive as the power of the item increases - something like weapon enchanting needs more sacrificial lamb... er... diamonds as wer bonus goes up; except that I'd like the cost to be exponential (or nearly). The other solution would be to limit the maximum item power a character can enchant an item to. Say, at level 10 you can at most enchant an item which has item power 1. This would be a hard limit, like charm never charming higher-level monsters than the caster. Also, the possibility of failing should be kept around. Additionally, at 100th level, it would be easier to make item power 1 than it is at 10th level. I also do not like that "improve stat bonus" and the like are applicaple to weapons only (monks, fireborns, dragons can not benefit from this). There are other solutions to this part of my grudge, but my idea above solves this as well. > That's why I've no idea why "fireborns with meteor swarm" is an issue > for game balance... I do not either, but it is probably because anyone else carelessly using meteor swarm will die of the *fire* damage *themselves*, fireborns won't. Being able to blast meteor swarms all around you in tough situations without need to escape the inferno is one of the few things that make playing fireborns worth while. Without it, they'd never close the gap caused by being able to wear no more than 7 items at a time. Besides, meteor swarm has its obvious disadvantages, namely monsters with fire immunity need to be hit directly with the meteors and that damn inferno burns all items around. You never get any nice rings or amulets that way (unless the items are in a different room). > Also for lower levels. Ever tried to level up praying as a level 1 > Ruggilli priest? I have, but since I was in a party, it was not tough. Sorig also has turning denied, which makes the first few levels very tough for sorigists as well. > > Fifth, at high levels, spells are useless. It's almost always easier > > and more effective to simply karate chop or weapon slash everything > > you bump into. > Not only on high levels, especially for low levels. I disagree. Low level fireballs are effective against orcs etc. At low level, orcs are still able to kill you, so you'd better watch it - blasting fireballs from way off is a good way to be careful. At ~60th level, my fireborn monk is unable to kill a greater daemon with spells (there are situations and tactics which make the statement untrue, but karate is still faster), but he can easily karate chop it. > Ever tried to play a sorcerer without using physical attack skills? You > won't be able to kill some monsters because they regenerate their hp > faster than you sp. A dragon player just run through them like they're Fireborn sorcerer, no problem, thanks to Attuned: fire and burning hands. Non-fireborns, however, *do* have the sp regen problem. But even a 108th level spellcaster, who regenerates 1 sp *each* *tick* cannot kill certain monsters with spells - and this is where the real problem lies. It's ok to have only a single method to kill a "final boss" monster, but first of all, this applies to ordinary monsters, too and second, this method often involves things some characters can not do, like using a very powerful weapon or being able to sustain zillion hp of cold damage (I chose cold here since fireborns have been a concern and they really cannot withstand cold - not even that of a couple of chinese dragons). > Not so for CF. Being a high level mage won't give you enough power to > kills some of the high level monsters where others just need to run into > them. This is really annoying. Agreed. > http://mailman.metalforge.org/pipermail/crossfire/2007-July/011613.html Exactly. The four items mentioned surpass any combination of two rings and an amulet from the spell casting point of view. Not to mention there are weapons and armour with spell casting bonuses as well (you left torso, hands and weapon slots free in your example; I assume Idaten boots). Also, I think "of Magi" is an artefact modifier which can apply to pretty much any item, at least I think it can apply to armours (I have a character with a crown of magi - I'm not sure if its random or unique item, cannot recall). > "reorganizing the entire world" thread: > http://mailman.metalforge.org/pipermail/crossfire/2007-June/011532.html I have read that and I dislike the idea of segregating players of different levels. Much better would be warning signs immediately after entering a dungeon - or the "magic mouth" -kind of warning someone suggested: "You get the feeling this dungeon is extremely dangerous/very easy". Of course, high level players repeatedly cleansing low-level dungeons for various reasons is a problem. Testground for new spells might help that, though. (I admit having gone out to newbie tower to test some new stuff and spells.) > Don't make CF2 compatibel with CF1.x and everybody has to start with > level 1. This is necessary after big changes in the system. Ok. No argument here. > I'm still a friend of having quests only solvable once for each > character. No rerun possible. How often will King Arthurs Excalibur be > stolen by the same crowd? How about a party solving a quest? Should each character who participated be prevented from doing it again or only the one who "receives" the quest and the reward? This sounds like a nice idea, but I am also afraid it means that soon some characters will have nothing else except the random hack-and-slash dungeons left. > But don't mix up the regions. So you don't have to care about rebalance > the system again, because you have well balanced lower level regions. > If player with powerful items from high level regions are able to > harvest on lower level regions the balance is gone... That should be pointless. If you can go kill dragons with impunity and get 100000 gold from each one's hoard, there is no point harvesting the few dozen silver you get from newbie tower. Also, gearing towards D&D 3rd edition -type XP system might help. In the mentioned system, a 20th level fighter killing a kobold gets no XP what so ever. Thus you can't even level up by map camping in newbie tower (waiting for the generators to spawn you a million orcs). > > IMO, pretty much every generator could be removed from the game and > Yes, or make them run out of monsters. And hidden. Or how do you > explain a "monster generator" in the real world? ;-) Aah, that would be a nice solution! It would fit nicely in a "real" game world even. Ok, now the summary - if anyone bothered reading this far... =) Numbering is as in original post. And I will try to be brief, not mention any specifics and only write what I feel has been agreed upon by all posters. 1) Quest rewards must be rebalanced to be usable to all characters solving the quests. 2) Races must be rebalanced and allowed race-specific items (or at least feature-specific, like "human(like) finger" or "human(like) torso"). Class balancing is also warranted, but there has also been a proposition to scrap classes as they now exist alltogether. Finally, (magically adjusted) max stat limits should be increased and maximum magical bonuses for items specified. (Just got an idea: what if magic bonuses from items stacked up non-linearly like resistances do? That would make it a lot harder to get to maximum?) 3) Maximum level should stay. Perhaps even be lowered, but made much harder to reach in any case. 4) This was not commented much, so I take it everyone agrees that all spell casting "fields" (i.e. all separate deities, evocation, pyromancy, summoning and sorcery) should have equally powerful "best" spells. Preferably even equally powerful "best" spell for each spell level (or few levels); i.e. not just have the ultimate most powerful spells equally powerful, but the best first level spells as well and 10th and 20th and so on. No need to have them equal at every single level, but every few. Preferably when the previous best spell has become almost useless against monsters the character is supposed to be fighting. I.e. if spark shower is the best sorcery spell at 1st level and since is useless against 10th level monsters, at 10th level there should be another spell which should equal whatever other spell "fields" have acquired by 10th level. 5) Spells need to become more useful compared to running into monsters. No definite solution was found for this yet. 6) This was not in my original list. This is the alchemy/jewellery/etc change I propose earlier in this posting. No need to repeat it here, I hope. Phew... I wrote this mail in more than four stints during almost 24 hours, watching Die Hard 4.0 and such in between, so bear with me, if it seems non-coherent. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070720/d0c9f555/attachment-0001.pgp From huet.o at free.fr Fri Jul 20 14:58:29 2007 From: huet.o at free.fr (Olivier Huet) Date: Fri, 20 Jul 2007 21:58:29 +0200 Subject: [crossfire] bug in gtk-v2 client Exp's progressbar Message-ID: <000001c7cb08$585b3de0$0911b9a0$@o@free.fr> Hello, Sorry to flood again that list with patchs but I did noticed a bug in the gtk2 client : the label and progressbar of Exp do not works properly with hi levels because of int overflow. --> see patch in attachment (stat.c) : I did change int to uint64 and %d with the macro FMT64U. Best Regards, Olivier (findufin & findragon on metalforge) -------------- next part -------------- A non-text attachment was scrubbed... Name: client-gtk2-progressbar.diff Type: application/octet-stream Size: 821 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070720/9c01e0b9/attachment.obj From huet.o at free.fr Fri Jul 20 15:57:36 2007 From: huet.o at free.fr (Olivier Huet) Date: Fri, 20 Jul 2007 22:57:36 +0200 Subject: [crossfire] bug in gtk-v2 client Exp's progressbar In-Reply-To: <000001c7cb08$585b3de0$0911b9a0$@o@free.fr> References: <000001c7cb08$585b3de0$0911b9a0$@o@free.fr> Message-ID: <005001c7cb10$9a505660$cef10320$@o@free.fr> Hello again, Sorry to answer to myself but I did realize seing history of that file, that it have to be signed values for praying : here is a correction of that patch, with sint64 and FMT64. Best Regards, Olivier (findufin & findragon on metalforge) -----Message d'origine----- De?: crossfire-bounces at metalforge.org [mailto:crossfire-bounces at metalforge.org] De la part de Olivier Huet Envoy??: vendredi 20 juillet 2007 21:58 ??: crossfire at metalforge.org Objet?: [crossfire] bug in gtk-v2 client Exp's progressbar Hello, Sorry to flood again that list with patchs but I did noticed a bug in the gtk2 client : the label and progressbar of Exp do not works properly with hi levels because of int overflow. --> see patch in attachment (stat.c) : I did change int to uint64 and %d with the macro FMT64U. Best Regards, Olivier (findufin & findragon on metalforge) -------------- next part -------------- A non-text attachment was scrubbed... Name: client-gtk2-progressbar.diff Type: application/octet-stream Size: 819 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070720/a5eacd57/attachment.obj From nicolas.weeger at laposte.net Sat Jul 21 03:29:38 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 21 Jul 2007 10:29:38 +0200 Subject: [crossfire] gtk-v2 on MS Windows In-Reply-To: <000301c7c97e$7c215510$7463ff30$@o@free.fr> References: <000301c7c97e$7c215510$7463ff30$@o@free.fr> Message-ID: <200707211029.41586.nicolas.weeger@laposte.net> Hello. > It was really great : slightly faster and cooler than slow (on Windows) gtk > 1 client. Note that, if you're using the "official" Windows client, it is the GTK1 client built with GTK2. > I recently try to use again crossfire and was quite surprised that this > client is still not on "officials ones", so I did try to compile actual svn > sources and it didn't compile because a new use of "scandir" function that > is not present in MinGW. I did wrote a little substitute for this with more > standard unices functions that are present in MinGW (opendir / readdir > ...). I did bracket this substitute with "#ifdef WIN32" but that should > works on unix os without scandir in the same way. > > --> see that patch in attachment file. > > Now it do compile well and run but is it still a continued client ? As Mark said, Windows support isn't always up to date and lacking. I am (was?) the "official" Windows maintainer, and I've always built everything through MS's Visual Studio. Building the GTK1 client is a real mess, a weird process where you rename randomly files, copy and change names, change functions, and weird things like that. Therefore I didn't really want to try to build the GTK2 client. I also feel, maybe because I don't use it, that it isn't as advanced as the GTK1 client - from my point of view, GTK1 is still the official client ^_- Thanks for the patch, and the remainder :) As a note, I think patches are better on the Sourceforge tracker at http://sourceforge.net/tracker/?group_id=13833&atid=313833 instead of buried in the forum (tracker makes it easier to follow things) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070721/73d37a49/attachment.pgp From huet.o at free.fr Sat Jul 21 08:26:54 2007 From: huet.o at free.fr (Olivier Huet) Date: Sat, 21 Jul 2007 15:26:54 +0200 Subject: [crossfire] gtk-v2 on MS Windows In-Reply-To: <200707211029.41586.nicolas.weeger@laposte.net> References: <000301c7c97e$7c215510$7463ff30$@o@free.fr> <200707211029.41586.nicolas.weeger@laposte.net> Message-ID: <000f01c7cb9a$ce509c60$6af1d520$@o@free.fr> Hello, Yes I was talking about the "official" Windows client (gtk1 client build with gtk2). The problem of that one is that it's very slow and there is a lot of latency if you are in more than 13x13 (or perhaps 14x14), and especially when you are in a dark place. On the gtk2 version, there is an OpenGL and SDL display mode : with those mode, it's very smooth and reactive at 25x25. And to compile the Windows MinGW gtk2 client at its actual state, it's not so hard : the hard part is to setup a build environment : - I did found a website of another project with some details of what package and library to install / extract : http://www.ibiblio.org/apollo/WinGtkHowto.html - in addition to that site, there is a bug in installation of MinGW : u have to copy cc1.exe and other files near at the same place as gcc.exe. - If you are on windows Vista, you have to remove uac or at least the "autodetection of application install and ask privilege elevation" because when you use "make install", it calls some executables named "install" and it results in access denied. - I had to put the environment variable PKG_CONFIG_PATH /mingw/lib/pkgconfig in MinGW shell (msys) - To build SDL, there is a howto on SDL website - For SDL_image, the configure / make / make install works well too - after that, the actual configure / make of crossfire gtk2 works well. - And to have personnal config files to be taken, you have to copy executable and "themes" directory on the same place and launch it outside of MinGW shell. - (be sure to configure it in OpenGL if you have hardware OpenGL video driver, or SDL else because the pixmap renderer is as slow as in gtk1 version of cf client) Best Regards, Olivier (findufin & findragon on metalforge) -----Message d'origine----- De : crossfire-bounces at metalforge.org [mailto:crossfire-bounces at metalforge.org] De la part de Nicolas Weeger Envoy? : samedi 21 juillet 2007 10:30 ? : Crossfire Discussion Mailing List Objet : Re: [crossfire] gtk-v2 on MS Windows Hello. > It was really great : slightly faster and cooler than slow (on > Windows) gtk > 1 client. Note that, if you're using the "official" Windows client, it is the GTK1 client built with GTK2. > I recently try to use again crossfire and was quite surprised that > this client is still not on "officials ones", so I did try to compile > actual svn sources and it didn't compile because a new use of > "scandir" function that is not present in MinGW. I did wrote a little > substitute for this with more standard unices functions that are > present in MinGW (opendir / readdir ...). I did bracket this > substitute with "#ifdef WIN32" but that should works on unix os without scandir in the same way. > > --> see that patch in attachment file. > > Now it do compile well and run but is it still a continued client ? As Mark said, Windows support isn't always up to date and lacking. I am (was?) the "official" Windows maintainer, and I've always built everything through MS's Visual Studio. Building the GTK1 client is a real mess, a weird process where you rename randomly files, copy and change names, change functions, and weird things like that. Therefore I didn't really want to try to build the GTK2 client. I also feel, maybe because I don't use it, that it isn't as advanced as the GTK1 client - from my point of view, GTK1 is still the official client ^_- Thanks for the patch, and the remainder :) As a note, I think patches are better on the Sourceforge tracker at http://sourceforge.net/tracker/?group_id=13833&atid=313833 instead of buried in the forum (tracker makes it easier to follow things) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From kbulgrien at worldnet.att.net Sat Jul 21 10:04:53 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 21 Jul 2007 10:04:53 -0500 Subject: [crossfire] GTK2 on Linux (was gtk-v2 on MS Windows) In-Reply-To: <469F0C22.9000407@sonic.net> References: <000301c7c97e$7c215510$7463ff30$@o@free.fr> <469F0C22.9000407@sonic.net> Message-ID: <200707211004.53698.kbulgrien@worldnet.att.net> > Gtk2 client is IMO the most official of the clients - others may disagree. > I'm tempted to spend an evening whipping up a glade configuration file for the > gtk2 client that looks like the gtk1 client, just so it stops any complaints > there - the question then comes how many different glade configs should there be > - it is arguable if those are easier or harder to maintain than different bits > of code. A hearty amen to doing up a Glade configuration for the layout though, if it helps focus attention on one client code base! It seems there is a reasonably big split on the development side. I see that the GTK2 client is becoming true ("most official") from a packager's standpoint. Mandriva is no longer packaging the GTK1 client to my dismay. I do not wish to become (or continue to be) one of the "complainers", but it may take more than a different glade config to stop the complaints. I set about installing the GTK2 client on my son's (KDE) computer to get one running fast as he was bugging me to play - He just turned four, and I figured it would be a good time to try party play with him - and I did, but it left a bad taste in my mouth. Summary: If it is indeed the "most official" client, certain issues should not persist. To that end, as "priority" is being discussed, as much objection as there is to the GTK1 client crowd, I think putting the client work higher on the list is important. I've only worked with Glade one time to try out GUI programming - as I never got into graphical UI development - so the whole thing about trying to fix it myself is pretty intimidating. The client is as subject to feature creep vs. quality improvement work as the server is. Details for whomever might care to know. Screen resolution: His system was using a 13-15" monitor, because that is what I had laying around. I had fired it up once before, and said forget it because the desktop was set 800x600 or so both due to screen size, but also because it is good for learning mouse skills. The GTK2 client is, for any practical purpose, unusable at that resolution. He now has a 17" monitor at 1024 x 768 and I only set that resolution up for the sake of Crossfire. Anyway, I decided to give it another go and it took forever (in a four year old's mind) to play around with stuff to get it acceptable, and even that was only really possible, because he is four and cannot process information that a reader does. Font size / Text cut off. I don't know what determines the GTK2 default font size, but it is so big on his Mandriva system it causes difficulty getting even a little bit of information on a 1024x768 setup. It would be appropriate to have text size changeable somehow. Googling on changing default GTK2 font size hasn't revealed any miracle cures yet without getting some tool that does not appear to be in the distribution. Maybe it can be configured through KDE and I just haven't figured it out yet? Headings Some title headings will not render properly at any setting. I am sure this is not related to the screen resolution as mine is a dual-head 1280x1024 and no matter how wide the client is, the Weight\column title is always cut off. There is no reason for that as the description column is so big, as I test, that it is more than 50% white space. Skills & Experience At 1024x768, it practically impossible to get a Skills & Experience tab that is readable because the text overlaps. Maybe it would work if the right hand colums were microscopic? If I set my client on the 1280x768, dual head system to use one head for the map and the other for the text windows, it works ok, but that is pretty unreasonable for a client size requirement, let alone that the width does not help the troublesome vertical screen constraints on the right hand side of the client. Inventory icons. Non-graphical icons (inventory, and so on) are cut off too at 1024x768 and I haven't yet figured out if there is a scaling/size setting that might fix it. It was better than my configuration when I set it to 100/100, but it will take more fiddling to see if it is fixable. Ok, the basic issues represented here represent a set of technical issues, aside from the comment about the vertical space, that may or may not be in the vein of the layout issues in the client. I think GTK2 changed some default rendering things that affect lower resolution users more than others, but there are also some issues that are hard to think aren't due to design. Enough on that I guess. It sounds too much like a complaint for my liking. Sorry, I guess to to a player, the client is most of what they see, so the flaws, or limitations to fit the client to one's play style, stick out. From kbulgrien at worldnet.att.net Sat Jul 21 16:40:54 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 21 Jul 2007 16:40:54 -0500 Subject: [crossfire] GTK2 on Linux (Truncation of Weight) In-Reply-To: <200707211004.53698.kbulgrien@worldnet.att.net> References: <000301c7c97e$7c215510$7463ff30$@o@free.fr> <469F0C22.9000407@sonic.net> <200707211004.53698.kbulgrien@worldnet.att.net> Message-ID: <200707211640.55057.kbulgrien@worldnet.att.net> > Headings > > Some title headings will not render properly at any setting. I am sure this > is not related to the screen resolution as mine is a dual-head 1280x1024 > and no matter how wide the client is, the Weight\column title is always cut > off. There is no reason for that as the description column is so big, as I > test, that it is more than 50% white space. I would like to make this change in both trunk and branch/1.x. Anyone have a problem with it? It works at 1280x1024 which is what the README says is the target of the design. The commentary can be removed as desired. $ svn diff src/inventory.c Index: src/inventory.c =================================================================== --- src/inventory.c (revision 6798) +++ src/inventory.c (working copy) @@ -321,12 +321,14 @@ column = gtk_tree_view_column_new_with_attributes ("Weight", renderer, "text", LIST_WEIGHT, NULL); - /* 50 is just a guess. However, testing showed that with auto resize, - * the name column for some objects is very long, which causes weight - * column to be pushed off the right edge and not fully visible. Given - * the choice, I'd rather have the name truncated. + /* At 50, the title was always truncated on some systems. 64 is the + * minimum on those systems for it to be possible to avoid truncation + * at all. Truncating the title looks cheesy, especially since heavy + * items (100+) need the width of the field anyway. If weight pushed + * off the edge is a problem, it would be just better to let the user + * resize or find a way to allow rendering with a smaller font. */ - gtk_tree_view_column_set_min_width(column, 50); + gtk_tree_view_column_set_min_width(column, 64); gtk_tree_view_column_set_sizing(column, GTK_TREE_VIEW_COLUMN_FIXED); gtk_tree_view_column_set_sort_column_id(column, LIST_WEIGHT); From kbulgrien at worldnet.att.net Sat Jul 21 23:10:42 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 21 Jul 2007 23:10:42 -0500 Subject: [crossfire] GTK2 Client (Metaserver Dialog RFC) Message-ID: <200707212310.42442.kbulgrien@worldnet.att.net> Since I mumbled about the GTK2 client, and since I had dabbled in the glade designer tool (a long time ago), I thought about digging into the client... I dislike having to mouse to the quit button on the metaserver dialog. I know that alt-f4 will kill the window and app, but that is awkward too. Does anyone care if I add an Escape key as an accelerator for the Quit button on that dialog? This works to close the dialog and application whether or not a server has been selected. To tell people about the feature, I added a tool tip to the Quit button that says: Escape also quits. While working on that dialog, I made some small cosmetic changes. The changes involve add padding to theelements at the bottom of the dialog so that widgets have a small amount of spacing between each other and between the bottom edge of the panel. Also, I prefer to see more of the Server Comment field than having wide column titles. I propose changing "# Players" -> "Players" "Last Update (sec)" -> "Updated (Sec)" I also propose removing "IP Addr" since all entries use the same value as they give for "Hostname". See http://krayvin.home.att.net/metaserver.png for the proposed changes. I made the Glade changes in the Glade Designer. I would like to check in my changes. Is everyone okay with that? Kevin R. Bulgrien From kbulgrien at worldnet.att.net Sat Jul 21 23:36:54 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 21 Jul 2007 23:36:54 -0500 Subject: [crossfire] GTK2 Client Column title patch. Message-ID: <200707212336.55137.kbulgrien@worldnet.att.net> A previous attempt to send this message didn't seem to work for some reason. > Headings > > Some title headings will not render properly at any setting. ?I am sure this > is not related to the screen resolution as mine is a dual-head 1280x1024 > and no matter how wide the client is, the Weight\column title is always cut > off. ?There is no reason for that as the description column is so big, as I > test, that it is more than 50% white space. I would like to make this change in both trunk and branch/1.x. ?Anyone have a problem with it? ?It works at 1280x1024 which is what the README says is the target of the design. The commentary can be removed as desired. A screenshot is at http://krayvin.home.att.net/gtk2client.png - Nnte how the gravestone weights are about the same width as the title after the modification. $ svn diff src/inventory.c Index: src/inventory.c =================================================================== --- src/inventory.c ? ? (revision 6798) +++ src/inventory.c ? ? (working copy) @@ -321,12 +321,14 @@ ? ? ?column = gtk_tree_view_column_new_with_attributes ("Weight", renderer, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"text", LIST_WEIGHT, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?NULL); - ? ?/* 50 is just a guess. ?However, testing showed that with auto resize, - ? ? * the name column for some objects is very long, which causes weight - ? ? * column to be pushed off the right edge and not fully visible. ?Given - ? ? * the choice, I'd rather have the name truncated. + ? ?/* At 50, the title was always truncated on some systems. ?64 is the + ? ? * minimum on those systems for it to be possible to avoid truncation + ? ? * at all. ?Truncating the title looks cheesy, especially since heavy + ? ? * items (100+) need the width of the field anyway. ?If weight pushed + ? ? * off the edge is a problem, it would be just better to let the user + ? ? * resize or find a way to allow rendering with a smaller font. ? ? ? */ - ? ?gtk_tree_view_column_set_min_width(column, 50); + ? ?gtk_tree_view_column_set_min_width(column, 64); ? ? ?gtk_tree_view_column_set_sizing(column, GTK_TREE_VIEW_COLUMN_FIXED); ? ? ?gtk_tree_view_column_set_sort_column_id(column, LIST_WEIGHT); From kbulgrien at worldnet.att.net Sun Jul 22 01:07:12 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 22 Jul 2007 01:07:12 -0500 Subject: [crossfire] GTK2 Client (Metaserver Dialog RFC) In-Reply-To: <200707212310.42442.kbulgrien@worldnet.att.net> References: <200707212310.42442.kbulgrien@worldnet.att.net> Message-ID: <200707220107.13016.kbulgrien@worldnet.att.net> > I dislike having to mouse to the quit button on the metaserver dialog. I know that > alt-f4 will kill the window and app, but that is awkward too. Does anyone care if I add > an Escape key as an accelerator for the Quit button on that dialog? This works to > close the dialog and application whether or not a server has been selected. > > To tell people about the feature, I added a tool tip to the Quit button that says: > > Escape also quits. FYI, the accelerator does not interfere with the Escape function that exits a search for a server when typing in the characters that start the name of a server listed in the dialog. I had thought about using "q" as an accelerator... handy, except that it would likely interfere with searching for a server that begins with a "q", so I nixed that idea. Kevin R. Bulgrien From mwedel at sonic.net Sun Jul 22 01:13:40 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 21 Jul 2007 23:13:40 -0700 Subject: [crossfire] GTK2 Client (Metaserver Dialog RFC) In-Reply-To: <200707212310.42442.kbulgrien@worldnet.att.net> References: <200707212310.42442.kbulgrien@worldnet.att.net> Message-ID: <46A2F594.3020706@sonic.net> Kevin R. Bulgrien wrote: > See http://krayvin.home.att.net/metaserver.png for the proposed changes. I made > the Glade changes in the Glade Designer. > > I would like to check in my changes. Is everyone okay with that? That all looks/sounds fine to me. From mwedel at sonic.net Sun Jul 22 01:15:07 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 21 Jul 2007 23:15:07 -0700 Subject: [crossfire] GTK2 Client Column title patch. In-Reply-To: <200707212336.55137.kbulgrien@worldnet.att.net> References: <200707212336.55137.kbulgrien@worldnet.att.net> Message-ID: <46A2F5EB.70806@sonic.net> Kevin R. Bulgrien wrote: > A previous attempt to send this message didn't seem to work for some > reason. > >> Headings >> >> Some title headings will not render properly at any setting. I am sure this >> is not related to the screen resolution as mine is a dual-head 1280x1024 >> and no matter how wide the client is, the Weight\column title is always cut >> off. There is no reason for that as the description column is so big, as I >> test, that it is more than 50% white space. > > I would like to make this change in both trunk and branch/1.x. Anyone have > a problem with it? It works at 1280x1024 which is what the README says is > the target of the design. The commentary can be removed as desired. > > A screenshot is at http://krayvin.home.att.net/gtk2client.png - Nnte how the > gravestone weights are about the same width as the title after the Looks fine. From mwedel at sonic.net Sun Jul 22 01:47:50 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 21 Jul 2007 23:47:50 -0700 Subject: [crossfire] GTK2 on Linux (was gtk-v2 on MS Windows) In-Reply-To: <200707211004.53698.kbulgrien@worldnet.att.net> References: <000301c7c97e$7c215510$7463ff30$@o@free.fr> <469F0C22.9000407@sonic.net> <200707211004.53698.kbulgrien@worldnet.att.net> Message-ID: <46A2FD96.4040408@sonic.net> Kevin R. Bulgrien wrote: > > His system was using a 13-15" monitor, because that is what I had laying > around. I had fired it up once before, and said forget it because the desktop > was set 800x600 or so both due to screen size, but also because it is good > for learning mouse skills. The GTK2 client is, for any practical purpose, > unusable at that resolution. Which is one reason why there may need to be more than one glade set up. Having a layout that works at both 800x600 and 1280x1024 seems unlikely, but I could be wrong in that (or it may be doable, but then a lot of the layout may not long be in glade, but may actually be coded into the game). > > Font size / Text cut off. > > I don't know what determines the GTK2 default font size, but it is so big on > his Mandriva system it causes difficulty getting even a little bit of > information on a 1024x768 setup. It would be appropriate to have text size > changeable somehow. Googling on changing default GTK2 font size hasn't > revealed any miracle cures yet without getting some tool that does not > appear to be in the distribution. Maybe it can be configured through KDE > and I just haven't figured it out yet? So the client should be using the system default font setting. If you are running KDE (and not gnome), I'm not sure how that all works out - it may be that there isn't any easy way to change that. And system wide can be a bit of a misnomer, because so many applications have their own method to change font size - gnome-terminal, firefox, thunderbird, and others all have their own font selection mechanism built in. However, I can't see any better solution than to use the system wide as a default - any compiled in value is likely to be even more broken. That said, the gtk2 client now has them support, so it should be pretty easy to make up a new theme (say 'LowRes' or something) that is set to use a smaller font size. The default themes are in the gtk-v2/themes directory. there is not any in-client way to adjust these values. I suppose it could be nice to basically have a config window that lets you change all the things in the theme file and save it out as a custom theme, but that is a fair amount of work (there are lots of things that can be set in the theme file). > Skills & Experience > > At 1024x768, it practically impossible to get a Skills & Experience tab that > is readable because the text overlaps. Maybe it would work if the right > hand colums were microscopic? If I set my client on the 1280x768, dual > head system to use one head for the map and the other for the text windows, > it works ok, but that is pretty unreasonable for a client size requirement, let > alone that the width does not help the troublesome vertical screen > constraints on the right hand side of the client. Yes - that has always been a problem area. What would be nice is to have different icons to represent the different skills - right there, that would save quite a bit of space. But upon thinking of this further, even that won't work for everything - especially if new skills are added. I'm not wild about adding a scrollbar for that area either - it lets you see all the skills, but most often there are a few you really care about, and so you'd want to be able to see both of those at the same time. so my latest thought is for there to be a window (under Player/Skills) which shows all the skills in some detail (this could be really useful if different versions of skills are added like some discussions are talking about). In that window, have a few other things, like checkboxes for the skills you want displayed, so you can choose the 8 or 10 or whatever skills you actually care about and show them in the skill area. It might be even nicer to have some method to actually choose the order the skills show up in the main window, but that may be overly complicating things. > > Inventory icons. > > Non-graphical icons (inventory, and so on) are cut off too at 1024x768 and > I haven't yet figured out if there is a scaling/size setting that might fix it. It > was better than my configuration when I set it to 100/100, but it will take > more fiddling to see if it is fixable. I'm not quite sure what you mean by non graphical icons. Are you talking about the icons in the inventory and look lists? Or icons used elsewhere in the client? In either case, I'm not seeing that problem myself. GTK itself is supposed to take care of proper sizing of the inventory/look lists (making sure there is enough space for the icons), so if that isn't happening, it would sound more like a bug in gtk2 than the client. > > Ok, the basic issues represented here represent a set of technical issues, > aside from the comment about the vertical space, that may or may not be > in the vein of the layout issues in the client. I think GTK2 changed some > default rendering things that affect lower resolution users more than > others, but there are also some issues that are hard to think aren't > due to design. Yes - there are differences in the layout elements. The GTK2 client presumes the map area will be wide enough to stat bars and stat information side by side. If you have low vertical resolution, the stacking of the information, inventory, and look on top of each other probably gets too tight. OTOH, the layout of the gtk2 client uses spaces more efficiently if you have high enough resolution - the fact that the gtk1 client puts the stat information above the skill information about the map information which is above the stat bars/protection area means that for a given map size, you need more vertical real-estate to use the client. And if you have that vertical size, then some things like the information pane start to seem excessive big. That one reason I designed the gtk2 client with that minimum resolution - if you had it, things work out pretty good - if you don't, not so well. But when I first did it, at the time it was a bit more to co-exist with the other clients (just like the gtk1 client co-exists with the x11 client). But at this point, supporting 3 different clients with fairly limited code overlap is somewhat burdening. Also, what was probably a mistake is that I kept some of the came bindings in the gtk2 client as previous clients. A fresh thinking about what different mouse buttons do is probably in order. In particular, having left button examing, middle button apply and right button drop with various shift and control modifiers to do special things is hardly intuitive. Left button being examine may make sense - it should probably be whatever action players would need to do most. I'm thinking that right button should bring up a context menu of different options (mark, lock/unlock, drop, examine, apply, whatever else) - I'm not sure what the default for the middle button should be - it seems like being able to drop in a single click is probably desirable (just like pickup is). So maybe left to pickup/drop makes sense, keep middle be apply/unapply, and make right context help would be most consistent. And maybe holding a mouse over an item would cause it to basically do an examine. This is a bit more consistent with other problems. From crossfire at kahnert.de Sun Jul 22 09:23:38 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sun, 22 Jul 2007 16:23:38 +0200 Subject: [crossfire] Priority feature list In-Reply-To: <46A048A3.7040003@sonic.net> Message-ID: <20070722142338.GA12432@cthulhu.desy.de> Sorry to mix up the topic a little bit, but I add a summary at the bottom, like Juha did. Nice idea, should become standard. ;) On Thu, Jul 19, 2007 at 10:31:15PM -0700, Mark Wedel wrote: > Juergen Kahnert wrote: > > No, why should I ever start / solve a quest if the payment is > > worthless for me? I don't want to get useless rubbish as a "reward". > > But you can never completely fix that. It may not be rubbish, but > could still be something of no real value - for example, the girdle > you have is better than the one you just got. Sure, but that's why I prefer the "reorganization of the entire world". As long as the characters aren't able to visit maps with powerful items, quest items can't be surpassed by random items. As long as you follow the storyline, you'll get better and better equipment due to quests. And xp in random dungeons suited for your level. > I think characters should be able to find really nice equipment in > random treasure now and again. This also helps give some incentive > for players to do things like random dungeons, etc. Sure, but the quest items of this region should be always more powerful than the random treasure of the same region. This will only work after the reogranization of the world. Sorry, big deal, but in my opinion, this is the most effective way to make CF more attractive for newbies. > > But Excalibur won't be the quest reward! King Arthur just wants it back. > > So you have give it to King Arthur to receive your quest reward. And > > this won't be Excalibur, isn't it? > > It certainly makes more sense that someone in town may want that > creature killed, and once you kill it and return, will give you > something in return for that task. And that could even be something > like 'You have a choice of 1 of these 3 items...', so the player can > choose the item they want. That's a nice idea, having the choice. This doesn't needs to be the rule, but a good option. :) > This also works well in the "can't repeat a quest" type of thing Which isn't a big deal, but would make the world more consistent and gives other players the chance to do the quest, too. If someone likes the quest reward and always repeats this quest, no other player gets the chance to solve this quest. And in the "reorganized world" this will prevent other players to reach the next region, because of the storyline... So getting a quest reward only once will solve this problem in most of the cases, too. > And this method also works good for parties - it is unclear if a > party should get more reward than a single character doing a quest. To be honest, I've no idea how to make CF work well with parties. Maybe party support could be the topic for CF3, and for CF2 the topic is gameplay / balance. How much parties do you see on servers which will do something else than leveling up lower level character(s) with a high level character? Step one (CF2), increase gameplay. Make CF more attractive and allure more players. More active players will offer a better base for parties. Step two (CF3), increase party support. Maybe we can have quests for parties, only solvable with a party. And for such a quest every member of the party will get a reward. Otherwise it's a quest for a single hero; the reward won't change regardless of the number of characters. For example, the king offers 1000 platinum for the head of the goblin chief. The one who brings the head to the king will get 1000 platinum, that's it. If this dude required 5 mates to get the head, fine, but the king won't pay more. He don't care how they split the bounty. But he would never ever pay 6 * 1000 platinum. > > > but I personally like the idea of making more race-specific items; > > > add body parts like "dragon tail" and "fireborn tentacle" to the > > > races and create objects that consume these. > > > > I like that idea, too. :) > > It's an implementation detail, but I'd rather there be some certain > tags in objects for race/class/god allowability than to use the body > part stuff. Even better. :) > And it goes beyond that - taking from other games, you often have > things like armor or swords that can only be used by certain races - > adding things like 'dwarf_arm' to use a weapon gets weird, or > 'elven_body'. And that can lead to more complication, like people > wearing two suits of armor, etc. And more complications for having e.g. a large club one handed for a troll, but two handed for humans and unusable for dwarves. > Just a note - looking at metalfore, only 2 characters have reached > the high score/level limit. And I suspect even without retuning the > exp table, if we re-adjust other factors (and fix bugs) it may not be > possible to do that again with CF2. Yes, that may be right. And yes, not technically important. Anyways, it's just about the feeling. I don't like to encounter monsters with a higher level than I have without the theoretically chance to reach this level. And... if someone ever managed to reach the max xp, what's next? Those two with level 115 stopped playing or playing different characters, right? And, I personally don't like the extreme xp gap between the last few levels. What about a xp table which makes level 100 as hard to reach as now level 115, but calculate the table up to level 150 or 200? And don't give monsters a higher level then this maximum. Again, just for the feeling and motivation, not that I expect to see people reaching level 100 (in CF2) or even higher... > So yes, you have a cap, but if it no one ever gets to it, is it > really a cap? No, it's not. But don't make monsters getting a higher level than the maximum of the xp table. > Some new spells are certainly needed, and a redistribution of > existing spells (more to cover the broader level range) is also > needed. There are very few spells above level 20 right now, dating > back to when there were not that many levels. If we say that 100 > levels is the range we aim for, then there should be a few level 90 > and 100 spells. If we reorganize the entire world to make regions for certain levels, we just add the ones necessary to survive this region. This also leaves room for extensions than spreading all the spells to 100 levels. > >> Fifth, at high levels, spells are useless. It's almost always easier > >> and more effective to simply karate chop or weapon slash everything > >> you bump into. > > > > Not only on high levels, especially for low levels. > > I'd disagree with that - I've found spells very useful at high > levels. If you have the mana, and a large room full of monsters, > blasting the room with spells is often a safer and faster method of > killing them all than running about with a weapon. I disagree with you. High level spells are useful against a room full with low level monsters, yes. But spells are totally useless against lot of high level monsters. Having a hard start as a mage turns up into an impossible mission on higher levels. That's not fair. If it's hard in the beginning, it should become easier later on, not harder or impossible... > A lot of monsters have really high protection to magic and other > attacks - basically they were designed in a sense so that the only way > to kill them was with melee. That isn't the correct approach - if > players are clever and can hit monsters with spells from a distance, > that shouldn't be punished. That has nothing to do with being clever or not. If we enforce more class like playing, our magic classes will be stuck if this won't be fixed. > > If you rebalance the combat / spells / speed system, you need to > > check every single map if it still works. If not you have to change > > the map. And if this backfitting starts, I would like to remind to > > the "reorganizing the entire world" thread: > > I see no basis on that assertion - that is almost like saying that > if I add a new weapon, I need to check every map to make sure they > still work. You can't heavily change the system and hope everything will work fine. Changing the combat / spells / speed system is totally different than adding a new weapon. For example, you like to remove generators, but you don't like to see if old maps still work? Reorganizing the entire world will fix that issue, too. > Some maps may become considerably harder - probably not a bad thing. > I'd also say that the proper check would be to play every map and see > how it plays - you probably would learn virtually nothing looking at > the maps in an editor - you'd have to play it to see how hard it is > now. I would like to have "standard character archetypes" for testing the maps. For example, logging in as "human_warrior_level10_Siegfried" will create a human warrior on level 10 named 'Siegfried' with typical equipment for this kind of character. Such a character won't gain xp, it's just for testing maps on servers with STD_CHAR_ARCHETYPES set. Something like that. And I would like to see something similar for monsters. It should be enough if a map designer adds a goblin level 10, to get a much stronger goblin; same for every other monster. This method could also be used for random maps, where the monster level is inreased for every new dungeon level. > I think I've stated it previously, but IMO, the effort needed to > redo the entire world could better be spent elsewhere. And I think, the time can't be spent any better. > I'd like to see a lot more new maps/quests/etc, and those should be > arranged so that it makes sense (put the tough maps in areas that > already have tough maps,etc) That will be part of the reorganization, yes. > > Quest rewards should be deterministic, but race / class specific. > > Problem then is how many combos do you get if you do race * class Yes, doing that right is could be hard. But you don't need to permute race with class. Just avoid obvious combos like armour for fireborns, weapon for monks, boots for serpentman, ... Ok, still hard to manage, because followers of gaea, ruggilli, ... and any other restriction (no fire spells for wraith, ...) needs to be checked as well. But it doesn't needs to be checked for every quest reward. I think rods should be really rare random treasure, and than they're a nice payments for the quest heros. And having more (not all!) quest given out by the guild masters, you don't have to care much about the class, just the race. > But the idea of there being some number of deterministic rewards that > you can choose from works really well IMO. Sure, it may not be > especially realstic that people would end up having 4 different things > they could give you. Why should it be unrealistic? I think this is a usual trade. If you give me A, what do you like in exchange for it out of B, C, D, E? I don't have a problem with that. And having guild masters giving out class specific stuff, using more generic things like rods, horns, ... as a quest reward and NPC offering different items will work well in combination. > But you get into the general problem of how do you explain things in a > world where a map resets? I don't need to explain it. It's a multi player computer game. We need such things, see: http://mailman.metalforge.org/pipermail/crossfire/2007-June/011535.html > > > IMO, pretty much every generator could be removed from the game and > > > it would probably make things better. > > > > Yes, or make them run out of monsters. And hidden. Or how do you > > explain a "monster generator" in the real world? ;-) > > of course, crossfire isn't the real world. See, you don't need to explain some things, either. ;-p And for the generators, see above, we need to check the maps and fix it. I see this as a part of the reorganization (sorry for repeating me that often, but I really think this is a very important part). > If you want the room full of monsters, start the dungeon with the > room full of monsters - don't rely on generators to fill it up. What about charm monsters? You enter a room, charm all monsters, and it's over. Monsters "inside" of generators don't become charmed. I think, generators aren't bad at all, just needs to be handled different. But especially not that often as right now. On Fri, Jul 20, 2007 at 12:53:19PM +0300, Juha J?ykk? wrote: > > But Excalibur won't be the quest reward! King Arthur just wants it > > back. So you have give it to King Arthur to receive your quest > > reward. And this won't be Excalibur, isn't it? > > What if King Arthur has been dead for little over a millennium? He > won't be giving out the quest nor the reward; the evil lich (all > powerful villains always seem to be lichs or wizards...) has simply > kept Excalibur as a trophy over his fireplace (or, his being a lich, > should that be an ice-cube pool?). In that case Excalibur would be the > reward, *every* time, even for the monk. I do not see this as a bad > thing - at least not when it is known beforehand that the reward will > be useless *and* when this type of quest is a vanishing minority. If the choice is, not having a quest or having a quest with an uninspired story, ok, than I'll take this quest with a sword as a reward even for monks. But I think it's always possible to create a quest with a better story to avoid such situations. I really don't like to get a sword as a reward if I'm playing monk, dragon, fireborn, gaea priest or whatever. Re: race specific items > Second, it helps balance things: consider a fireborn, who can wear 7 > items (4 rings, 2 amulets and a cloak) Your fireborn is able to wear a cloak? The fireborn definition is this one: body_range 1 body_neck 2 body_skill 1 body_finger 4 That's it, nothing else than four rings and two amulets. > and a human, who can wear 11 items 12, you've forgotten "legs". But so far there are no items using this slot. > To keep things balanced, the 7 items a fireborn can wear *and* its > race-abilities must equal in power the 11 items a human can wear. 6 items vs. 12 items; not 7 vs. 11. Having a single fireborn race-slot for an item which needs to be as powerful as 6 human body part items makes this item very powerful, too much. But it's a good start. > > http://mailman.metalforge.org/pipermail/crossfire/2007-July/011596.html > > Your idea seems good, but perhaps a little confusing to beginners The beginner don't need to know how the computer calculates stuff. It's not a pen & paper RPG, the players don't even know the rules of how things are calculated. > (and we need to be attractive to beginners to get more players). That's the main reason why I want to reorganize the entire world... > I'm sure, though, that it can be refined to a non-confusing system. What's confusing. Skills keeps their levels as right now. Everyone playing RPGs realized how this works. And the "capability value" of the skill is just used by the server. The player only sees the grade of the skill as something of this: "Unskilled", "Novice", "Apprentice", "Amateur", "Adept", "Expert", "Master" or "Grand Master". Only "perceive self" will give the player detailed informations about the skills. And that a skill with a grade of "Expert" is better than one with "Novice" can't be called confusing, right? > I particularly like the idea of guild memberships as a requirement of > high capability level of skill X ,though I never figured out why the > "skill level" exists in your system at all. The "skill level" is just used as right now. For example, you need to be level 5 in sorcery to learn steambolt. And [new] as a measurement for the guild membership. > One point of stat-caps needs to be made here: I did not mean I am > against fixed *natural* stat limits, they are ok. I'd say they are > adamant. With natural stat limits, the absolute stat limit follows > from the amount of bonuses you can equip simultaneously. I do not feel > there is a need to separately limit this magically adjusted maximum. Same for me, see: http://mailman.metalforge.org/pipermail/crossfire/2007-July/011612.html > That said, I *do* favour the idea of fixing limits on the maximum > bonuses items can bring about. There was also a discussion about setting levels to items. For example for the high enchanted sword you need at least level 30 in one handed weapons to equip it. > Sword with Str +10 is too powerful, unless it has item power ~100. Item power in combination with a level on items could do the job. Maybe even without item power. But a maximum bonus is still reasonable. Don't make it obvious, but improvements exorbitant expensive and a rampant item power. And we need a review for new maps. Something like That is girdle of Valriel of the Crusade (Str+3)(Dex+3)(Con+3)(Wis+5)(Cha+2)(ac+2)(item_power +1)(grace+3) shouldn't be allowed, especially not with IP 1. :-O Things like that should be fixed during the reorganization of the world. > At this point, I'll advance another idea I have, which is a major > change: alchemy. Alchemy is very funny, but needs lot of changes, too. If we like to keep an alchemist as a class, we need to make sure that an alchemist is playable as an alchemist. For example, an alchemist likes to make some potions of fire (firebolt) to kill hill giants. Hill giants takes more than one firebolt before they die. Besides that potions are really heavy if carried on mass, our alchemist needs to find for each potion of fire a fire para-elemental's residue and has to pay 3 rubies for the water of ruby. In fact, an alchemist is unplayable. Same for all the other creation skills. The formulas needs reviews, too. Very common things like firebolt shouldn't be made out of very rare parts. I would like to see a formula for almost every item in CF. Who made those stuff if it can't be made? ;) Your idea is nice and we should keep that in mind. But it's not on my priority list. Highest priority is to make this game more attractive for newbies. After that we can tune expert skills like alchemy and the corresponding class alchemist. Until that I would remove this class and keep alchemy as is. > > That's why I've no idea why "fireborns with meteor swarm" is an > > issue for game balance... > > I do not either, but it is probably because anyone else carelessly > using meteor swarm will die of the *fire* damage *themselves*, > fireborns won't. As I said, meteor swarm is doing weapon magic damage, not fire damage. And no character race / class is immune to weapon magic nor get the chance to increase the resistance against weapon magic. Visit hanuk as a fireborn and see what happens... > Low level fireballs are effective against orcs etc. As long as there aren't to much of them and you've enough place to run away, yes. Still there is a problem with the loot (burns away). But ok, the orcs are gone. If there are some more, you won't be able to blast them away, because your sp runs out and you won't regenerate fast enough. Try to clear beginners with a lvl 1 fireborn sorcerer (magic only, no melee, not as a monk - no meditation) and the same with a troll warrior (melee only, no magic). > At low level, orcs are still able to kill you, so you'd better watch > it - blasting fireballs from way off is a good way to be careful. If you have luck and you got small fireball with pyromancy skill. If not, you may start with detect magic or slow. And now? How to play a sorcerer unwilling / unable to do melee? > At ~60th level, my fireborn monk is unable to kill a greater daemon > with spells (there are situations and tactics which make the statement > untrue, but karate is still faster), but he can easily karate chop it. That's what I say. Hard beginning as a mage, no reward on higher levels; just harder to impossible... > > Ever tried to play a sorcerer without using physical attack skills? You > > won't be able to kill some monsters because they regenerate their hp > > faster than you sp. A dragon player just run through them like they're > > Fireborn sorcerer, no problem, thanks to Attuned: fire and burning hands. Prove it. Try it out, feel the difference. Again, not playing a monk, playing a sorcerer! > Non-fireborns, however, *do* have the sp regen problem. Also fireborns (without meditation). Try it. > But even a 108th level spellcaster, who regenerates 1 sp *each* *tick* > cannot kill certain monsters with spells - and this is where the real > problem lies. Yes, hard beginning, harder to impossible later on. > > "reorganizing the entire world" thread: > > http://mailman.metalforge.org/pipermail/crossfire/2007-June/011532.html > > I have read that and I dislike the idea of segregating players of > different levels. Much better would be warning signs immediately after > entering a dungeon - or the "magic mouth" -kind of warning someone > suggested: "You get the feeling this dungeon is extremely dangerous/very > easy". What about a skill "sixth sense"? http://mailman.metalforge.org/pipermail/crossfire/2007-June/011536.html > Of course, high level players repeatedly cleansing low-level > dungeons for various reasons is a problem. This won't happen with the reorganization of the world, segregating maps (not players, but will be more or less the same) of different levels. I know Mark don't like this idea, because it's lots of work. But you just said, you disklike it. What are your reasons? Having regions for the same level will increase the fun for the players. I saw so much newbies unable to find suitable dungeons. Some got their fun spoiled by high level characters boosting them ten or more levels by a short party at a high level map. I think xp sharing in a party is very bad and should be disabled. Anyway, having a storyline quest in a region best suited for the level of a character, leading through the maps of this region and increasing their xp step by step without overextending their abilities and without underchallenge them, will be (from my point of view) a great improvement. What's the problem of that, except of the work? > That should be pointless. If you can go kill dragons with impunity and > get 100000 gold from each one's hoard, there is no point harvesting > the few dozen silver you get from newbie tower. If you can kill dragons with impunity, you're to strong for this kind of maps. Move on to the next region and leave this maps to lower level characters! And did you never saw a character above level 100 harvesting in raffle1? Zebulon for example cleared all the generators at raffle1 over and over again. Or other high level characters, not being a bot? They're all wrong there, move them to regions where they can find items for their level, not disturbing newbies on low level maps. > Also, gearing towards D&D 3rd edition -type XP system might help. In > the mentioned system, a 20th level fighter killing a kobold gets no XP > what so ever. This may help, I thought about it, too. Won't be hard to implement it into a computer based role playing game. So far I thought it's enough to have bigger xp gaps the higher the level gets. But that's wrong. As I said above, high level characters are still clearing low level maps. Why? Because the skill level counts, not the overall level. Giving xp relative to the overall level regardless of the skill, will help a lot. The more I think about it, the more I like that. :) This also forces more class like role playing. If a warrior trains magic skills, this warrior won't get as much xp in melee skills any more because of the higher overall level. Keep your role and you won't be punished. ;-P > Ok, now the summary As I said above, nice one. Should be standard. :) ========================================================================= Everyone agrees to have a high priority improving gameplay / balance. I would make this as _the_ main priority for CF2. Here's my preliminary priority list: 1) Reorganization of the world will do most of the gameplay improvement especially for newbies but also for veterans. But so far no majority for this idea. Changing rewards of quests is accepted. Also some less drastic changes like adding a newbie island. Changing maps with generators, maybe even remove all generator, was discussed, too. I would coordinate this reorganization, write quest stories, test the maps with different characters, bring in lots of ideas... I would even start the map editor to modify existing maps, but I won't create new maps. I have other skills than making nice looking maps. So we need some more map makers willing to help at this task. Teamwork is the key. There are people being able to make nice looking maps but they may lack on ideas. Others having ideas, but no skill for map making. Others neither of both, but likes to test the maps with all kind of race / class combinations, ... 2) Rebalance races is widely accepted. Adding more race specific items. Also having the attributes more distinctive between different races. 3) Using class guilds instead of the class system right now is approved by most of the panelists. Making classes distinctive and enforce more class role playing. Rebalance classes, spells, etc. 4) Maximum level should be something around level 100. Maybe as a hard cap or make higher levels theoretically reachable, but practically not. The maximum level shouldn't be reached by any player at any time. 5) Skills should get different "versions". Some discussants prefer some kind of "bad" or "good" versions of a skill. For example "Novice", "Expert", "Master", ... grade. Priority is set on newbies, on a coherent system and on a logical world. J?rgen From mwedel at sonic.net Sun Jul 22 23:37:44 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 22 Jul 2007 21:37:44 -0700 Subject: [crossfire] Priority feature list In-Reply-To: <20070722142338.GA12432@cthulhu.desy.de> References: <20070722142338.GA12432@cthulhu.desy.de> Message-ID: <46A43098.2000101@sonic.net> Juergen Kahnert wrote: >> And this method also works good for parties - it is unclear if a >> party should get more reward than a single character doing a quest. > > To be honest, I've no idea how to make CF work well with parties. Maybe > party support could be the topic for CF3, and for CF2 the topic is > gameplay / balance. > > How much parties do you see on servers which will do something else than > leveling up lower level character(s) with a high level character? > > Step one (CF2), increase gameplay. Make CF more attractive and allure > more players. More active players will offer a better base for parties. > Step two (CF3), increase party support. I consider this sort of a chicken and egg party - people may not use parties often because there is not much reason to form parties. There are probably several reasons why parties are not heavily used - lack of race/class distinction means everyone is a spell caster or fighter or whatever, so you don't have to worry about trying to balance out the party. Combat happens so fast right now that it is difficult to really coordinate anything. I'm sure there are others. At least on the two specific points I mention, there have already been discussions about changing those about. So I'm very reluctant to say we don't need to worry about party support - I'd be really bad to not think about that at all, and then after we make other changes, be in a situation where lots of players want party support which has been removed, or at least not improved upon. I'd also think that while some things perhaps get deferred to later releases, we should at least keep those features in mind, and not make changes that are counter to those longer term goals. It would be counter productive to not do any sort of party support for CF2, and then when we do CF3, have to redo all the maps/quests because of that. We should at least have some sort of idea of how parties should work and how they work with quests. It may very well be that it is too complicated to do for CF2. It may also very well be that it isn't very complicated, and thus could be done. But before saying it won't be done, we should at least have an understanding. Max levels of monsters: The problem here is feature (or monster toughness) creep. It is easy enough to say 'max level for any monster should be 100'. The problem is that if you have characters that are level 150, they will start saying 'where is the challenge, what is left to do - I can kill any monster easily, etc'. So someone decides to fix this and make level 150 monsters, etc. This is what has happened before, and this is why a level limit is needed. As said before, it may be that the limit is purely practical - there is in fact no limit, but the exp gains are such that levels are effectively limited. If players say 'The exp gain above level 100 is way too high', simple response would be you either do that, or we put in a hard level cap - take your choice. High level players doing low level maps: Is this really a problem? I never do it because it isn't worth while - the exp gain isn't there, nor are there good items. the only exception I can really think here is the dragon character - the number of maps that have suitable creatures to generate proper flesh for dragons is limited - as such, they are much more likely to repeat certain dungeons. I personally don't think the exp system (as far as killing monstes go) really needs a major redo - at one time in the past, difference in level was taken into account, but that caused other problems - if a low level character was able to kill a tough monster, they got lots more exp. With various special items and specific race/class attributes, this became more likely. Also, the crossfire exp table is almost an exponential system, where as AD&Dv3 is more linear (the exp needed for level 20 is 10 times that of level 2). So adding this extra adjustment really just amounts to extra penalty/bonus. The other reason this adjustment of exp was removed is that it actually makes it more difficult to set up exp rewards. You can basically say 'this dungeon is worth 80,000 exp, no matter what the level.' Maybe for the level you designed it for, that amounts to half a level. If a lower level character is able to complete it, maybe it is a full level, but more power to them From nicolas.weeger at laposte.net Mon Jul 23 12:22:49 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 23 Jul 2007 19:22:49 +0200 Subject: [crossfire] Priority feature list In-Reply-To: <20070722142338.GA12432@cthulhu.desy.de> References: <20070722142338.GA12432@cthulhu.desy.de> Message-ID: <200707231922.53212.nicolas.weeger@laposte.net> > To be honest, I've no idea how to make CF work well with parties. Maybe > party support could be the topic for CF3, and for CF2 the topic is > gameplay / balance. > > How much parties do you see on servers which will do something else than > leveling up lower level character(s) with a high level character? > > Step one (CF2), increase gameplay. Make CF more attractive and allure > more players. More active players will offer a better base for parties. > Step two (CF3), increase party support. > > > Maybe we can have quests for parties, only solvable with a party. And > for such a quest every member of the party will get a reward. Otherwise > it's a quest for a single hero; the reward won't change regardless of > the number of characters. > > For example, the king offers 1000 platinum for the head of the goblin > chief. The one who brings the head to the king will get 1000 platinum, > that's it. If this dude required 5 mates to get the head, fine, but the > king won't pay more. He don't care how they split the bounty. But he > would never ever pay 6 * 1000 platinum. Totally revamp parties. Like party spells, places you can only go at 3 or 4 players. Monsters you can only defeat with some combo that only 2 players can achieve. And so on. Else how can CF be a "multiplayer" game? :) > > Just a note - looking at metalfore, only 2 characters have reached > > the high score/level limit. And I suspect even without retuning the > > exp table, if we re-adjust other factors (and fix bugs) it may not be > > possible to do that again with CF2. > > Yes, that may be right. And yes, not technically important. Anyways, > it's just about the feeling. I don't like to encounter monsters with a > higher level than I have without the theoretically chance to reach this > level. And... if someone ever managed to reach the max xp, what's next? > Those two with level 115 stopped playing or playing different characters, > right? Different players have different ideas of the game. IMO we should keep the current exp system, maybe rebalance exp gaps, but keep the 115 limit. And, on the other, keep expanding content. Content, you know, something we always forget :) (this is not meant to be insulting) Also add player interaction, enable players to (gasp) role-play (open a shop? purify themselves to be able to enter a monastery) > No, it's not. But don't make monsters getting a higher level than the > maximum of the xp table. Sure we should. High level (150) monsters you can only kill with 4 100+ level players. > > Some new spells are certainly needed, and a redistribution of > > existing spells (more to cover the broader level range) is also > > needed. There are very few spells above level 20 right now, dating > > back to when there were not that many levels. If we say that 100 > > levels is the range we aim for, then there should be a few level 90 > > and 100 spells. > > If we reorganize the entire world to make regions for certain levels, we > just add the ones necessary to survive this region. > > This also leaves room for extensions than spreading all the spells to > 100 levels. Trash the multiple versions of spells. "small fireball, "medium fireball", "large fireball" sound fun, but let's not multipliate spells :) Suggestion: have the "medium" replace the "small", assuming the cost/dam ratio is equivalent. As a weird example: small healing is much faster to cast than major healing, so you can possibly use the first all the time instead of the second. > Having a hard start as a mage turns up into an impossible mission on > higher levels. That's not fair. If it's hard in the beginning, it > should become easier later on, not harder or impossible... Too many high level places have "no magic", too. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070723/7d26778e/attachment.pgp From crossfire at kahnert.de Mon Jul 23 14:42:04 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Mon, 23 Jul 2007 21:42:04 +0200 Subject: [crossfire] Party Support (was: Priority feature list) Message-ID: <20070723194204.GA18282@cthulhu.desy.de> On Sun, Jul 22, 2007 at 09:37:44PM -0700, Mark Wedel wrote: > I consider this sort of a chicken and egg party - people may not use > parties often because there is not much reason to form parties. The only reason I know for a CF party is, to level up a lower level character. And regardless of the party support of CF, I would remove the xp sharing for killing monsters. > There are probably several reasons why parties are not heavily used - > lack of race/class distinction means everyone is a spell caster or > fighter or whatever, so you don't have to worry about trying to > balance out the party. We like to change that, right? Not primary for better party support, but for the race / class distinction. > Combat happens so fast right now that it is difficult to really > coordinate anything. There are also voices for speed reduction. > I'm sure there are others. There are a lot of other reasons and so far no real solution for all of them. > So I'm very reluctant to say we don't need to worry about party > support - I'd be really bad to not think about that at all, and then > after we make other changes, be in a situation where lots of players > want party support which has been removed, or at least not improved > upon. > > I'd also think that while some things perhaps get deferred to later > releases, we should at least keep those features in mind, and not make > changes that are counter to those longer term goals. It would be > counter productive to not do any sort of party support for CF2, and > then when we do CF3, have to redo all the maps/quests because of that. Yes, you're right. Let us talk about party support on 2D tiled maps. We need to know how to make it to be open for later extensions. > We should at least have some sort of idea of how parties should work > and how they work with quests. First of all, the list of problems with parties right now: 1) very fast combat, no time for group tactics 2) no assistant spells for parties (group healing, ...) 3) no overview of the status bar of party members (How could a healer know who needs healing?) 4) party members often blocks the way (either the movement or the target line) 5) no maps / quests for parties => CF is aimed to be a single player RPG in a multi player world. And now, what's necessary to solve this problems to have a working party support. 1) Slow down combat speed. Some player just won't like that, especially no slower movement. So the only chance for that is to reduce weapon speed. May work. But on a 2D tiled map with fast moving monsters you could quickly run out of escape routes. Slower movement will help, too. But I think no majority for a general slowdown. 2) There are simply no spells for party support. Most support spells are self directed or combat spells. Nothing special for the party. Protection spells, bless, healing, ... all of them needs a "party version". This shouldn't be that hard to implement. The easiest part of all. :) Besides that, you have to take away all the supporting spells and offer them just for special classes. Who needs a healer if everybody has a binding for "apply rod of heal" / "invoke restoration"? But if you don't allow everybody to heal themselves, CF will totally change and needs parties. Nobody used to play CF like this. So you have to replace the players, too. 3) If you have spells as pointed out at 2), you have to know to cast which spell on whom. For example, as long as a healer don't know who needs help, he can't heal that member... Same for protection spells. Whoms fire protection is running out? Or any other of this spell class. All without chatting or who has time in front of a big monster to ask for a healing? 3D RPGs usually display the status of the party members above the character. This works in a high resolution 3D world, but not on a low resolution 2D one. Having an extra windows with party members and their stats will give you an overview, but you don't necessarily know where "Bob" is who needs to be healed. You just know that "Bob" should be healed... 4) And now the biggest problem for a 2D tiled map game. How do you avoid that party members blocks your way? For the movement, you can do something like made with pet monsters. You just move "into" them and change the positions. This may lead into some confusion, but should be better than dying because of a sleepy member... Anyway, not nice. For example I cast a spell and someone runs "through" me so I change the position and I may miss the monster but hit the wall. I won't like that. How do 3D RPGs solve this problem. Easy, you just click on the monster you like to hit. If someone pushes me aside, I won't miss the monster. What about characters in the second row like archers or spellcasters? How do they hit the monster, if warriors do direct melee combat? How do they hit the monster without hurting the warrior? Or if the archer stands on coordinates (0;0) and the monster on (2;1)? Which direction key do you have to press for that? You can hit monsters on (2;0), (2;2) and (0;2), but not on (2;1) or (1;2). And this is just for a 3x3 square... I've no idea how to solve this. After you solved all this problems without changing the game that much that most of the current players still likes to play CF, you can work on point: 5) Create party quests. In the past year there was some discussions about this issue. Not much, most of the discussion was questions how to make it. And a few ideas like giving xp as a reward to all party members who really made the quest instead of joining short before it ends. Or how to give out items to the party members as a reward. Something like that, but without a better party support (see above) party-quest-maps aren't really playable and thus not important. Maybe point 2 can be fixed partially with party maps. But for example raffle2_u2 isn't really popular. Ok, it's not really a teamplay map, because both players are split and need to play their side alone. It's just a map where two player needs to be in at the same time. My suggestion is, CF is a 2D RPG and because of that, party support is very limited. That's it. Fine for me. J?rgen From crossfire at kahnert.de Mon Jul 23 15:24:07 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Mon, 23 Jul 2007 22:24:07 +0200 Subject: [crossfire] xp gaining (was: Priority feature list) In-Reply-To: <46A43098.2000101@sonic.net> Message-ID: <20070723202407.GB18282@cthulhu.desy.de> On Sun, Jul 22, 2007 at 09:37:44PM -0700, Mark Wedel wrote: > Max levels of monsters: > The problem here is feature (or monster toughness) creep. It is easy > enough to say 'max level for any monster should be 100'. The problem > is that if you have characters that are level 150, they will start > saying 'where is the challenge, what is left to do - I can kill any > monster easily, etc'. The level 100 should be practically / nearly impossible to reach. So having level 150 characters is unlikely. Anyway, if we get such high level characters which may be bored, we just add a new region for this level. > So someone decides to fix this and make level 150 monsters, etc. This > is what has happened before, and this is why a level limit is needed. And player won't become bored if they hit the maximum level? I don't think so. You like to solve the boredom of a level 150 character slaying level 100 monsters with a (50 level earlier beginning) boredom after hitting level limit at level 100? I don't get your point, why a hard cap is needed. > As said before, it may be that the limit is purely practical - there > is in fact no limit, but the exp gains are such that levels are > effectively limited. If players say 'The exp gain above level 100 is > way too high', simple response would be you either do that, or we put > in a hard level cap - take your choice. I choose to let it extensible. No level limit and if players reach the last region with nothing more to explore, we need to add a new region with new and stronger monsters. > High level players doing low level maps: > Is this really a problem? Yes, it is. > I never do it because it isn't worth while - the exp gain isn't there, > nor are there good items. A high level dragon with clawing level 100 decides to level up sorcery will block a low level map for a very long time until the sorcery skill is on a desired level. > the only exception I can really think here is the dragon character - > the number of maps that have suitable creatures to generate proper > flesh for dragons is limited - as such, they are much more likely to > repeat certain dungeons. There are a lot of exceptions. Because of the missing storyline a lot of players just don't know where to go. They do the same [known] maps over and over again. And the high level experienced players just take the maps where to get most xp and / or treasure. And than this map is blocked by a few players over and over again. > I personally don't think the exp system (as far as killing monstes go) > really needs a major redo - at one time in the past, difference in > level was taken into account, but that caused other problems - if a > low level character was able to kill a tough monster, they got lots > more exp. Just reduce the xp gained by a monster if you're higher. Don't give out more xp if you killed a monster on a lower level. The monster xp is the maximum you can get from it. > With various special items and specific race/class attributes, this > became more likely. Fix that. Don't make high level items equipable for low level characters. > Also, the crossfire exp table is almost an exponential system, where > as AD&Dv3 is more linear (the exp needed for level 20 is 10 times that > of level 2). So adding this extra adjustment really just amounts to > extra penalty/bonus. Making level 100 as hard to reach as level 115 is right now, won't make level 101 characters more likely even if the xp table is more linear. > The other reason this adjustment of exp was removed is that it > actually makes it more difficult to set up exp rewards. Do we have xp rewards? Where? How do they look like? Which skill would get the xp? The xp reward is nice for pen & paper RPGs with just an overall level. But why do you like to use it if you have levels on skills which raises if you use them? On Mon, Jul 23, 2007 at 07:22:49PM +0200, Nicolas Weeger wrote: > > Anyways, it's just about the feeling. I don't like to encounter > > monsters with a higher level than I have without the theoretically > > chance to reach this level. And... if someone ever managed to reach > > the max xp, what's next? Those two with level 115 stopped playing > > or playing different characters, right? > > Different players have different ideas of the game. > IMO we should keep the current exp system, maybe rebalance exp gaps, > but keep the 115 limit. The level number doesn't matter. Keep this maximum xp value for the aimed highest level, if 100, 115, 150 or whatever. But rebalance the gaps, make it more linear. > And, on the other, keep expanding content. Content, you know, > something we always forget :) > (this is not meant to be insulting) As I said, if the player reach the aimed highest level, it's time to extend the world. Add a new higher level region. A level cap is no solution. > > No, it's not. But don't make monsters getting a higher level than > > the maximum of the xp table. > > Sure we should. High level (150) monsters you can only kill with 4 > 100+ level players. No, we shouldn't. ;) Just extend the xp table up to level 150, even if the players never ever reach level 100. There is technically no difference, but still leave room for extensions. J?rgen From juolja at utu.fi Mon Jul 23 17:10:57 2007 From: juolja at utu.fi (Juha =?UTF-8?B?SsOkeWtrw6Q=?=) Date: Tue, 24 Jul 2007 01:10:57 +0300 Subject: [crossfire] xp gaining (was: Priority feature list) In-Reply-To: <20070723202407.GB18282@cthulhu.desy.de> References: <46A43098.2000101@sonic.net> <20070723202407.GB18282@cthulhu.desy.de> Message-ID: <20070724011057.0b8e9ca2@alnitak.stiff.utu.fi> Hm.. I still have a lengthy message from Sunday not replied to, but I'll chime in on this one first... > > The problem here is feature (or monster toughness) creep. It is easy > > enough to say 'max level for any monster should be 100'. The problem > The level 100 should be practically / nearly impossible to reach. So > having level 150 characters is unlikely. I think this is a problem any way you put it. With hard cap, players get bored when they hit the cap and the character can no longer improve. With impossible-to-reach maximum level, there is a gap *below* the hard cap: if level 100 is "impossible" to reach, it simply means level 99 is the cap! And players still get bored when their characters no longer advance. So even without a hard cap, just impossibly difficult-to-reach levels, people will get bored exactly like they would with a hard cap. I am not quite sure just adding new regions and monsters will help here since the character advancement has ceased. If there is no gain from doing quests, why do them? Even if you get some new fancy thingy as a reward, it probably is not enough to motivate players when that is the only thing to gain. Increasing levels, perhaps even by adding new areas to the map or whatever, is probably the only way around this problem. Another would be if the capped characters would be able to advance in some other way: in pen-and-paper RPG's people often start building their own kingdoms etc. Although I have no idea how THAT would work in cf. But it definitely is fun. > A high level dragon with clawing level 100 decides to level up sorcery > will block a low level map for a very long time until the sorcery skill > is on a desired level. Immediately after reading this, I got a great idea (at least I think it is great): make the skills more like D&D 3rd ed. skills (or what do they call them nowadays? They used to be called proficiencies back in AD&D). They've spent a lot of time thinking about those and they definitely have got it done pretty well. This is how the skills *could* work: Every player race *and class* gets some starting skills, like they do now. After gaining enough experience to get to level N, they get to improve *those* skills that they most used (say, M skills, no more) between reaching levels N-1 and N, but only those skills. This way there would not be an issue of 50th level dragon leveling his first levels of sorcery in a newbie map, because the dragon would *never* get enough xp for sorcery in that manner to make sorcery one of the skills he improves when reaching 51st level. (Note that if M above is too big, this is untrue; for M=1 and possibly some other low numbers as well, this statement holds.) This has the added benefit of making classes matter! It would no more be practically possible to have all skills leveled up to 50th level. If you start with pyromancy, sorcery and flame touch, it is pretty much guaranteed those are the first ones to reach levels 5-10. If you then learn evocation, it is again pretty much guaranteed you will not gain enough evocation xp to reach the next level. (At least when M=1.) Example: fireborn sorcerer, starting monster-bashing skills are pyro, sorc and flame touch. Suppose you are total level 15, and have been very careful to advance those equally, so they are all 5th level. Now, you learn evocation. You need to gain 800000 xp *with evocation* to reach level 16. How probable is it that anyone *ever* bothers killing 160000 kobolds to gain a single level? (Kobolds are worth 5 xp, right?) This can be modified in many ways to make things as we want them. For example, it would be quite ok to make M=3, though in that case this does not solve the "dragon leveling sorcery" -problem without other modifications. One such modification might be, that M=3 *but* you can only advance in each of those three skills if its accumulated xp between the two levels accounts for no less than 10% of the total xp between the two levels. I.e. 1 xp for evocation, 399999 for pyro and 400000 for sorcery only advances pyro and sorcery, you need at least 80000 to advance any given skill between those two levels. This still means 16000 kobolds... > And the high level experienced players just take the maps where to get > most xp and / or treasure. And than this map is blocked by a few > players over and over again. Can we make the map reset delay character specific? I.e. the map would reset in, say, two hours for other players, but for the same character, it does not reset until, say a week has passed. That would put an end to repeating lucrative maps all over again by the same character. > Just reduce the xp gained by a monster if you're higher. Don't give out > more xp if you killed a monster on a lower level. The monster xp is the > maximum you can get from it. Well, this really is just a question of what does the xp-modification function look like. We can easily make the modification dependant upon Heaviside(monster_level-character_level), where Heaviside is the Heaviside unit step function. Or anything like that. If the problem is in altering xp gained from monster, altering the function does not solve it. I do not personally see from Mark's explanation, what the problem really is. It looks like it was simply implemented suboptimally. > Fix that. Don't make high level items equipable for low level > characters. Apart from rods, they aren't: they have item power specifically to prevent low lever characters from using high level stuff. The item powers are quite strange for some items, though. > > Also, the crossfire exp table is almost an exponential system, where > > as AD&Dv3 is more linear (the exp needed for level 20 is 10 times that > > of level 2). So adding this extra adjustment really just amounts to > > extra penalty/bonus. > Making level 100 as hard to reach as level 115 is right now, won't make > level 101 characters more likely even if the xp table is more linear. I do not think Mark was referring to level caps here. What he said is true: D&D 3rd ed has (almost? I'd need to get up, go to bookshelf and check...) linear xp tables, crossfire does not. Crossfire has ~exponential xp tables. Though I am at a loss at to how he reached the conclusion that is is a penalty/bonus. If all the current monsters are given the "correct" level and killing the monsters at "right" (i.e. when you are at the same level as the monster) level gives you the listed XP, there is absolutely NO difference from the current situation UNLESS you kill too easy monsters, which would get penalised (which was the whole point). Linearity vs. exponentiality has nothing to do with it. The only thing that has is the modification-function, which must give listed XP when killing monsters at proper level AND monster XP(level)-function must follow the same formula as player XP(level)-function. (Unless we want to make it so that reaching level N from N-1 needs more kills than N-1 from N-2 etc, but even that has nothing to do with penalising for killing too easy monsters.). > But rebalance the gaps, make it more linear. Actually, the form of the XP(level) function is totally irrelevant. It may even be logarithmic. The only thing that matters is that what you DO (kill monsters, do alchemy, read scrolls, use wands etc) gives you XP according to the same function. This is, of course, provided there are difficulty levels in what you do: I think woodsman gives the same amount of XP for all food, a reflection of the fact that it is equally easy to identify an orc chop as a dragon steak, whereas brewing a very complex potion (level 10 potion, say) is harder than brewing a simple (level 1) potion, so the former should give such an amount of XP that it advances you equally towards 11th level as the simple potion advances you towards 2nd level. If we always follow the method of "completing a task that has difficulty level N gives M% of the XP needed to advance from level N to N+1", it never matters what the XP(level) function looks like. Keeping the function exponential, however, is intuitive. It is easy to think that advancing from 10th to 11th level needs 10 times the xp of advancing from 1st to 2nd (or any such). If the function is very complicated, figuring out the correct amount of xp becomes a pita. Making the function linear, on the other hand, makes things very easy: every potion would just give the exact same amount of xp; same for the monsters. What you need to think about now, is the level. Is this monster worth M% of the difference between 10th and 11th levels or 11th and 12th? Since there are only ~100 levels to choose from, but exponential xp tables give you easily tens or hundreds of millions of xp values to choose from, I'd say exponential table is easier - and safer when introducing new things (the choice of correct level has less impact than in linear system). > > > No, it's not. But don't make monsters getting a higher level than > > > the maximum of the xp table. > > Sure we should. High level (150) monsters you can only kill with 4 > > 100+ level players. > No, we shouldn't. ;) Err... I do not quite agree here. It is a very intriguing idea to have monsters that are simply too powerful for (practically) any character to kill. Whether the xp table goes up to the level of the monster is irrelevant, though. What does it matter if there is 100 lines instead of 150 in the exp_table file? (I know it's not organised one per line, but that's easier to write.) It can always be extended any way the server admin sees fit. And if someone creates a 110th level region in the world, even the official xp table can be extended. Where is the lack of room for extensions? -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070724/12b64a70/attachment-0001.pgp From mwedel at sonic.net Mon Jul 23 23:58:01 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 23 Jul 2007 21:58:01 -0700 Subject: [crossfire] Party Support (was: Priority feature list) In-Reply-To: <20070723194204.GA18282@cthulhu.desy.de> References: <20070723194204.GA18282@cthulhu.desy.de> Message-ID: <46A586D9.1090403@sonic.net> Juergen Kahnert wrote: > On Sun, Jul 22, 2007 at 09:37:44PM -0700, Mark Wedel wrote: >> I consider this sort of a chicken and egg party - people may not use >> parties often because there is not much reason to form parties. > > The only reason I know for a CF party is, to level up a lower level > character. And regardless of the party support of CF, I would remove > the xp sharing for killing monsters. Some other advantage is that there are the chat party chat commands, so can be easier to communicate with other people if in a party. But how parties should work out is something to be thought about. Server level support (being able to form parties, exp sharing, etc) may not be strictly needed. So it may be more a thing that players should be able to cooperate on a single map, and somehow share the rewards. OTOH, if classes have more distinction, some classes may need party assistance in order to advance. If you want to play a pure healer, you can't expect that character to be going out and killing monsters. But could be very valuable as part of a party, so so want some way for the character to get exp. The other more general problem is that if you don't have exp sharing, players can to some extent do it unofficially - the fighters weaken the monster, take the damage, etc, so that the healer can finish it off. > > And now, what's necessary to solve this problems to have a working party > support. > > 1) Slow down combat speed. Some player just won't like that, especially > no slower movement. So the only chance for that is to reduce weapon > speed. May work. > > But on a 2D tiled map with fast moving monsters you could quickly run > out of escape routes. Slower movement will help, too. But I think > no majority for a general slowdown. I don't think there are enough details on that. In my thought, movement would really only be slowed down for high level characters, and in fact sped up for lower level characters - in a sense, reduce the speed variance that currently exists, so that high level characters don't move 5 times faster than low level characters. Certain things still affect speed - how much junk is being carried, etc. But I think that without magical assistance, no character should be able to have a speed above 1.0, no matter what their strength and dex. > 2) There are simply no spells for party support. Most support spells > are self directed or combat spells. Nothing special for the party. > Protection spells, bless, healing, ... all of them needs a "party > version". Support for party spells was added, just not many spells use it. Part of redoing spells may be to add more party spells. Characters must have a way to heal themselves - but not every spell should have a potion or rod/wand counterpart. I can think of several useful spells in that there is no reason non spell versions exist - think things like extra hp (basically healing that lets you go above your normal max), a regeneration spell (get hp back faster for some time period). I also think that even if combat isn't slowed down, many of these spells should have longer durations - at least in minutes in real time, so you could help out the party before they head to the next level, etc. > > > 3) If you have spells as pointed out at 2), you have to know to cast > which spell on whom. For example, as long as a healer don't know who > needs help, he can't heal that member... > > Same for protection spells. Whoms fire protection is running out? > Or any other of this spell class. All without chatting or who has > time in front of a big monster to ask for a healing? > > 3D RPGs usually display the status of the party members above the > character. This works in a high resolution 3D world, but not on a > low resolution 2D one. > > Having an extra windows with party members and their stats will give > you an overview, but you don't necessarily know where "Bob" is who > needs to be healed. You just know that "Bob" should be healed... Yes - that is a problem. And it isn't just knowing about when spells run out - as an example, you could probably care less if the fireborn doesn't have a resistance to fire spell. so it may be that when part of a party, more information is shared with party members - you can see all your party members resistances, which are currently boosted by spells, current hp, sp, grace, if party member is under effect of any spells (confusion, paralyzation, slow, etc). As said, this would probably have to be done in another window/pane, but would give a way to quickly see who is in trouble. Perhaps as part of that is tie in the party spells with that - that window has some way to make it easy to cast 'heal other' on different party members - drag and drop, pull down menus, something. And as long as the caster and recipient are on the same map or close enough, the spell works - don't need to be next to the character. In this way, the spell caster could hang back a bit and help out party members. > > > 4) And now the biggest problem for a 2D tiled map game. How do you > avoid that party members blocks your way? > > For the movement, you can do something like made with pet monsters. > You just move "into" them and change the positions. This may lead > into some confusion, but should be better than dying because of a > sleepy member... > > Anyway, not nice. For example I cast a spell and someone runs > "through" me so I change the position and I may miss the monster but > hit the wall. I won't like that. > > How do 3D RPGs solve this problem. Easy, you just click on the > monster you like to hit. If someone pushes me aside, I won't miss > the monster. > > What about characters in the second row like archers or spellcasters? > How do they hit the monster, if warriors do direct melee combat? How > do they hit the monster without hurting the warrior? Or if the archer > stands on coordinates (0;0) and the monster on (2;1)? Which direction > key do you have to press for that? You can hit monsters on (2;0), > (2;2) and (0;2), but not on (2;1) or (1;2). And this is just for a > 3x3 square... > > I've no idea how to solve this. It has been suggested that there should be a way to target creatures not in the front row - likewise, monsters should have the same advantage, so a bunch of orc archers behind orcs with swords would be pretty deadly. At some level, this targetting logic isn't that hard - when you cast a spell/shoot an arrow, it is targeted as some specific space. If by the time the spell gets there, the monsters is no longer there, or a party member is there, tough luck. At least for players, they'd probably see the arrow or spell flying in that direction, that'd probably avoid it. But there are problems with this - good way to do it on the client (clicking on a space would work, but is that spell or arrow? Could use ready skill I suppose). This change does have bigger effects - you could now fire things in the non 8 directions. I'd say spells that can be targeted in this way should be limited - not every spell should be usable in that way. It would probably be simplest to say that intervening creatures/party members won't be hit by those arrows or spells (this otherwise makes things too deadly or too unfriendly to use). Movement itself is a problem - acting lik pet move sort of works, unless both people are trying to move the same direction and end up swapping places with each other and not actually attacking the monster. Don't have a great solution there. > > > After you solved all this problems without changing the game that much > that most of the current players still likes to play CF, you can work on > point: > > 5) Create party quests. In the past year there was some discussions > about this issue. Not much, most of the discussion was questions how > to make it. And a few ideas like giving xp as a reward to all party > members who really made the quest instead of joining short before it > ends. Or how to give out items to the party members as a reward. > Something like that, but without a better party support (see above) > party-quest-maps aren't really playable and thus not important. But that isn't really the point - just because points 1-4 do not currently exist, or are not currently used, doesn't mean we can't/shouldn't be able to think about how parties/quests would work if those points did exist. It may be like several features - not used by many people. But it seems to me that the above points really don't have anything to do whatsoever about how you give rewards - they are completely separate. We could certainly say that CF is a single player RPG game and that there is no party support, and so yo really shouldn't work with any other players on dungeons or quests, because simply put, you'd be disappointed/upset when you find you don't get a reward. That is certainly an option, but I haven't seen a lot of people saying that is what should be done. From mwedel at sonic.net Tue Jul 24 00:43:40 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 23 Jul 2007 22:43:40 -0700 Subject: [crossfire] xp gaining In-Reply-To: <20070724011057.0b8e9ca2@alnitak.stiff.utu.fi> References: <46A43098.2000101@sonic.net> <20070723202407.GB18282@cthulhu.desy.de> <20070724011057.0b8e9ca2@alnitak.stiff.utu.fi> Message-ID: <46A5918C.3080003@sonic.net> Juha J?ykk? wrote: > Hm.. I still have a lengthy message from Sunday not replied to, but I'll > chime in on this one first... > >>> The problem here is feature (or monster toughness) creep. It is easy >>> enough to say 'max level for any monster should be 100'. The problem >> The level 100 should be practically / nearly impossible to reach. So >> having level 150 characters is unlikely. > > I think this is a problem any way you put it. With hard cap, players get > bored when they hit the cap and the character can no longer improve. With > impossible-to-reach maximum level, there is a gap *below* the hard cap: > if level 100 is "impossible" to reach, it simply means level 99 is the > cap! And players still get bored when their characters no longer advance. > So even without a hard cap, just impossibly difficult-to-reach levels, > people will get bored exactly like they would with a hard cap. That's exactly my thought - to me, having no cap but impossible to reach exp totals is basically the same thing as a hard cap. So why not do a hard cap then? If the exp table is such that characters can get above level 99, or 100, then you don't have a cap. Now I'm certainly open to the idea that there is no cap on exp, just a cap on level. So once you reach max level (100), you'll be max level, but you can keep accumulate exp all you want - it just doesn't get you much (save for some padding if you get drained). > > I am not quite sure just adding new regions and monsters will help here > since the character advancement has ceased. If there is no gain from > doing quests, why do them? Even if you get some new fancy thingy as a > reward, it probably is not enough to motivate players when that is the > only thing to gain. > > Increasing levels, perhaps even by adding new areas to the map or > whatever, is probably the only way around this problem. Another would be > if the capped characters would be able to advance in some other way: in > pen-and-paper RPG's people often start building their own kingdoms etc. > Although I have no idea how THAT would work in cf. But it definitely is > fun. IMO, adding new regions when characters reach the cap is completely unrealistic, so I dismiss it as an option. Sure, it sounds great, and could happen, but past experience shows it won't happen. Making a complete new region for super high level characters isn't something that is going to happen in a few days - that is a lot of work. And I think getting people to do that work is not going to be easy. > >> A high level dragon with clawing level 100 decides to level up sorcery >> will block a low level map for a very long time until the sorcery skill >> is on a desired level. > > Immediately after reading this, I got a great idea (at least I think it > is great): make the skills more like D&D 3rd ed. skills (or what do they > call them nowadays? They used to be called proficiencies back in AD&D). > They've spent a lot of time thinking about those and they definitely have > got it done pretty well. This is how the skills *could* work: > > Every player race *and class* gets some starting skills, like they do > now. After gaining enough experience to get to level N, they get to > improve *those* skills that they most used (say, M skills, no more) > between reaching levels N-1 and N, but only those skills. This way there > would not be an issue of 50th level dragon leveling his first levels of > sorcery in a newbie map, because the dragon would *never* get enough xp > for sorcery in that manner to make sorcery one of the skills he improves > when reaching 51st level. (Note that if M above is too big, this is > untrue; for M=1 and possibly some other low numbers as well, this > statement holds.) Balancing this is probably more difficult. First, it certainly couples skill levels to overall level - this means characters may avoid using some skills because they want to make sure the skills they care about go up (don't use find traps - it might mean my pyromancy won't go up). the other problem with this, and the other idea of limiting exp gain based on overall level, is that it really means you need balance your skill usage as you advance your character. Suppose for example you start as the 'mage' character, which gets you pyromancy & evocations. For some random reason, you don't use that evocation skill, and you're now level 20 with a level 1 evocation skill. Under both methods, you're evocation is basically a lost cause - its unlikely you'll be able to kill level 15 monsters with your evocation skill, even if you weaken them with other skills. It may be that is the correct thing, but even AD&Dv3 doesn't really do that - each level you get skill points, and can put them in whatever skills you want - there is a max of how good a skill can be relative to level, but in AD&Dv3, a high level character could pick up a new skill and get very good at it very quickly. That isn't quite the model you are describing. I personally dislike games that force some style of playing. I'd dislike crossfire if I say 'I must improve my evocation skill right now, because if I don't, I won't ever be able to get very good at it'. I do agree that high level characters leveling up certain skills in easy dungeons is not a good method. But how is this for another method: Whenever a character gains exp through any method, some portion (<10%) goes into a reserved pool - these exp don't go into any specific skill, but do count for overall level. The player is then able to move exp from this reserved pool into skills to increase their level. So if you're level 50, and find your evocation skill is really bad, you can shuffle exp from that general pool into evocation. And almost certainly, if you're level 50, killing level 50 creatures with your good skills will get you exp faster in evocation that trying to kill level 1 creatures with evocation. At some point, this balance changes - at level 15 evocation, it may be faster to kill level 15 creatures with evocation than do that exp transfer. OTOH, if you're level 50 overall and level 15 evocation, you're evocation is probably good enough now to finish off some level 50 creatures now and again. >> And the high level experienced players just take the maps where to get >> most xp and / or treasure. And than this map is blocked by a few >> players over and over again. > > Can we make the map reset delay character specific? I.e. the map would > reset in, say, two hours for other players, but for the same character, > it does not reset until, say a week has passed. That would put an end to > repeating lucrative maps all over again by the same character. Not possible - maps are global attributes, so very hard to make things on them per player. And you also get a case like this: High level player goes in map, clears it out. It shouldn't reset for a week. But low level player goes, and it has been the 2 hours, so should reset for him. What happens now if high level player shows up? Other problem is that you now need to track for every player and every map when they last went to it. One could perhaps add per player instance maps with different reset times. This clearly isn't good for multiplayer (as two players entering at the same time would no longer be together). In this model, one could add logic that those per player instance maps reset after some amount of time. > >> Just reduce the xp gained by a monster if you're higher. Don't give out >> more xp if you killed a monster on a lower level. The monster xp is the >> maximum you can get from it. > > Well, this really is just a question of what does the xp-modification > function look like. We can easily make the modification dependant upon > Heaviside(monster_level-character_level), where Heaviside is the > Heaviside unit step function. Or anything like that. If the problem is in > altering xp gained from monster, altering the function does not solve it. > I do not personally see from Mark's explanation, what the problem really > is. It looks like it was simply implemented suboptimally. May have been suboptimal. But the problem is you also start getting too many variables, so very hard know fair exp rewards. If the boss monster may give between 10K and 100K exp depending on level of character, very hard to know what is fair. But this also goes back to above - if you're level 50 and only get exp for killing level 40+ monsters, once again, skills you have neglected are basically useless - you're not going to kill level 40 creatures with level 1 evocation spells (or level 1 punching) This also I don't think completely fixes the problem - it just forces characters to figure out the minimum creature necessary to get exp. So maybe instead of that level 50 person getting evocation exp on orcs, he has to do it on hill giants. Some improvement I guess, but not for the level 10 characters who want to take on some hill giants. > >>> Also, the crossfire exp table is almost an exponential system, where >>> as AD&Dv3 is more linear (the exp needed for level 20 is 10 times that >>> of level 2). So adding this extra adjustment really just amounts to >>> extra penalty/bonus. >> Making level 100 as hard to reach as level 115 is right now, won't make >> level 101 characters more likely even if the xp table is more linear. > > I do not think Mark was referring to level caps here. What he said is > true: D&D 3rd ed has (almost? I'd need to get up, go to bookshelf and > check...) linear xp tables, crossfire does not. Crossfire has > ~exponential xp tables. Though I am at a loss at to how he reached the > conclusion that is is a penalty/bonus. If all the current monsters are > given the "correct" level and killing the monsters at "right" (i.e. when > you are at the same level as the monster) level gives you the listed XP, > there is absolutely NO difference from the current situation UNLESS you > kill too easy monsters, which would get penalised (which was the whole > point). Linearity vs. exponentiality has nothing to do with it. The only > thing that has is the modification-function, which must give listed XP > when killing monsters at proper level AND monster XP(level)-function must > follow the same formula as player XP(level)-function. (Unless we want to > make it so that reaching level N from N-1 needs more kills than N-1 from > N-2 etc, but even that has nothing to do with penalising for killing too > easy monsters.). Correct, to some extent. The exponential crossfire exp tables makes it pointless to kill low level creatures - the number of orcs a level 50 character would need to get to level 51 is a huge total. Yes, unlike AD&Dv3, he would eventually get to level 51. But that is what the exponential table does - makes killing lower level things virtually useless. But as several people have noted above, exp is skill based, so if you're level 1 in evocation, kill level 1 creatures gets you something. But there are lots of problems if exp gain for skills is adjusted by overall level - you now really need to take a balanced approach to gaining levels, but then at the same time you really want to have 1 good exp that corresponds to overall level. For example, if you're level 50 and have 1 skill at level 50 and rest at level 1, you're in pretty good shape so long as that single skill does what you need - you get true exp value for each level 50 creature you kill. But if you're level 50 and have 6 skills at level 30, you're in bad shape - you probably can't kill level 50 creatures, so maybe you kill level 40 creatures instead. But now you're getting less exp for each creature you kill than you normally would, so that much harder to improve skills and overall level. Maybe that becomes self regulating at some point - I'm not sure about that. And maybe the game should be that way - really focus on just a couple skills per character. But that really has to be clearly documented - I find it really frustrating to have played a game for quite a while only to find out I didn't do the correct thing, and thus the character is basically messed up and I should start a new one. I much prefer games that are forgiving - maybe you didn't make ideal choices, but what you did before doesn't have a huge impact now. From juolja at utu.fi Tue Jul 24 13:30:09 2007 From: juolja at utu.fi (Juha =?UTF-8?B?SsOkeWtrw6Q=?=) Date: Tue, 24 Jul 2007 21:30:09 +0300 Subject: [crossfire] Priority feature list In-Reply-To: <20070722142338.GA12432@cthulhu.desy.de> References: <46A048A3.7040003@sonic.net> <20070722142338.GA12432@cthulhu.desy.de> Message-ID: <20070724213009.02a3197c@alnitak.stiff.utu.fi> > How much parties do you see on servers which will do something else than > leveling up lower level character(s) with a high level character? Partying is "essential" for multiplayer games, at least some rudimentary support either with or without xp sharing. Multiplaying is the sole reason I prefer CF over things like Wesnoth. BTW, another multiplayer game we might learn from is Widelands. It does not do interactive battles, but it does have very nice graphics (in 2D!) and it manages to fit stunning amounts of info into a 800x600 window! > Having a hard start as a mage turns up into an impossible mission on > higher levels. That's not fair. If it's hard in the beginning, it > should become easier later on, not harder or impossible... I think everyone has agreed on this. Is it ok to list this in wiki? > Your fireborn is able to wear a cloak? The fireborn definition is this > one: Perhaps I was thinking of a dragon at that point, sorry. > 6 items vs. 12 items; not 7 vs. 11. Having a single fireborn race-slot > for an item which needs to be as powerful as 6 human body part items > makes this item very powerful, too much. But it's a good start. I never specified the number of race-slots, but Mark's (?) idea of putting the who-can-use-this info into the item instead seems even better, *though* we still need some way to determine how many items and of which types a character simultaneously equip. This means Mark's idea does not solve the problem: fireborn would still only be able to apply 6 items against human's 12. Of course, there *could* be some extremely powerful fireborn -item, but I'd rather give fireborns a couple of "fireborn tentacles" or something like that to wear the fireborn stuff at. > And that a skill with a grade of "Expert" is better than one with > "Novice" can't be called confusing, right? Is 10th level Expert better or worse than 100th level novice? And what the heck does a 100th level novice mean anyway? Suppose you are 100th level novice carpenter. Does that mean you can only chop logs into pieces and nothing else, but you can do that extremely well, while a 10th level expert can sculpt beautiful statues, but is not as good at chopping logs as the other guy? > That is girdle of Valriel of the Crusade > (Str+3)(Dex+3)(Con+3)(Wis+5)(Cha+2)(ac+2)(item_power +1)(grace+3) Does this actually exist..? > I would like to see a formula for almost every item in CF. Who made > those stuff if it can't be made? ;) Me too, and with my "generalised" formulas we would not need to separately invent a formula for every single item, since ring ac +1 and ring ac +5 would have the same ingredients, just different amounts and difficulties. > As I said, meteor swarm is doing weapon magic damage, not fire damage. > And no character race / class is immune to weapon magic nor get the > chance to increase the resistance against weapon magic. Visit hanuk > as a fireborn and see what happens... Meteors do weaponmagic, the fire does not. The fire from an impacting meteor does simply fire damage. Unless someone has chaged this since April. Visiting Hanuk with a fireborn is not a problem unless you get to the path of Hanuk's meteors - the fire is not a problem. If the fire did weaponmagic damage, how could you stand in it as a fireborn with impunity? > beginners with a lvl 1 fireborn sorcerer (magic only, no melee, not as a > monk - no meditation) and the same with a troll warrior (melee only, no > magic). Been there, done that, many times. Not a problem, but true, the troll probably cleans the place faster - that's as it should be. The problem, as everyone has agreed, comes at higher levels, where it is STILL easier and faster for the troll. > If you have luck and you got small fireball with pyromancy skill. If > not, you may start with detect magic or slow. And now? How to play a > sorcerer unwilling / unable to do melee? That might be troublesome. I've started quite a lot of sorcerers and never had useless spells at first level. Is there such a spell in level 1 sorcerer treasure list? The fireborn always gets pyromancy and there are only killing-spells in pyromancy. Non-fireborns might get to trouble, though. This could, however, be fixed by letting sorcery gain xp from non-fatal spells as well, like slow, detect magic etc. But how to prevent their abuse, then..? > Prove it. Try it out, feel the difference. Again, not playing a monk, > playing a sorcerer! I won't be starting new characters at the moment, but I've played quite a few fireborn sorcerers before I realised how useful monks are. You just need patience. (And lots of food.) > I know Mark don't like this idea, because it's lots of work. But you > just said, you disklike it. What are your reasons? It's an artificial limitation into what a character can do in a world. I dislike those. I even dislike the fact that I cannot simply break any wall I choose (but realise that it is something that can not be changed without huge amounts of work). Segregating players into different areas is something that is not necessary in my opinion. I believe there are other ways to prevent abuse as well. > Having regions for the same level will increase the fun for the players. > I saw so much newbies unable to find suitable dungeons. Some got their That's a totally different thing. It would be difficult to find dungeons even with level-based segregation if there are not enough clues around. If there are enough clues around, there should in no case be any difficulty. Warnings when entering a too difficult dungeon, otoh, would be nice to have for players how, for example, get lost or simply want to try to take it to the limit. > fun spoiled by high level characters boosting them ten or more levels by > a short party at a high level map. I think xp sharing in a party is > very bad and should be disabled. Two things here: 1) joining a party is voluntary, so if someone voluntarily spoils his game, why should we care? 2) sharing xp in a party is paramount, especially if we move towards "healers stand back and cast cure wounds and do not kill monsters" -type of play. Xp sharing can be tuned, however. It would be, for example, be possible to not give any xp to party members who are 10 levels lower than the guy killing the monster is. Or, we could figure out other ways to prevent people from spoiling their gameplay. > And did you never saw a character above level 100 harvesting in raffle1? Raffle1 is generally accepted to be a map that should not exist. Not with all those generators around. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070724/c8c8ddcb/attachment.pgp From juolja at utu.fi Tue Jul 24 13:42:00 2007 From: juolja at utu.fi (Juha =?UTF-8?B?SsOkeWtrw6Q=?=) Date: Tue, 24 Jul 2007 21:42:00 +0300 Subject: [crossfire] xp gaining In-Reply-To: <46A5918C.3080003@sonic.net> References: <46A43098.2000101@sonic.net> <20070723202407.GB18282@cthulhu.desy.de> <20070724011057.0b8e9ca2@alnitak.stiff.utu.fi> <46A5918C.3080003@sonic.net> Message-ID: <20070724214200.45749c32@alnitak.stiff.utu.fi> > IMO, adding new regions when characters reach the cap is completely > unrealistic, so I dismiss it as an option. Sure, it sounds great, and > could happen, but past experience shows it won't happen. Making a Ok, you're more experienced on that, I trust your judgement. How about the kingdom and politics side? Could that be implemented? Or researching new spells or items? > the other problem with this, and the other idea of limiting exp gain > based on overall level, is that it really means you need balance your > skill usage as you advance your character. It does not have to be overall level, it could equally well be the highest skill level as well. Or, when killing monsters, it could even be the skill you use to kill it (although then we again will have high level characters in low level maps when they start a new skill). > I personally dislike games that force some style of playing. I'd > dislike crossfire if I say 'I must improve my evocation skill right > now, because if I don't, I won't ever be able to get very good at it'. That's true, it's not very nice. But "if I do not improve my evocation now, improving it later will be more difficult" is ok with me. It's like growing older: it's easier to learn new things when you're young and becomes harder with age. (At least that's the common belief, I do not know if it's true.) > Whenever a character gains exp through any method, some portion (<10%) > goes into a reserved pool - these exp don't go into any specific skill, > but do count for overall level. That might be a good solution. Anyone any objections or other thoughts on this? > And maybe the game should be that way - really focus on just a couple > skills per character. But that really has to be clearly documented - I I think it should. It should not enforce it, but it should make it much more difficult to be exceptionally good at very many skills. This fosters both class distictivity and multiplayer adventuring. > basically messed up and I should start a new one. I much prefer games > that are forgiving - maybe you didn't make ideal choices, but what you > did before doesn't have a huge impact now. Agreed. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070724/06a5e644/attachment.pgp From kbulgrien at worldnet.att.net Tue Jul 24 14:31:27 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 24 Jul 2007 14:31:27 -0500 Subject: [crossfire] block view vs. xray vision Message-ID: <200707241431.27601.kbulgrien@worldnet.att.net> The ground (/scorn/guilds/mailed_fist/ground) map in Scorn is made in such a way that if you are wearing an XRay helmet you can see behind a block view "wall" to see mechanisms that are used to make the map work. Is this expected behavior, and the map maker did not account for the fact that XRay might show things that are not intended for players to see? In this map, there is room to slide everything over and make the block view region wider so that XRay would not show the items. Is this the correct way to "fix" the map? Does XRay ever have a range greater than two tiles? From kbulgrien at worldnet.att.net Tue Jul 24 14:53:16 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 24 Jul 2007 14:53:16 -0500 Subject: [crossfire] bug in gtk-v2 client Exp's progressbar In-Reply-To: <005001c7cb10$9a505660$cef10320$@o@free.fr> References: <000001c7cb08$585b3de0$0911b9a0$@o@free.fr> <005001c7cb10$9a505660$cef10320$@o@free.fr> Message-ID: <200707241453.17099.kbulgrien@worldnet.att.net> > --> see patch in attachment (stat.c) : I did change int to uint64 and %d > with the macro FMT64U. > > Best Regards, > Olivier (findufin & findragon on metalforge) Not seeing any objections to the patch posted, I applied the patch for you... It is revision 6808. Kevin Bulgrien From kbulgrien at worldnet.att.net Tue Jul 24 15:18:40 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 24 Jul 2007 15:18:40 -0500 Subject: [crossfire] GTK2 on Linux (was gtk-v2 on MS Windows) In-Reply-To: <46A2FD96.4040408@sonic.net> References: <000301c7c97e$7c215510$7463ff30$@o@free.fr> <200707211004.53698.kbulgrien@worldnet.att.net> <46A2FD96.4040408@sonic.net> Message-ID: <200707241518.41260.kbulgrien@worldnet.att.net> > > Inventory icons. > > > > Non-graphical icons (inventory, and so on) are cut off too at 1024x768 and > > I haven't yet figured out if there is a scaling/size setting that might fix it. It > > was better than my configuration when I set it to 100/100, but it will take > > more fiddling to see if it is fixable. > > I'm not quite sure what you mean by non graphical icons. Are you talking > about the icons in the inventory and look lists? Or icons used elsewhere in the > client? > > In either case, I'm not seeing that problem myself. > > GTK itself is supposed to take care of proper sizing of the inventory/look > lists (making sure there is enough space for the icons), so if that isn't > happening, it would sound more like a bug in gtk2 than the client. I do not even know what I meant by "non-graphical icons"... What I did mean was the graphical icons of individual inventory items are cut off on the right hand side. I do not see the problem evidence itself at 1280x1024, but I have not tested scaling down very far because I had more screen space and could tolerate bigger icons. At 1024x768 and 100% scaling for the icons, only the largest icons are cut off (bows, mithril armor, quivers, etc). At 66% scaling, a greater number of icons are cut off. At 50% scaling, as best I can tell, all icons are cut off. It seems the column width is scaling down disproportionately compared to the scaling of the icon graphic. Kevin R. Bulgrien From mwedel at sonic.net Wed Jul 25 00:44:54 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 24 Jul 2007 22:44:54 -0700 Subject: [crossfire] block view vs. xray vision In-Reply-To: <200707241431.27601.kbulgrien@worldnet.att.net> References: <200707241431.27601.kbulgrien@worldnet.att.net> Message-ID: <46A6E356.90702@sonic.net> Kevin R. Bulgrien wrote: > The ground (/scorn/guilds/mailed_fist/ground) map in Scorn is made in such a way > that if you are wearing an XRay helmet you can see behind a block view "wall" to > see mechanisms that are used to make the map work. Is this expected behavior, > and the map maker did not account for the fact that XRay might show things that > are not intended for players to see? Yes, and that probably isn't the only map - lots of maps don't take x-ray vision into account. There are probably some other ways that can be used to hide this, depending what needs to be hidden. One could use the 'blocked' space (which is all back) - put that on top, but change it so it doesn't have any weight and doesn't block any movement. In this case, people with x-ray would still see the space, but it would just be black. > > In this map, there is room to slide everything over and make the block view region > wider so that XRay would not show the items. Is this the correct way to "fix" the > map? > > Does XRay ever have a range greater than two tiles? X-Ray vision is hardcoded with a 2 tile range right now. And it completely ignores any attributes of the space - basically, it just says that all spaces with 2 spaces are visible to the character, regardless of any other attributes. It is conceivable that at some point, different range for x-ray vision could be added, as well as flags to block it. But I don't really see either of those happening anytime soon. From mwedel at sonic.net Wed Jul 25 01:18:45 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 24 Jul 2007 23:18:45 -0700 Subject: [crossfire] xp gaining In-Reply-To: <20070724214200.45749c32@alnitak.stiff.utu.fi> References: <46A43098.2000101@sonic.net> <20070723202407.GB18282@cthulhu.desy.de> <20070724011057.0b8e9ca2@alnitak.stiff.utu.fi> <46A5918C.3080003@sonic.net> <20070724214200.45749c32@alnitak.stiff.utu.fi> Message-ID: <46A6EB45.2070103@sonic.net> Juha J?ykk? wrote: >> IMO, adding new regions when characters reach the cap is completely >> unrealistic, so I dismiss it as an option. Sure, it sounds great, and >> could happen, but past experience shows it won't happen. Making a > > Ok, you're more experienced on that, I trust your judgement. How about > the kingdom and politics side? Could that be implemented? Or researching > new spells or items? I'd need to see more details. It really comes down to effort. To come up with a new high level area, you probably need around 50 maps - that is a lot of work - especially if you want good maps, and not just things with scaled up monster and no plot. I'd think researching new spells and items is more modest. New items can be pretty easy - we'd need to extra work for spell research, but for new item to be created via players, that is really just adding some new formula - figuring out a good formula may not be easy, but one could probably come up with 5 new formula in the time it takes to do a map. > >> the other problem with this, and the other idea of limiting exp gain >> based on overall level, is that it really means you need balance your >> skill usage as you advance your character. > > It does not have to be overall level, it could equally well be the > highest skill level as well. Or, when killing monsters, it could even be > the skill you use to kill it (although then we again will have high level > characters in low level maps when they start a new skill). Right - so if the goal is to prevent high level characters from gaining exp in low level dungeons, exp gain has to be based on overall level, not skill level. >> I personally dislike games that force some style of playing. I'd >> dislike crossfire if I say 'I must improve my evocation skill right >> now, because if I don't, I won't ever be able to get very good at it'. > > That's true, it's not very nice. But "if I do not improve my evocation > now, improving it later will be more difficult" is ok with me. It's like > growing older: it's easier to learn new things when you're young and > becomes harder with age. (At least that's the common belief, I do not > know if it's true.) I don't mind if it is harder, as long as it isn't so much harder that it is near impossible. > >> Whenever a character gains exp through any method, some portion (<10%) >> goes into a reserved pool - these exp don't go into any specific skill, >> but do count for overall level. > > That might be a good solution. Anyone any objections or other thoughts on > this? Just a note on this - I do believe that as part of a revamp, it should be possible to get to high level in every skill. Right now, for some skills, there is basically some practical limit (literacy gets hard at some point - there just are not enough books about, and spellbooks are a good source, but eventually you know all the spells). Those things need to be rebalanced - it should be something like 20 books at current level equals a level in literacy (which means level 100 literacy would be 2000 books, presuming they are all of the appropriate level). That is actually a lot of books if you think about it. That said, the ability to shuffle some experience gives a way to get exp in harder to advance skills - it shouldn't be the only way to do it, but does help out. In a sense, it is sort of like the AD&Dv3 idea of skill points you get each level. > >> And maybe the game should be that way - really focus on just a couple >> skills per character. But that really has to be clearly documented - I > > I think it should. It should not enforce it, but it should make it much > more difficult to be exceptionally good at very many skills. This fosters > both class distictivity and multiplayer adventuring. I agree that should be rewarded. I think some previously suggested adjustments (broader range of spell levels) might give more reason for this. But a good way to do this is tricky - the problem if you give less exp for lower level skills (so that if you are level 50 overall and level 5 in sorcery, it is now more difficult to get to level 6 sorcery than if you were level 6 overall) is that this just adds the needs for those characters to go into low level dungeons to level up those skills. Or if the idea of a pool of experience that can be shuffled, it means that the point at which it is worthwhile to go into dungeons to kill creatures is now lower levels than if the exp gain was the same. It is sort of competing needs - there is the desire for high level players not to level up their skills in low level dungeons. But there is also the desire for players to concentrate on fewer skills and not be generalists. From mwedel at sonic.net Wed Jul 25 01:23:01 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 24 Jul 2007 23:23:01 -0700 Subject: [crossfire] Priority feature list In-Reply-To: <20070724213009.02a3197c@alnitak.stiff.utu.fi> References: <46A048A3.7040003@sonic.net> <20070722142338.GA12432@cthulhu.desy.de> <20070724213009.02a3197c@alnitak.stiff.utu.fi> Message-ID: <46A6EC45.8060702@sonic.net> Just some quick thoughts on this: I agree that in principle, most of the classes and races should be about equal in power/balance. A certain race/class shouldn't always be the best to play. And in broad terms, fighters and spell casters should be about equal. However, I don't think all races/classes have to be equal. I know in the past, certain races were made available, but made available as 'challenge' classes, for lack of better term For those players who have played a lot, you can now play this other race for a different experience, as well as something a bit more challenging. So I don't think all of those should be removed. We should try to keep them fairly close, but I don't think everything needs to be perfectly balanced. From subs at eracc.com Wed Jul 25 12:34:03 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Wed, 25 Jul 2007 12:34:03 -0500 Subject: [crossfire] block view vs. xray vision In-Reply-To: <46A6E356.90702@sonic.net> References: <200707241431.27601.kbulgrien@worldnet.att.net> <46A6E356.90702@sonic.net> Message-ID: <200707251234.04119.subs@eracc.com> On Wednesday 25 July 2007 Mark Wedel wrote: > Kevin R. Bulgrien wrote: > > The ground (/scorn/guilds/mailed_fist/ground) map in Scorn is made in > > such a way that if you are wearing an XRay helmet you can see behind a > > block view "wall" to see mechanisms that are used to make the map work. > > ?Is this expected behavior, and the map maker did not account for the > > fact that XRay might show things that are not intended for players to > > see? > > ? Yes, and that probably isn't the only map - lots of maps don't take x-ray > vision into account. [...] True, I have seen several maps where the map maker apparently did not think about x-ray or did not care about x-ray. In my opinion x-ray means x-ray and it should be able to reveal everything within its' radius always. It is up to the map developers to take this into account. When I created the "alarm system" on /brest/zorn/castle.upper.floor.two I made sure those with x-ray vision could not see the workings of the system. One could use the information from that to figure out how long one has before the alarm goes off (presuming it did not go off already). Thinking about x-ray vision and how to prevent its' use if needed is How It Should Be Done when designing maps. Not changing (nerfing) x-ray vision. One change I would agree is needed is that true x-ray vision would not show color through walls or in total darkness. Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From lordyoukai at gmail.com Wed Jul 25 17:26:59 2007 From: lordyoukai at gmail.com (Ben Jolitz) Date: Wed, 25 Jul 2007 15:26:59 -0700 Subject: [crossfire] block view vs. xray vision In-Reply-To: <46A6E356.90702@sonic.net> References: <200707241431.27601.kbulgrien@worldnet.att.net> <46A6E356.90702@sonic.net> Message-ID: <46A7CE33.3090605@gmail.com> > > >> The ground (/scorn/guilds/mailed_fist/ground) map in Scorn is made in such a way >> that if you are wearing an XRay helmet you can see behind a block view "wall" to >> see mechanisms that are used to make the map work. Is this expected behavior, >> and the map maker did not account for the fact that XRay might show things that >> are not intended for players to see? >> > > Yes, and that probably isn't the only map - lots of maps don't take x-ray > vision into account. > > There are probably some other ways that can be used to hide this, depending > what needs to be hidden. One could use the 'blocked' space (which is all back) > - put that on top, but change it so it doesn't have any weight and doesn't block > any movement. In this case, people with x-ray would still see the space, but it > would just be black. > > I find Xray vision is so limited that taking the time to hide mechansims that power maps is pointless. If cheating is an issue, let me point out that downloading the maps and opening them with a map editor is so much more effective. Taking the time to make maps x-ray vision proof is ludicrous is so few people might use it for cheating or less than honorable game play. I, for one, have used it to see if I killed demilichs through earthwalls. Its awfully nasty to open up the protective earth wall, see a wall of ice, and have the server lag (murphy's law) at the wrong time to land one back at the last save bed, minus hard gained experience. Xray vision is useful for a small set of circumstances, but is useful nonetheless. >> In this map, there is room to slide everything over and make the block view region >> wider so that XRay would not show the items. Is this the correct way to "fix" the >> map? >> >> Does XRay ever have a range greater than two tiles? >> > > Is it really so bad if x-ray vision players could see the items your guild has? The only way they'll obtain them illegitimately is through an inside job or stealing. > X-Ray vision is hardcoded with a 2 tile range right now. And it completely > ignores any attributes of the space - basically, it just says that all spaces > with 2 spaces are visible to the character, regardless of any other attributes. > > It is conceivable that at some point, different range for x-ray vision could > be added, as well as flags to block it. But I don't really see either of those > happening anytime soon. > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From kbulgrien at worldnet.att.net Wed Jul 25 18:14:08 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 25 Jul 2007 18:14:08 -0500 Subject: [crossfire] block view vs. xray vision In-Reply-To: <46A7CE33.3090605@gmail.com> References: <200707241431.27601.kbulgrien@worldnet.att.net> <46A6E356.90702@sonic.net> <46A7CE33.3090605@gmail.com> Message-ID: <200707251814.11304.kbulgrien@worldnet.att.net> > >> In this map, there is room to slide everything over and make the block view region > >> wider so that XRay would not show the items. Is this the correct way to "fix" the > >> map? > >> > >> Does XRay ever have a range greater than two tiles? > > > Is it really so bad if x-ray vision players could see the items your > guild has? The only way they'll obtain them illegitimately is through an > inside job or stealing. I could care less that x-ray shows items in the guild. That's not what this was about. From mwedel at sonic.net Thu Jul 26 01:00:45 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 25 Jul 2007 23:00:45 -0700 Subject: [crossfire] block view vs. xray vision In-Reply-To: <200707251814.11304.kbulgrien@worldnet.att.net> References: <200707241431.27601.kbulgrien@worldnet.att.net> <46A6E356.90702@sonic.net> <46A7CE33.3090605@gmail.com> <200707251814.11304.kbulgrien@worldnet.att.net> Message-ID: <46A8388D.2000002@sonic.net> Note also that high level electric dragons get x-ray vision as a free bonus. So you end up with potentially a lot of characters having that ability. As far as color of objects through walls - that isn't something that can really be controlled - the client makes non visible stuff grey on its own (for fog of war). There is not currently anyway for the server to tell a client that a space should be drawn in grey. From nicolas.weeger at laposte.net Thu Jul 26 13:27:21 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 26 Jul 2007 20:27:21 +0200 Subject: [crossfire] Moving faceset info from socket to common Message-ID: <200707262027.24491.nicolas.weeger@laposte.net> Hello. Currently, the read_client_images() function, and supporting variables (everything related to faceset, including the actual png pictures), are located in the socket library. I'd like to move this to common (in trunk), for 2 reasons: 1) it isn't related to sockets, except because it's sent to the client 2) for my mapper tool, I need the actual face. But linking to libsocket causes many issues, many undefined functions. So any program wishing to use actual faces will have a hard time to do this :) Objections? -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070726/022b0606/attachment.pgp From subs at eracc.com Thu Jul 26 13:41:36 2007 From: subs at eracc.com (ERACC Subscriptions) Date: Thu, 26 Jul 2007 13:41:36 -0500 Subject: [crossfire] block view vs. xray vision In-Reply-To: <46A8388D.2000002@sonic.net> References: <200707241431.27601.kbulgrien@worldnet.att.net> <200707251814.11304.kbulgrien@worldnet.att.net> <46A8388D.2000002@sonic.net> Message-ID: <200707261341.37288.subs@eracc.com> On Thursday 26 July 2007 Mark Wedel wrote: [...] > ? As far as color of objects through walls - that isn't something that can > really be controlled - the client makes non visible stuff grey on its own > (for fog of war). > > ? There is not currently anyway for the server to tell a client that a > space should be drawn in grey. Right. I was merely dropping that into this discussion for consideration as a feature-add in future releases. It is not a necessity but would be one of those "nice touch" kind-of additions at some point. Gene Alexander -- ERA Computers & Consulting We can provide you with VoIP phone service for your home and/or business. Our VoIP phone service has FREE long distance in the USA and Canada! Contact us! Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From kbulgrien at worldnet.att.net Thu Jul 26 18:10:33 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu, 26 Jul 2007 18:10:33 -0500 Subject: [crossfire] GTK2-v2 Client new layout defined Message-ID: <200707261810.34130.kbulgrien@worldnet.att.net> I did up a new Glade Designer project for the GTK2 client today... I don't claim it is polished, but I already like it better than the original layout. This is the layout at about 1600x1000 or so. http://krayvin.home.att.net/gtk2_new_layout_1280.png This is the same layout sized to about 1280x1000. http://krayvin.home.att.net/gtk2_new_layout_1280.png No code changes were required, only a new Glade layout. I'm prepared to check it in to SVN, but some plan for how to do that should be had. I think each layout should have its generated files pregenerated and checked in so that people do not have to build the Glade configuration in the Designer. I couple of people have ideas on how to tweak the layout to taste. I can likely accomodate if there is consensus on how to put parallel layouts in SVN. Also there would be the issue of naming the client / layout combos. Feedback desired. Kevin R. Bulgrien From kbulgrien at worldnet.att.net Thu Jul 26 18:21:12 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu, 26 Jul 2007 18:21:12 -0500 Subject: [crossfire] GTK2-v2 Client new layout defined In-Reply-To: <200707261810.34130.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> Message-ID: <200707261821.12819.kbulgrien@worldnet.att.net> > This is the layout at about 1600x1000 or so. > > http://krayvin.home.att.net/gtk2_new_layout_1280.png Oops... that's http://krayvin.home.att.net/gtk2_new_layout.png > This is the same layout sized to about 1280x1000. > > http://krayvin.home.att.net/gtk2_new_layout_1280.png > > No code changes were required, only a new Glade layout. I'm > prepared to check it in to SVN, but some plan for how to do > that should be had. I think each layout should have its > generated files pregenerated and checked in so that people > do not have to build the Glade configuration in the Designer. > > I couple of people have ideas on how to tweak the layout to > taste. I can likely accomodate if there is consensus on how > to put parallel layouts in SVN. Also there would be the issue > of naming the client / layout combos. > > Feedback desired. > > Kevin R. Bulgrien From kbulgrien at worldnet.att.net Fri Jul 27 00:01:16 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Fri, 27 Jul 2007 00:01:16 -0500 Subject: [crossfire] GTK2-v2 Client new layout defined In-Reply-To: <200707261821.12819.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200707261821.12819.kbulgrien@worldnet.att.net> Message-ID: <200707270001.17317.kbulgrien@worldnet.att.net> > > No code changes were required, only a new Glade layout. I'm > > prepared to check it in to SVN, but some plan for how to do > > that should be had. I think each layout should have its > > generated files pregenerated and checked in so that people > > do not have to build the Glade configuration in the Designer. > > > > I couple of people have ideas on how to tweak the layout to > > taste. I can likely accomodate if there is consensus on how > > to put parallel layouts in SVN. Also there would be the issue > > of naming the client / layout combos. Feedback from Meflin (IRC) yielded yet another layout possibility. http://krayvin.home.att.net/gtk2_meflin_layout_inv.png http://krayvin.home.att.net/gtk2_meflin_layout_msg.png This too is a fully running layout. A tweak or two is needed. I didn't set the message pane to be default, so right now it comes up on the inventory pane... not helpful for logging in. Shouldn't be hard to fix, but I need to call it a day. The projects I have now are workable. At start, a few errors are thrown that appear to be related to saved window positions... so some work will need to be done there, but otherwise they seem fine. I now have an idea of how to put it in svn. It's not quite what I'd like, but some thing like this works. Glade Designer seems to have strong ideas about where the source directory must be relative to the project file. . |-- Documentation | `-- examples | `-- script |-- common |-- gtk | `-- win32 |-- gtk-v2 | |-- meflin | |-- mwedel | |-- po | |-- rayvin | |-- src | `-- themes |-- help |-- macros |-- pixmaps |-- sound-src |-- utils `-- x11 The glade project files are named something like rayvin.glade, meflin.glade, etc. The project files are modified to build to the gtk-v2/rayvin, gtk-v2/meflin directories instead of gtk-v2/src. To build a layout, you copy the files from one of these directories over top of src. The only file you do not copy is main.c Glade Designer didn't like when I set the source directory to something like src/rayvin. It wanted them right below the directory where the .glade file was. I chose names by in-game characters...does not necessarily have to stay that way if better names can be found. Comments? Kevin R. Bulgrien From kbulgrien at worldnet.att.net Fri Jul 27 00:33:45 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Fri, 27 Jul 2007 00:33:45 -0500 Subject: [crossfire] GTK2-v2 Client new layout defined In-Reply-To: <200707270001.17317.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200707261821.12819.kbulgrien@worldnet.att.net> <200707270001.17317.kbulgrien@worldnet.att.net> Message-ID: <200707270033.45395.kbulgrien@worldnet.att.net> On Friday 27 July 2007 00:01, Kevin R. Bulgrien wrote: > > > No code changes were required, only a new Glade layout. I'm > > > prepared to check it in to SVN, but some plan for how to do > > > that should be had. I think each layout should have its > > > generated files pregenerated and checked in so that people > > > do not have to build the Glade configuration in the Designer. > > > > > > I couple of people have ideas on how to tweak the layout to > > > taste. I can likely accomodate if there is consensus on how > > > to put parallel layouts in SVN. Also there would be the issue > > > of naming the client / layout combos. > > Feedback from Meflin (IRC) yielded yet another layout possibility. > > http://krayvin.home.att.net/gtk2_meflin_layout_inv.png > > http://krayvin.home.att.net/gtk2_meflin_layout_msg.png > > This too is a fully running layout. A tweak or two is needed. I > didn't set the message pane to be default, so right now it comes > up on the inventory pane... not helpful for logging in. Shouldn't > be hard to fix, but I need to call it a day. Hmmm... not impressed... you have to switch back and forth between tabs to see what stuff is... if you're using the mouse to look at things. I'm thinking this layout is not a winner... but at least it was easier than the first one. From juolja at utu.fi Fri Jul 27 01:22:20 2007 From: juolja at utu.fi (Juha =?UTF-8?B?SsOkeWtrw6Q=?=) Date: Fri, 27 Jul 2007 09:22:20 +0300 Subject: [crossfire] Priority feature list In-Reply-To: <46A6EC45.8060702@sonic.net> References: <46A048A3.7040003@sonic.net> <20070722142338.GA12432@cthulhu.desy.de> <20070724213009.02a3197c@alnitak.stiff.utu.fi> <46A6EC45.8060702@sonic.net> Message-ID: <20070727092220.57a6df4c@alnitak.stiff.utu.fi> > I agree that in principle, most of the classes and races should be > about equal in power/balance. A certain race/class shouldn't always be > the best to play. And in broad terms, fighters and spell casters should > be about equal. Agreed and an Nth level fighter should be better in melee than an Nth sorcerer - if we keep the class distinctions. If not, Nth level member of warrior's guild should be better in melee than Nth level member of wizards' guild. One question, though: do we need the overall level at all? We could bind HP, dragon abilities etc to the relevant skill level or, in case of dragon abilities and such that are not related to any skill, to the highest skill level. (If highest skill level is pyromancy when dragon eats the ancient elemental residue, we track pyro as long as it is highest. If clawing exceeds it, we switch to trackin clawing, but do NOT forget how many levels the dragon had already gained in pyro.) I especially like the idea that the accuracy of melee and missile weapons would increase with the relevant skill. Perhaps AC could also increase (and really, we should change this to "higher better"; the lower better system is a D&D relic), when "evading attacks" skill improves? > However, I don't think all races/classes have to be equal. I know in > the past, certain races were made available, but made available as > 'challenge' classes, for lack of better term For those players who > have played a lot, you can now play this other race for a different > experience, as well as something a bit more challenging. Agreed here as well. The "balance" I was referring to, is just that there should be some point in playing all races/classes. If it's harder in the beginning, it should be more rewarding in the end. For example, fireborns are immune to fire, very magical, but fear cold and are physically weak - this is about what the game tells in character selection phase. I think this should mean that fireborns make better spell casters than any race which is not "very magical", but on the other hand they should never be able to carry as much loot as a troll. If, furthermore, we want to keep some races more challenging, like fireborns really are, that's ok, as long as there is some in-game reward for it as well (like dragon immunities or fireborns being the best spellcasters possible). Hard to play means you must be more careful, think more beforehand and so on, but I do not think just thinking and being careful are goals for our players, the in-game rewards are. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070727/e6d47ca6/attachment-0001.pgp From crossfire at kahnert.de Fri Jul 27 10:37:00 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Fri, 27 Jul 2007 17:37:00 +0200 Subject: [crossfire] xp gaining In-Reply-To: <46A5918C.3080003@sonic.net> Message-ID: <20070727153700.GD22565@cthulhu.desy.de> On Mon, Jul 23, 2007 at 10:43:40PM -0700, Mark Wedel wrote: > Juha J??ykk?? wrote: > > With hard cap, players get bored when they hit the cap and the > > character can no longer improve. With impossible-to-reach maximum > > level, there is a gap *below* the hard cap: if level 100 is > > "impossible" to reach, it simply means level 99 is the cap! And > > players still get bored when their characters no longer advance. So > > even without a hard cap, just impossibly difficult-to-reach levels, > > people will get bored exactly like they would with a hard cap. > > That's exactly my thought - to me, having no cap but impossible to > reach exp totals is basically the same thing as a hard cap. So why > not do a hard cap then? First of all, having level 100 aimed to be unreachable doesn't means that level 99 is reachable and leaves a BIG gap between level 99 and 100. Check out line -E- of the xp table: http://wiki.metalforge.net/lib/exe/detail.php/dev_todo:exp_table_log2.png Making level 100 nearly impossible to reach won't make level 99 much easier to achieve. In fact, in such a xp table even level 80 is unlikely. You'll never ever collect all the players at level 99, because level 100 is the "unreachable cap". But there are no longer such frustrating gaps between two levels. And still leaves room for extensions without tuning the xp table. > Now I'm certainly open to the idea that there is no cap on exp, just > a cap on level. I would understand to set a cap on a level to avoid an overflow of the data type used to store xp. But what's the idea of having a level cap and keep xp raising? My idea is to produce a better felling for the player, having more motivation playing on higher levels without becoming bored due to a hard cap. Your idea is to set a hard cap because you can't imagine that there will be more. I say, let it run. Make it more fun for newbies may increase the player number which may increase the number of map makers which may solve your extension problem. If not, people may become level 101 or 102. So what? Does this hurt? I don't expect to see much level 80, so really no big deal. > IMO, adding new regions when characters reach the cap is completely > unrealistic, so I dismiss it as an option. Keeping this option won't hurt. So why do you like to cancel this option without offering the chance to let it happen? > Sure, it sounds great, and could happen, but past experience shows it > won't happen. Isn't one of the goals to make the game more attractive? Won't that increase the player number as well? And the more player you have, the higher the chance to get new map designers. Show the newbies that their work is welcome. Don't stall thinking. Just because you can't imagine that there will be any extensions, doesn't mean that there never ever will be any. Same for me with a working party support. Just because I can't imagine how this will work with CF doesn't mean it's impossible to implement. ;) > But how is this for another method: > Whenever a character gains exp through any method, some portion (<10%) > goes into a reserved pool - these exp don't go into any specific > skill, but do count for overall level. > > The player is then able to move exp from this reserved pool into > skills to increase their level. Hmmm, that sounds like pen & paper version of xp spreading. After finishing a quest every member of the party gets some xp to increase skills. That's for making it faster and easier without the need to calculate the xp for every skill role. But a computer based RPG doesn't need this kind of simplification. Here the computer just counts every skill role and adds xp for that specific skill. This would make it to easy to level up skills. I wouldn't implement it. > > Can we make the map reset delay character specific? > > Not possible - maps are global attributes, so very hard to make > things on them per player. But it should be possible to deny a player to enter such a map, right? Sorry, dungeon closed, already solved. Whatever, not nice but keeps them available for those who didn't solved them, yet. > > > Just reduce the xp gained by a monster if you're higher. Don't > > > give out more xp if you killed a monster on a lower level. The > > > monster xp is the maximum you can get from it. > > > If the boss monster may give between 10K and 100K exp depending on > level of character, very hard to know what is fair. Needs some testing, but should be possible to make it fair. If you stay in the region for your level, you always gain the full xp. Just if you go to lower level regions, you get less xp. Don't calculate it for each map / monster, just for the region. It's unfair against low level characters to harvest their maps. It's not unfair aginst high level characters to reduce their xp gain in lower level regions. They have other options, the lower level characters not. > But this also goes back to above - if you're level 50 and only get > exp for killing level 40+ monsters, once again, skills you have > neglected are basically useless - you're not going to kill level 40 > creatures with level 1 evocation spells (or level 1 punching) Hey, aren't we searching for ways to have more distinction between classes? That's something which will help reaching this goal. So what's the problem with this? I think this is a good option. > This also I don't think completely fixes the problem - it just > forces characters to figure out the minimum creature necessary to get > exp. They should always get some xp. The option to train low level skills should be kept. Just make it less attractive to leave the path of your class choice. So you still have to option to change the class, but it's harder. "Class distinction" is the keyword here... > The exponential crossfire exp tables makes it pointless to kill low > level creatures - the number of orcs a level 50 character would need > to get to level 51 is a huge total. Yes, unlike AD&Dv3, he would > eventually get to level 51. But that is what the exponential table > does - makes killing lower level things virtually useless. I disagree. There is no need to increase the overall level with orcs. You always train specific low level skills with low level monsters. And this will never be useless. > But if you're level 50 and have 6 skills at level 30, you're in bad > shape - you probably can't kill level 50 creatures, so maybe you kill > level 40 creatures instead. But now you're getting less exp for each > creature you kill than you normally would, so that much harder to > improve skills and overall level. I know what you mean and we need to balance that, yes. We could also add some low level random maps at higher level regions that high level characters are still able to train their low level skills against low level monsters without disturbing low level characters at low level regions. If we match on the region and not the monster level, this may work to keep low level maps clean from high level players. It always depends on the goal we like to reach. Should high level characters stay out of maps for low level characters, this should work well. If we like to have more class distinctions, we need to pay more attentions with the levels and the balance as you said. > And maybe the game should be that way - really focus on just a > couple skills per character. But that really has to be clearly > documented - I find it really frustrating to have played a game for > quite a while only to find out I didn't do the correct thing, and thus > the character is basically messed up and I should start a new one. This won't be the only change in the game. So you need to see that in combination with the class guilds. And the guilds will lead you the way to develop a character which looks like the class you've choosen in the beginning. You join a guild to become a sorcerer, and the guild will make you a strong sorcerer. You shouldn't be upset at level 50 that you're not able to kill big monsters with melee. I wouldn't say this character is messed up because the sorcerer decides at level 50 to become a mighty warrior. It will still be possible to train it, but it's a much bigger pain to reach that goal than someone who played as a warrior from the very first beginning. > I much prefer games that are forgiving - maybe you didn't make ideal > choices, but what you did before doesn't have a huge impact now. We can't say that we want more distinction between classes and than make it easy to become a sorcerer out of a barbarian or vice versa. I guess most players already have more than one character. I can't see a big problem with that. And who knows, maybe we found a way to make party playing more valuable. So far nobody needs a party, everybody could become expert for everything. This will change. I wouldn't say that's bad. It's different, yes. And yes, you need to know about it from the beginning. And this job will be done by the guilds introduction. We should define the goals we like to reach and discuss about the ways to implement it. A discussion about several features without the big picture is exhausting. Like this one. Complaining about that we don't have class distinctions on higher levels leads to the discussion how to change that. And than in that discussion complaining about the lack of freedom to learn every skill as easy as the main skills won't help, right? What's the goal, what do we like to reach and than let us discuss how to make it. J?rgen From crossfire at kahnert.de Fri Jul 27 10:38:18 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Fri, 27 Jul 2007 17:38:18 +0200 Subject: [crossfire] xp gaining In-Reply-To: <20070724011057.0b8e9ca2@alnitak.stiff.utu.fi> Message-ID: <20070727153818.GE22565@cthulhu.desy.de> On Tue, Jul 24, 2007 at 01:10:57AM +0300, Juha J?ykk? wrote: > > > The problem here is feature (or monster toughness) creep. It is > > > easy enough to say 'max level for any monster should be 100'. > > The level 100 should be practically / nearly impossible to reach. > > So having level 150 characters is unlikely. > > Increasing levels, perhaps even by adding new areas to the map or > whatever, is probably the only way around this problem. Yes, that's right. Why we don't just aim for this way instead of setting caps? > Another would be if the capped characters would be able to advance in > some other way: in pen-and-paper RPG's people often start building > their own kingdoms etc. Although I have no idea how THAT would work > in cf. But it definitely is fun. Yes, but what's working with a pen & paper RPG doesn't necessarily work for a computer based RPG, too. You need algorithmn and functions for the computer, and just an imaginative dungeon master for the pen & paper version. CF has the problem creating new higher level regions, which is less work than adding a completely new game system. Nice idea, would be fun to have. But we should keep realistic. And adding new regions is hard enough to aim for. > > A high level dragon with clawing level 100 decides to level up > > sorcery will block a low level map for a very long time until the > > sorcery skill is on a desired level. > > Immediately after reading this, I got a great idea (at least I think > it is great): make the skills more like D&D 3rd ed. CF is not a pen & paper RPG. You can't just pick parts of the rules from such a game and implement it into a computer RPG. With a pen & paper RPG you're always part of a group with different character classes. Thus you can have a strong diversity of the classes. This won't work with CF. So we need to find our own rules. > This has the added benefit of making classes matter! Classes should matter, but not that extreme. Here we have the party oriented RPG vs. a more single player oriented like CF. I don't think we should change the rules to enforce party playing. If we manage to add party support, great, but changing rules to make parties inescapable will alienate some (maybe most) of the current players. > It would no more be practically possible to have all skills leveled up > to 50th level. With the guilds, you won't or you'll become ostracized by your guild. > One such modification might be, that M=3 *but* you can only advance in > each of those three skills if its accumulated xp between the two > levels accounts for no less than 10% of the total xp between the two > levels. I.e. 1 xp for evocation, 399999 for pyro and 400000 for > sorcery only advances pyro and sorcery, you need at least 80000 to > advance any given skill between those two levels. This still means > 16000 kobolds... I've proposed something similar for the capability values of the skills, see http://mailman.metalforge.org/pipermail/crossfire/2007-July/011596.html But this won't prevent players from learning this skill, just they won't become masters in all but their primary class skills. > Can we make the map reset delay character specific? With party support (even this rudimentary one of CF) this will lead into some problems. But may be worth to think about more. :) > > Fix that. Don't make high level items equipable for low level > > characters. > > Apart from rods, they aren't: they have item power specifically to > prevent low lever characters from using high level stuff. The item > powers are quite strange for some items, though. That's what needs to be fixed. For example: girdle of Valriel of the Crusade (Str+3)(Dex+3)(Con+3)(Wis+5)(Cha+2)(ac+2)(grace+3)(item_power +1) Shouldn't be hard to equip for a level 1 character if this character has a body part to use it... > > Making level 100 as hard to reach as level 115 is right now, won't > > make level 101 characters more likely even if the xp table is more > > linear. > > D&D 3rd ed has [...] linear xp tables, crossfire does not. Crossfire > has ~exponential xp tables. Sorry, my fault, I meant linear on a logarithmic scale. Check out line -E-: http://wiki.metalforge.net/lib/exe/detail.php/dev_todo:exp_table_log2.png All others produces this big gaps between two levels at the end. Only line -E- will let enough room for extensions if players really hit the maximum. > I think woodsman gives the same amount of XP for all food, a > reflection of the fact that it is equally easy to identify an > orc chop as a dragon steak, No, you'll get totally different xp, depending on the xp of the monsters. That's ok, but needs to be modified, too. If you collect some unidentified hill giant parts and bring them to a level 1 character with woodsman skill, this level 1 character will quickly advance in levels... These flesh parts needs levels, too. For example, you won't be able to identify a level 10 flesh part with a lower level woodsman skill. This way you prefent that level boosting but still keeps the option to level up this skill on a exponential xp table. > whereas brewing a very complex potion (level 10 potion, say) is harder > than brewing a simple (level 1) potion, so the former should give such > an amount of XP that it advances you equally towards 11th level as the > simple potion advances you towards 2nd level. If we always follow the > method of "completing a task that has difficulty level N gives M% of > the XP needed to advance from level N to N+1", it never matters what > the XP(level) function looks like. I wish every xp gaining would be implemented in that consistent way. :) We should discuss that for each skill - see above for woodsman with level on the flesh. > I'd say exponential table is easier Yes, you're totally right and it was my fault to choose an unclear explanation of my train of thoughts. > > > > No, it's not. But don't make monsters getting a higher level > > > > than the maximum of the xp table. > > > Sure we should. High level (150) monsters you can only kill with 4 > > > 100+ level players. > > No, we shouldn't. ;) > > Err... I do not quite agree here. It is a very intriguing idea to have > monsters that are simply too powerful for (practically) any character to > kill. Whether the xp table goes up to the level of the monster is > irrelevant, though. What does it matter if there is 100 lines instead of > 150 in the exp_table file? In one case the monsters are part of the game rules, in the other case not. Nothing more. It won't hurt to have 50 more values in the exp_table file, so why not? Especially if they're generated by a function... Besides that, just setting the level of a goblin to 150 won't make it immutable. Making strong monsters depends on other things than the level. So what? Having monsters outside of the exp_table means nothing more than having monsters outside of the game rules for players. That's not consistent and won't help in any way. Ok, won't hurt either. ;) I just like consistent game engines. Same for the formulas, how could items exists if there is no formula to make them? What's wrong designing the game engine in a way that the object of the world fits into the rules the players have to follow? J?rgen From nicolas.weeger at laposte.net Fri Jul 27 12:59:46 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 27 Jul 2007 19:59:46 +0200 Subject: [crossfire] Documentation revamp, was spoiler generation In-Reply-To: <469AED57.7010503@sonic.net> References: <200706100016.32359.nicolas.weeger@laposte.net> <200707151259.15636.nicolas.weeger@laposte.net> <469AED57.7010503@sonic.net> Message-ID: <200707271959.59545.nicolas.weeger@laposte.net> > Can you give some better examples of that? > > I will admit that the current layout of documentation (or maybe more > specifically, the doc dir) isn't great. To find out if something is > documented, one basically has to resort to grep, as what file something is > documented in isn't really the most consistent. Yes, now I can :) Check out trunk, run doxygen, point your favorite browser to /html/index.html You should have a nice main page (ok, the id doesn't look nice, will need to be fixed...). Check the various subpages (objects is probably the most advanced). IMO this is a nice documentation bundle that could be made. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070727/a9f7b530/attachment.pgp From crossfire at kahnert.de Fri Jul 27 14:42:59 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Fri, 27 Jul 2007 21:42:59 +0200 Subject: [crossfire] xp gaining In-Reply-To: <20070724214200.45749c32@alnitak.stiff.utu.fi> Message-ID: <20070727194259.GA14966@cthulhu.desy.de> On Tue, Jul 24, 2007 at 09:42:00PM +0300, Juha J?ykk? wrote: > > the other problem with this, and the other idea of limiting exp > > gain based on overall level, is that it really means you need > > balance your skill usage as you advance your character. > > It does not have to be overall level, it could equally well be the > highest skill level as well. That's a good idea, it will ease this problem a lot. Indeed, this is a very nice solution. :) > Or, when killing monsters, it could even be the skill you use to kill > it (although then we again will have high level characters in low > level maps when they start a new skill). That one I don't like. It depends on the goals we like to reach. It's still an option. This one will make it easier to reach high levels for each skill which will obviate the idea of having more distinctions between classes... On Tue, Jul 24, 2007 at 11:18:45PM -0700, Mark Wedel wrote: > To come up with a new high level area, you probably need around 50 > maps - that is a lot of work - especially if you want good maps, and > not just things with scaled up monster and no plot. If we reorganize the entire world, we can recycle a lot of the maps and adjust the monster levels and add a new plot. I think that's something I could do, too. ;) > New items can be pretty easy - we'd need to extra work for spell > research, but for new item to be created via players, that is really > just adding some new formula - figuring out a good formula may not be > easy, but one could probably come up with 5 new formula in the time it > takes to do a map. I would write a script to figure out which treasure is how likely to be found. Out of this we can develop formulas which reflects the relative frequency of items. Common things should be out of common ingredients. Having formulas which needs rare stuff to create low power items are discouraging. But redoing alchemy is nothing I see for CF2. We have to set priorities and CF2 should have the priority on newbies to attract more players. > Just a note on this - I do believe that as part of a revamp, it > should be possible to get to high level in every skill. I hope you don't mean a high level in every skill of the same character. We won't create a lot of distinctions between classes this way... If you mean for skills of your class, yes, I totally agree. > Right now, for some skills, there is basically some practical limit I would say "sense curse" is the hardest skill to level up. Same for "lockpicking", "bargaining" and "throwing". "Disarm traps" and "find traps" are also very hard to level up. The easiest skill ever is "inscription". This needs to be fixed. For example make pens consume charges. And reduce the xp gain. It's hilarious to reach level 10 in seconds via inscription. > Those things need to be rebalanced I fully agree. > - it should be something like 20 books at current level equals a level > in literacy (which means level 100 literacy would be 2000 books, > presuming they are all of the appropriate level). That is actually a > lot of books if you think about it. You mean I just need to read 20 books to reach level 100 from level 99? Nope, I don't like that rate... Each skill should take similar time to develop. And killing 20 monsters won't bring you from level 99 to 100, right? > That said, the ability to shuffle some experience gives a way to get > exp in harder to advance skills As I said, I don't like this xp pool. We should create a better concept to get xp in every skill. > In a sense, it is sort of like the AD&Dv3 idea of skill points you get > each level. That's simplifying skill development because of the pen & paper nature of AD&D. It's just not appropriate for a computer RPG. And you'll hardly get class distinctions this way. J?rgen From kbulgrien at worldnet.att.net Fri Jul 27 18:20:54 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Fri, 27 Jul 2007 18:20:54 -0500 Subject: [crossfire] xp gaining In-Reply-To: <46A5918C.3080003@sonic.net> References: <46A43098.2000101@sonic.net> <20070724011057.0b8e9ca2@alnitak.stiff.utu.fi> <46A5918C.3080003@sonic.net> Message-ID: <200707271820.55205.kbulgrien@worldnet.att.net> This isn't really a reply to a reply so much as it is to the thread. Can you really force people to play "right" or is there even a "right" way to play? I don't understand what is so fun about screaming up through levels anyway when there is so much to just discover and play in bigworld. There is a pile of fun in Crossfire that people just don't even try to get out of it I think. Why on earth would a level 100 player, with a game that has such richness in race, vocation, magic, religion, not want to start over with a completely different combination? The people with problems up at level whatever are only part of the playing population. To me it is downright disgusting to listen to some level 100+ braggart blabbing on chat that he just made 2 levels making scrolls. I hate that. I could care less. I can't believe that is fun, but it must be, mustn't it? When asked how many maps were played, the answer is none... or whatever... Fine, tweak here a bit, there a bit, suggest ideas, but the whole thing about making a new world only for high-level characters... please. At some point it become ridiculous when there is so much that goes unplayed already. How about working on stuff that actually helps players discover a new way of playing... like scoring based on % of maps solved, etc. I think there are a lot easier, if more creative, ways to fix crossfire than beating level caps to death. Besides, if the devs are all high level players... be careful not to cripple the slow and steady player who takes a few years to savor the game never making 100 once... but... nobody is paying anyone anyway, so where is the right to complain... ;-) And then again... maybe the fun part isn't playing... or coding... but talking... cogitating... etc. and who says that is a wrong way to have fun anyway... LOL. Full circle. Enjoy. From crossfire at kahnert.de Sat Jul 28 05:06:33 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sat, 28 Jul 2007 12:06:33 +0200 Subject: [crossfire] "the right way to play" (was: xp gaining) In-Reply-To: <200707271820.55205.kbulgrien@worldnet.att.net> Message-ID: <20070728100633.GA32106@cthulhu.desy.de> On Fri, Jul 27, 2007 at 06:20:54PM -0500, Kevin R. Bulgrien wrote: > Can you really force people to play "right" or is there even a "right" > way to play? There is no "right" or "wrong" way to play. Just because some people think that having distinctions between classes and others like to have uniform characters doesn't mean the one is right and the other one wrong. It's simply a matter of preference. It's up to the developers to make the game they like and up to the players to play the game they like most. > I don't understand what is so fun about screaming up through levels > anyway when there is so much to just discover and play in bigworld. Just because you like to travel around the world doesn't mean that you have to enforce everybody to explore the world. ;) Other players like to level up their characters in a single map... There are also players who likes to see the character jumping into a fountain. Fun is what brings light into life. > There is a pile of fun in Crossfire that people just don't even try to > get out of it I think. They simply don't know about these things and there is no guide to lead them. > When asked how many maps were played, the answer is none... Yes, they don't know where to go. Check out the "reorganization the entire world" thread. It's about a way to offer players to explore the world and find out new things without being one of the game developers. Having a storyline for each region will lead the players to all interesting places. > How about working on stuff that actually helps players discover a new > way of playing... like scoring based on % of maps solved, etc. Reorganizing the world would help a lot. Adding new hiscores for different part of the games will satisfy those who like to level up their characters even on a single map by inscribing thousands of scrolls... And having a hiscore with " of quests solved" will [maybe] encourage those map campers to explore the world. > I think there are a lot easier, if more creative, ways to fix > crossfire than beating level caps to death. Feel free to tell us more about your ideas. ;) > Besides, if the devs are all high level players... Yes, and I think some of them don't care about low level characters. But I think most of the fun is on lower levels. That's why I would like to focus on this part first, before thinking about caps; especially if all have to start over with level 1 characters. Who of the high level developers tried to level up summoning (without xp sharing via party!) with a first level character? It's a pain! Don't forget the newbies. And don't waste your time by thinking about the right way to play. Think about game rules which allows most of the players to have fun. And for the other players, well, they're free to change the game. You can't satisfy all at the same time. And don't hesitate to add rules which won't hurt. If most don't care about such a rule and a few like it, hey, what's the problem adding it? This will simply increase the number of satisfied players. :) J?rgen From crossfire at kahnert.de Sat Jul 28 08:03:44 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sat, 28 Jul 2007 15:03:44 +0200 Subject: [crossfire] Party Support In-Reply-To: <46A586D9.1090403@sonic.net> Message-ID: <20070728130344.GB32106@cthulhu.desy.de> On Mon, Jul 23, 2007 at 09:58:01PM -0700, Mark Wedel wrote: > Juergen Kahnert wrote: > > The only reason I know for a CF party is, to level up a lower level > > character. And regardless of the party support of CF, I would > > remove the xp sharing for killing monsters. > > Some other advantage is that there are the chat party chat commands, > so can be easier to communicate with other people if in a party. Sure, it's a party feature which should stay. But that's not the main feature for creating parties, isn't it? ;) > But how parties should work out is something to be thought about. > Server level support (being able to form parties, exp sharing, etc) > may not be strictly needed. How do you handle informations (health and things like that) about your party members? This needs server support. > So it may be more a thing that players should be able to cooperate on > a single map, and somehow share the rewards. Yes, real multiplayer maps / quests would be nice to have. I just lack on ideas how to create some with the current system. Some characters are able to clear a map before any other member of the party has a chance to talk about the tactics... > OTOH, if classes have more distinction, some classes may need party > assistance in order to advance. If you want to play a pure healer, > you can't expect that character to be going out and killing monsters. I wouldn't like CF if I need a party to play. If I'd time for playing this way, I would choose WoW... > But could be very valuable as part of a party, So, and you remove the ability to heal from each other class? No longer rods of heal or restoration scrolls, potion of healing, etc. for everybody? The focus is still single player maps. Don't destroy that just for a rudimentary party support. > so so want some way for the character to get exp. Make the "healer" getting xp from healing. No xp sharing, please. Let it make more xp the higher the healed character is, or whatever. But make sure that xp comes out of the skill you use. > The other more general problem is that if you don't have exp > sharing, players can to some extent do it unofficially - the fighters > weaken the monster, take the damage, etc, so that the healer can > finish it off. Doesn't matter. Count the damage each character made and divide the xp pro-rata. If not, won't hurt. But I won't like to play a healer if I need a warrior which weakens the monster that I get the chance to gain a little bit xp... Make the xp comes out of the skill will solve that problem. > > 1) Slow down combat speed. Some player just won't like that, > > especially no slower movement. So the only chance for that is to > > reduce weapon speed. May work. > > > > But on a 2D tiled map with fast moving monsters you could quickly > > run out of escape routes. Slower movement will help, too. But I > > think no majority for a general slowdown. > > I don't think there are enough details on that. In my thought, > movement would really only be slowed down for high level characters, > and in fact sped up for lower level characters - in a sense, reduce > the speed variance that currently exists, so that high level > characters don't move 5 times faster than low level characters. Sounds good for me. But long travels around the world will probably be fatigueing. It's a good start for better party support. But traveling around the world shouldn't be boring. Don't forget that not every race is able to wear speedboots... > > 2) There are simply no spells for party support. Most support spells > > are self directed or combat spells. Nothing special for the party. > > Protection spells, bless, healing, ... all of them needs a "party > > version". > > I also think that even if combat isn't slowed down, many of these > spells should have longer durations - at least in minutes in real > time, so you could help out the party before they head to the next > level, etc. Yes, a longer duration for some spells is nice. But you need to take away the ability to cast such spells for all but a few classes... And don't forget to let casting such spells increase the xp for that skill. At the moment such assistant spells are less useful because of the minor effect and / or the short duration. > > 3) If you have spells as pointed out at 2), you have to know to cast > > which spell on whom. > > so it may be that when part of a party, more information is shared > with party members - you can see all your party members resistances, > which are currently boosted by spells, current hp, sp, grace, if party > member is under effect of any spells (confusion, paralyzation, slow, > etc). We also need spells to cure paralyzation, slow, etc. Some of them, like paralyzation, only makes sense for party playing. > As said, this would probably have to be done in another window/pane, > but would give a way to quickly see who is in trouble. > > Perhaps as part of that is tie in the party spells with that - that > window has some way to make it easy to cast 'heal other' on different > party members - drag and drop, pull down menus, something. And as > long as the caster and recipient are on the same map or close enough, > the spell works - don't need to be next to the character. Sounds good. Maybe a little bit tricky to make it work well. I don't like to fiddle around with the mouse in a fast battle. That may produce situations like the chat-key in combat. Hit the wrong key and become overrun by the enemy. > In this way, the spell caster could hang back a bit and help out > party members. May work, need some more details, for example do you need at least 1600x1280 resolution to find a layout which offers you to see the party members in an extra window? > > 4) What about characters in the second row like archers or spellcasters? > > It has been suggested that there should be a way to target creatures > not in the front row But how? Do you need the mouse to click on the monster? Than move around with the keys to switch back to the mouse because the monster also moved? You have to find a way to make the game fully playable with the mouse or this won't work. Or find a way to make it work only with keys. Or both. But a combination out of both won't work. > likewise, monsters should have the same advantage, so a bunch of orc > archers behind orcs with swords would be pretty deadly. Monsters will have no problem to aim, but the players... And such a feature will boost the level of goblins. No newbie will survive the encounter with a bunch of goblin archers using this feature. > Movement itself is a problem - acting lik pet move sort of works, > unless both people are trying to move the same direction and end up > swapping places with each other and not actually attacking the > monster. May be fun to see for a short time, but won't help to kill the monster. > Don't have a great solution there. Neither I do. > > After you solved all this problems without changing the game that > > much that most of the current players still likes to play CF, you > > can work on point: > > > > 5) Create party quests. > > But that isn't really the point - just because points 1-4 do not > currently exist, or are not currently used, doesn't mean we > can't/shouldn't be able to think about how parties/quests would work > if those points did exist. I don't have your imaginativeness to create maps which works well with features nobody knows how they look like... I always thought you need to know how the system looks like to create well working addons for this system. How do you develop addons without knowing about the system? > It may be like several features - not used by many people. But it > seems to me that the above points really don't have anything to do > whatsoever about how you give rewards - they are completely separate. Sure, giving out rewards is more independent from the given points. But creating multiplayer quest maps is not. Why thinking about the finish of a multiplayer quest if you have no system to create multiplayer maps? And adding multiplayer rewards into single player maps is not necessary. > We could certainly say that CF is a single player RPG game and that > there is no party support, No, I don't mean "no party support", but "limited party support" as long as we don't know how to offer a "full featured party support". > and so yo really shouldn't work with any other players on dungeons or > quests, because simply put, you'd be disappointed/upset when you find > you don't get a reward. Did you never solved a quest to find out that the quest reward is useless for you? Will this cancel your xp gain / the fun you had? > That is certainly an option, but I haven't seen a lot of people saying > that is what should be done. An option is to keep the party support as is (but remove xp sharing) and collect some more ideas of how to improve the party system. As long as we don't have a working party system, no need to create party quests. J?rgen From mwedel at sonic.net Sun Jul 29 01:09:50 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 28 Jul 2007 23:09:50 -0700 Subject: [crossfire] Party Support In-Reply-To: <20070728130344.GB32106@cthulhu.desy.de> References: <20070728130344.GB32106@cthulhu.desy.de> Message-ID: <46AC2F2E.1020609@sonic.net> Juergen Kahnert wrote: >> So it may be more a thing that players should be able to cooperate on >> a single map, and somehow share the rewards. > > Yes, real multiplayer maps / quests would be nice to have. I just lack > on ideas how to create some with the current system. Some characters > are able to clear a map before any other member of the party has a > chance to talk about the tactics... This is a bigger/tougher problem to tackle. There are some multiplayer maps, but really, most of them only require multiplayer because two levers need to be pulled at the same time - making maps like that is easy to do, but doesn't really add much in the way of cooperation - one player can still go in, kill everything, then the rest of the people come in to pull the levers. But would be nice, which may happen with class/race/skill rebalancing, is for parties to be able to handle tougher dungeons than they might otherwise be able to handle on their own, and thus get better items/more exp. For example, if 4 level 40 characters team together, and as such, are able to complete a map for level 60 characters, that may prove some good incentive. Right now, things go so fast (and so many large effect spells) that it really doesn't work that way - all 4 level 40 characters would probably be killed quickly on a level 60 dungeon. >> But could be very valuable as part of a party, > > So, and you remove the ability to heal from each other class? No longer > rods of heal or restoration scrolls, potion of healing, etc. for everybody? I didn't say that. But using such items takes some amount of time, at which point you're not casting spells or inflicting damage. If you have someone else healing the fighters, instead of them using those items, their effective damage rate goes up. There has been a lot of discussion about rebalancing/redoing classes - that is completely unrelated to party support (the discussions about redoing it are really separate), but those changes may make playing with parties more desirable. This is especially true of spells are distributed more evenly among levels. If you're character can be level 30 in both one handed weapon and prayinging, or in the same time it takes to get that, level 50 in one handed weapon and level 5 in praying, there are some choices there. If playing with a party is feasible, you may no longer feel the need to increase praying skill much, and if you're level 50 in melee, that allows you to do tougher maps than if you are level 30 in both. As noted, those levels are presuming equal playing time. It may/probably would be possible to get level 50 in both, but that is obviously going to take longer than a 50/5 split. >> so so want some way for the character to get exp. > > Make the "healer" getting xp from healing. No xp sharing, please. Let > it make more xp the higher the healed character is, or whatever. But > make sure that xp comes out of the skill you use. Things like that don't work very well. Off the top of my head, I can think of numerous abuses that players would quickly come up to get healing exp up (players damage each other, etc). I personally think exp sharing should be part of the game. Now it may be that exp sharing shouldn't be equal like it is now - maybe the person that kills the monster gets 50% of the exp, and the rest of the party splits up the remaining 50% (or maybe even more, based on members of party - eg, for 2 member party, it is 75/25 split, for 3 it is 50/25/25, for 4 it is 40/20/20/20 or something - don't know - don't really need to figure out exact formula right now). Under such a model, those not killing creatures get exp more slowly, but still get something - if the only way to get exp is by killing creatures, pretty much means that every class must be something that goes and kills bunches of creatures, which I don't think is good. > > Doesn't matter. Count the damage each character made and divide the xp > pro-rata. If not, won't hurt. But I won't like to play a healer if I > need a warrior which weakens the monster that I get the chance to gain a > little bit xp... That doesn't work for several reasons. First, what do you do about creatures with fast regeneration? If you get damage for each hit, you now open up a way for infinite exp. The alternative is at some point the monster becomes with 0 exp. The other thing is that IMO, killing the creature should be rewarded much more than damaging it. It is easy to damage a lot of creatures, but may be harder to kill them (regen rate, damage they do to you, etc). You also get another potential abuse here - players going into a map, doing some damage to a high exp monster they have no hope of killing, and then retreating before they get killed. >>> 1) Slow down combat speed. Some player just won't like that, >>> especially no slower movement. So the only chance for that is to >>> reduce weapon speed. May work. >>> >>> But on a 2D tiled map with fast moving monsters you could quickly >>> run out of escape routes. Slower movement will help, too. But I >>> think no majority for a general slowdown. >> I don't think there are enough details on that. In my thought, >> movement would really only be slowed down for high level characters, >> and in fact sped up for lower level characters - in a sense, reduce >> the speed variance that currently exists, so that high level >> characters don't move 5 times faster than low level characters. > > Sounds good for me. But long travels around the world will probably be > fatigueing. > > It's a good start for better party support. But traveling around the > world shouldn't be boring. Don't forget that not every race is able to > wear speedboots... More use of transports could be added. Note that right now, even for a moderate/low level character without high speed, unless going cross country through mountains, it never takes more than a couple minutes real time to get to any point. Things won't be any slower than that with a revamp - what changes is characters won't have 1.0+ speed. I think in some ways, reducing speed may be useful - right now, it really doesn't make much difference where you character is based out of, as you can get anyplace else in the world very quickly. If it actually took some time, characters may instead base themselves where they are currently adventuring, which would help keep the high level characters in the same area, and not near the low level characters. >>> 4) What about characters in the second row like archers or spellcasters? >> It has been suggested that there should be a way to target creatures >> not in the front row > > But how? Do you need the mouse to click on the monster? Than move > around with the keys to switch back to the mouse because the monster > also moved? > > You have to find a way to make the game fully playable with the mouse or > this won't work. > > Or find a way to make it work only with keys. Or both. But a combination > out of both won't work. Aiming with keys would be difficult. Aiming with a mouse would be easy, but as said, going between keyboard and mouse is a bit annoying. I'm not sure what it would take to make the game completely playable with the mouse (and completely may be a bit of an overstatement - some things may only be doable by keyboard, but if those are things you don't do in combat, probably ok) Movement can easily enough be done with the mouse. Likewise, firing can be done with mouse. It's things like selecting spells - in the clients, you can use the spell windows, but those take up a bunch of real-estate. Some form of quick pulldowns/icons could perhaps be done to select spells - not sure. >>> 5) Create party quests. >> But that isn't really the point - just because points 1-4 do not >> currently exist, or are not currently used, doesn't mean we >> can't/shouldn't be able to think about how parties/quests would work >> if those points did exist. > > I don't have your imaginativeness to create maps which works well with > features nobody knows how they look like... > > I always thought you need to know how the system looks like to create > well working addons for this system. How do you develop addons without > knowing about the system? But lets take it from this view: Presume you have party support (not that big a presumption). And presume you have some way of recording the party members that completed a quest (killed the monster). At that level, it then doesn't take too much imagination to think about when the party returns to town, how they get a shared reward. You don't necessarily need to know how a party will work together in order to know there should be some way to reward it. And in many ways, it shouldn't make a difference - if that NPC in town wants something done, he probably doesn't care how it got done - he just cares it did get done. Now as programmers of that NPC, we should take into account that people may work in groups to get that task done. But my real point here is that we really shouldn't pretend that parties won't exist, and don't have any support for group rewards at all. > > Did you never solved a quest to find out that the quest reward is > useless for you? Will this cancel your xp gain / the fun you had? If I constantly did quests as part of a party, and found out that on all quests, only a single person got a reward, that would be a big disincentive to ever work as a party. And I still say that you don't need party specific maps to think about party quest rewards. Many single player maps may be played by parties, and if there is a quest, it should be thought about how that reward would be shared (alternative rewards, each person gets the reward, whatever). From mwedel at sonic.net Sun Jul 29 01:31:32 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 28 Jul 2007 23:31:32 -0700 Subject: [crossfire] Moving faceset info from socket to common In-Reply-To: <200707262027.24491.nicolas.weeger@laposte.net> References: <200707262027.24491.nicolas.weeger@laposte.net> Message-ID: <46AC3444.10605@sonic.net> Nicolas Weeger wrote: > Hello. > > Currently, the read_client_images() function, and supporting variables > (everything related to faceset, including the actual png pictures), are > located in the socket library. > > I'd like to move this to common (in trunk), for 2 reasons: > 1) it isn't related to sockets, except because it's sent to the client > 2) for my mapper tool, I need the actual face. But linking to libsocket causes > many issues, many undefined functions. So any program wishing to use actual > faces will have a hard time to do this :) I don't have any objections. From crossfire at kahnert.de Sun Jul 29 04:20:28 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sun, 29 Jul 2007 11:20:28 +0200 Subject: [crossfire] Priority feature list In-Reply-To: <20070724213009.02a3197c@alnitak.stiff.utu.fi> Message-ID: <20070729092028.GA27970@cthulhu.desy.de> On Tue, Jul 24, 2007 at 09:30:09PM +0300, Juha J?ykk? wrote: > Partying is "essential" for multiplayer games, at least some > rudimentary support either with or without xp sharing. Multiplaying is > the sole reason I prefer CF over things like Wesnoth. Sure, don't remove party support, doesn't matter if it's rudimentary. But don't create a pure multiplayer game out of CF, this won't work. > BTW, another multiplayer game we might learn from is Widelands. It > does not do interactive battles, but it does have very nice graphics > (in 2D!) and it manages to fit stunning amounts of info into a 800x600 > window! That's made with higher resolution. You need to exchange all images in CF to add additional informations into the map view. And overlapping windows are no solution for CF. You won't like it to see your party member informations in a windows which overlaps your map view where a retributioner is slashing your character because a party member cleared the way for him... :-O > > Having a hard start as a mage turns up into an impossible mission on > > higher levels. That's not fair. If it's hard in the beginning, it > > should become easier later on, not harder or impossible... > > I think everyone has agreed on this. Is it ok to list this in wiki? I would like to see an overview of the goals we like to reach. And for each goal we discuss the solutions and write them into the wiki. Some wishes are diametrically opposed to each other. So we need the overview of what we like to reach. > fireborn would still only be able to apply 6 items against human's 12. > Of course, there *could* be some extremely powerful fireborn -item, > but I'd rather give fireborns a couple of "fireborn tentacles" or > something like that to wear the fireborn stuff at. Same for me. Or let the intrinsic abilities increase with levels. For example add +1 to the magic of a fireborn for every 10 levels. Something like that. For every race which lacks on slots and has no other real benefits. Some high level items are very powerful and a "night vision" or similar won't compensate the lack of a slot on higher levels. > > And that a skill with a grade of "Expert" is better than one with > > "Novice" can't be called confusing, right? > > Is 10th level Expert better or worse than 100th level novice? And what > the heck does a 100th level novice mean anyway? Suppose you are 100th > level novice carpenter. Does that mean you can only chop logs into > pieces and nothing else, but you can do that extremely well, while a > 10th level expert can sculpt beautiful statues, but is not as good at > chopping logs as the other guy? Now I understand your point. Wow, took some time... I'll revise this idea. > > That is girdle of Valriel of the Crusade > > (Str+3)(Dex+3)(Con+3)(Wis+5)(Cha+2)(ac+2)(item_power +1)(grace+3) > > Does this actually exist..? Sure... incredible, isn't it? > > I would like to see a formula for almost every item in CF. Who made > > those stuff if it can't be made? ;) > > Me too, and with my "generalised" formulas we would not need to > separately invent a formula for every single item, since ring ac +1 > and ring ac +5 would have the same ingredients, just different amounts > and difficulties. Yes, as I said, I like that idea. > > > beginners with a lvl 1 fireborn sorcerer (magic only, no melee, not > > as a monk - no meditation) and the same with a troll warrior (melee > > only, no magic). > > Been there, done that, many times. Not a problem, but true, the troll > probably cleans the place faster "Probably faster"? The troll runs through everything and the place was cleaned within seconds. The fireborn sorcerer (without meditation) wasn't even able to kill all monsters from the right side of the map before reaching 500 food. :-O And no chance to clear the left side with the generators before starvation. Using melee this changes a lot, but the competition was about magic vs melee. > - that's as it should be. The problem, as everyone has agreed, comes > at higher levels, where it is STILL easier and faster for the troll. I beg your pardon? A few seconds for the troll vs half an hour for the fireborn sorcerer without being able to kill the ogre with fireballs? I had to buy "small lightning" to defeat the ogre. No, that's not "as it should be". This is just ridiculous. > > If you have luck and you got small fireball with pyromancy skill. If > > not, you may start with detect magic or slow. And now? How to play a > > sorcerer unwilling / unable to do melee? > > That might be troublesome. I've started quite a lot of sorcerers and > never had useless spells at first level. You'll get a level 1 sorcerer spell, one of these: detect magic magic bullet magic missile marking rune probe slow spark shower This gives you a chance of 3/7 to get a spell you're able to make xp. > Is there such a spell in level 1 sorcerer treasure list? How you're able to start a lot of sorcerer without ever getting "probe" or something like that? I'm impressed about your luck... > The fireborn always gets pyromancy and there are only killing-spells > in pyromancy. Yes, fireborns, but those will always choose monk, isn't it? > Non-fireborns might get to trouble, though. "Might"? No, always without meditation and at least half of the time with a useless starting spell. > This could, however, be fixed by letting sorcery gain xp from > non-fatal spells as well, like slow, detect magic etc. But how to > prevent their abuse, then..? How to abuse this? If there is no more magic items undetected, no more xp. If you don't slow down a monster, no xp as well, ... What's the problem with this? > > Prove it. Try it out, feel the difference. Again, not playing a > > monk, playing a sorcerer! > > I won't be starting new characters at the moment, but I've played > quite a few fireborn sorcerers before I realised how useful monks are. > You just need patience. (And lots of food.) It's not developing a new character, it's just a testing character to clear beginning. In the past I bet you used melee as well instead of pure magic. And any other race than fireborn wouldn't even get the +2 magic. Much more patience. For what? Unable to defeat the high level monsters later in the game. Yes, I also guess, everybody understood this point. Re: segregating players to regions for their level > > I know Mark don't like this idea, because it's lots of work. But you > > just said, you disklike it. What are your reasons? > > It's an artificial limitation into what a character can do in a world. The limitation will be to not commit suicide at a higher level regions by facing monsters you can't handle. That's a problem? > I dislike those. I even dislike the fact that I cannot simply break > any wall I choose (but realise that it is something that can not be > changed without huge amounts of work). Segregating players into > different areas is something that is not necessary in my opinion. I > believe there are other ways to prevent abuse as well. It's not about abuse, it's about a guide for newbies to find all the places which are worth to be found. Most newbies don't even know where to go and what to do. Having a storyline quest in regions best suited for their level will change that. > > Having regions for the same level will increase the fun for the > > players. I saw so much newbies unable to find suitable dungeons. > > That's a totally different thing. It would be difficult to find > dungeons even with level-based segregation if there are not enough > clues around. That's why there has to be a storyline. A quest for every region with lots of side-quests. > > Some got their fun spoiled by high level characters boosting them > > ten or more levels by a short party at a high level map. I think xp > > sharing in a party is very bad and should be disabled. > > Two things here: 1) joining a party is voluntary, so if someone > voluntarily spoils his game, why should we care? My first experience with CF: I joined a server, didn't know anything about CF, found a player who said what I have to do. I joined his party, teleported to humanoid train, got lots of xp and items. The second time I didn't found any suitable maps, all the beginner maps are boring, and no idea how to find maps for my quick boosted character. I wasn't even able to find again the humanoid training centre (neither with this nor with lots of other characters) later on... I stopped playing CF for a year or even longer. > 2) sharing xp in a party is paramount, especially if we move towards > "healers stand back and cast cure wounds and do not kill monsters" I don't think so. If you can't become better due to performing your craft, the game engine is bad. Let the healer gain xp from healing and you don't need xp sharing. > Xp sharing can be tuned, however. It would be, for example, be > possible to not give any xp to party members who are 10 levels lower > than the guy killing the monster is. May be a solution, but I still can't see how a character behind a wall is able to learn anything from the actions of other characters in the same party? I would expect, _if_ there is any learn effect by watching others, this should be something within the line of view, not the membership of a party. And only a fraction of the xp. > Or, we could figure out other ways to prevent people from spoiling > their gameplay. For example? Newbies don't know anything about the game. They become spoiled before they realize what's going on. Dropping powerful items for low level characters is kind of spoiling, too. Let us segregate the characters on different levels and all this is less likely. Maybe we add the region level to every items, so you can't equip an item out of a region you have no access right at the moment. J?rgen From crossfire at kahnert.de Sun Jul 29 06:13:33 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sun, 29 Jul 2007 13:13:33 +0200 Subject: [crossfire] Priority feature list In-Reply-To: <46A6EC45.8060702@sonic.net> Message-ID: <20070729111333.GB27970@cthulhu.desy.de> On Tue, Jul 24, 2007 at 11:23:01PM -0700, Mark Wedel wrote: > I agree that in principle, most of the classes and races should be > about equal in power/balance. There are two styles possible. Make all classes and race combination equal in power from the very first beginning. Or you have some classes / races which are weaker in the beginning and become stronger on higher levels than the other ones. A bad combination is having weak classes / races which always stay weak. > A certain race/class shouldn't always be the best to play. I fully agree. > And in broad terms, fighters and spell casters should be about equal. Which style do you prefer: Equal strength from the first level or make spell caster become stronger than an equal level fighter? > However, I don't think all races/classes have to be equal. I know > in the past, certain races were made available, but made available as > 'challenge' classes Challenging in the beginning, on mid / high level or always? There is no need to play a combination which won't never ever give out any advantages. > I don't think everything needs to be perfectly balanced. No, not perfectly balanced. But it depends on the style how much differences between class / race combination is acceptable. On Fri, Jul 27, 2007 at 09:22:20AM +0300, Juha J?ykk? wrote: > One question, though: do we need the overall level at all? For things like stat improvements an overall level is fine. I would keep it. > We could bind HP, dragon abilities etc to the relevant skill level What's an appropriate skill for HP? Overall level is not bad. This is well proven. > and really, we should change this to "higher better"; the lower better > system is a D&D relic Yes, the higher the better is easier to understand for newbies without D&D experiences. And having attack and defense values for every skill, not only "Wc" is more logical. It's easier to understand why someone is harder to hit who's using a small shield and a short sword (easier to defend) than someone with a plate mail and a two handed sword. But in fact, using a small shield gives you ac -1 and a plate mal ac -5. And the monsters will now miss the slow one with the heavy armour more often. This D&D style isn't really self explaining... It's ok for pen & paper dice rolls, but that's it. Summary: Some classes and races are more challenging to play in the beginning, but should get some in-game rewards on higher levels. What means on the other hand that those who are easy to play in the beginning become harder to play on higher levels. Making the speed of the weapon and the weight of the armour affecting the dodging skill is more logical. Introduce a "Dc" skill for the defense and remove "Ac". The armour is well represented with the percent value. J?rgen From crossfire at kahnert.de Sun Jul 29 12:13:58 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sun, 29 Jul 2007 19:13:58 +0200 Subject: [crossfire] Party Support In-Reply-To: <46AC2F2E.1020609@sonic.net> Message-ID: <20070729171358.GC27970@cthulhu.desy.de> On Sat, Jul 28, 2007 at 11:09:50PM -0700, Mark Wedel wrote: > There are some multiplayer maps, but really, most of them only > require multiplayer because two levers need to be pulled at the same > time Yeah, which isn't either challenging nor interesting. We need real multiplayer maps. > But would be nice, which may happen with class/race/skill > rebalancing, is for parties to be able to handle tougher dungeons than > they might otherwise be able to handle on their own, and thus get > better items/more exp. Yes, would be nice. But again, be careful not changing the classes that much, that multiplayer is necessary. Re: healing items > But using such items takes some amount of time, at which point > you're not casting spells or inflicting damage. A rod of healing is very fast to use. Much faster than any party member is able to cast heal; especially if you have to fiddle around with the mouse... And if you slow down such things, the single player ability may get lost. From my point of view would be very bad, because the focus of CF is single player adventures in a multi player world. Oh, and high level monsters are able to kill a character pretty fast. Waiting for a party healer who has to take the mouse may be to late. So we need to adjust the monsters, too. And again, reorganization of the entire world comes into my mind. > There has been a lot of discussion about rebalancing/redoing classes > - that is completely unrelated to party support (the discussions about > redoing it are really separate), but those changes may make playing > with parties more desirable. I don't think so. But we should skip the idea of a "healer" class. This leads into the wrong direction. As you said, having more class distinctions may solve some of the problems. Having a character with level 50 in melee and another one with level 50 in spell casting should be able to solve quests where two character with equal level 30 in melee and casting won't. This can also be combined with the reorganization of the world. Having such multiplayer maps in one region will offer teamplay as well as some challenging maps for single player character who likes to hit the limit. > > Make the "healer" getting xp from healing. No xp sharing, please. Let > > it make more xp the higher the healed character is, or whatever. But > > make sure that xp comes out of the skill you use. > > Things like that don't work very well. Off the top of my head, I > can think of numerous abuses that players would quickly come up to get > healing exp up (players damage each other, etc). As I said, the "healer" as a class will lead into the wrong direction. But what about xp gaining from the amount of hp healed? For example, someone heals 20 hp of a party member will get 20 xp. Player don't have a huge amount of hp, so leveling up by abusing this will take some time. > I personally think exp sharing should be part of the game. I think that's not necessary. But if you like to keep it, we should try the idea of Juha. Don't share xp between characters with to much level difference, or reduce the shared xp the higher the level difference is. Sharing xp offers a much bigger abuse than by damaging and healing each other. The reward for party play should be the ability to solve a quest which won't be possible on the own. > if the only way to get exp is by killing creatures, We don't have that. You should gain xp by using your skill. > pretty much means that every class must be something that goes and > kills bunches of creatures, which I don't think is good. Yes, with the focus on single player maps every class has to have the ability to kill monsters... Forget about the pure healer. A paladin could get some good healing spells, same for the priest. Both are able to kill monsters by their own. No big deal. > > Doesn't matter. Count the damage each character made and divide the > > xp pro-rata. If not, won't hurt. But I won't like to play a healer > > if I need a warrior which weakens the monster that I get the chance > > to gain a little bit xp... > > That doesn't work for several reasons. First, what do you do about > creatures with fast regeneration? Those are harder to kill, more slashing is needed. ;-) > If you get damage for each hit, you now open up a way for infinite > exp. I never said that. Only killing the monster will give you xp, but now pro-rata of the damage you made. If the xp for a monster is 1000 and (for the easier calculation example) also have 1000 hp, but regenerates fast. Now our party members have to inflict 2000 damage. Player A made 1000, B inflicted 500, and C and D each 250. Now the 1000 xp are diveded pro-rata. Player A gets 500 xp, player B 250 and C and D each 125. No way for infinite xp. No way to spoil fun for lower level characters. > The other thing is that IMO, killing the creature should be rewarded > much more than damaging it. Only killing will give xp, damaging not. Same behaviour as right now. Re: Travelling around with reduced speed > More use of transports could be added. Yes, reorganization of the world pops up into my mind. ;-) Making more island for the regions and you're able to travel between them with ships. > Note that right now, even for a moderate/low level character without > high speed, unless going cross country through mountains, it never > takes more than a couple minutes real time to get to any point. Yes, you're right. I'm unable to navigate my high speed character in real time. I always leave the pathes and hit mountains. So really no big deal. Re: mouse vs keys > Aiming with keys would be difficult. Yes, no idea so far for this. Maybe lock on a monster and hit it as long as in line of view and auto lock another one. > Aiming with a mouse would be easy, but as said, going between > keyboard and mouse is a bit annoying. This should be avoided, yes. Party spells could be applied in two steps. You have an overview of the party, for example: a - Siegfried b - Kriemhild c - Gunther d - Hagen Now you invoke "heal member" and a query asks you on which one: a, b, c or d? Hit the key and the member feels the effect. Should be fast enough for combats. > I'm not sure what it would take to make the game completely playable > with the mouse (and completely may be a bit of an overstatement - some > things may only be doable by keyboard, but if those are things you > don't do in combat, probably ok) Usually you have two hands. One on the mouse, the other one on the keyboard. If you move and aim with the mouse and do other things with keys, depends on the implementation, may work. Combinations like aiming with mouse, moving with keys is bad, I think. We may add identifiers over the monsters. Similar to the "heal member" query (see above) you could get an "aim monster" query. Re: Create party quests > Presume you have party support (not that big a presumption). And > presume you have some way of recording the party members that > completed a quest (killed the monster). > > At that level, it then doesn't take too much imagination to think > about when the party returns to town, how they get a shared reward. Ok, the king sends you out to solve a problem. You return to the king with your party members. Every party member gets the "quest solved flag" who really participated into the quest. Make some "milestone flags", and only those with all the milestone flags receive the solved flag. And for the rewards: The one who returns the quest item to the king will receive a bunch of items. For example, if it's a quest for three players, the king will give away three items. If you played with 5 players, the reward won't change. If you ask for a plumber to fix your flooding, and 5 plumbers requesting each 100$ per hour, you won't be amused. Paying a bill of 100$ per hour which is divided between those 5 plumbers won't bother you, isn't it? If the quest is desinged for a warrior, a wizard and a priest and you solved the quest with 5 warrior, the rewards won't change. I don't like to see a party of 50 members ripping the king of. ;) > if that NPC in town wants something done, he probably doesn't care how > it got done - he just cares it did get done. Now as programmers of > that NPC, we should take into account that people may work in groups > to get that task done. Yes, everybody on the map with the appropriate flag collection will get the quest solved flag. But the reward won't change. Make clear how the rewards looks like at the beginning that you're able to form a party for it. And than the quest should be best solved with this kind of classes that the rewards will fit. Or make a selection thing we discussed for single player quests. But only the first characters should get a reward, not all to avoid abuses. J?rgen From nicolas.weeger at laposte.net Sun Jul 29 13:02:55 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 29 Jul 2007 20:02:55 +0200 Subject: [crossfire] Party Support In-Reply-To: <20070729171358.GC27970@cthulhu.desy.de> References: <20070729171358.GC27970@cthulhu.desy.de> Message-ID: <200707292002.58504.nicolas.weeger@laposte.net> > I don't think so. But we should skip the idea of a "healer" class. > This leads into the wrong direction. This leads in the wrong direction for you, but not necessarily for other players :) In my opinion, the more roles players can choose from, the funnier. Even non combat roles, be it alchemist, smith, whatever - including healer. Though we should make it so that one can play alone if she wishes so :) Ideally, players could play together, or single, without (many) map restrictions - it is ok to have some maps requiring multiplayer, but not all ; it is ok to have maps suitable for only one player, not all. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070729/871753fa/attachment.pgp From crossfire at kahnert.de Sun Jul 29 14:20:09 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sun, 29 Jul 2007 21:20:09 +0200 Subject: [crossfire] Party Support In-Reply-To: <200707292002.58504.nicolas.weeger@laposte.net> Message-ID: <20070729192009.GE27970@cthulhu.desy.de> On Sun, Jul 29, 2007 at 08:02:55PM +0200, Nicolas Weeger wrote: > > I don't think so. But we should skip the idea of a "healer" class. > > This leads into the wrong direction. > > This leads in the wrong direction for you, but not necessarily for > other players :) Offering characters for pure party gaming in a game with only a rudimentary party support and just a few players online at the same time is nothing you have to spent much time of thinking. It's just unplayable... > In my opinion, the more roles players can choose from, the funnier. Only if such a role is playable. Offering classes which are unrealistic to play are no fun at all. > Even non combat roles, be it alchemist, smith, whatever - including > healer. We don't have a smith class. And the alchemist is unplayable at the moment; see: http://mailman.metalforge.org/pipermail/crossfire/2007-July/011693.html > Though we should make it so that one can play alone if she wishes so :) How do you play a pure healer alone? Or do you mean a paladin / priest? > Ideally, players could play together, or single, without (many) map > restrictions - it is ok to have some maps requiring multiplayer, but > not all ; it is ok to have maps suitable for only one player, not all. Yes, ideally, I fully agree. But CF is far away from ideal conditions for this. So concentrate on classes which are playable at the given system and add more classes, if those become playable, too. J?rgen From yann.chachkoff at myrealbox.com Sun Jul 29 15:44:17 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun, 29 Jul 2007 22:44:17 +0200 Subject: [crossfire] Party Support In-Reply-To: <20070729192009.GE27970@cthulhu.desy.de> References: <20070729192009.GE27970@cthulhu.desy.de> Message-ID: <200707292244.17382.yann.chachkoff@myrealbox.com> Le Sunday 29 July 2007 21:20:09 Juergen Kahnert, vous avez ?crit?: > So concentrate on classes which are playable at the given system and add > more classes, if those become playable, too. > Except if one accept the hypothesis that maybe the real problem is not in the current definition of classes, but rather lies in the system itself. If that's the case, then adding more classes will just move issues elsewhere. Just my two cents. From nicolas.weeger at laposte.net Sun Jul 29 16:23:02 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 29 Jul 2007 23:23:02 +0200 Subject: [crossfire] Party Support In-Reply-To: <20070729192009.GE27970@cthulhu.desy.de> References: <20070729192009.GE27970@cthulhu.desy.de> Message-ID: <200707292323.05738.nicolas.weeger@laposte.net> > Offering characters for pure party gaming in a game with only a > rudimentary party support and just a few players online at the same > time is nothing you have to spent much time of thinking. It's just > unplayable... So let's trash existing system and create a real multiplayer system - that allows single player mode, of course. > We don't have a smith class. And the alchemist is unplayable at the > moment; see: > > http://mailman.metalforge.org/pipermail/crossfire/2007-July/011693.html Then let's fix it. > How do you play a pure healer alone? Or do you mean a paladin / priest? > Yes, ideally, I fully agree. But CF is far away from ideal conditions > for this. > > So concentrate on classes which are playable at the given system and add > more classes, if those become playable, too. Then let's be ambitious :) Let's rewrite the system from scratch (or almost) to enable us to do this kind of things. Instead of just saying "we can't do that". We want 2.0 to be a real milestone, or what? :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070729/286c3395/attachment.pgp From mwedel at sonic.net Mon Jul 30 01:29:58 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 29 Jul 2007 23:29:58 -0700 Subject: [crossfire] Party Support In-Reply-To: <200707292323.05738.nicolas.weeger@laposte.net> References: <20070729192009.GE27970@cthulhu.desy.de> <200707292323.05738.nicolas.weeger@laposte.net> Message-ID: <46AD8566.90404@sonic.net> The definition of what is a playable class is very broad. A class that can only gain exp as part of a party is still quite playable, if you are always able to play with parties. A pure weapon smith class may also be very playable - not even needing party support, just cooperation of other players to bring in materials, give payment for stuff, whatever. Now, I probably wouldn't want to play such a character, but there are people that do. So I don't think that the ability to play such characters should not be there because some people don't find it interesting. It may be that character creation should be redone (as has been suggested) - but a basic change could be that only easily playable classes be presented to the player, unless they select expert/advanced mode or something. And I'll restate my original belief: We don't need to fix the party system right now - I think there will be many other changes done that will affect party playability in various ways. However, in all those other changes, we should keep in mind how it may affect party play - we shouldn't just dimiss party play as something we don't care about. Now I'll add to that: It may be that some of those changes don't improve party play in any regard, or doing party support for some change isn't feasible. But we should still think about that for other changes. From lalo.martins at gmail.com Mon Jul 30 07:13:37 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 30 Jul 2007 12:13:37 +0000 (UTC) Subject: [crossfire] GTK2-v2 Client new layout defined References: <200707261810.34130.kbulgrien@worldnet.att.net> Message-ID: A discussion we had a while ago when the v2 client first appeared: Many laptops on the market today aren't able to do more than 1024x768, and that isn't about to change any time soon. I *normally* play on my PC, but if I ever became unable to play on the laptop, I would be very disappointed. Generally, your layout reminds me of the v1 client, which makes me ask: if you're going to have 3 columns, why not put the map in the middle? Now, on the subject of layouts: I think it would be a neat idea if the v2 client used libglade, and allowed the user to choose a layout file in the preferences dialogue. Yeah, that would probably require a client restart to take effect, and for best results we should include thumbnail screenshots with the glade files and find a way to display them in preferences; but overall it shouldn't be too hard, and if people are serious about writing different layouts, it might be worth it. Of course, my preference would be for using a widget similar to the Gimp's dockable panes, so an user can change the layout at runtime. But I looked around and found no such widget in a library format. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From kbulgrien at worldnet.att.net Mon Jul 30 19:52:02 2007 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 30 Jul 2007 19:52:02 -0500 Subject: [crossfire] GTK2-v2 Client new layout defined In-Reply-To: References: <200707261810.34130.kbulgrien@worldnet.att.net> Message-ID: <200707301952.02760.kbulgrien@worldnet.att.net> Lalo Martins wrote: > A discussion we had a while ago when the v2 client first appeared: > > Many laptops on the market today aren't able to do more than 1024x768, > and that isn't about to change any time soon. > > I *normally* play on my PC, but if I ever became unable to play on the > laptop, I would be very disappointed. The biggest challenge there is that the v2 client appears to use a system defined font, so unless that font is pretty small, the v2 client cannot be as tight as the v1 GTK client. > Generally, your layout reminds me of the v1 client, which makes me ask: > if you're going to have 3 columns, why not put the map in the middle? Sure, that layout was done mostly to see if I could do a new layout... As such, I changed as few widgets as I could. I feel the same about having the map in the middle, and intend to redo a layout in the v1 client format shortly, but my development system motherboard had a SATA controller go out on it the day after I posted all that, so I've been distracted temporarily. As far as redoing the layout with the map in the middle goes, as a right- handed mouse user, I think I may prefer having the inventory on the right and the messages on the left, but now that I've done it a couple of times, doing both a lefty and a righty version would be pretty easy. > Now, on the subject of layouts: > > I think it would be a neat idea if the v2 client used libglade, and > allowed the user to choose a layout file in the preferences dialogue. > Yeah, that would probably require a client restart to take effect, and > for best results we should include thumbnail screenshots with the glade > files and find a way to display them in preferences; but overall it > shouldn't be too hard, and if people are serious about writing different > layouts, it might be worth it. I mentioned as much on IRC... yes, libglade would be neat. I'd have to get a lot more comfortable with Glade and the client code to try it myself. (I was able to do the re-layout without touching any of the client code.) I think, though, unless it was easy, it seems there may be better things to do than convert the client to use libglade. It's not like you have a lot of options on layout unless you have an obscenely large display - and that's not a problem I have, and it doesn't seem to be a problem a lot of players have. > Of course, my preference would be for using a widget similar to the > Gimp's dockable panes, so an user can change the layout at runtime. But > I looked around and found no such widget in a library format. > > best, > Lalo Martins From edler at heydernet.de Mon Jul 30 21:07:26 2007 From: edler at heydernet.de (Bernd Edler) Date: Tue, 31 Jul 2007 04:07:26 +0200 (CEST) Subject: [crossfire] Party Support In-Reply-To: <46AD8566.90404@sonic.net> References: <20070729192009.GE27970@cthulhu.desy.de> <200707292323.05738.nicolas.weeger@laposte.net> <46AD8566.90404@sonic.net> Message-ID: My 2 cents: 1. Slowing down the speed to a human manageable one. This will improve both single and party play. If the PCs were not buzzing about like a hornet on crack, the server would have time to calculate whether party members are in visible (range) for party spells / party XP. 2. Harmonizing the HP / damage ratio between players and monsters. Would not only make a friendly-fire > 0 survivable, it could make pvp more interesting. 3. Targeting Friends: As aiming with the mouse is too slow, we could make the typical party spell targeting all (visible) party members in the spell's range. e.g. heal all : 2* mana (heal) range 10 protect all from fire, etc When do I need to recast my protection/pump spell? Answer: When it wears out on me, as we all got it at the same time. Some spells might be allowed to work through walls. 4. Party Info: If the spells need visible range, we could do without extra party info screen. We just use a health bar on the PC icon like rts games do. These could be visible for monsters too, maybe requiring some level of lore or probe spell. 5. Targeting Monsters: a,b,c : players 1,2,3 : Monsters a bc12 3 Simply make it so, that arrows,fireballs etc. from player a will go through b and c and hit monster 1. No need to fumble with the mouse here either. That's how other games like eg. diablo do it, and has nothing to do with 2d vs. 3d or isometric vs. square. Same goes for the monster: 3 could hit c with arrows/spells. But I'd still restrict the monsters to 8 directions just like the players. I would further like it, if player b could hit monster 1 with melee when using a polearm. (Same goes for monsters: fear the pikemen :) From crossfire at kahnert.de Tue Jul 31 00:15:24 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Tue, 31 Jul 2007 07:15:24 +0200 Subject: [crossfire] Party Support In-Reply-To: <46AD8566.90404@sonic.net> Message-ID: <20070731051524.GA2996@cthulhu.desy.de> On Sun, Jul 29, 2007 at 11:29:58PM -0700, Mark Wedel wrote: > A class that can only gain exp as part of a party is still quite > playable, if you are always able to play with parties. Yes, but only _if_ you're always able to play with parties. CF is far away from that. Adding such classes at this state is counterproductively and wasted time. Much more worse, it'll frustrate player who like to play this class and realizes later, that it's unplayable because there are not enough players to form a party. > A pure weapon smith class may also be very playable Not within CF, and probably won't ever be. > Now, I probably wouldn't want to play such a character, but there > are people that do. So I don't think that the ability to play such > characters should not be there because some people don't find it > interesting. Sure, there might be people who likes to play(!) such a character. But offering this choice in a system where you can't play it, has nothing to do with finding it interesting or not. Before you can have a good party system, you need a lot of players. Face the truth. There are a few CF servers around the world. Most of them empty almost all the time. The server with most players listed by the metaserver is almost always schmorp, which isn't even CF. Second one is metalforge and the third one cat2. Even if you take all the few players from this three servers, you won't be able to offer a working party game, because that are still just far to less players. The priority should be to make the game more attractive for newbies to get some more players. > We don't need to fix the party system right now [...] But we should > still think about that for other changes. I think those points listed by Bernd will do well for the first step, see: http://mailman.metalforge.org/pipermail/crossfire/2007-July/011739.html J?rgen From mwedel at sonic.net Tue Jul 31 00:24:29 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 30 Jul 2007 22:24:29 -0700 Subject: [crossfire] GTK2-v2 Client new layout defined In-Reply-To: <200707301952.02760.kbulgrien@worldnet.att.net> References: <200707261810.34130.kbulgrien@worldnet.att.net> <200707301952.02760.kbulgrien@worldnet.att.net> Message-ID: <46AEC78D.1020807@sonic.net> Kevin R. Bulgrien wrote: > Lalo Martins wrote: > >> A discussion we had a while ago when the v2 client first appeared: >> >> Many laptops on the market today aren't able to do more than 1024x768, >> and that isn't about to change any time soon. >> >> I *normally* play on my PC, but if I ever became unable to play on the >> laptop, I would be very disappointed. > > The biggest challenge there is that the v2 client appears to use a > system defined font, so unless that font is pretty small, the v2 client > cannot be as tight as the v1 GTK client. Does the gtk1 client actually specify a font to use? I thought that also used the system font. In any case, the gtk2 client also supports themes, so it is certainly possible to make a custom theme that uses a different/smaller font file. Now it would start to be a little goofy to be playing with both the them and font to try and get something that works. OTOH, these are really two separate things - window layout and text size is really independent. Note that the main reason the gtk1 client can fit more in smaller space is that it defaults to an 11x11 map size. So out of the box, that effectively gives a lot more space to things like the text window, inventory, stats, etc. But IMO, it also de-emphasizes the map a bit - the total space used by the map is very little compared to all the rest of the information. That said, there has been some suggestions about features to make things more usable. One which I haven't done yet is something like quick apply areas. Take a little screen place someplace, and have something like 5-10 spaces for icons. Let players drag and drop stuff from their inventory to these icons - these then become fast apply areas - you click on that icon, and whatever that item is is applied (be it potion, weapon, armor). Perhaps also assign them numbers (0-9), and with control-0 or something, it also applies it. If this was done, then during normal exploration of a dungeon, the player probably wouldn't need the inventory area anymore. I could be wrong in this, but my experience is that I need to access a few items in my inventory (switch weapons, drink a potion, etc) - I probably don't need more than 10. But if inventory was hidden (perhaps by a tab), that frees up a lot of space for other information. Note that even with this, the look (on the ground) would still need to be displayed. It'd be even cooler to be able to drag spells into that area, so you have fast apply of spells also. > I mentioned as much on IRC... yes, libglade would be neat. I'd have to > get a lot more comfortable with Glade and the client code to try it > myself. (I was able to do the re-layout without touching any of the > client code.) I think, though, unless it was easy, it seems there may > be better things to do than convert the client to use libglade. It's > not like you have a lot of options on layout unless you have an obscenely > large display - and that's not a problem I have, and it doesn't seem to > be a problem a lot of players have. If need help, I could also look at the libglade stuff. Now as person with an obscenely large display, I find the default gtk2 client works just fine. But would be curious what improvements could be done - but to be honest, I tend to run it at roughly the 1280x1024 resolution - that just gives me room to have other windows up and about. The real advantage of libglade is that it then makes it very easy for anyone to be a tinkerer - anyone with some proficiency in libglade can go about and try moving things about, and not have to worry about needing to recompile, etc. There is a non trivial number of people that download the precompiled packages - OTOH, I have no idea how many of those would then try to go about playing with glade files. > >> Of course, my preference would be for using a widget similar to the >> Gimp's dockable panes, so an user can change the layout at runtime. But >> I looked around and found no such widget in a library format. At one point, that was the reason for the gnome client - the sub windows were tearaway, so you could pull one off, put it elsewhere, etc. I don't see that functionality in glade - doesn't mean that those widgets don't exist, but there is some amount of stuff that requires extra work to do. I know it has also been suggested that there be a split window mode - I think the only thing to do that would be to remove the root window and make sub windows for all the other stuff. But I'm sure there is some stuff that presumes that window_root actually exists, and that the other windows are children off it. Making window_root exist would be easy - if some code requires that heirarchy, that is a problem. Also, with the gtk2 client (compared to the X11 client), some window still has to be nominated as the main/root window - need someplace to put the menubar. X11 client doesn't have a menubar. From lalo.martins at gmail.com Tue Jul 31 02:55:26 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 31 Jul 2007 07:55:26 +0000 (UTC) Subject: [crossfire] GTK2-v2 Client new layout defined References: <200707261810.34130.kbulgrien@worldnet.att.net> <200707301952.02760.kbulgrien@worldnet.att.net> <46AEC78D.1020807@sonic.net> Message-ID: Also spracht Mark Wedel (Mon, 30 Jul 2007 22:24:29 -0700): > The real advantage of libglade is that it then makes it very easy for > anyone > to be a tinkerer - anyone with some proficiency in libglade can go about > and try moving things about, and not have to worry about needing to > recompile, etc. There is a non trivial number of people that download > the precompiled packages - OTOH, I have no idea how many of those would > then try to go about playing with glade files. Yeah, that was my thinking exactly. First time I got my hands on the v2 client, years ago, I had a 1024x768 system only for playing. So I fearlessly whipped up glade and made a layout that allowed me to play. No sweat. >>> Of course, my preference would be for using a widget similar to the >>> Gimp's dockable panes, so an user can change the layout at runtime. >>> But I looked around and found no such widget in a library format. > > At one point, that was the reason for the gnome client - the sub > windows were > tearaway, so you could pull one off, put it elsewhere, etc. > > I don't see that functionality in glade - doesn't mean that those > widgets > don't exist, but there is some amount of stuff that requires extra work > to do. I did some research a while ago, there is no such a thing, at least not in library format. It would certainly be a great service to the community in general if someone could abstract the relevant code from the Gimp, either into a new library, or as a contribution to one of libgnome, libsexy, or even gtk+. In fact, for those who haven't used the Gimp in the last few years (or ever), I have to say -- the Gimp dock widgets are simply awesome, they do much more and much better than the Gnome 1 thingies did (or the v1/x11 client's "split windows" mode). Of notably relevance to the CF client: tabbed widgets would become an user decision. Gimp docks create tabs if more than one pane is docked in the same slot. (Did that sentence even make sense? If not, fire up the Gimp and experiment a bit.) > I know it has also been suggested that there be a split window mode - > I think > the only thing to do that would be to remove the root window and make > sub windows for all the other stuff. But I'm sure there is some stuff > that presumes that window_root actually exists, and that the other > windows are children off it. Making window_root exist would be easy - > if some code requires that heirarchy, that is a problem. > > Also, with the gtk2 client (compared to the X11 client), some window > still has > to be nominated as the main/root window - need someplace to put the > menubar. X11 client doesn't have a menubar. But the gtk-v1 client does (did?) have a "split windows" mode, and a menubar. The menubar goes on the window with the stats. On v2 I'd argue it would be on the map. best, Lalo Martins best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From nicolas.weeger at laposte.net Tue Jul 31 13:52:23 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 31 Jul 2007 20:52:23 +0200 Subject: [crossfire] Party Support In-Reply-To: <20070731051524.GA2996@cthulhu.desy.de> References: <20070731051524.GA2996@cthulhu.desy.de> Message-ID: <200707312052.26224.nicolas.weeger@laposte.net> > Yes, but only _if_ you're always able to play with parties. > > CF is far away from that. Adding such classes at this state is > counterproductively and wasted time. Much more worse, it'll frustrate > player who like to play this class and realizes later, that it's > unplayable because there are not enough players to form a party. > Not within CF, and probably won't ever be. Again, we are talking about revamping the whole system, so let's think "out of the box" :) Now is a good time to create such a playmode. Let's innovate, let's focus on storytelling, real quests, real roles - wanna rule an empire? wanna become the God of Healers? why not? > Sure, there might be people who likes to play(!) such a character. But > offering this choice in a system where you can't play it, has nothing to > do with finding it interesting or not. Then let's remake the system :) Thta's the point of the whole exercice, no? (I promise, last time I say this ^_-) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070731/cda803c5/attachment.pgp