From mwedel at sonic.net Thu Dec 1 00:04:37 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Dec 1 00:05:28 2005 Subject: [crossfire] Set traps skill (please make it server config-able (on/off). In-Reply-To: <20051130164332.56383.qmail@web61025.mail.yahoo.com> References: <20051130164332.56383.qmail@web61025.mail.yahoo.com> Message-ID: <438E9275.6090305@sonic.net> Mitch Obrian wrote: > The set traps skill is currently inopreative because > idiot nebs on metalforge (or whatever the big server > was in the 1.0 days) killed themselves with it because > they were retarded morons. That is actually 100% false. > > This should be made into a server variable in the > config file > by default it will be off > > settrapsskill off (or 0) > > but a server admin (such as me with Cat2) could set it > on if desired (this is something my users want). The reason it isn't on is that the person that wrote that code wasn't particularly satisfied with the code in many areas . So he is the one that disabled it, or perhaps to a better point, it was never finished. From antonoussik at gmail.com Thu Dec 1 02:36:48 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Thu Dec 1 02:37:28 2005 Subject: [crossfire] alchemy ideas (was: Idea for skills) Message-ID: On 28/11/05, Mark Wedel wrote: > Nicolas Weeger wrote: > > Btw, it could be used for "secondary" skills (alchemy, woodsman, ...) > > skills only, not main combat ones. This way no penalty for > > fighters/wizards, just for players wanting to do other things than combat :) > > But I then wonder if an actual cap on exp/skills is needed, or if it would be > good enough to give exp bonuses in specific skills for specific quests. Now that you say it, it seems like a plausable idea. Alchemy, woodsman, etc. are all closer to knowlege than to something else, so players can level in them like they do with academic subjects in real life. At the moment the main problem with it is: Eiher it is very very tedious to level, and takes many months to get to making simple potions, as you try to stockpile some ingredients, then eventually after dying several times and spending several thousand on extra ingredients, cauldron access, etc, make something that is cursed, and costs 4 platinum to sell. Or you can spend a few very tedious days iding altar ingredients and get to the point of making something usable. First approach is far too boring for anyone to seriously consider, and I think second approach is a cheat in a way, and needs substantial financial backing. Either way there is not much incentive to do so apart from selling the items for wealth, as by the time you can make the items you can either find them in dungeons, or can afford to buy them in shops. So, I suggest some interesting changes to how these skills can work, some alchemy-related changes in group A, and some general change in gorup B, which are not essential, but would complement alchemy changes. By "alchemy" here I mean alchemy and all related skills. A Alchemy related changes: 1. Do not award experience for identifying items. I find the fact that you can make summoned water (or get things from altar) and then say "What is it here? Ah, yes, here is a bottle of water! I now know more! What is it here? Ah, yes, here is a bottle of water! I now know more! What is it here? ..." quite silly, and would have complained about it long ago if it was not the only plausable way of raising experience at lower levels. 2. Players should only recieve more experience for alchemy by making formulae that are of difficulty comparable to that of their alchemy level. This is explained by the fact that you do not learn more by doing something you can already do well again and again. It is not challenging, and does not teach you anything new. 3. Players would only recieve experience up to a point (say, level 19, 39, 59, ...), after which they need to do an "exam" (I propose a combination of oral and practical, I was never much of a fan of written exams) to get the next level (and academic title), after which they would be able to get into the next institution, be able to make cooler stuff, and earn more experience and wealth. If institutions that taught them were dotted around world (so to level alchemists would have to move from place to place throughout their life) players would also be encouraged to explore. 4. However this does not encourage interaction between players, as you would end up having the alchemy crowd completely ignore the normal people, and so to compensate I propose that alchemy generated items do not sell well in shops (if at all?), and so to generate wealth alchemists would need to sell the items to other players. However if shops and altars continue to readily sell the items, or items are plentiful in the wild, this idea would never succeed, and so alchemy-generatable items should be removed from auto-replenished shops and altars, and be made rare in the dungeons. 5. Also, the institutions can act like hubs to alchemy-centered quest hubs, which would be mostly puzzle solving or humorous (eg. deriving ingredients to the next formula you are learning by solving a puzzle, and then getting an xp bonus when you succeed, or "Our neighbours complained to the city authorities that our emissions are dangerous to the health. They reported the smoke causes mutations with some other magical side effects. Go clean it up." for a more combat-oriented quest.). Since these quests should offer substantial experience in alchemy awarded (extra bonus that mwedel suggested), they should only be allowed to completed once. I'm not sure if the current quest system can accomodate this readily. 6. To compensate for the difficulty of advancing formulae should be changed to use more findable ingredients, as at the moment people simply do not bother - to level up making complicated potions you will never find enough ingredients, no matter how much you look and even hire others to look for you. If difficult potions are made difficult only by their difficulty it will add much more incentive for people to do them, especially now that most "alternative" formulae have been cursed to failure by the forces above... 7. Another incentive that can be added is some alchemy-only items that can not be found in dungeous, such as cool swords and armour plauers would want to buy for good money. Ingredients for those should be rare, but it should be made known what they are, so players know what to look for. I see most of the work here as map-making, as if this is to work it would need something like 5 different institutions per skill, each offering about 10 quests, so it is a lot of work. B General changes: 1. Item wear would work really nicely with this, since players would be in constant need of new items. Rare artefact armour and swords should not age quickly if at all, but permanent items should either be not as effective items that wear out, or only be avaliable at very high levels (100+), all other things should wear with use, and become less effective and fall apart, therefore keeping alchemists in job, and generating a working economy, where figher people do dungeous, find wealth, spend wealth on buying new items etc. from alchemists, alchemists spend their wealth getting themselves better items and advancing themselves. 2. Buildable land plots would enable player owned shops and workshops to be set up, therefore establishing a proper economy for the game. It could also be used for new skills such as farming, foresting, etc. to make a stable wealth source, and a complete self-supporting economy. 3. Transportation improvements would enable a "trader" player class to emerge - someone who can pilot a horsecart or a ship (or maybe even a hot air baloon very slowly) loaded with goods, and sell them between areas, although most probably trade between player owned shops listed in B2. For this to work teleportation between areas should be disabled, and conventional methods of travel should be used to get around, but maybe with some improvements. For example directors could be placed around the roads, so to travel along a road, a player simply needs to step onto the road, and they will be carried along it, until they step off. Likewise, shipping routes can be made with directors. From mikeeusaaa at yahoo.com Thu Dec 1 12:03:04 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Thu Dec 1 12:09:02 2005 Subject: [crossfire] drop_food_level In-Reply-To: <438E912E.50909@sonic.net> Message-ID: <20051201180304.84940.qmail@web61016.mail.yahoo.com> Has the drop_food_level 'uservariable' (is that what it is called?) been implemented? __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From nicolas.weeger at laposte.net Sun Dec 4 11:41:01 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Dec 4 11:41:30 2005 Subject: [crossfire] Tweaking alchemy Message-ID: <43932A2D.2090701@laposte.net> Hello. I'd like to extend alchemy-like skills, probably with a 'cooking' skill. What i'd like to do is: * add a way for formulaes to never blow up, and just yield a specific item when failed ('burnt cake'). This will make it safer and more fun, of course this would be for low exp recipes (or for a skill having a low skill => overall percentage) * add a 'min_level' for a recipe, which you couldn't do if you're not high-level enough (or with a *really* low probability). Just to feel the meaning of 'experience' :) And to prevent just trying a high exp recipe over and over again. * then i'd like to add food-related recipes, like pizzas (yummy!), bread, cakes, things like that. Of course i'll add matching archetypes. And thinking of making use of 'keycode' field and using quests to learn recipes. Unrelated to alchemy, but I'm thinking on using the 'on_apply_yield' field to eat (apply) food by parts (cake => 3/4 of cake => half cake => 1/4 of cake => nothing). Comments, suggestions? Ryo From fuchs.andy at gmail.com Sun Dec 4 15:39:43 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun Dec 4 15:41:32 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: <43932A2D.2090701@laposte.net> References: <43932A2D.2090701@laposte.net> Message-ID: On 12/4/05, Nicolas Weeger wrote: > Hello. > > I'd like to extend alchemy-like skills, probably with a 'cooking' skill. Aaronf0 said he would work on a more dynamic alchemy system, however, I have no idea if he has even started it. > What i'd like to do is: > * add a way for formulaes to never blow up, and just yield a specific > item when failed ('burnt cake'). This will make it safer and more fun, > of course this would be for low exp recipes (or for a skill having a low > skill => overall percentage) I think this has been needed for a long time. Though IMO the distinction between recipes that can be fatal should be made on the premises that the recipe has some magical quality to it. > * add a 'min_level' for a recipe, which you couldn't do if you're not > high-level enough (or with a *really* low probability). Just to feel the > meaning of 'experience' :) And to prevent just trying a high exp recipe > over and over again. If a level 1 player tries a level 110 recipe repeatedly, maybe give him a few warnings, if he ignores those kill him if the recipe is magical. > * then i'd like to add food-related recipes, like pizzas (yummy!), > bread, cakes, things like that. Of course i'll add matching archetypes. > And thinking of making use of 'keycode' field and using quests to learn > recipes. And add some "fancy" high level recipes. Preferably that don't blow up, but a loss of cash from expensive ingredients used in the recipe would be desirable. > Unrelated to alchemy, but I'm thinking on using the 'on_apply_yield' > field to eat (apply) food by parts (cake => 3/4 of cake => half cake => > 1/4 of cake => nothing). Probably a good idea to allow the use of item transformers on these. (slicing knife) On an other note, more items that can only be obtained through alchemy, would be interesting. -- Andrew Fuchs From mwedel at sonic.net Sun Dec 4 19:09:13 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Dec 4 19:09:31 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: <43932A2D.2090701@laposte.net> References: <43932A2D.2090701@laposte.net> Message-ID: <43939339.3060208@sonic.net> Nicolas Weeger wrote: > Hello. > > I'd like to extend alchemy-like skills, probably with a 'cooking' skill. > > What i'd like to do is: > * add a way for formulaes to never blow up, and just yield a specific > item when failed ('burnt cake'). This will make it safer and more fun, > of course this would be for low exp recipes (or for a skill having a low > skill => overall percentage) I wonder if instead of just having that be a flag, have some fields like 'danger_potential' or 'blowup_chance' or something? Thus, you could have potentially very complicated recipes that are safe but hard to do, and could have other recipes that aren't really complicated, but if you mess up, would be quite dangerous. > > * add a 'min_level' for a recipe, which you couldn't do if you're not > high-level enough (or with a *really* low probability). Just to feel the > meaning of 'experience' :) And to prevent just trying a high exp recipe > over and over again. Reasonable. But when doing so, it should be clear what the diff and exp fields then mean - are the based on overall level, thus something with difficulty 20 but min_level 50 then easy? Or does the diff scale from what the min level is, such that 'diff 20' corresponds how hard the recipe is if above min level (thus, a diff 20 min level 50 recipe would effectively be very hard, as at level 50, it is still a diff 20). > > * then i'd like to add food-related recipes, like pizzas (yummy!), > bread, cakes, things like that. Of course i'll add matching archetypes. > And thinking of making use of 'keycode' field and using quests to learn > recipes. It'd be interesting/add character to be able to make a fair number of the number food items that already exist. Making bread is an obvious example, but how about things like waybread, roast birds, etc. As an aside, it'd be cool to be able to actually specify recipes in maps. This could probably be done by adding a RECIPE object. The actual formulae information could just be stored in the msg field of that object. When you find a recipe book, it puts that recipe into your inventory (perhaps just like spell books - question whether such books should just give one reading or unlimited). When you go an make something, it looks in your inventory for any matching recipe objects. Could also add a command like 'show_recipes' to show what recipes you have learned, and 'show_recipes ' to get detailed info on the recipe or something. But that is a bit aside from this discussion. > > Unrelated to alchemy, but I'm thinking on using the 'on_apply_yield' > field to eat (apply) food by parts (cake => 3/4 of cake => half cake => > 1/4 of cake => nothing). I'm not sure you need to use that. I'd think you could just reduce the stats.food value accordingly. Eg, food starts at 200. You eat some, its food value is now 150, etc. Note that the apply logic would need to be changed (to not just decrement object number). I also think you'd need some logic on what food you eat partially, and how much partially. For example, I don't see anyone that would eat just a quarter mint sprig or some of the other value low food items. It would probably make sense to say something like you can eat 100 value of food/tick. So things with food value less than that, you'd gobble the entire thing. For items with more, you eat partial amounts. Or maybe do it by weight instead - you can eat 500 grams/tick. So for waybread, it goes down quickly, but some things, like corpses, would take a while to eat. You'd also have to think about how this applies to certain special food effects - the magical breads - do you get the effect on first bite? On all bites? What about dragon players eating a corpse? Do they now get that many more chances to get an improved bonus? From antonoussik at gmail.com Sun Dec 4 19:35:56 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sun Dec 4 19:37:32 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: References: <43932A2D.2090701@laposte.net> Message-ID: On 04/12/05, Andrew Fuchs wrote: > On 12/4/05, Nicolas Weeger wrote: > > Hello. > > > > I'd like to extend alchemy-like skills, probably with a 'cooking' skill. > > Aaronf0 said he would work on a more dynamic alchemy system, however, > I have no idea if he has even started it. > > > What i'd like to do is: > > * add a way for formulaes to never blow up, and just yield a specific > > item when failed ('burnt cake'). This will make it safer and more fun, > > of course this would be for low exp recipes (or for a skill having a low > > skill => overall percentage) > > I think this has been needed for a long time. Though IMO the > distinction between recipes that can be fatal should be made on the > premises that the recipe has some magical quality to it. Seems like a sensible idea, and one that is easy to implement. However, you need lots of new foods archetypes (and corresponding graphics), as these formulae should have normal food ingredients as ingredients, so you now need flour, tomatoes, ham, milk, cheese (made from milk), and so on. This could also be a good time to include a farming skill. Milk can be mined from a cow, and flour can be obtainable by using some wheat in a mill, and wheat can be collectable growing in fields (gaining the person some farming exp) and plantable using the farming skill. The higher the farming skill, the more wheat should grow when planted. Milk can also use farming skill, and I guess one would get better at it with practice, and be able to milk more milk from a cow if you are good at farming. However this needs cows, pigs, goats, rabbits, wheat, apple trees, maybe some magical farm animals from which magical foods can be made (like flying pigs for levitation food). We already have sheep and chickens and geese, so that can be a start. Farm animals should be able to asexually reproduce over time to account for cullings, so they can be kept in captivity and reproduce. However they should not reproduce too quickly (much much slower than mice) and maybe die of old age after a while. Charm monster can probably be adapted to have farm_mode, which will make farm animals in the area to become your farm_pets and follow you, until you get them into a closure of some sort and release the cows, so they will roam within the bounds of the closure and be milked or killed for food. If this is to be a viable economic device cows should be scarce, and be almost a currency of their own (Ukranian currency is theoretically based on the value of a horse, so this is not far-fetched). Since they reproduce on their own and can be sold, this should be the primary means of generating farm animals, and they should not occur often in the wild. Maybe make a farm market that sells very expensive farm animals, far above the in-game market value. Also things like summoned food and golden unicorn horn should be changed, since they effectively make cooking skill useless by giving infinite supply of infinite supply of food. > > * add a 'min_level' for a recipe, which you couldn't do if you're not > > high-level enough (or with a *really* low probability). Just to feel the > > meaning of 'experience' :) And to prevent just trying a high exp recipe > > over and over again. > > If a level 1 player tries a level 110 recipe repeatedly, maybe give > him a few warnings, if he ignores those kill him if the recipe is > magical. Maybe add an IsMagical flag to recipes, and treat magical recipes in the old dangerous ways, but things like cooking, carpenting, and so on in safe ways? > > * then i'd like to add food-related recipes, like pizzas (yummy!), > > bread, cakes, things like that. Of course i'll add matching archetypes. > > And thinking of making use of 'keycode' field and using quests to learn > > recipes. > > And add some "fancy" high level recipes. Preferably that don't blow > up, but a loss of cash from expensive ingredients used in the recipe > would be desirable. Using quests to learn recipes? Does this make recipes spell-like (so you enter 'cookbook list to view the recipes you know, and 'cookbook make pizza to make a pizza?) or you just encounter cookbooks from time to time? > > Unrelated to alchemy, but I'm thinking on using the 'on_apply_yield' > > field to eat (apply) food by parts (cake => 3/4 of cake => half cake => > > 1/4 of cake => nothing). > > Probably a good idea to allow the use of item transformers on these. > (slicing knife) Yes, a good idea. Needs yet more archetypes though. > On an other note, more items that can only be obtained through > alchemy, would be interesting. Which need even more graphics. If someone made lots and lots of different graphics it would be excellent (for sword-like things, shields, cloaks, rings, armours, bows, amulets, potions, and so on). Many of them could then be made into alchemyable items. From brenlally at gmail.com Sun Dec 4 20:46:14 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sun Dec 4 20:47:31 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: References: <43932A2D.2090701@laposte.net> Message-ID: <7903f03c0512041846m238b1f66pc8dd064fc47f2502@mail.gmail.com> On 12/5/05, Anton Oussik wrote: > This could also be a good time to include a farming skill. > > Milk can be mined from a cow, ... > Milk can also use farming skill, and I guess one would get better at > it with practice, and be able to milk more milk from a cow if you are > good at farming. ... > Farm animals should be > able to asexually reproduce over time This seems quite distinct from 'real' farming. The amount of milk a cow will give is mainly based on things like diet, breed and stress, as well as how thoughly they have been milked before. ( if you care, http://classes.aces.uiuc.edu/AnSci308/factorsaffecting.html is quite interesting). It will not noticably increase with level. What might happen is that the milking time would drop (mechanised milking is faster than manual milking, although one assumes that the former wouldn't be present in crossfire). If there were a standard unit of milk (I would favour the quart here, which is about 100 squeezes of a cow's udders - a nice round number) then you could simply define the time it takes to get that to vary with level, from 2 minutes or so at level 1, down to 10 seconds or thereabouts at level 100. in any case, farm animals do not asexually reproduce. - certainly in the case of cows, having to keep (and feed) a bull, would mean there would be a substantial investment in energy to go from 'keeping a cow' to raising a dairy herd. - especially if the genetic depression from inbreeding was a modelled effect (this could be done by taking one of the unused strings, and making it hold a 'DNA' which would consist of the middle 6 bits of a 10 (ish) byte string (the lowest one should be always on, to avoid \0's and the high one off due to code page issues) then, whenever you breed two animals, compare the strings, define the new animals health as the product of the healths of the parents multiplied by the number of bits that are different in the DNA. Then make the new DNA be a combination of the parents (bytewise - representing genes) 5 random ones from each. and have a 1 in n chance (not quite sure what n would have to be) to flip a single bit somewhere in the string. - mutation This sounds a little complicated to describe, but it is really just some rather simple pointer manipulation to implement. Oh, and the chance of succeeding in breeding should be based on the animals health. This would mean that having two offspring from a single cow, and breeding them for successive generations would rapidly result in a herd that was essentially sterile. in fact, this could be taken further, by defining one of the bytes to be the 'milk production' gene, which would define how long a cow would need to wait between milkings. From mwedel at sonic.net Sun Dec 4 23:17:10 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Dec 4 23:17:32 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: <7903f03c0512041846m238b1f66pc8dd064fc47f2502@mail.gmail.com> References: <43932A2D.2090701@laposte.net> <7903f03c0512041846m238b1f66pc8dd064fc47f2502@mail.gmail.com> Message-ID: <4393CD56.40705@sonic.net> As far as alchemy is concerned, an easy first pass would be to extend the general store (maybe rename it grocery store or something) to include raw food items, eg, wheat, milk, hunks of meat, etc. That still requires graphics, but but doesn't a whole set of farms, etc, where one can go and gather this. The farming aspect is a different piece. I'd imagine, if it doesn't exist already, the buildable land plots would have to come in farms, or at least the player to build wheat fields, etc. There is already code in place for creatures to be able to spawn other creatures, and for creatures to have a life cycle. It'd be nice to re-use as much as that as possible. Thus, in a simple case, a chicken lays an egg. After some amount of time, the egg hatches into a baby chicken, and over time, it grows up, with same age categories it being able to lay eggs. As time passes, it gets older, stops laying eggs, and at some point, dies of old age. The real question, I suppose, is whether there is a large number of players that actually want to play farmers. Otherwise, this entire idea could be a fair amount of work for something that no one ever uses. From nicolas.weeger at laposte.net Mon Dec 5 02:29:57 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Dec 5 02:31:32 2005 Subject: [crossfire] Tweaking alchemy Message-ID: > I wonder if instead of just having that be a flag, have some fields like 'danger_potential' or 'blowup_chance' or something? Yes, could be more extensible later on. > It would probably make sense to say something like you can eat 100 value of food/tick. So things with food value less than that, you'd gobble the entire thing. For items with more, you eat partial amounts. Or maybe do it by weight instead - you can eat 500 grams/tick. So for waybread, it goes down quickly, but some things, like corpses, would take a while to eat. But you then run into the merging issue - you'd have many items with different weight/food left, and a real pain to merge. Also you couldn't easily change the face to reflect how much you eat. Which is why it seems simpler to me to just change the item via on_apply_yield :) Also it's more visual to see half a pic of an apple and pic of a half apple than 2 apples with the same pic not merging. > You'd also have to think about how this applies to certain special food effects - the magical breads - do you get the effect on first bite? On all bites? What about dragon players eating a corpse? Do they now get that many more chances to get an improved bonus? Well, again using on_apply_yield solves the issue - the 2nd item won't have any special property. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; Jusqu'au 25 d?cembre, participez au grand jeu du Calendrier de l'Avent et ?gagnez tous les jours de nombreux lots, + de 300 cadeaux en jeu ! From antonoussik at gmail.com Mon Dec 5 02:34:38 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Mon Dec 5 02:37:32 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: <4393CD56.40705@sonic.net> References: <43932A2D.2090701@laposte.net> <7903f03c0512041846m238b1f66pc8dd064fc47f2502@mail.gmail.com> <4393CD56.40705@sonic.net> Message-ID: On 05/12/05, Mark Wedel wrote: > > As far as alchemy is concerned, an easy first pass would be to extend the > general store (maybe rename it grocery store or something) to include raw food > items, eg, wheat, milk, hunks of meat, etc. That still requires graphics, but > but doesn't a whole set of farms, etc, where one can go and gather this. Yes, in the short run this is a much better idea. However, a long term goal of a self-supporting economy based on inter-player interaction (where government-owned shops do not exist except to maybe provide some very basic food and weapons at time of war/famine/natural disaster) is IMO desirable. Then a community of about 200 players would be completely self-sufficient > The real question, I suppose, is whether there is a large number of players > that actually want to play farmers. Only if food is scarce enough for people to buy it, and people need to eat to survive. Currently many dungeons have a lot of food in them, there is the golden unicorn horn, and other sources of infinite food like summoning. Since low level characters need food as much as high level characters, but have far less means to afford it I am not sure how low level characters can survive other than by begging until they can afford to pay for food. Therefore as a skill farming is probably doomed to failure unless it is made very easy (generic ever-lasting self-reproducing cows, that can be milked every few minutes, etc.), in which case it would be more of a means of survival than a source of profit. So, you can farm your food yourself at any level, but if you are too lazy you can pay others to farm your food. From nicolas.weeger at laposte.net Mon Dec 5 07:08:59 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Dec 5 07:09:33 2005 Subject: [crossfire] Tweaking alchemy Message-ID: > Yes, in the short run this is a much better idea. However, a long term goal of a self-supporting economy based on inter-player interaction (where government-owned shops do not exist except to maybe provide some very basic food and weapons at time of war/famine/natural disaster) is IMO desirable. Then a community of about 200 players would be completely self-sufficient Unfortunately, I think this can't really be done for 2 reasons: * there aren't 200 players even on all servers together, so unless we do massive recruitement campaigns, we won't have enough players * not all players will want a self-sustained economy. The second point actually leads me to some thought i had earlier: we can basically split (current) Crossfire players/developers in two groups (please don't read next sentences as i'm criticizing any group, i sure don't want to!). First is more hacking-oriented, playing for the sake of trashing monsters, getting loot and much exp/money. For this group, self-sustained economy won't cut it, shops should have way too much things to sell. Second group (in which i'd include myself) is more "real-world" oriented, wanting features like cooking, building (remember my proposal on shop opening hours?), farming, and so on. (as i said this is a very rough split) So the hard part is doing features that everyone will enjoy, or that can be safely ignored. Self-sustained economy isn't imo in that field. > Therefore as a skill farming is probably doomed to failure unless it is made very easy (generic ever-lasting self-reproducing cows, that can be milked every few minutes, etc.), in which case it would be more of a means of survival than a source of profit. I'd even say "as a mean of doing different things than killing monsters", or "for the fun of it". Farming should imo too be not too hard. Nicolas Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; Jusqu'au 25 d?cembre, participez au grand jeu du Calendrier de l'Avent et ?gagnez tous les jours de nombreux lots, + de 300 cadeaux en jeu ! From gabriele.diniciacci at gmail.com Mon Dec 5 13:37:37 2005 From: gabriele.diniciacci at gmail.com (Gabriele Dini Ciacci) Date: Mon Dec 5 13:46:08 2005 Subject: [crossfire] Tweaking alchemy Message-ID: Hello, I talk only of alchemy. About other farming skills and such.. remember the onions.. let's start with alchemy and then see if we can go a step lower later (just want to keep the thing on topic... since it is spreading too fast in other directions and focus on alchemy is more important IMHO, just to be sure to have 1 thing done and not 10 started) Here a summary of ideas about alchemy redesign, some mine some from your mail I just read: # Alchemy recipes should be like spell books, they have to be learned by the player. Pro: no more cheaters that know recipes without reading it on a real scroll (many do this, nearly all) Cons: No more experimenting and discovering alone of new formulas (not that many use this) # "alchemize" skill, if you know "philosophical oil" you can just do 'alchemize philosophical oil standing on a cauldron and ingredients for ONE philosophical oil will be prepared. If you want to do mass production you have to do by hand. Script can do this I think. Pro: reduce the hassle and makes everything more appealing Cons: if it is possible to put a delay after EACH preparation there are not much cons, since people will use the old way for mass production. # Difficulty, each recipe have a single number/level that indicated both difficulty and level needed to have 50% of success of making it. Formula for chance of success (%): 50 - ( - ) + *5 Max (%): 95 - /10 Examples: considering a +5 cauldron, a level 110 skill this should be limiting for recipe level < 100 considering normal cauldron, a level 110 skill this should be limiting for recipe level < 72 explosion (%) (ONLY if failed, no overlapping percentages, it's easier to code) : 20 + ( - ) - *2.5 random effect (%) (Can happen too after an explosion, can be a useful thing but most often a piece of crap) : 20 + ( - ) + *7.5 Magical cauldron tend to always output something, even if not useful, they produce more and are less likely to explode. You can learn recipes of ANY level (success is based on sum of alchemy + literacy skill). Pro: It is simpler than having two numbers, one for level and one for difficulty. You never have 100% success. It is influenced by all variables Cons: Just simple, no quadratic formulas or anything that make it realistic/complex # 'alchemize should give a list with all recipes known by the player and base % of success (without the cauldron modifier). Pro: Player know what they are doing and if it too dangerous. i.e. if they fail they can explode. Cons: Disclosure of internal game numbers. I'm personally not against that, you can always show instead of %, easy (50-80%), medium (30-50%), hard (10-30%), very hard (0-10%). # shop with basic recipe dispenser altar, drop money, you get basic recipe, like waybread and basic things. Everyone should be able to learn trivial recipes without having to quest for it. # Old Granny cake quest, recipe for a healing cake, newbie recipe, everyone around level 15 should be able to do this quest. # Uncle Sam grog quest, recipe for a potion that restore a few mana (like 10-15), newbie recipe, everyone around level 20 should be able to do this quest. With that I think I have considered all aspects, just suggest and ask. Salutes Gabriele ----------- http://linux-wildo.sf.net http://www.diniciacci.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20051205/08803d77/attachment.htm From mwedel at sonic.net Mon Dec 5 23:49:13 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Dec 5 23:49:33 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: References: <43932A2D.2090701@laposte.net> <7903f03c0512041846m238b1f66pc8dd064fc47f2502@mail.gmail.com> <4393CD56.40705@sonic.net> Message-ID: <43952659.9000709@sonic.net> Anton Oussik wrote: > Yes, in the short run this is a much better idea. However, a long term > goal of a self-supporting economy based on inter-player interaction > (where government-owned shops do not exist except to maybe provide > some very basic food and weapons at time of war/famine/natural > disaster) is IMO desirable. Then a community of about 200 players > would be completely self-sufficient but should it be assumed that the players are the only people living in the crossfire world? At some level, this obviously isn't true - hundreds of monsters live in the world. so I'd say at some level, there would also be hundreds (thousands, whatever) of humans living the world that are AI. These are the people harvesting the wheat, making bread, etc. So when you go to the store to buy it, it is there. If you want to make a world that none of those invisible ai humans exist, you could, but that opens up a whole new can of worms. For example, right now, there is no indication where all sorts of raw materials come from. Where is that iron, gold, silver, etc being mined? Who is making all of those objects? And so on. I suppose you could come up with a case where all of that is done by actual players, but then what about all those monsters? Are they new equipment less? If not, then all you're really doing is moving who is making those items (case could be made that those orcs are mining the iron for their weapons, so the human players just go kill the orcs for their iron, etc). I'd just say that making a truly closed economy may be as complex as most all the code currently in crossfire. From mwedel at sonic.net Mon Dec 5 23:55:59 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Dec 5 23:57:33 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: References: Message-ID: <439527EF.2060005@sonic.net> Nicolas Weeger wrote: > But you then run into the merging issue - you'd have many > items with different weight/food left, and a real pain to merge. > Also you couldn't easily change the face to reflect how much > you eat. I don't think it would be much worse then your proposal. If you go by that supposition that you eat 500 grams of food/tick, that means that normal food (weighing 3500 grams I think) would have 6 states, all pretty clearly marked. So if you have 2 foods that you have eat 1000 grams of (leaving 2500 left), they'd merge just fine. > Which is why it seems simpler to me to just change the item > via on_apply_yield :) Also it's more visual to see half a pic > of an apple and pic of a half apple than 2 apples with the > same pic not merging. True. OTOH, at some level, I wonder what we are really gaining by having partially eaten food states. But the other gotcha is that if you use the on_apply_yield, this only applies to items that you so set up. And I don't think you could do it at all for body parts, simply because right now, the value/weight for different body parts (arms, legs, etc) is partially determined by donor monster, so if you just switch to 'half_eaten_leg' arch, the weight and food value could very well be inconsistent (much different than non eaten leg). Now you could adjust the values based on the orignal object and what it turns into. But then you're not that far off of just not doing all of that logic in the apply eat area. One thing that I also thought would be needed is to add some slow decay factor to most all flesh items like there are for a few special ones (demon ichor). You shouldn't be able to carry around the orc corpse for 3 months and expect it to still be edible. That wouldn't be hard to do, but once again, it gets into the merging issue. From kirschbaum at myrealbox.com Fri Dec 9 12:35:30 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri Dec 9 12:39:34 2005 Subject: [crossfire] Command learn_spell does not work for some spells Message-ID: <20051209183530.GA29879@kirschbaum.myrealbox.com> The DM command learn_spell does not work for some spells: for example "learn_spell ball lightning" does not work. The reason is that three different archetypes with "name ball lightning" and "type 101" (SPELL) exist: - abil_ball_lightning, - spell_ball_lightning, - spelldirect_ball_lightning. This makes get_spell_by_name() fail because it finds more than one matching spell and therefore rejects the name as ambiguous. To fix this, I'd suggest to make this function consider only archetypes with names "spell_xxx". Any objections or other suggestions? From nicolas.weeger at laposte.net Fri Dec 9 15:12:52 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Dec 9 15:13:37 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: <439527EF.2060005@sonic.net> References: <439527EF.2060005@sonic.net> Message-ID: <4399F354.8030508@laposte.net> > One thing that I also thought would be needed is to add some slow decay > factor to most all flesh items like there are for a few special ones > (demon ichor). You shouldn't be able to carry around the orc corpse for > 3 months and expect it to still be edible. > > That wouldn't be hard to do, but once again, it gets into the merging > issue. What about something more simpler, even if less realistic: every tick, one food has a 0.01% (or anoyher number) chance of rotting (if nrof > 1 only one rots)? No mergin issue, will decrease available food, introduces some random element, pretty easy to do. Ryo From nicolas.weeger at laposte.net Fri Dec 9 15:31:07 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Dec 9 15:31:39 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: <439527EF.2060005@sonic.net> References: <439527EF.2060005@sonic.net> Message-ID: <4399F79B.6040407@laposte.net> > One thing that I also thought would be needed is to add some slow decay > factor to most all flesh items like there are for a few special ones > (demon ichor). You shouldn't be able to carry around the orc corpse for > 3 months and expect it to still be edible. > > That wouldn't be hard to do, but once again, it gets into the merging > issue. What about something more simpler, even if less realistic: every tick, one food has a 0.01% (or anoyher number) chance of rotting (if nrof > 1 only one rots)? No mergin issue, will decrease available food, introduces some random element, pretty easy to do. Ryo From alex_sch at telus.net Fri Dec 9 16:27:47 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri Dec 9 16:29:37 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: <4399F354.8030508@laposte.net> References: <439527EF.2060005@sonic.net> <4399F354.8030508@laposte.net> Message-ID: <439A04E3.7020902@telus.net> Nicolas Weeger wrote: >> One thing that I also thought would be needed is to add some slow decay >>factor to most all flesh items like there are for a few special ones >>(demon ichor). You shouldn't be able to carry around the orc corpse for >>3 months and expect it to still be edible. >> >> That wouldn't be hard to do, but once again, it gets into the merging >>issue. >> >> > >What about something more simpler, even if less realistic: every tick, >one food has a 0.01% (or anoyher number) chance of rotting (if nrof > 1 >only one rots)? >No mergin issue, will decrease available food, introduces some random >element, pretty easy to do. > IMHO the proper behavior for cases if nrof > 1, is to multiply the chance by nrof, and if rolled true then remove one. Also I think that number representing the chance should be dependent on what type of food it is. Alex Schultz From mikeeusaaa at yahoo.com Fri Dec 9 23:42:35 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Dec 10 15:10:59 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: <4399F79B.6040407@laposte.net> Message-ID: <20051210054235.9063.qmail@web61013.mail.yahoo.com> Please no hacks. If something needs to be added to the all the food archtypes it is not terrible hard to do. This should be done correctly. I would suggest that the ?hp? (the nutrition value field, whatever it is) decreases depending on what kind of food, time, heat (if near a fire will decay more, if on snow, near ice will decay less or not at all) etc. --- Nicolas Weeger wrote: > > One thing that I also thought would be needed is > to add some slow decay > > factor to most all flesh items like there are for > a few special ones > > (demon ichor). You shouldn't be able to carry > around the orc corpse for > > 3 months and expect it to still be edible. > > > > That wouldn't be hard to do, but once again, it > gets into the merging > > issue. > > What about something more simpler, even if less > realistic: every tick, > one food has a 0.01% (or anoyher number) chance of > rotting (if nrof > 1 > only one rots)? > No mergin issue, will decrease available food, > introduces some random > element, pretty easy to do. > > Ryo > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mwedel at sonic.net Sun Dec 11 19:43:40 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Dec 11 19:45:41 2005 Subject: [crossfire] Tweaking alchemy In-Reply-To: <439A04E3.7020902@telus.net> References: <439527EF.2060005@sonic.net> <4399F354.8030508@laposte.net> <439A04E3.7020902@telus.net> Message-ID: <439CD5CC.1000706@sonic.net> Alex Schultz wrote: > Nicolas Weeger wrote: > >>> One thing that I also thought would be needed is to add some slow decay >>> factor to most all flesh items like there are for a few special ones >>> (demon ichor). You shouldn't be able to carry around the orc corpse for >>> 3 months and expect it to still be edible. >>> >>> That wouldn't be hard to do, but once again, it gets into the merging >>> issue. >>> >> >> What about something more simpler, even if less realistic: every tick, >> one food has a 0.01% (or anoyher number) chance of rotting (if nrof > 1 >> only one rots)? >> No mergin issue, will decrease available food, introduces some random >> element, pretty easy to do. >> > IMHO the proper behavior for cases if nrof > 1, is to multiply the > chance by nrof, and if rolled true then remove one. Also I think that > number representing the chance should be dependent on what type of food > it is. > Note one problem is identifying all those food items. If you give them a speed value, that works - you just process the active list. However, if you're not doing that, then you have to look through _all_ the items in the world to see which ones rot away. That would be a timely operation - certainly not something that can be done every tick (this is one reason why giving it speed helps out - seperate list of objects that have speed vs non speed objects, and since the bulk of objects are non speed, makes things better) - probably be even better if we fixed up objects whose sole purpose of having speed is for animation (eg, water). If client side animations are done for map, that may help out, but that is a different discussion. All that said, you could have the food decomposition in do_specials() or something - only do it every X ticks. The problem then is that everyone accross the world sees some food disappear at the same time. And if food loss is limited to just 1 item, then carrying lots of the same food is better than carrying 20 different types of food. Also, when I mentioned this, I was really envisioning this for flesh objects, which should rot much faster than prepared food - leave a steak on the counter for a day - do you really want to eat it? OTOH, most prepared items can last several days - potatos last weeks for example. So I'd also say that if applied to food, there should be different policies vs that for flesh (and the liquids should basically last for ever). So I think I'm with Mike here - arch changes are needed - the question then becomes the best way to do this. Giving the objects a low speed value is perhaps best. Objects with different speed will merge in the players inventory I believe (this does open potential abuse of players trying to merge objects that are about to decompose with those that aren't, but unless the player know where things are in the cycle, I don't see that a problem). When the object gets a turn, then look at other fields (decomposition chance, decompose into, etc) From mwedel at sonic.net Sun Dec 11 19:49:46 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Dec 11 19:51:39 2005 Subject: [crossfire] Command learn_spell does not work for some spells In-Reply-To: <20051209183530.GA29879@kirschbaum.myrealbox.com> References: <20051209183530.GA29879@kirschbaum.myrealbox.com> Message-ID: <439CD73A.5080404@sonic.net> Andreas Kirschbaum wrote: > The DM command learn_spell does not work for some spells: for example > "learn_spell ball lightning" does not work. > > The reason is that three different archetypes with "name ball lightning" > and "type 101" (SPELL) exist: > - abil_ball_lightning, > - spell_ball_lightning, > - spelldirect_ball_lightning. > > This makes get_spell_by_name() fail because it finds more than one > matching spell and therefore rejects the name as ambiguous. > > To fix this, I'd suggest to make this function consider only archetypes > with names "spell_xxx". Any objections or other suggestions? I'd think that the abil_ball_lightning could perhaps change names. The monsters don't care what it is called :). I'm just not sure if that is used for dragon players to give them the spell or something. Not even sure what spelldirect_ball_lightning is used for - the archetype exists, but isn't used in the treasure for any monster nor is it used by any other arch (quick grep spelldirect_ball_lightning */*) - I _think_ this is here for compatiblity because some maps gave the monster this object (old spell code) so needed an object to use for that instead of getting a null object. IF this is the case, the maps should perhaps be examined to see if anything is still using this, and ideally, just fix up those references and remove this arch. All that said, looking for objects that have spell_ as the archetype name would probably be a safe workaround. It'd perhaps also be good to somehow get that multiple matches were found and print a warning in that case, but not sure how easy that is to do. From mwedel at sonic.net Sun Dec 11 19:49:46 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Dec 11 19:51:43 2005 Subject: [crossfire] Command learn_spell does not work for some spells In-Reply-To: <20051209183530.GA29879@kirschbaum.myrealbox.com> References: <20051209183530.GA29879@kirschbaum.myrealbox.com> Message-ID: <439CD73A.5080404@sonic.net> Andreas Kirschbaum wrote: > The DM command learn_spell does not work for some spells: for example > "learn_spell ball lightning" does not work. > > The reason is that three different archetypes with "name ball lightning" > and "type 101" (SPELL) exist: > - abil_ball_lightning, > - spell_ball_lightning, > - spelldirect_ball_lightning. > > This makes get_spell_by_name() fail because it finds more than one > matching spell and therefore rejects the name as ambiguous. > > To fix this, I'd suggest to make this function consider only archetypes > with names "spell_xxx". Any objections or other suggestions? I'd think that the abil_ball_lightning could perhaps change names. The monsters don't care what it is called :). I'm just not sure if that is used for dragon players to give them the spell or something. Not even sure what spelldirect_ball_lightning is used for - the archetype exists, but isn't used in the treasure for any monster nor is it used by any other arch (quick grep spelldirect_ball_lightning */*) - I _think_ this is here for compatiblity because some maps gave the monster this object (old spell code) so needed an object to use for that instead of getting a null object. IF this is the case, the maps should perhaps be examined to see if anything is still using this, and ideally, just fix up those references and remove this arch. All that said, looking for objects that have spell_ as the archetype name would probably be a safe workaround. It'd perhaps also be good to somehow get that multiple matches were found and print a warning in that case, but not sure how easy that is to do. From mikeeusaaa at yahoo.com Sun Dec 11 20:38:22 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Dec 12 09:59:00 2005 Subject: [crossfire] Tomato picture, scale down? In-Reply-To: <439CD73A.5080404@sonic.net> Message-ID: <20051212023822.19271.qmail@web61024.mail.yahoo.com> Should the tomato pic be scaled down, it looks too big (like a pumpkin). Also it would be nice if the green part was on the top as per the CF perspective. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From kirschbaum at myrealbox.com Tue Dec 13 01:38:44 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Tue Dec 13 01:39:43 2005 Subject: [crossfire] Command learn_spell does not work for some spells In-Reply-To: <439CD73A.5080404@sonic.net> References: <20051209183530.GA29879@kirschbaum.myrealbox.com> <439CD73A.5080404@sonic.net> Message-ID: <20051213073843.GA23473@kirschbaum.myrealbox.com> Mark Wedel wrote: > I'd think that the abil_ball_lightning could perhaps change names. The > monsters don't care what it is called :). Seems to work: I did rename abil_xxx to "xxx ability". The actual spell cast by the monster was still "xxx". > I'm just not sure if that is used for dragon players to give them the > spell or something. The treasure lists dragon_ability_yyy (yyy=fire,cold,etc.) contain spell_xxx but not abil_xxx. Renaming these spells (perhaps to "ball lightning ability"?) also would allow DMs to learn the abilities. > Not even sure what spelldirect_ball_lightning is used for - the > archetype exists, but isn't used in the treasure for any monster nor > is it used by any other arch (quick grep spelldirect_ball_lightning */*) > - I _think_ this is here for compatiblity because some maps gave > the monster this object (old spell code) so needed an object to use > for that instead of getting a null object. IF this is the case, the > maps should perhaps be examined to see if anything is still using > this, and ideally, just fix up those references and remove this arch. No map (in maps-bigworld, both current and some old versions) references this archetype. Some more digging revealed: the ChangeLog file contains two references to spelldirect_xxx. And checking out old versions from cvs did show that dragon_ability_xxx did include spelldirect_xxx a while ago. At some time spelldirect_xxx was replaced by spell_xxx. Leaf did check the player files on metalforge: ten players include spelldirect_xxx objects. Therefore we probably should not delete these archetypes. > All that said, looking for objects that have spell_ as the archetype > name would probably be a safe workaround. With the above findings, I think we should use a slightly different approach: allow all objects with type 101 (SPELL) with the exception of arch names spelldirect_xxx. This, combined with the renamed abilities, and also an improved learn_spell command to prefer full matches over prefix matches should enable a DM to learn all existing spells other than the obsolete spelldirect ones. > It'd perhaps also be good to somehow get that multiple matches were > found and print a warning in that case, but not sure how easy that is > to do. Should not be too hard -- I'll implement that. And also improve the commands learn_spell and forget_spell to give more accurate failure messages, and to allow a direct match even if a longer one exists ("xxx" vs. "xxx ability", or "vitriol" vs. "vitriol splash"). From kirschbaum at myrealbox.com Tue Dec 13 01:56:26 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Tue Dec 13 01:57:42 2005 Subject: [crossfire] chat-embeddable in webpage In-Reply-To: <20051022134722.71480.qmail@web61025.mail.yahoo.com> References: <20051022134722.71480.qmail@web61025.mail.yahoo.com> Message-ID: <20051213075626.GA23724@kirschbaum.myrealbox.com> Mitch Obrian wrote: > You can crash the server with old sockets mode :(. I recently committed a patch that fixes all problems I could find for this mode. From alex_sch at telus.net Tue Dec 13 17:29:56 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Dec 13 17:31:42 2005 Subject: [crossfire] chat-embeddable in webpage In-Reply-To: <2501b33a0510201514x61c531e9n6c6959f4ae7c669b@mail.gmail.com> References: <2501b33a0510201514x61c531e9n6c6959f4ae7c669b@mail.gmail.com> Message-ID: <439F5974.90209@telus.net> Lord Youkai wrote: > I've been wondering if there was a way to embed a read-only view of > chat into a server's webpage. (this is a bit of a late reply, but..) I am currently writing a python implementation of the protocol as a python module. One could use mod_python or similar to make a very short script using it to log that chat. Alternatively one could have a python script running with my module that would stream to a "static" file. That said one could use ((bash + (sed or awk)) or perl) + (telnet or netcat) + oldsocketmode + piping to a static file. Alex Schultz From alex_sch at telus.net Tue Dec 13 17:30:07 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Dec 13 17:31:46 2005 Subject: [crossfire] chat-embeddable in webpage In-Reply-To: <2501b33a0510201514x61c531e9n6c6959f4ae7c669b@mail.gmail.com> References: <2501b33a0510201514x61c531e9n6c6959f4ae7c669b@mail.gmail.com> Message-ID: <439F597F.406@telus.net> Lord Youkai wrote: > I've been wondering if there was a way to embed a read-only view of > chat into a server's webpage. (this is a bit of a late reply, but..) I am currently writing a python implementation of the protocol as a python module. One could use mod_python or similar to make a very short script using it to log that chat. Alternatively one could have a python script running with my module that would stream to a "static" file. That said one could use ((bash + (sed or awk)) or perl) + (telnet or netcat) + oldsocketmode + piping to a static file. Alex Schultz From brenlally at gmail.com Thu Dec 15 14:06:41 2005 From: brenlally at gmail.com (Brendan Lally) Date: Thu Dec 15 14:07:45 2005 Subject: [crossfire] requestable spell lists. Message-ID: <7903f03c0512151206r3bdff453j4758827ddc4d8a92@mail.gmail.com> I have today attached a patch to the sf tracker (which can be found at https://sourceforge.net/tracker/index.php?func=detail&aid=1381875&group_id=13833&atid=313833 ) which implements the beginnings of support for a new requestinfo type - spell_list. Whilst this is not complete - the cases where the spell list could be updated are not all dealt with, and there is no proper client support (although https://sourceforge.net/tracker/index.php?func=detail&aid=1381871&group_id=152431&atid=784287 contains a hack for jcrossclient that I've been using for testing purposes). - it is at a stage where comments are needed. - Should any of the fields used change, or be extended or added to? With this in mind, I ask you to read the rest of this message which contains a (hopefully clear) description of the changes I am considering. requestinfo spell_list: This is intended to allow clients to request the spell list, and get it back in a controlled way, so that it can build menus/lists/interfaces of whatever sort it thinks appropriate. Additionally, it adds a new setup option, spellmon, which sends a value if the spell list has altered. This is sent once each time it alters (or might have altered) between sending of the stats command, and only if requested. It sends back a value which corresponds to the type of change that might have occurred; 1 - costs changed. 2 - attunements change 4 - spells were added or removed. This is a bitmask, so multiple values may be sent, depending on what the client wants to do with the information, it may or may not want to re-request the spell_list. from the diff to doc/Developers/protocol: spell_list (no parameters) This returns a list of all the spells the player knows, along with some other information about them. The data is sent in plain text, one spell per line in the following format. spell name:spell level:skill:spell paths:status:mana cost:grace cost Where: skill is sent as the number that maps to the skill as provided by skill info (above) spell paths is sent as a series of space seperated words status is a number that has the following meanings; 1 - attuned 2 - repelled 4 - denied any or all of these may or may not be set for each spell, if so, they add together. All of these fields will be sent, but it is not certain that any field will have entries. If extra fields are added later, it will be to the end of each entry. an example response is: burning hands:1:174:Fire:1:4:0 holy word:1:170:Turning:0:0:4 spark shower:1:176:Electricity:0:5:0 note that in the case where the player hasn't logged in, or doesn't have any spells, a blank list is returned (the replyinfo forms the only line in the response) From mwedel at sonic.net Fri Dec 16 00:37:52 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Dec 16 00:39:45 2005 Subject: [crossfire] requestable spell lists. In-Reply-To: <7903f03c0512151206r3bdff453j4758827ddc4d8a92@mail.gmail.com> References: <7903f03c0512151206r3bdff453j4758827ddc4d8a92@mail.gmail.com> Message-ID: <43A260C0.9060208@sonic.net> Quick thoughts: 1) Why not just go for a straight push approach, eg, have the server send updates whenever needed? It seems as written now, you'll get the case like: S->C: stats ... spells have changed C->S: requestinfo spell_list S->C: spell_list ... I just don't really see what we get by having to do it via a purely request basis. I can't really see the client not sending a request when things change. If there is the potential of client only sending requestinfo based on what changed, that could also be done with a push approach (setup spellmon val, and based on val determines what events we send spell updates. the other advantage of push is we can be more bandwidth efficient. If a player learns a new spell, only need to send that spell down the line, and not all the spells if done on a pull approach. 2) I wonder if more spell info should be sent. For example, base damage values, lore information, etc. If we only send spells on push, bandwidth shouldn't be that costly, and it then gives the player more info to choose spells (fireball, 24 dam, ...). Related, I think it'd be easier all around to send the spell path information as a bitmask - saves some bandwidth, and the bitmasks values should be pretty stable (can't remember last time a new spell path was added, and even then, the client could just display something like 'unknown' or whatever) 3) Related to point #2, I wonder if it would be 'easier' to just send the base values for costs that the server users to calculate real cost. Otherwise, whenever the player equips an item that changes their spellpaths, you get the case of potentially all the spells changing in value. Level changes can also effect costs, and that is likely to happen when you really don't want more data sent down, eg, in combat. The only change needed for that to really work would be to send down the players current spellpaths in the stats command. Thus, the only time in this case you really need to send spell information is when the player learns a new spell. That said, it does complicate the client a bit. From brenlally at gmail.com Fri Dec 16 09:17:55 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Dec 16 09:19:47 2005 Subject: [crossfire] requestable spell lists. In-Reply-To: <43A260C0.9060208@sonic.net> References: <7903f03c0512151206r3bdff453j4758827ddc4d8a92@mail.gmail.com> <43A260C0.9060208@sonic.net> Message-ID: <7903f03c0512160717x6b3eb125sb7fb2a4813cee290@mail.gmail.com> On 12/16/05, Mark Wedel wrote: > > Quick thoughts: > > 1) Why not just go for a straight push approach, eg, have the server send > updates whenever needed? > > It seems as written now, you'll get the case like: > S->C: stats ... spells have changed > C->S: requestinfo spell_list > S->C: spell_list ... > > I just don't really see what we get by having to do it via a purely request > basis. I can't really see the client not sending a request when things change. I can, that's why I started off with the status values. If a client only shows spell names, or only names and denied status, they would only request a new copy of the list on status 4 or 4 & 2 respectively. > If there is the potential of client only sending requestinfo based on what > changed, that could also be done with a push approach (setup spellmon val, and > based on val determines what events we send spell updates. This could work, but requires a new command in the protocol. > the other advantage of push is we can be more bandwidth efficient. If a > player learns a new spell, only need to send that spell down the line, and not > all the spells if done on a pull approach. I thought about that, but I can't see how it can be done without the server storing the spell list for each player, which is a fairly ugly way to implement things. (the only other thing I could think of is to abuse the spell objects, and set an update value for each one (added, removed, changed costs, changed damage, etc) > 2) I wonder if more spell info should be sent. For example, base damage values, > lore information, etc. If we only send spells on push, bandwidth shouldn't be > that costly, and it then gives the player more info to choose spells (fireball, > 24 dam, ...). Lore and damage seem reasonable, although then the question is, should that be base damage or effective damage? Both of these values have issues, effective damage may not do as much damage as stated (even before resistance) owing to quirks in how each spell propagates, if base damage is sent, then you need to send a lot more data and hardcode the calculation. (more on that below) > Related, I think it'd be easier all around to send the spell path > information as a bitmask - saves some bandwidth, and the bitmasks values should > be pretty stable (can't remember last time a new spell path was added, and even > then, the client could just display something like 'unknown' or whatever) This could work, although currently the clients have no information about spellpaths. This could be added, although maybe then a request_info spellpaths would be better to initialise it? (this way clients couldn't fall out of sync, and there is no restriction on adding new paths). > 3) Related to point #2, I wonder if it would be 'easier' to just send the base > values for costs that the server users to calculate real cost. more consistant in terms of data sent in a single iteration. but SP_level_spellpoint_cost - the function that does this server side, calls on about half a dozen other values, all of which the client would need to know, and some of which (settings.spellpoint_level_depend for example) are quite obscure. If ever the method used to calculate cost changed, then this would fail hopelessly. I don't think a commitment to keep the same spell costing rate can be made, therefore hardcoding it into clients is a bad idea. > Otherwise, whenever the player equips an item that changes their spellpaths, > you get the case of potentially all the spells changing in value. Level changes > can also effect costs, and that is likely to happen when you really don't want > more data sent down, eg, in combat. This would be where the logic behind letting the client decide when to request the information comes into play. > The only change needed for that to really > work would be to send down the players current spellpaths in the stats command. This seems like quite a good idea, it is simpler and yet more powerful than the status I have been using. > Thus, the only time in this case you really need to send spell information is > when the player learns a new spell. That said, it does complicate the client a bit. I'm more concerned with how it complicates the server, it will mean that each spell will need to track its status independently. It might be possible to pick an unused value in the spell objects, and use this to hold states, and then iterate over them with a diff like syntax. so we might have spellupdate !spark shower:1:176:Electricity:0:5:0:Sparkshower is a cone of electrical energy. Creatures caught within the cone take magical and electrical damage. +holy word:1:170:Turning:0:0:4:: -burning hands:1:174:Fire:1:4:0:: (icidentally, these last two do not have msg's) In this case then, every line altering a spell would start with + - or ! to add, remove or modify a spell respectively, any line not starting with one of these characters, would be the next line of the msg associated with the previous spell. This could still lead to a lot of traffic at login, although maybe that is preferable than a lot of traffic during combat. From antonoussik at gmail.com Fri Dec 16 17:59:33 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Fri Dec 16 17:59:46 2005 Subject: [crossfire] Wraith changes Message-ID: Today I have posted a patch to the tracker, which can be found at https://sourceforge.net/tracker/index.php?func=detail&aid=1382884&group_id=13833&atid=313833 Repeating the patch description, it does the following to wraiths: >1 Wraith characters gain no food or health regeneration >by eating normal food. > >2 Wraith characters do not regenerate health naturally >at any noticable rate. > >3 Wraith characters deal more damage with life_stealing >than other players do. > >4 Wraith characters also gain food when they attack >using life_stealing. > >5 Wraith characters start with an extra skill called >wraith_feed, which deals life_stealing attack and >paralysis attack. > >6 life_stealing only works on living things now, and >specifically not on doors. > >If these patches are applied to a running server, old >wraith characters will be affected by change 1, 3, and >4, but are not affected by changes 2 and 5. Change 6 >affects all characters. The patch seems to work, but my biggest concern is game balance. On one hand, a wraith should be strong enough to suck life from victim faster than victim sucks blood from it, since if it is losing hp it will die. I feel a few more people should try the new wraith out before the patch is applied to the main tree, as it is a sifnificant change to how the race is played, and may not agree with other people's perceptions of what this race should be like. From brenlally at gmail.com Fri Dec 16 18:45:49 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Dec 16 18:45:46 2005 Subject: [crossfire] Wraith changes In-Reply-To: References: Message-ID: <7903f03c0512161645h50b24188xf5f20d26b915b546@mail.gmail.com> On 12/16/05, Anton Oussik wrote: > > a wraith should be strong enough to suck life from victim > faster than victim sucks blood from it, since if it is losing hp it > will die. But surely this point is only true for creatures that are weaker than it? One wouldn't expect a level 1 wraith to be able to kill a dragon surely. From mwedel at sonic.net Fri Dec 16 19:25:32 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Dec 16 19:25:48 2005 Subject: [crossfire] requestable spell lists. In-Reply-To: <7903f03c0512160717x6b3eb125sb7fb2a4813cee290@mail.gmail.com> References: <7903f03c0512151206r3bdff453j4758827ddc4d8a92@mail.gmail.com> <43A260C0.9060208@sonic.net> <7903f03c0512160717x6b3eb125sb7fb2a4813cee290@mail.gmail.com> Message-ID: <43A3690C.80800@sonic.net> Brendan Lally wrote: >> I just don't really see what we get by having to do it via a purely request >> basis. I can't really see the client not sending a request when things change. > > I can, that's why I started off with the status values. If a client > only shows spell names, or only names and denied status, they would > only request a new copy of the list on status 4 or 4 & 2 respectively. > >> If there is the potential of client only sending requestinfo based on what >> changed, that could also be done with a push approach (setup spellmon val, and >> based on val determines what events we send spell updates. > > This could work, but requires a new command in the protocol. I don't know why it would require a new command. the setup command is not true/false values, it is setting some variable to whatever value. So a 'setup spellmon 6' is perfectly valid. And to push the data, the same command could be used - it'd just need to be clarified that spellist would represent updates to existing data. Or the spellist command could send optional params to denote what it is updating. > >> the other advantage of push is we can be more bandwidth efficient. If a >> player learns a new spell, only need to send that spell down the line, and not >> all the spells if done on a pull approach. > > I thought about that, but I can't see how it can be done without the > server storing the spell list for each player, which is a fairly ugly > way to implement things. (the only other thing I could think of is to > abuse the spell objects, and set an update value for each one (added, > removed, changed costs, changed damage, etc) Same way it is done for most objects - you send it at the time of the event. So in server/apply.c, in learn_spell, you'd make a call to send_spellist() when the player learns a spell. This is how most all of the object updates for player inventory are currently done - the update is sent in the code that makes the change - we don't hold the results and send them later. > >> 2) I wonder if more spell info should be sent. For example, base damage values, >> lore information, etc. If we only send spells on push, bandwidth shouldn't be >> that costly, and it then gives the player more info to choose spells (fireball, >> 24 dam, ...). > > Lore and damage seem reasonable, although then the question is, should > that be base damage or effective damage? Both of these values have > issues, effective damage may not do as much damage as stated (even > before resistance) owing to quirks in how each spell propagates, if > base damage is sent, then you need to send a lot more data and > hardcode the calculation. (more on that below) For damage, we obviously can't take into account resistances of creatures. So it'd be basic damage - if the spell does more, like cones, because of multiple effects on top of each other, we don't factor that, as you can't really know for sure how that will work out (likewise for fireballs - damage would vary greatly based on where the creature is in the effect). The lore info could note those increased effects. > >> Related, I think it'd be easier all around to send the spell path >> information as a bitmask - saves some bandwidth, and the bitmasks values should >> be pretty stable (can't remember last time a new spell path was added, and even >> then, the client could just display something like 'unknown' or whatever) > > This could work, although currently the clients have no information > about spellpaths. > This could be added, although maybe then a request_info spellpaths > would be better to initialise it? (this way clients couldn't fall out > of sync, and there is no restriction on adding new paths). Perhaps, adding requesting adds complication, but not that much. At the same time, there is a lot of communication that is defined stable. IF someone were to add another stat for example, that would require some significant changes - the client isn't designed for dynamic stat information. At some level, it could be nice for the server to somehow note what current client version is and tell the player if their client is out of date. So if the client is out of date, they'd know to go update it - that'd be good for reasons beyond just spellpaths. But hardcoding them or doing via requestinfo both work. Note of course the spell path info in this case is really the bitmask to name mapping. For all spell calculations itself, the client wouldn't really care (player bitmask is attuned 4, denied 24, repelled 1. This spells path is 16, so it is denied to the player, etc). It doesn't need to know what spell path 16 is to make those calculations. But that is one reason why I say giving the client hte numbers is easier - it makes handling easier. Otherwise, what I'm sure will happen is at some point someone will come up with code in the client that takes the spellpaths and converts them into bitmasks, etc. If I've learned one thing through lots of client/server programming, almost always best to send the raw data and let the client figure out what it means vs having the server try to figure out what it thinks the data should look like and send that processed data to the client. > >> 3) Related to point #2, I wonder if it would be 'easier' to just send the base >> values for costs that the server users to calculate real cost. > > more consistant in terms of data sent in a single iteration. but > SP_level_spellpoint_cost - the function that does this server side, > calls on about half a dozen other values, all of which the client > would need to know, and some of which > (settings.spellpoint_level_depend for example) are quite obscure. If > ever the method used to calculate cost changed, then this would fail > hopelessly. I don't think a commitment to keep the same spell costing > rate can be made, therefore hardcoding it into clients is a bad idea. well, settings.spellpoint_level_depend determines if spellpoint costs differ - it is either an on/off value. Looking at other values: Since the spell is linked to a skill, the client does know the skill level. The client also will know the spell level (one of the most importent bits of the spell). As per notes above, it would also know the spell paths. To figure out actual sp costs, it would need the sp/maxsp and grace/maxgrace values. the PATH_SP_MULT macro is perhaps the most variable. However, since that macro has values hard coded in (not pulling it from settings or anyplace else), probably relatively hard coded. All that said, one could see something like a C->S: requestinfo spell_conf, in which the server responds with those values. But that does make things more complicated. But I don't think those values have changed in 5+ years, so I'd call them relatively stable also. > >> Otherwise, whenever the player equips an item that changes their spellpaths, >> you get the case of potentially all the spells changing in value. Level changes >> can also effect costs, and that is likely to happen when you really don't want >> more data sent down, eg, in combat. > > This would be where the logic behind letting the client decide when to > request the information comes into play. But I don't really see how the client can make any real intelligent decision on that. It would basically seem to me that the client will request a spell dump if the spells have changed and it matches why it wants updates. I can't see the client really being able to know that the player is in combat and thus now is a bad time to request all that data. I'd think at best the client could perhaps decide 'at most, I'll request spell info every 10 seconds' or something. But then you'll get the case where a player equips something that makes them attuned, goes to cast the spell, and is confused because the client is still showing old data in terms of spell cost and damage. This may seem trivial, but when it happens, I'm sure bugs will be filed and people complain. > >> The only change needed for that to really >> work would be to send down the players current spellpaths in the stats command. > > This seems like quite a good idea, it is simpler and yet more powerful > than the status I have been using. > >> Thus, the only time in this case you really need to send spell information is >> when the player learns a new spell. That said, it does complicate the client a bit. > > I'm more concerned with how it complicates the server, it will mean > that each spell will need to track its status independently. See note above. You'd just inject the appropriate send spell data command wherever the player can learn a spell. And in fact, the number of places a player can learn a spell is limited- in fact, I think it all leads back to do_learn_spell(), and all the data that is needed to send the data to the client is there (player object, spell object, etc). > > It might be possible to pick an unused value in the spell objects, and > use this to hold states, and then iterate over them with a diff like > syntax. > > so we might have > > spellupdate > !spark shower:1:176:Electricity:0:5:0:Sparkshower is a cone of > electrical energy. > Creatures caught within the cone take magical and electrical damage. > +holy word:1:170:Turning:0:0:4:: > -burning hands:1:174:Fire:1:4:0:: > (icidentally, these last two do not have msg's) > > In this case then, every line altering a spell would start with + - or > ! to add, remove or modify a spell respectively, any line not starting > with one of these characters, would be the next line of the msg > associated with the previous spell. > > This could still lead to a lot of traffic at login, although maybe > that is preferable than a lot of traffic during combat. Right now, I believe it is basically a requirement that spell names be unique. This, it can be assumed (within the protocol) that if a spellupdate contains a spell name that the client already knows about, it is just and update for that spell. If it contains info it doesn't know about, it is a new spell. Right now, other than DM action, there is no way to lose a spell. But for that, might just be easiest to do something like 'spellremove ....', and just like do_learn_spell() being the only place to add a spell, the only place to remove a spell is probably just a few places so wouldn't be hard to do. In terms of bandwidth, I wonder if it is reasonable to do some form of caching of the message info, eg, the client have a spell file that contains the info it got. Instead of the server sending the message text each time, it sends a checksum of the message data. The client could load the spell up from its history file and see if the checksum match - if so, use the one in the history file, if not, request info from server. From mwedel at sonic.net Fri Dec 16 19:30:29 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Dec 16 19:31:47 2005 Subject: [crossfire] Wraith changes In-Reply-To: References: Message-ID: <43A36A35.3020405@sonic.net> Quick question - does this mean the only way a wraith gets food is by life stealing attacks? If so, I'd think they need to get given a very high sustenance type of value - otherwise, I'd think you'd get a lot of starving wraiths at certain times, eg, you're hauling your loot of the dungeon and don't have anything convenient to attack. Also, from myths, undead can live for hundreds of years without food/water, so that'd also make sense - that wraith could sit in the corner for a long time and not need food. From brenlally at gmail.com Fri Dec 16 20:57:55 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Dec 16 20:59:48 2005 Subject: [crossfire] requestable spell lists. In-Reply-To: <43A3690C.80800@sonic.net> References: <7903f03c0512151206r3bdff453j4758827ddc4d8a92@mail.gmail.com> <43A260C0.9060208@sonic.net> <7903f03c0512160717x6b3eb125sb7fb2a4813cee290@mail.gmail.com> <43A3690C.80800@sonic.net> Message-ID: <7903f03c0512161857m47085ff3ge6f6b4c26392bd6c@mail.gmail.com> On 12/17/05, Mark Wedel wrote: > Brendan Lally wrote: > > This could work, but requires a new command in the protocol. > > I don't know why it would require a new command. the setup command is not > true/false values, it is setting some variable to whatever value. > > So a 'setup spellmon 6' is perfectly valid. > > And to push the data, the same command could be used - it'd just need to be > clarified that spellist would represent updates to existing data. Or the > spellist command could send optional params to denote what it is updating. There is no 'same command' the existing implementation uses stats and request/reply info. > >> the other advantage of push is we can be more bandwidth efficient. If a > >> player learns a new spell, only need to send that spell down the line, and not > >> all the spells if done on a pull approach. > > > > I thought about that, but I can't see how it can be done without the > > server storing the spell list for each player, which is a fairly ugly > > way to implement things. (the only other thing I could think of is to > > abuse the spell objects, and set an update value for each one (added, > > removed, changed costs, changed damage, etc) > > Same way it is done for most objects - you send it at the time of the event. > > So in server/apply.c, in learn_spell, you'd make a call to send_spellist() > when the player learns a spell. > > This is how most all of the object updates for player inventory are currently > done - the update is sent in the code that makes the change - we don't hold the > results and send them later. One thing that was suggested by gros on IRC earlier was almost a hybrid approach, instead of having a stats value that says what type of change has occurred, you have a stats value that contains a number for the spell object, these would be assigned sequentially, and be unique for any one player on each run of the server. (everyone would have their spells numbered 1,2,3,4, etc.) Then, if ever a spell was added or removed (by moving the attunement into a seperate stat, and sending only the base cost, this can be the only time an update is needed), the stats command can send the number of the spell that was changed, and the client could then requestinfo # and get back only that spell. (this was my understanding of gros' suggestion, I hope he will clarify if I misunderstood some detail) > >> 2) I wonder if more spell info should be sent. For example, base damage values, > >> lore information, etc. If we only send spells on push, bandwidth shouldn't be > >> that costly, and it then gives the player more info to choose spells (fireball, > >> 24 dam, ...). > > > > Lore and damage seem reasonable, although then the question is, should > > that be base damage or effective damage? Both of these values have > > issues, effective damage may not do as much damage as stated (even > > before resistance) owing to quirks in how each spell propagates, if > > base damage is sent, then you need to send a lot more data and > > hardcode the calculation. (more on that below) > > For damage, we obviously can't take into account resistances of creatures. So > it'd be basic damage - if the spell does more, like cones, because of multiple > effects on top of each other, we don't factor that, as you can't really know for > sure how that will work out (likewise for fireballs - damage would vary greatly > based on where the creature is in the effect). The lore info could note those > increased effects. This requires a substantial increase in the number of spells with such information. > >> Related, I think it'd be easier all around to send the spell path > >> information as a bitmask - saves some bandwidth, and the bitmasks values should > >> be pretty stable (can't remember last time a new spell path was added, and even > >> then, the client could just display something like 'unknown' or whatever) > > > > This could work, although currently the clients have no information > > about spellpaths. > > This could be added, although maybe then a request_info spellpaths > > would be better to initialise it? (this way clients couldn't fall out > > of sync, and there is no restriction on adding new paths). > > Perhaps, adding requesting adds complication, but not that much. At the same > time, there is a lot of communication that is defined stable. IF someone were > to add another stat for example, that would require some significant changes - > the client isn't designed for dynamic stat information. Requesting spell path names, at least on the server side, is easy, I had it working locally already. The way I'm dealing with stats is to only send them if spellmon is set, anyone sending that should know what they will get back. > At some level, it could be nice for the server to somehow note what current > client version is and tell the player if their client is out of date. So if the > client is out of date, they'd know to go update it - that'd be good for reasons > beyond just spellpaths. I'm not sure this is such a good idea, consider the case of someone running a distro that has its own package management and creation, they may be told to update their client, but not have any packages available. > well, settings.spellpoint_level_depend determines if spellpoint costs differ - > it is either an on/off value. Ok, how do you propose to let the client know what it is set to? > Looking at other values: > Since the spell is linked to a skill, the client does know the skill level. > The client also will know the spell level (one of the most importent bits of > the spell). > As per notes above, it would also know the spell paths. > To figure out actual sp costs, it would need the sp/maxsp and grace/maxgrace > values. > the PATH_SP_MULT macro is perhaps the most variable. However, since that > macro has values hard coded in (not pulling it from settings or anyplace else), > probably relatively hard coded. > > All that said, one could see something like a C->S: requestinfo spell_conf, > in which the server responds with those values. But that does make things more > complicated. But I don't think those values have changed in 5+ years, so I'd > call them relatively stable also. In that case, it would need to be accepted that any change to such calculations would require a change in the server protocol version number. > >> Otherwise, whenever the player equips an item that changes their spellpaths, > >> you get the case of potentially all the spells changing in value. Level changes > >> can also effect costs, and that is likely to happen when you really don't want > >> more data sent down, eg, in combat. > > > > This would be where the logic behind letting the client decide when to > > request the information comes into play. > > But I don't really see how the client can make any real intelligent decision > on that. It would basically seem to me that the client will request a spell > dump if the spells have changed and it matches why it wants updates. > > I can't see the client really being able to know that the player is in combat > and thus now is a bad time to request all that data. It would be possible to wait for the rate of drawinfo's to drop below a certain level (since there are normally lots of these in combat. > I'd think at best the client could perhaps decide 'at most, I'll request spell > info every 10 seconds' or something. But then you'll get the case where a > player equips something that makes them attuned, goes to cast the spell, and is > confused because the client is still showing old data in terms of spell cost and > damage. If the cost and damage are sent as base values, this information will be updatable client-side as soon as the new stats data is sent. > Right now, I believe it is basically a requirement that spell names be unique. Well, if it isn't, using the cast command becomes interesting. > This, it can be assumed (within the protocol) that if a spellupdate contains a > spell name that the client already knows about, it is just and update for that > spell. If it contains info it doesn't know about, it is a new spell. fair enough. > Right now, other than DM action, there is no way to lose a spell. But for > that, might just be easiest to do something like 'spellremove ....', and just > like do_learn_spell() being the only place to add a spell, the only place to > remove a spell is probably just a few places so wouldn't be hard to do. I think do_forget_spell is the only place it is used. > In terms of bandwidth, I wonder if it is reasonable to do some form of caching > of the message info, eg, the client have a spell file that contains the info it > got. Instead of the server sending the message text each time, it sends a > checksum of the message data. The client could load the spell up from its > history file and see if the checksum match - if so, use the one in the history > file, if not, request info from server. This seems overly complicated, the msg field is only a couple of lines anyway, and, if the list is mostly static (as your suggestions would make it be) it would only really be sent once per session. Certainly this is untrue of message fields on visible items, and no checksumming is used for the descriptions of them. Overall, I am inclined to go with your approach, but I am still unsure how to inform the client about spellpoint_level_depend. From mwedel at sonic.net Fri Dec 16 21:46:04 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Dec 16 21:47:47 2005 Subject: [crossfire] requestable spell lists. In-Reply-To: <7903f03c0512161857m47085ff3ge6f6b4c26392bd6c@mail.gmail.com> References: <7903f03c0512151206r3bdff453j4758827ddc4d8a92@mail.gmail.com> <43A260C0.9060208@sonic.net> <7903f03c0512160717x6b3eb125sb7fb2a4813cee290@mail.gmail.com> <43A3690C.80800@sonic.net> <7903f03c0512161857m47085ff3ge6f6b4c26392bd6c@mail.gmail.com> Message-ID: <43A389FC.4000401@sonic.net> Brendan Lally wrote: > On 12/17/05, Mark Wedel wrote: >> Brendan Lally wrote: >>> This could work, but requires a new command in the protocol. >> I don't know why it would require a new command. the setup command is not >> true/false values, it is setting some variable to whatever value. >> >> So a 'setup spellmon 6' is perfectly valid. >> >> And to push the data, the same command could be used - it'd just need to be >> clarified that spellist would represent updates to existing data. Or the >> spellist command could send optional params to denote what it is updating. > > There is no 'same command' the existing implementation uses stats and > request/reply info. There are several setup commands that currently pass in numeric values and not just a simple true/false. mapsize is the most obvious. There is currently the 'exp64' setup command that determines if exp values are sent as 64 bit in the stats command. So having a setup command that takes a numeric value and effects operation of other things is pretty standard. > One thing that was suggested by gros on IRC earlier was almost a > hybrid approach, instead of having a stats value that says what type > of change has occurred, you have a stats value that contains a number > for the spell object, these would be assigned sequentially, and be > unique for any one player on each run of the server. (everyone would > have their spells numbered 1,2,3,4, etc.) > > Then, if ever a spell was added or removed (by moving the attunement > into a seperate stat, and sending only the base cost, this can be the > only time an update is needed), the stats command can send the number > of the spell that was changed, and the client could then requestinfo # > and get back only that spell. (this was my understanding of gros' > suggestion, I hope he will clarify if I misunderstood some detail) Since spell are objects, you could use the object tag as a unique identifier. That'd at least be easier on the C->S request. But this does complicate things - if a player learns a spell, you need to send a stat command at that time (or you need to hold that player learned spell X, which would be a pain). If player equips something, then a bunch of spells could change, and you somehow need to record that all those changed. It is much easier to send the differences when they happen - then you don't have to hold any state in the server. I'd also be a little concerned about using the stats command to denote what spells have changed - this seems to be getting away from what it was really designed for, which was a simple method to communicate stats. I'd be more inclined to create a new command then, like spells_changed. I guess it sort of comes down to what data is expected. I'd personally prefer not to see holding of a lot more state data on the server side - for this project, I don't think that is needed (other than spellpath communication). Just easier to send the data as you know it changes, but that gets messy with level changes and spellpath changes (otoh, if client knows spellpaths, it would then know what on its own what spells have just changed, and could request info on those specific spells). < much about spell info/lore cut about> > > This requires a substantial increase in the number of spells with such > information. True, but that has to be written at some point. At some level, however, providing damage information is still a step forward - right now, the only thing a player easily knows about spells is level and cost. If we provide damage info, it'd be hard to imagine people saying 'this is bad - shouldn't provide it because I don't know what it means'. And if nothing else, it at least provides some guidance for spells of the same type (hmm, small snowball does X damage, small fireball does Y, X>Y, I'll cast the snowball) >> At some level, it could be nice for the server to somehow note what current >> client version is and tell the player if their client is out of date. So if the >> client is out of date, they'd know to go update it - that'd be good for reasons >> beyond just spellpaths. > > I'm not sure this is such a good idea, consider the case of someone > running a distro that has its own package management and creation, > they may be told to update their client, but not have any packages > available. OTOH, you get the flip side of that - someone trying to play on an old client, having troubles, and giving up. Maybe a new client isn't available for their distro, maybe one is. But right now, a user trying to play just sees something is broken - my normal practice is more info usually isn't a bad thing. At least if we tell the player there is an updated client, he can decide if he wants to try and install it, etc. > >> well, settings.spellpoint_level_depend determines if spellpoint costs differ - >> it is either an on/off value. > > Ok, how do you propose to let the client know what it is set to? Easy enough to be part of a request command or something. Or for that matter, the spellinfo could have some option parameters, like: spellinfo , etc. That might be overkill to send that each time however. >> All that said, one could see something like a C->S: requestinfo spell_conf, >> in which the server responds with those values. But that does make things more >> complicated. But I don't think those values have changed in 5+ years, so I'd >> call them relatively stable also. > > In that case, it would need to be accepted that any change to such > calculations would require a change in the server protocol version > number. If the calculation method is changed a great deal, then some form of communicating that would be order. Or for that matter, could just have a field like 'spellpoint_calculation_mode ...'. However, I was thinking about this, a simpler approach would be to send base values based on current level, but not spell path data. Thus, when player equip/unequip. easy to apply the spellpath costs (as its just a simple multiplier). When the player gains a level, then costs get re-sent. I'm not positive I like that approach - I'm more tempted for an all or nothing approach on that calculatable information. >> I can't see the client really being able to know that the player is in combat >> and thus now is a bad time to request all that data. > > It would be possible to wait for the rate of drawinfo's to drop below > a certain level (since there are normally lots of these in combat. True, there are lots of things you could try and do. Just I don't see any info the client has right now as making that decision easy (it doesn't record rate of drawinfos for example). And even then, you'd get weird cases - player goes to a shop, drops a pile of good on the identify altar, sees what all his stuff is, and says 'oh, a new spellbook'. Client just got a bunch of drawinfos, thus doesn't think now is a good time, etc. All that said, if we're only sending the occasional spell now and again, that bandwidth cost shouldn't be an issue. I really only see it being an issue if we dump all the spells to the client, because that is enough data to cause some lag. > >> I'd think at best the client could perhaps decide 'at most, I'll request spell >> info every 10 seconds' or something. But then you'll get the case where a >> player equips something that makes them attuned, goes to cast the spell, and is >> confused because the client is still showing old data in terms of spell cost and >> damage. > > If the cost and damage are sent as base values, this information will > be updatable client-side as soon as the new stats data is sent. Right, which is one reason I like that apporach. > >> In terms of bandwidth, I wonder if it is reasonable to do some form of caching >> of the message info, eg, the client have a spell file that contains the info it >> got. Instead of the server sending the message text each time, it sends a >> checksum of the message data. The client could load the spell up from its >> history file and see if the checksum match - if so, use the one in the history >> file, if not, request info from server. > > This seems overly complicated, the msg field is only a couple of lines > anyway, and, if the list is mostly static (as your suggestions would > make it be) it would only really be sent once per session. Certainly > this is untrue of message fields on visible items, and no checksumming > is used for the descriptions of them. True. That said, for visible items, message information is only sent when player examines the item - it is not sent when it becomes part of the player inventory. You can look at the itemcmd code and see that the amount of data sent for items is relatively basic. > > Overall, I am inclined to go with your approach, but I am still unsure > how to inform the client about spellpoint_level_depend. Well, the cost variation based on level is documented in the doc/Developer/spells file. I'd make the case that behaviour is unlikely to change. As said, the attunement/repelled costs are currently hard coded, so I'd say those are unlikely to change (would probably be good to at least replace those with a #define value however) I think it is perfectly reasonable to expect the current calculations to remain stable, save for there being some error found in them. So I'd say at least that it is reasonable to assume the way costs are calculated is not likely to change. From antonoussik at gmail.com Sat Dec 17 01:49:08 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sat Dec 17 01:49:47 2005 Subject: [crossfire] Wraith changes In-Reply-To: <43A36A35.3020405@sonic.net> References: <43A36A35.3020405@sonic.net> Message-ID: On 17/12/05, Mark Wedel wrote: > Quick question - does this mean the only way a wraith gets food is by life > stealing attacks? Yes, although magical means (like golden unicorn horn) will also work. Also food that restores hp has no restoration effect, although food that restores mana works as with any other characters (but restoring mana only). > If so, I'd think they need to get given a very high sustenance type of value - > otherwise, I'd think you'd get a lot of starving wraiths at certain times, eg, > you're hauling your loot of the dungeon and don't have anything convenient to > attack. Restoration -100 and sust +60 that was already there give the wraith incredibly high sustenance. When idling they seem to lose about 5 food per hour, which means they can live for up to 8 real life days of playing without needing to feed. Also, although restoration -100 means they do not heal naturaly very well, they still do heal over time. The wraith I left overnight had 14/22 health, and in the morning it was fully healed. From antonoussik at gmail.com Sat Dec 17 01:53:36 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sat Dec 17 01:54:36 2005 Subject: [crossfire] Wraith changes In-Reply-To: <7903f03c0512161645h50b24188xf5f20d26b915b546@mail.gmail.com> References: <7903f03c0512161645h50b24188xf5f20d26b915b546@mail.gmail.com> Message-ID: On 17/12/05, Brendan Lally wrote: > On 12/16/05, Anton Oussik wrote: > > a wraith should be strong enough to suck life from victim > > faster than victim sucks blood from it, since if it is losing hp it > > will die. > > But surely this point is only true for creatures that are weaker than it? Quite right, you gain levels in feeding like you do in anything else. You start off being able to feed to weak feeble things, but then get better and are able to feed off stronger enemies. From nicolas.weeger at laposte.net Sat Dec 17 08:48:36 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Dec 17 08:49:47 2005 Subject: [crossfire] Proposal for player logfile / plugins Message-ID: <43A42543.6020704@laposte.net> Hello. It seems the slow issues Metalforge has been experiencing are related to Python, and possibly due to the size of the logfile (log containing birth date, kick info, muzzle, and so on). My proposal is to split this file, putting player's information directly in the player's directory. To do that, I'd like to enable plugins to access specific files in player's directory (or, for safety, a subdirectory, as to not mess with unique maps). Plugins could this way store player-related information easily. Also, when a player quits, information is just removed with everything else with the player's directory. Drawback (for logfile at least), no more consolidated file with all the info - but shouldn't be too hard to do a script to merge all info for statistical purposes. What do you think of that? Nicolas From yann.chachkoff at myrealbox.com Sat Dec 17 10:14:44 2005 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat Dec 17 10:15:47 2005 Subject: [crossfire] requestable spell lists. Message-ID: <1134836084.c7d9c5dcyann.chachkoff@myrealbox.com> >One thing that was suggested by gros on IRC earlier was almost a >hybrid approach, instead of having a stats value that says what type >of change has occurred, you have a stats value that contains a number >for the spell object, these would be assigned sequentially, and be >unique for any one player on each run of the server. (everyone would >have their spells numbered 1,2,3,4, etc.) >Then, if ever a spell was added or removed (by moving the attunement >into a seperate stat, and sending only the base cost, this can be the >only time an update is needed), the stats command can send the number >of the spell that was changed, and the client could then requestinfo # >and get back only that spell. (this was my understanding of gros' >suggestion, I hope he will clarify if I misunderstood some detail) > Well, not quite. My idea was simply that the client identifies spells in messages by a numerical ID, in a way similar to what is currently done with faces when they're cached. My vision of the communication scheme would be: C->S: spell [] Asks the server to send us detailed information about a given spell, identified by its numerical id. An id=SEND_ALL would ask the server to send the list of all spells currently known by the player. The optional argument would be a bitmask of all fields the client wants to receive. I'm not sure that this is really necessary - the initial setup command could be used for the similar purpose. S->C: spell ... This is either an answer to an explicit C->S spell message, or the result of a change in the spell list of the player. Nrspells is the number of spells sent in the message. Id # are the numerical (16bit) identifiers for each spell. Information # holds the detailed info about spells. The information field would be something like this: - (8bit): Tells if the spell has been added (+), removed (-), modified (!) or requested by the client by a spell command (=). - (string): The internal name of the spell, as used in cast or invoke commands ("burning hands"); - (string): The visible name of the spell, as displayed by the client ("Small Firestorm of Lhangwival"). The client is free to do whatever it wants with its value. - (16bit): The base casting cost. ... and so on. The information content would depend on the content of the C->S spell /setup mask in the case of an answer to a specific spell request from the client. In the case of a removal, only the spell id would be sent. In the case of an addition, the setup mask is used. In the case of a modification, only the fields amongst those included in the setup mask that changed would be resent. The S->C spell message is sent as soon as its trigger (reception of the C->S spell, or addition/removal/change of the given spell) happens. My guess is that more than one spell being sent per message would rarely occur (probably mostly during the character init/login process). Note that I'm actually opposed to use the stats command for spells - I think it is much better to create new messages for that specific purpose. Spells are no stats, AFAIK. I'd also like to underline that IMHO the client should never ever have to compute any value from a "base value" sent by the server. Secondary in-game values should never be the responsability of the client, because it has absolutely no way to know if the server it is connected on uses the same formula. Just because the numbers are hardcoded *now* doesn't mean they'll always be in the future, or that some administrators will not change them to make the game harder/easier on their own server. Finally, note that I don't address how the protocol would get implemented server-side here - I was only considering the problem from the client side of things. I also used a generic "spell" name for the command names - for what matters, it could in fact be "requestinfo spell/replyinfo spell", or anything else. I think that *before* discussing how to implement the protocol server-side, I think that we *first* need to have a clear idea on what needs to be exchanged by the client and when - after having read what was written so far on that topic, it seems to me that so far, it is somewhat not the case. From yann.chachkoff at myrealbox.com Sat Dec 17 10:15:48 2005 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat Dec 17 10:15:51 2005 Subject: [crossfire] requestable spell lists. Message-ID: <1134836148.c7d9c5dcyann.chachkoff@myrealbox.com> >One thing that was suggested by gros on IRC earlier was almost a >hybrid approach, instead of having a stats value that says what type >of change has occurred, you have a stats value that contains a number >for the spell object, these would be assigned sequentially, and be >unique for any one player on each run of the server. (everyone would >have their spells numbered 1,2,3,4, etc.) >Then, if ever a spell was added or removed (by moving the attunement >into a seperate stat, and sending only the base cost, this can be the >only time an update is needed), the stats command can send the number >of the spell that was changed, and the client could then requestinfo # >and get back only that spell. (this was my understanding of gros' >suggestion, I hope he will clarify if I misunderstood some detail) > Well, not quite. My idea was simply that the client identifies spells in messages by a numerical ID, in a way similar to what is currently done with faces when they're cached. My vision of the communication scheme would be: C->S: spell [] Asks the server to send us detailed information about a given spell, identified by its numerical id. An id=SEND_ALL would ask the server to send the list of all spells currently known by the player. The optional argument would be a bitmask of all fields the client wants to receive. I'm not sure that this is really necessary - the initial setup command could be used for the similar purpose. S->C: spell ... This is either an answer to an explicit C->S spell message, or the result of a change in the spell list of the player. Nrspells is the number of spells sent in the message. Id # are the numerical (16bit) identifiers for each spell. Information # holds the detailed info about spells. The information field would be something like this: - (8bit): Tells if the spell has been added (+), removed (-), modified (!) or requested by the client by a spell command (=). - (string): The internal name of the spell, as used in cast or invoke commands ("burning hands"); - (string): The visible name of the spell, as displayed by the client ("Small Firestorm of Lhangwival"). The client is free to do whatever it wants with its value. - (16bit): The base casting cost. ... and so on. The information content would depend on the content of the C->S spell /setup mask in the case of an answer to a specific spell request from the client. In the case of a removal, only the spell id would be sent. In the case of an addition, the setup mask is used. In the case of a modification, only the fields amongst those included in the setup mask that changed would be resent. The S->C spell message is sent as soon as its trigger (reception of the C->S spell, or addition/removal/change of the given spell) happens. My guess is that more than one spell being sent per message would rarely occur (probably mostly during the character init/login process). Note that I'm actually opposed to use the stats command for spells - I think it is much better to create new messages for that specific purpose. Spells are no stats, AFAIK. I'd also like to underline that IMHO the client should never ever have to compute any value from a "base value" sent by the server. Secondary in-game values should never be the responsability of the client, because it has absolutely no way to know if the server it is connected on uses the same formula. Just because the numbers are hardcoded *now* doesn't mean they'll always be in the future, or that some administrators will not change them to make the game harder/easier on their own server. Finally, note that I don't address how the protocol would get implemented server-side here - I was only considering the problem from the client side of things. I also used a generic "spell" name for the command names - for what matters, it could in fact be "requestinfo spell/replyinfo spell", or anything else. I think that *before* discussing how to implement the protocol server-side, I think that we *first* need to have a clear idea on what needs to be exchanged by the client and when - after having read what was written so far on that topic, it seems to me that so far, it is somewhat not the case. From lordyoukai at gmail.com Sat Dec 17 15:01:15 2005 From: lordyoukai at gmail.com (Lord Youkai) Date: Sat Dec 17 15:01:47 2005 Subject: [crossfire] Proposal for player logfile / plugins In-Reply-To: <43A42543.6020704@laposte.net> References: <43A42543.6020704@laposte.net> Message-ID: <2501b33a0512171301x71cdde7cxa459cba3b200cbcb@mail.gmail.com> That might speed things up. I think it is a great idea. On 12/17/05, Nicolas Weeger wrote: > > Hello. > > It seems the slow issues Metalforge has been experiencing are related to > Python, and possibly due to the size of the logfile (log containing > birth date, kick info, muzzle, and so on). > > My proposal is to split this file, putting player's information directly > in the player's directory. > > To do that, I'd like to enable plugins to access specific files in > player's directory (or, for safety, a subdirectory, as to not mess with > unique maps). > > Plugins could this way store player-related information easily. Also, > when a player quits, information is just removed with everything else > with the player's directory. > > Drawback (for logfile at least), no more consolidated file with all the > info - but shouldn't be too hard to do a script to merge all info for > statistical purposes. > > What do you think of that? > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20051217/4ccc63b2/attachment.htm From kirschbaum at myrealbox.com Sat Dec 17 14:35:07 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sat Dec 17 15:35:46 2005 Subject: [crossfire] Proposal for player logfile / plugins In-Reply-To: <43A42543.6020704@laposte.net> References: <43A42543.6020704@laposte.net> Message-ID: <20051217203507.GA16580@kirschbaum.myrealbox.com> Nicolas Weeger wrote: > It seems the slow issues Metalforge has been experiencing are related > to Python, and possibly due to the size of the logfile (log containing > birth date, kick info, muzzle, and so on). I agree that the lags for players logging in on mf are probably related to Python. (Disabling Python did "solve" them.) But I have concerns that the real cause of these lags is indeed the size of the logfile (Player_log): A while ago Leaf told me that the Player_log file on mf was about 226k. At that time the server did lag for about 5s for every player logging in. I created a Player_log file with 4901k size (50000 players) on my own server. This did lag my server for about 5-7s (on a *much slower* computer). Since the Python parsing function should scale linear with file size, and if I assume that mf is (much) faster than my computer, the 226k file should result in a lag of (much) less than 0.3s (=6s*226k/4901k) on mf. That said, I'm still not convinced that the size of this file is the real cause for these lags. > My proposal is to split this file, putting player's information directly > in the player's directory. [...] > Drawback (for logfile at least), no more consolidated file with all the > info - but shouldn't be too hard to do a script to merge all info for > statistical purposes. Maybe it could be interesting for DMs to know which players did log in from an ip address (or ip address range)? With the split info approach this feature probably is not possible. And I don't think using such a script is a good idea: it creates another external dependency. (And the Python scripts accessing this collected information probably will not detect old (i.e. not updated) information in case that external collect script fails to run.) > What do you think of that? Removing code that does not scale well is probably a good thing to do. An alternative approach to consider: use a file format that does scale much better. Note that a previous commit apparently did the reverse thing: replace an efficient file format by an (accessible but) inefficient file format: | # cvs log python/CFLog.py | [...] | Working file: CFLog.py | [...] | revision 1.3 | date: 2004/09/01 02:03:25; author: temitchell; state: Exp; lines: +48 -28 | [...] | - replace crossfirelog shelf with plain text datafile (less efficient | but more accessable) | [...] From temitchell at sympatico.ca Sun Dec 18 10:11:24 2005 From: temitchell at sympatico.ca (todd) Date: Sun Dec 18 10:11:49 2005 Subject: [crossfire] Proposal for player logfile / plugins In-Reply-To: <20051217203507.GA16580@kirschbaum.myrealbox.com> References: <43A42543.6020704@laposte.net> <20051217203507.GA16580@kirschbaum.myrealbox.com> Message-ID: <43A58A2C.1040805@sympatico.ca> At the time there was no cvs module in python (2.1) and you could not iterate over dictionaries. Now that there is a CVS parser and more robust dictionary support which is way more efficient because it uses internal data structures the logs should probably be changed to use them. From temitchell at sympatico.ca Sun Dec 18 15:22:10 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sun Dec 18 15:21:48 2005 Subject: [crossfire] Proposal for player logfile / plugins In-Reply-To: <43A58A2C.1040805@sympatico.ca> References: <43A42543.6020704@laposte.net> <20051217203507.GA16580@kirschbaum.myrealbox.com> <43A58A2C.1040805@sympatico.ca> Message-ID: <1134940930.3653.1.camel@oberon.kameria> This should read CSV (Comma Separated Value) not CVS (Concurrent Versioning System) - sometimes I type too fast for my brain. On Sun, 2005-18-12 at 11:11 -0500, todd wrote: > At the time there was no cvs module in python (2.1) and you could not > iterate over dictionaries. Now that there is a CVS parser and more > robust dictionary support which is way more efficient because it uses > internal data structures the logs should probably be changed to use them. From mwedel at sonic.net Mon Dec 19 00:42:36 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Dec 19 00:43:50 2005 Subject: [crossfire] requestable spell lists. In-Reply-To: <1134836084.c7d9c5dcyann.chachkoff@myrealbox.com> References: <1134836084.c7d9c5dcyann.chachkoff@myrealbox.com> Message-ID: <43A6565C.8080204@sonic.net> Well, to me, the only thing that is likely to change for sp calculations may be the attunement bonuses. But a couple more random thoughts: Using the object id to denote spells is probably easiest, as that is a unique value that already exists. The disadvantage is that it is a 4 byte value, so a few extra bytes of data. After what gros says, I wonder if we could follow something like the updateitem command, eg, a command like: spelldata ... where flags denote what data is being sent. Thus, when the player logs on, all data is sent (perhaps not some based on client preferences), as when the player learns a spell. When the player gains a level in a skill, a function could go through all the spells the player knows and see if any have changed in damage or sp cost, and if so, send the data down (but in this case, the amount of data actually wouldn't be much - < 10 bytes/spell (flags, tag, sp, dam). Similarly, if a characters spellpaths change, updated spells info is sent. Once again, not a lot of bytes per spell (one question is what to do with spells that are denied - you can't really update the cost, as it can't be cast. So I'd imagine the client should be 'smart' in that regard and grey them out or something. However, when a spell transitions from being denied to something else, we'd need to send the data down, because we don't know the last state the data was in (maybe player is now attuned, where last time we sent it it was just 'normal'). I'd also suggest that a binary format is used - this is typical for S->C communications. but also, I'm thinking that things like the msg/endmsg may contain newlines - if sent binary, no special processing is needed on those. If sent as text with newline (or something else) being a delimiter, some escape code is needed. In addition, if text form is used, my <10 byte probably increases a bit (3 for flags, maybe 7 for tag, 2-3 for sp and dam values, and add in spaces - maybe talking 20 now). But in addition, packing and unpacking binary data is just easier and faster. From tchize at myrealbox.com Mon Dec 19 10:21:23 2005 From: tchize at myrealbox.com (tchize) Date: Mon Dec 19 10:21:50 2005 Subject: [OT] Re: [crossfire] Proposal for player logfile / plugins In-Reply-To: <1134940930.3653.1.camel@oberon.kameria> References: <43A42543.6020704@laposte.net> <43A58A2C.1040805@sympatico.ca> <1134940930.3653.1.camel@oberon.kameria> Message-ID: <200512191721.23156.tchize@myrealbox.com> Le Dimanche 18 D?cembre 2005 22:22, Todd Mitchell a ?crit : > sometimes I type too fast for my brain. I'm tempted to say you don't type very fast. But i will not! Because i don't joke about such things as mental diseases. :D Ok, you deserved it, never tempt me! From mwedel at sonic.net Tue Dec 20 00:39:20 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Dec 20 00:39:51 2005 Subject: [crossfire] Wraith changes In-Reply-To: References: <43A36A35.3020405@sonic.net> Message-ID: <43A7A718.8040106@sonic.net> Anton Oussik wrote: > Also, although restoration -100 means they do not heal naturaly very > well, they still do heal over time. The wraith I left overnight had > 14/22 health, and in the morning it was fully healed. random thought then - if you're a low level wraith and get beat up (say down to 1-2 hp), is your only real hope then healing devices (potions, staves, spells)? Just curious - even at 1-2 hp, I don't think I'd want to risk running into any creature, even things like kobolds. If so, I wonder if it may be nice to give starting wraiths some like a staff of minor healing just so they can use it to get enough hp to go kill wimpy things. Otherwise, letting your character sit overnight seems like a bit of a bother. From antonoussik at gmail.com Tue Dec 20 04:57:57 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Tue Dec 20 04:59:51 2005 Subject: [crossfire] Wraith changes In-Reply-To: <43A7A718.8040106@sonic.net> References: <43A36A35.3020405@sonic.net> <43A7A718.8040106@sonic.net> Message-ID: On 20/12/05, Mark Wedel wrote: > Anton Oussik wrote: > > > Also, although restoration -100 means they do not heal naturaly very > > well, they still do heal over time. The wraith I left overnight had > > 14/22 health, and in the morning it was fully healed. > > random thought then - if you're a low level wraith and get beat up (say down > to 1-2 hp), is your only real hope then healing devices (potions, staves, > spells)? First I'd like to note that the third version of the patch makes wraith not heal at all by sensing for a wraith in do_some_living in player.c. Restoration -100 was a bit of a hack, and is no longer needed (and is therefore also removed from latest patch). Actually wraith scaled up life stealing works remarkably well. Perhaps too well and needs scaling down. The reason I scaled it up in the first place was that it did not work at all at low levels as after reducing the damage done by it in the code, as done for all other players, the resulting damage was always 0 at low levels. However, scaled up, it quite easily kills through goblins at level 1, and enables the player to run through a goblin infested room by level 3, which I think a player should not be able to do until level 10-15. What I could do with no difficulty is to make the wraiths eat until they reach, say, level 15, and only then give them the feeding skill. The current patch currenly does that to old wraiths - it treats them as if patch was not there until they try eating, and when they eat, it senses for an old wraith and converts them to a new wraith, after which they behave like new wraith. Another thing that could be done is to reduce the feding speed. What is the proper way of reducing weapon speed of a skill? I looked around briefly, but could not find it. > If so, I wonder if it may be nice to give starting wraiths some like a staff > of minor healing just so they can use it to get enough hp to go kill wimpy > things. As it stands now, a newborn wraith at 0hp can quite happily clear a room of kobolds and come out with full hp. I feel it is too powerful, so perhaps doing both, scaling down the feeding speed (probably about 5-10fold), and also not giving the wraith the skill until they reach level 15 would be appropriate to balance the race. From lalo.martins at gmail.com Fri Dec 23 13:06:03 2005 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri Dec 23 13:11:55 2005 Subject: [crossfire] [patch] Large-denomination coins Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just submitted a patch to the tracker. It adds two high-denomination coins: jade (after Chinese history and many Chinese-themed RPGs such as Exalted) and amberium (a Zelazny reference, although this material doesn't exist on his books). One jade coin = 100 plat; one amb = 100 jade. Incidentally, thanks to implementation details of shop.c, this raises the largest possible item value by a factor of 10000 - it used to be 2^32 plat, now it's 2^32 amb. Also included is a patch for the Scorn bank; other banks and the guilds are left as exercise for the reader (or I may do it if a dev asks nicely). http://sourceforge.net/tracker/index.php?func=detail&aid=1389033&group_id=13833&atid=313833 best, Lalo Martins - -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - -- http://www.laranja.org/ mailto:lalo.martins@gmail.com GNU: never give up freedom http://www.gnu.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDrEQhc+NusBpPPUkRAhGUAKCfUVoqgIbqu/Dq51GXH+8LZvg2AQCfavfo bM0LTXKXc3TJtUGu/v3T/wk= =kd/I -----END PGP SIGNATURE----- From mikeeusaa at yahoo.com Fri Dec 23 20:09:05 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Fri Dec 23 20:09:56 2005 Subject: [crossfire] [patch] Large-denomination coins In-Reply-To: Message-ID: <20051224020905.25131.qmail@web32707.mail.mud.yahoo.com> Very cool :D. I suppose I should update my server code soon then :). --- Lalo Martins wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Just submitted a patch to the tracker. > > It adds two high-denomination coins: jade (after > Chinese history and many Chinese-themed RPGs such as > Exalted) and amberium (a Zelazny reference, although > this material doesn't exist on his books). One jade > coin = 100 plat; one amb = 100 jade. > > Incidentally, thanks to implementation details of > shop.c, this raises the largest possible item value > by > a factor of 10000 - it used to be 2^32 plat, now > it's > 2^32 amb. > > Also included is a patch for the Scorn bank; other > banks and the guilds are left as exercise for the > reader (or I may do it if a dev asks nicely). > > http://sourceforge.net/tracker/index.php?func=detail&aid=1389033&group_id=13833&atid=313833 > > best, > Lalo > Martins > - -- > So many of our dreams at first seem > impossible, > then they seem improbable, and then, when we > summon the will, they soon become inevitable. > - -- > http://www.laranja.org/ > mailto:lalo.martins@gmail.com > GNU: never give up freedom > http://www.gnu.org/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - > http://enigmail.mozdev.org > > iD8DBQFDrEQhc+NusBpPPUkRAhGUAKCfUVoqgIbqu/Dq51GXH+8LZvg2AQCfavfo > bM0LTXKXc3TJtUGu/v3T/wk= > =kd/I > -----END PGP SIGNATURE----- > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mwedel at sonic.net Sat Dec 24 00:35:58 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Dec 24 00:37:55 2005 Subject: [crossfire] [patch] Large-denomination coins In-Reply-To: References: Message-ID: <43ACEC4E.7050300@sonic.net> Lalo Martins wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Just submitted a patch to the tracker. > > It adds two high-denomination coins: jade (after > Chinese history and many Chinese-themed RPGs such as > Exalted) and amberium (a Zelazny reference, although > this material doesn't exist on his books). One jade > coin = 100 plat; one amb = 100 jade. > > Incidentally, thanks to implementation details of > shop.c, this raises the largest possible item value by > a factor of 10000 - it used to be 2^32 plat, now it's > 2^32 amb. Don't know if this is still a concern/issue. But at one time, there was a strong inclination not to do this - instead, the players were supposed to buy gems, etc for easy transportation. From mikeeusaa at yahoo.com Sat Dec 24 01:09:06 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sat Dec 24 02:30:56 2005 Subject: [crossfire] This commit fixed nothing, Dwall was not removed from the shop tile list Message-ID: <20051224070906.33963.qmail@web32702.mail.mud.yahoo.com> This commit fixed nothing, Dwall was not removed from the shop tile list. Notice list building_material_stonewall_norm . Dwall was still there. This commit has been reverted and the reversion tested. It works fine. Use shop_building for the treasurelist (as always) if making a build shop. Please don't accuse me of "breaking things" when thee was not using the shop_building treasure list. Please do not say "don't ever update CVS because metalforge doesn't feel like updating it's archtypes". Update your archtypes or use the stable distro. treasureone shop_building arch building_builder chance 2 more arch building_destroyer chance 2 more list building_material chance 78 more list building_material_stonewall_norm chance 20 end ##For areas like scorn area, sells DWall treasureone building_material_stonewall_norm arch building_wall2 end ##For brest area, sells Red Cwall rather then DWall treasureone building_material_stonewall_fant arch building_wall4 end ##For navar area, sells West Cwall rather then DWall treasureone building_material_stonewall_west arch building_wall3 end ##For areas like azumauindo area, sells DWall and EastWall (japanese paper wall) treasureone building_material_stonewall_east arch building_wall2 chance 50 more arch building_wall5 chance 50 end Module Name: arch Committed By: eracc Date: Sat Dec 24 04:12:47 UTC 2005 Modified Files: arch/mapbuilding: building.trs Log Message: Attempting to make Dwall appear in random shopbuilding tile treasurelist again. Someone broke it. Needed for new Lone Town apartment maps. Please leave it as is. Do not remove it from the building_material list. Do not change it into some other arch that is not available on metalforge right now. Thank you. Start of context diffs Index: arch/mapbuilding/building.trs diff -c arch/mapbuilding/building.trs:1.8 arch/mapbuilding/building.trs:1.9 *** arch/mapbuilding/building.trs:1.8 Sat Nov 26 07:33:31 2005 --- arch/mapbuilding/building.trs Fri Dec 23 20:12:47 2005 *************** *** 11,16 **** --- 11,19 ---- arch building_wall chance 25 more + arch building_wall2 + chance 20 + more arch building_vertical_gate chance 10 more __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From mikeeusaa at yahoo.com Sat Dec 24 00:42:03 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sat Dec 24 02:30:59 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/mapbuilding In-Reply-To: Message-ID: <20051224064203.1239.qmail@web32710.mail.mud.yahoo.com> It was not broken. This change has been reverted. --- crossfire-cvs-admin@lists.sourceforge.net wrote: > > Module Name: arch > Committed By: eracc > Date: Sat Dec 24 04:12:47 UTC 2005 > > Modified Files: > arch/mapbuilding: building.trs > > Log Message: > Attempting to make Dwall appear in random > shopbuilding tile treasurelist > again. Someone broke it. Needed for new Lone Town > apartment maps. Please > leave it as is. Do not remove it from the > building_material list. Do not > change it into some other arch that is not available > on metalforge right > now. Thank you. > > > > Start of context diffs > > > Index: arch/mapbuilding/building.trs > diff -c arch/mapbuilding/building.trs:1.8 > arch/mapbuilding/building.trs:1.9 > *** arch/mapbuilding/building.trs:1.8 Sat Nov 26 > 07:33:31 2005 > --- arch/mapbuilding/building.trs Fri Dec 23 > 20:12:47 2005 > *************** > *** 11,16 **** > --- 11,19 ---- > arch building_wall > chance 25 > more > + arch building_wall2 > + chance 20 > + more > arch building_vertical_gate > chance 10 > more > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do > you grep through log files > for problems? Stop! Download the new AJAX search > engine that makes > searching your log files as easy as surfing the > web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Crossfire-cvs mailing list > Crossfire-cvs@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/crossfire-cvs > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From antonoussik at gmail.com Sat Dec 24 04:40:23 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sat Dec 24 04:41:56 2005 Subject: [crossfire] [patch] Large-denomination coins In-Reply-To: <43ACEC4E.7050300@sonic.net> References: <43ACEC4E.7050300@sonic.net> Message-ID: On 24/12/05, Mark Wedel wrote: > Lalo Martins wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Just submitted a patch to the tracker. > > > > It adds two high-denomination coins: jade (after > > Chinese history and many Chinese-themed RPGs such as > > Exalted) and amberium (a Zelazny reference, although > > this material doesn't exist on his books). One jade > > coin = 100 plat; one amb = 100 jade. I would have thought that a patch to make Imperial notes accepted as shop payment would be more useful, but adding new coins is also good. Thanks! > Don't know if this is still a concern/issue. But at one time, there was a > strong inclination not to do this - instead, the players were supposed to buy > gems, etc for easy transportation. Yes, some of the more expensive items were currently unbuyable unless one used a bug, as they cost more in platinum than the strongest person could lift. I also have some concerns that this will cause inflation, and "platinum is the new silver". Could map and item makers please avoid making items that cost that much unless there is a very good reason for doing so? From antonoussik at gmail.com Sat Dec 24 05:01:05 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sat Dec 24 05:01:55 2005 Subject: [crossfire] Banking system Message-ID: Thinking about lalo's patch, an interesting idea would be to make a patch that makes the banking system more useful by introducing the following changes to the banks: - Gain interest on money deposited - introducing chequebooks. If you attempt to leave a shop, and have unbought items, and have not enough cash to pay for it, and you have a chequebook, then if you have sufficient funds in the Imperial bank, and the chequebook belongs to you, then have the money deducted straight from your account. else have a message displayed saying that you try to pay with a cheque, but the shopkeeper does not trust it. In my opinion this will encourage people to use the banking system to store money. From brenlally at gmail.com Sat Dec 24 07:35:05 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Dec 24 07:35:56 2005 Subject: [crossfire] Banking system In-Reply-To: References: Message-ID: <7903f03c0512240535k1ee596c3i3b1a1fac0179a444@mail.gmail.com> On 12/24/05, Anton Oussik wrote: > Thinking about lalo's patch, an interesting idea would be to make a > patch that makes the banking system more useful by introducing the > following changes to the banks: > > - Gain interest on money deposited [snip] > In my opinion this will encourage people to use the banking system to > store money. It would, but I think there would need to be an associated opportunity cost, otherwise there would be no incentive to keep liquid capital. maybe something like 'real' banks do, where there are two accounts, one a currant account against which cheques are drawn, and a savings account, which takes a week (or more) to take money from, has a high transaction charge, and also offers a reasonable interest rate. This would unfortunatly require a more complex interface. From mikeeusaa at yahoo.com Sat Dec 24 08:23:31 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sat Dec 24 13:17:47 2005 Subject: [crossfire] This commit fixed nothing, Dwall was not removed from the shop tile list In-Reply-To: <20051224070906.33963.qmail@web32702.mail.mud.yahoo.com> Message-ID: <20051224142331.62653.qmail@web32704.mail.mud.yahoo.com> (Note: tone of email may have been angry as I was rather tired when writing it). --- Miguel Ghobangieno wrote: > This commit fixed nothing, Dwall was not removed > from > the shop tile list. > > Notice list building_material_stonewall_norm . Dwall > was still there. This commit has been reverted and > the > reversion tested. It works fine. Use shop_building > for > the treasurelist (as always) if making a build shop. > Please don't accuse me of "breaking things" when > thee > was not using the shop_building treasure list. > Please > do not say "don't ever update CVS because metalforge > doesn't feel like updating it's archtypes". Update > your archtypes or use the stable distro. > > treasureone shop_building > arch building_builder > chance 2 > more > arch building_destroyer > chance 2 > more > list building_material > chance 78 > more > list building_material_stonewall_norm > chance 20 > end > > > ##For areas like scorn area, sells DWall > treasureone building_material_stonewall_norm > arch building_wall2 > end > ##For brest area, sells Red Cwall rather then DWall > treasureone building_material_stonewall_fant > arch building_wall4 > end > ##For navar area, sells West Cwall rather then DWall > treasureone building_material_stonewall_west > arch building_wall3 > end > ##For areas like azumauindo area, sells DWall and > EastWall (japanese paper wall) > treasureone building_material_stonewall_east > arch building_wall2 > chance 50 > more > arch building_wall5 > chance 50 > end > > > Module Name: arch > Committed By: eracc > Date: Sat Dec 24 04:12:47 UTC 2005 > > Modified Files: > arch/mapbuilding: building.trs > > Log Message: > Attempting to make Dwall appear in random > shopbuilding > tile > treasurelist > again. Someone broke it. Needed for new Lone Town > apartment maps. > Please > leave it as is. Do not remove it from the > building_material list. Do > not > change it into some other arch that is not available > on metalforge > right > now. Thank you. > > > > Start of context diffs > > > Index: arch/mapbuilding/building.trs > diff -c arch/mapbuilding/building.trs:1.8 > arch/mapbuilding/building.trs:1.9 > *** arch/mapbuilding/building.trs:1.8 Sat Nov 26 > 07:33:31 2005 > --- arch/mapbuilding/building.trs Fri Dec 23 > 20:12:47 > 2005 > *************** > *** 11,16 **** > --- 11,19 ---- > arch building_wall > chance 25 > more > + arch building_wall2 > + chance 20 > + more > arch building_vertical_gate > chance 10 > more > > > > > __________________________________ > Yahoo! for Good - Make a difference this year. > http://brand.yahoo.com/cybergivingweek2005/ > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mwedel at sonic.net Sat Dec 24 13:24:07 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Dec 24 13:25:56 2005 Subject: [crossfire] Banking system In-Reply-To: <7903f03c0512240535k1ee596c3i3b1a1fac0179a444@mail.gmail.com> References: <7903f03c0512240535k1ee596c3i3b1a1fac0179a444@mail.gmail.com> Message-ID: <43ADA057.8000402@sonic.net> Brendan Lally wrote: > On 12/24/05, Anton Oussik wrote: >> Thinking about lalo's patch, an interesting idea would be to make a >> patch that makes the banking system more useful by introducing the >> following changes to the banks: >> >> - Gain interest on money deposited > > [snip] Interest is probably a bad idea - you might very well get players gaining more money from interest than they can from adventuring. > >> In my opinion this will encourage people to use the banking system to >> store money. > > It would, but I think there would need to be an associated opportunity > cost, otherwise there would be no incentive to keep liquid capital. > > maybe something like 'real' banks do, where there are two accounts, > one a currant account against which cheques are drawn, and a savings > account, which takes a week (or more) to take money from, has a high > transaction charge, and also offers a reasonable interest rate. > > This would unfortunatly require a more complex interface. At some level, it becomes a question of why not just make money a 'stat'. Instead of gold pieces, silver, platinum, etc, floating in your inventory, something just says you have 123456 gold pieces. That would actually simplify the code - look at a lot of the shop code to try to figure out if the player has enough money, as well as to give the player money. If it was just a stat, all that becomes a simple add/delete operation. It would add some complexity to the pickup code - when picking up money, it would have to just add to that stat, but that wouldn't be that hard. The hardest part in this is dealing with things where you need to drop money to activating them. Some form of legacy interface would be needed, but even that wouldn't be that hard (could just use some unique tag number to make a synthetic object in the players inventory or something). All this starts to get away from the discussion at hand, but is food for thought From subs at eracc.com Sat Dec 24 12:48:44 2005 From: subs at eracc.com (ERACC) Date: Sat Dec 24 13:28:52 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/mapbuilding In-Reply-To: References: Message-ID: <200512241248.45903.subs@eracc.com> On Saturday 24 December 2005 12:41 am crossfire-cvs-admin@lists.sourceforge.net wrote: > metalforge isn't the center of the universe Yes. It is. :-p From lalo.martins at gmail.com Sat Dec 24 20:05:23 2005 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat Dec 24 20:05:57 2005 Subject: [crossfire] Re: [patch] Large-denomination coins In-Reply-To: References: <43ACEC4E.7050300@sonic.net> Message-ID: And so says Anton Oussik on 24/12/05 18:40... > I also have some concerns that this will cause inflation, and > "platinum is the new silver". Could map and item makers please avoid > making items that cost that much unless there is a very good reason > for doing so? If I understand the code correctly, a small change in shop.c can make these coins pretty much "invisible" - they will still be accepted in shops, but price evaluations will remain in plat, and shopkeepers will not give you jade/amber. Would that be better? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ GNU: never give up freedom http://www.gnu.org/ From mikeeusaa at yahoo.com Sat Dec 24 13:37:59 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sat Dec 24 21:18:03 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/mapbuilding In-Reply-To: <200512241248.45903.subs@eracc.com> Message-ID: <20051224193759.30853.qmail@web32711.mail.mud.yahoo.com> Well in that case the center needs to update it's archtypes :). --- ERACC wrote: > On Saturday 24 December 2005 12:41 am > crossfire-cvs-admin@lists.sourceforge.net wrote: > > > metalforge isn't the center of the universe > > Yes. It is. > > :-p > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From antonoussik at gmail.com Sat Dec 24 22:10:27 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sat Dec 24 22:11:56 2005 Subject: [crossfire] Banking system In-Reply-To: <43ADA057.8000402@sonic.net> References: <7903f03c0512240535k1ee596c3i3b1a1fac0179a444@mail.gmail.com> <43ADA057.8000402@sonic.net> Message-ID: On 24/12/05, Mark Wedel wrote: > At some level, it becomes a question of why not just make money a 'stat'. > Instead of gold pieces, silver, platinum, etc, floating in your inventory, > something just says you have 123456 gold pieces. > All this starts to get away from the discussion at hand, but is food for thought No, it is very much on topic - the main issue here is to avoid the need to have large piles of money lying about in apartments and having to carry more than your own weight in platinum in order to go outside to the shop (perhaps the subject is misnamed though ;-) ). Your idea seems more sensible. Perhaps make all players carry a special wallet/money pouch item, which is a container into which money automatically go and become weightless (or near enough so), which will say "you have foo gold" when clicked, and from which you can drop money? This could also be implemented as a property and interfaced by adding new server commands and adding a UI pouch... but that is for version 2 of CrossFire. From antonoussik at gmail.com Sat Dec 24 22:20:43 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sat Dec 24 22:21:58 2005 Subject: [crossfire] Re: [patch] Large-denomination coins In-Reply-To: References: <43ACEC4E.7050300@sonic.net> Message-ID: On 25/12/05, Lalo Martins wrote: > And so says Anton Oussik on 24/12/05 18:40... > > I also have some concerns that this will cause inflation, and > > "platinum is the new silver". Could map and item makers please avoid > > making items that cost that much unless there is a very good reason > > for doing so? > > If I understand the code correctly, a small change in shop.c can make > these coins pretty much "invisible" - they will still be accepted in > shops, but price evaluations will remain in plat, and shopkeepers will > not give you jade/amber. > > Would that be better? Having shops give the high value coins is better, for the following reason: Currently the shops will give you the platinum for a sold item regardless of the weight of platinum. This means, for example, you can go and sell something worth 50,000,000, then the shop keeper will give you 50,000,000 in plat, even knowing this is way more than your carry limit. Under the new system this is merely 5,000 of the highest denomination thing, which should be liftable. Now it is possible to fix the bug of shop keepers giving too much weight in money without adversly effecting gameplay if it is still an issue, although in general it should not be any more. What I was against is the introduction of super-expensive items to make use of the coins. 5,000 jade coins should remain to be worth a small fortune. From mwedel at sonic.net Sun Dec 25 00:27:18 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Dec 25 00:27:57 2005 Subject: [crossfire] Re: [patch] Large-denomination coins In-Reply-To: References: <43ACEC4E.7050300@sonic.net> Message-ID: <43AE3BC6.5090900@sonic.net> > What I was against is the introduction of super-expensive items to > make use of the coins. 5,000 jade coins should remain to be worth a > small fortune. I think the other potential problem is map makers seeing this high valued coins and start to place these in maps instead of the lower value coins currently there, so therefor, you get an inflation of available money. From mwedel at sonic.net Sun Dec 25 00:37:55 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Dec 25 00:39:57 2005 Subject: [crossfire] Banking system In-Reply-To: References: <7903f03c0512240535k1ee596c3i3b1a1fac0179a444@mail.gmail.com> <43ADA057.8000402@sonic.net> Message-ID: <43AE3E43.3020707@sonic.net> Anton Oussik wrote: > On 24/12/05, Mark Wedel wrote: >> At some level, it becomes a question of why not just make money a 'stat'. >> Instead of gold pieces, silver, platinum, etc, floating in your inventory, >> something just says you have 123456 gold pieces. > >> All this starts to get away from the discussion at hand, but is food for thought > > No, it is very much on topic - the main issue here is to avoid the > need to have large piles of money lying about in apartments and having > to carry more than your own weight in platinum in order to go outside > to the shop (perhaps the subject is misnamed though ;-) ). > > Your idea seems more sensible. Perhaps make all players carry a > special wallet/money pouch item, which is a container into which money > automatically go and become weightless (or near enough so), which will > say "you have foo gold" when clicked, and from which you can drop > money? > > This could also be implemented as a property and interfaced by adding > new server commands and adding a UI pouch... but that is for version 2 > of CrossFire. As said, this wouldn't be really hard. Add a uint64 field to the player object. Modify the pickup code to check item type being picked up. if type == MONEY, add it to that stat, a don't insert it (this could actually be done in the insert_ob_in_ob for that matter to make sure all cases are caught). For new clients, add a mechanism for server to tell client this value - probably via stats command makes the most sense. For these new clients, it is then up to them how they should display that (could just be next to exp or something). For older clients, or maybe all clients until altars and the like are somehow fixed up, the server would fake inventory items for the coins. For simplicity, probably only fake gold pieces (I don't think anything actually requires silver or platinum, and faking only 1 object instead of 3, makes sense). When player tries to drop some gold, the server would catch it is a fake object, and convert the objects into a pile of gold and insert it into the map. Covers those altars, tables, etc. Also, allows players to trade gold easily. For these fake objects, the draw_look function of previous/next object in large stacks could be used - basically set the high bit on the object tag, and drop and examine would catch this special tag and do the right thing. It actually isn't that hard to do, and probably a good thing to do. The biggest issue is making sure it works - having a bug and wiping out peoples gold would be a pain. the only real oddity is the weight values - that 'stat' of gold would basically be weightless (or presumably a much lower weight than currently in place). That said, it would seem an easy fix right now is just change the current weight of coins - the weight is currently 10 - it could be reduced to 1, and increase carrying capacity tenfold. From lalo.martins at gmail.com Sun Dec 25 04:41:11 2005 From: lalo.martins at gmail.com (Lalo Martins) Date: Sun Dec 25 04:41:58 2005 Subject: [crossfire] Re: [patch] Large-denomination coins In-Reply-To: <43AE3BC6.5090900@sonic.net> References: <43ACEC4E.7050300@sonic.net> <43AE3BC6.5090900@sonic.net> Message-ID: And so says Mark Wedel on 25/12/05 14:27... > I think the other potential problem is map makers seeing this high > valued coins and start to place these in maps instead of the lower value > coins currently there, so therefor, you get an inflation of available > money. oooh, people would whack this map maker VERY seriously upside the head :-P I feel the general sentiment in this list and IRC is to *reduce* available money rather than increasing... best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ GNU: never give up freedom http://www.gnu.org/ From antonoussik at gmail.com Sun Dec 25 07:02:00 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sun Dec 25 07:01:59 2005 Subject: [crossfire] Banking system In-Reply-To: <43AE3E43.3020707@sonic.net> References: <7903f03c0512240535k1ee596c3i3b1a1fac0179a444@mail.gmail.com> <43ADA057.8000402@sonic.net> <43AE3E43.3020707@sonic.net> Message-ID: On 25/12/05, Mark Wedel wrote: > Anton Oussik wrote: > > On 24/12/05, Mark Wedel wrote: > >> At some level, it becomes a question of why not just make money a > >> 'stat'. > > As said, this wouldn't be really hard. > > Add a uint64 field to the player object. I suspect this would also fix the client bug when the client crashes when it steps on a tile where something has nrof > 2^32. > The biggest issue is making sure it works - having a bug and wiping out > peoples gold would be a pain. I agree, it would need a lot of testing before being put into "production" use. > That said, it would seem an easy fix right now is just change the current > weight of coins - the weight is currently 10 - it could be reduced to 1, and > increase carrying capacity tenfold. Yes, one can do that, but then it would only be a workaround, and one that would not fix all money carrying related problems. From brenlally at gmail.com Sun Dec 25 11:59:05 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sun Dec 25 11:59:57 2005 Subject: [crossfire] Banking system In-Reply-To: References: <7903f03c0512240535k1ee596c3i3b1a1fac0179a444@mail.gmail.com> <43ADA057.8000402@sonic.net> <43AE3E43.3020707@sonic.net> Message-ID: <7903f03c0512250959h16958a6fqa0bee00c8ae76352@mail.gmail.com> On 12/25/05, Anton Oussik wrote: > On 25/12/05, Mark Wedel wrote: > > Anton Oussik wrote: > > > On 24/12/05, Mark Wedel wrote: > > >> At some level, it becomes a question of why not just make money a > > >> 'stat'. > > > > As said, this wouldn't be really hard. > > > > Add a uint64 field to the player object. > > I suspect this would also fix the client bug when the client crashes > when it steps on a tile where something has nrof > 2^32. Wouldn't stepping on non-money items which have a sufficiantly high nrof also trigger such a crash? From mikeeusaa at yahoo.com Sun Dec 25 01:33:20 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Dec 25 14:34:32 2005 Subject: [crossfire] Banking system In-Reply-To: <43AE3E43.3020707@sonic.net> Message-ID: <20051225073320.49793.qmail@web32706.mail.mud.yahoo.com> I think it should be made clear that these denomination notes are ankin to 10,000 USD and 1000,000 USD notes, respectivly. This should be put in the mappers hand book. I will be careful to not inflate my prices. Another thing I would like to have is the value variable as a double. That way we could have copper coins. Then we can make copper the "new silver" and deflate the economy (by editing the random wealth arch treasure list and the low and mid level monsters lists and putting in copper where silver is and silver where gold is and gold where plat is (and rarely a plat). This way money will have value again. Also conversion tables in banks for these new denominations, as they sound like something that would come from the east, shouldn't be in scorn or navar or brest. I think the conversion tables should only be in azamuindo, maybe (or maybe not) darcap (it may have stumbled upon some). All shops should accept them ofcourse but not give them as change (unless perhapse the shop has a given region set (azamuindo(sp)? darcap?). (Note: I'm opposed to the money as stat idea, I guess that was just a point being raised though for contrast). --- Mark Wedel wrote: > Anton Oussik wrote: > > On 24/12/05, Mark Wedel wrote: > >> At some level, it becomes a question of why not > just make money a 'stat'. > >> Instead of gold pieces, silver, platinum, etc, > floating in your inventory, > >> something just says you have 123456 gold pieces. > > > >> All this starts to get away from the discussion > at hand, but is food for thought > > > > No, it is very much on topic - the main issue here > is to avoid the > > need to have large piles of money lying about in > apartments and having > > to carry more than your own weight in platinum in > order to go outside > > to the shop (perhaps the subject is misnamed > though ;-) ). > > > > Your idea seems more sensible. Perhaps make all > players carry a > > special wallet/money pouch item, which is a > container into which money > > automatically go and become weightless (or near > enough so), which will > > say "you have foo gold" when clicked, and from > which you can drop > > money? > > > > This could also be implemented as a property and > interfaced by adding > > new server commands and adding a UI pouch... but > that is for version 2 > > of CrossFire. > > As said, this wouldn't be really hard. > > Add a uint64 field to the player object. > > Modify the pickup code to check item type being > picked up. if type == MONEY, > add it to that stat, a don't insert it (this could > actually be done in the > insert_ob_in_ob for that matter to make sure all > cases are caught). > > For new clients, add a mechanism for server to > tell client this value - > probably via stats command makes the most sense. > For these new clients, it is > then up to them how they should display that (could > just be next to exp or > something). > > For older clients, or maybe all clients until > altars and the like are somehow > fixed up, the server would fake inventory items for > the coins. For simplicity, > probably only fake gold pieces (I don't think > anything actually requires silver > or platinum, and faking only 1 object instead of 3, > makes sense). > > When player tries to drop some gold, the server > would catch it is a fake > object, and convert the objects into a pile of gold > and insert it into the map. > Covers those altars, tables, etc. Also, allows > players to trade gold easily. > > For these fake objects, the draw_look function of > previous/next object in > large stacks could be used - basically set the high > bit on the object tag, and > drop and examine would catch this special tag and do > the right thing. > > It actually isn't that hard to do, and probably a > good thing to do. > > The biggest issue is making sure it works - having > a bug and wiping out > peoples gold would be a pain. > > the only real oddity is the weight values - that > 'stat' of gold would > basically be weightless (or presumably a much lower > weight than currently in place). > > That said, it would seem an easy fix right now is > just change the current > weight of coins - the weight is currently 10 - it > could be reduced to 1, and > increase carrying capacity tenfold. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mikeeusaa at yahoo.com Sun Dec 25 01:37:10 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Dec 25 14:34:37 2005 Subject: [crossfire] Banking system In-Reply-To: Message-ID: <20051225073710.54155.qmail@web32713.mail.mud.yahoo.com> Please do not implement this. Gold is gold, silver is silver, plat is plat; elements, metals, useful in their own right. If you want a "money pouch" then what you want is a checkbook in addition to using what we have now. Mark was making a point in his post, saying basically 'this will make money as if it is nothing', contrast that thought with having a physical gold coin in you hand... gold coins are real not thin air. You want a checkbook. I can make the archtype face pic and perhapse cave can do the code, however real gold etc must not be mangled. --- Anton Oussik wrote: > On 24/12/05, Mark Wedel wrote: > > At some level, it becomes a question of why not > just make money a 'stat'. > > Instead of gold pieces, silver, platinum, etc, > floating in your inventory, > > something just says you have 123456 gold pieces. > > > All this starts to get away from the discussion > at hand, but is food for thought > > No, it is very much on topic - the main issue here > is to avoid the > need to have large piles of money lying about in > apartments and having > to carry more than your own weight in platinum in > order to go outside > to the shop (perhaps the subject is misnamed though > ;-) ). > > Your idea seems more sensible. Perhaps make all > players carry a > special wallet/money pouch item, which is a > container into which money > automatically go and become weightless (or near > enough so), which will > say "you have foo gold" when clicked, and from which > you can drop > money? > > This could also be implemented as a property and > interfaced by adding > new server commands and adding a UI pouch... but > that is for version 2 > of CrossFire. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mikeeusaa at yahoo.com Sun Dec 25 10:20:38 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Dec 25 14:34:39 2005 Subject: [crossfire] Re: [patch] Large-denomination coins In-Reply-To: Message-ID: <20051225162038.56313.qmail@web32710.mail.mud.yahoo.com> Exactly. I'd like the value var to be a double so we can add copper coins ... --- Lalo Martins wrote: > And so says Mark Wedel on 25/12/05 14:27... > > I think the other potential problem is map makers > seeing this high > > valued coins and start to place these in maps > instead of the lower value > > coins currently there, so therefor, you get an > inflation of available > > money. > > oooh, people would whack this map maker VERY > seriously upside the head > :-P I feel the general sentiment in this list and > IRC is to *reduce* > available money rather than increasing... > > best, > Lalo > Martins > -- > So many of our dreams at first seem > impossible, > then they seem improbable, and then, when we > summon the will, they soon become inevitable. > -- > personal: http://www.laranja.org/ > GNU: never give up freedom > http://www.gnu.org/ > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From mikeeusaa at yahoo.com Sun Dec 25 10:33:27 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Dec 25 14:34:41 2005 Subject: [crossfire] Banking system NO MONEY STAT, Use a checkbook if you want that. In-Reply-To: Message-ID: <20051225163327.91830.qmail@web32709.mail.mud.yahoo.com> PLLLLLLLLLLLLLLLEASE DO NOT change the weight of gold etc. Please DO NOT MAKE MONEY A STAT. GOLD CANNOT change into silver like magic etc. Do not do this please. If you want something like this then make a checkbook tied to the banking system. If gold coins, silver, etc are made into a stat I cannot work on this project anylonger. I have invested considerable effort in bullion arches etc. PLEASE DO NOT SCREW WITH GOLD, SILVER, AND PLAT coins! PLEASE DO NOT DO THIS. You want a checkbook, it can be made, I can make the checkbook face. PLEASE DO NOT SCREW WITH THE COINS. (Ps none of the players I spoke with want this change either, so the players are against it too). If you want a "crossfire-simple" mode then code that in as an option or fork off to a "crossfire-simple" project. Gold has a weight to value ration, PLEASE DO NOT FSCK WITH THIS!. If you are so concerned with the weight of the coins then make paper money for each region (in _addition_ to the bullion). Imperials should remain the international banking note, however. Damn.. every month there is a "let's remove stuff" iniative. GOLD IS NOT SILVER they ARE diffrent elements. THEY HAVE EXACT WEIGHT TO VALUE IN CROSSFIRE which I have based all my bullion and other metals on. DO NOT DO THIS. --- Anton Oussik wrote: > On 25/12/05, Mark Wedel wrote: > > Anton Oussik wrote: > > > On 24/12/05, Mark Wedel > wrote: > > >> At some level, it becomes a question of why > not just make money a > > >> 'stat'. > > > > As said, this wouldn't be really hard. > > > > Add a uint64 field to the player object. > > I suspect this would also fix the client bug when > the client crashes > when it steps on a tile where something has nrof > > 2^32. > > > The biggest issue is making sure it works - > having a bug and wiping out > > peoples gold would be a pain. > > I agree, it would need a lot of testing before being > put into "production" use. > > > That said, it would seem an easy fix right now > is just change the current > > weight of coins - the weight is currently 10 - it > could be reduced to 1, and > > increase carrying capacity tenfold. > > Yes, one can do that, but then it would only be a > workaround, and one > that would not fix all money carrying related > problems. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From brenlally at gmail.com Sun Dec 25 16:39:28 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sun Dec 25 16:39:58 2005 Subject: [crossfire] Re: [patch] Large-denomination coins In-Reply-To: <20051225162038.56313.qmail@web32710.mail.mud.yahoo.com> References: <20051225162038.56313.qmail@web32710.mail.mud.yahoo.com> Message-ID: <7903f03c0512251439q189a6b60kc3c1ed72f2d06a38@mail.gmail.com> On 12/25/05, Miguel Ghobangieno wrote: > Exactly. > > I'd like the value var to be a double so we can add > copper coins ... That could lead to all sorts of fun rounding errors. Probably it would be best to use a 64bit int, and store value*10000 or so - that way you could have 4 values after the decimal point, and still not have errors due to floating point maths. From eracclists at bellsouth.net Sun Dec 25 19:36:12 2005 From: eracclists at bellsouth.net (ERACC) Date: Sun Dec 25 19:43:58 2005 Subject: [crossfire] Banking system In-Reply-To: <20051225073710.54155.qmail@web32713.mail.mud.yahoo.com> References: <20051225073710.54155.qmail@web32713.mail.mud.yahoo.com> Message-ID: <200512251936.13751.eracclists@bellsouth.net> On Sunday 25 December 2005 01:37 am Miguel Ghobangieno wrote: > You want a checkbook. I can make the archtype face pic > and perhapse cave can do the code How about a bank card that is tied to the banking system? There would then be reason to deposit money in the banks. Could charge a fee for use of the card too, or not. I think keeping the coins in the system is a good thing. Removing them, not so good. For very costly items deposit in the bank and use a bank card in the shops, etc. Also making the existing bank notes work as cash would be a good thing. Gene -- Mandriva Linux release 2006.0 (Official) for i586 19:31:37 up 10 days, 2:38, 10 users, load average: 0.00, 0.02, 0.00 ERA Computer Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer & UnixWare resellers From mikeeusaa at yahoo.com Sun Dec 25 15:28:15 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Dec 25 22:32:34 2005 Subject: [crossfire] Banking system In-Reply-To: <7903f03c0512250959h16958a6fqa0bee00c8ae76352@mail.gmail.com> Message-ID: <20051225212815.13933.qmail@web32706.mail.mud.yahoo.com> PLEASE don't implement this (gold, plat, silver as a stat). What you want is a check book. If the player has the checkbook applied the $$ will be deducted or added to his account. Please don't alter the gold weight/value ration (nor the silver etc). Please don't make money a stat. I will make a checkbook arch face. uint64 is good. value as a double (so we can add copper coins) would be good too. Please keep the coins as they are though. Please no money stat. (Also when is the jade etc coins going in? I think they should exist and be acceppted but not given as change except if region = azamuindo (perhapse another? darcap? maybe just azamuindo). --- Brendan Lally wrote: > On 12/25/05, Anton Oussik > wrote: > > On 25/12/05, Mark Wedel wrote: > > > Anton Oussik wrote: > > > > On 24/12/05, Mark Wedel > wrote: > > > >> At some level, it becomes a question of why > not just make money a > > > >> 'stat'. > > > > > > As said, this wouldn't be really hard. > > > > > > Add a uint64 field to the player object. > > > > I suspect this would also fix the client bug when > the client crashes > > when it steps on a tile where something has nrof > > 2^32. > > Wouldn't stepping on non-money items which have a > sufficiantly high > nrof also trigger such a crash? > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mikeeusaa at yahoo.com Sun Dec 25 18:37:02 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Dec 25 22:32:38 2005 Subject: [crossfire] Re: [patch] Large-denomination coins In-Reply-To: <7903f03c0512251439q189a6b60kc3c1ed72f2d06a38@mail.gmail.com> Message-ID: <20051226003702.42882.qmail@web32709.mail.mud.yahoo.com> so the value in the arch might read 0.33 the server code will remove the . when reading it and put it at 33 internally? --- Brendan Lally wrote: > On 12/25/05, Miguel Ghobangieno > wrote: > > Exactly. > > > > I'd like the value var to be a double so we can > add > > copper coins ... > > That could lead to all sorts of fun rounding errors. > > Probably it would be best to use a 64bit int, and > store value*10000 or > so - that way you could have 4 values after the > decimal point, and > still not have errors due to floating point maths. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From mikeeusaa at yahoo.com Sun Dec 25 21:59:52 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Dec 25 22:32:41 2005 Subject: [crossfire] Banking system In-Reply-To: <200512251936.13751.eracclists@bellsouth.net> Message-ID: <20051226035952.40033.qmail@web32706.mail.mud.yahoo.com> /me whips out the gimp and starts work on the bank card. --- ERACC wrote: > On Sunday 25 December 2005 01:37 am > Miguel Ghobangieno wrote: > > > You want a checkbook. I can make the archtype face > pic > > and perhapse cave can do the code > > How about a bank card that is tied to the banking > system? There would > then be reason to deposit money in the banks. Could > charge a fee for > use of the card too, or not. I think keeping the > coins in the system > is a good thing. Removing them, not so good. For > very costly items > deposit in the bank and use a bank card in the > shops, etc. Also > making the existing bank notes work as cash would be > a good thing. > > Gene > -- > Mandriva Linux release 2006.0 (Official) for i586 > 19:31:37 up 10 days, 2:38, 10 users, load > average: 0.00, 0.02, 0.00 > ERA Computer Consulting - http://www.eracc.com/ > eComStation, Linux, FreeBSD, OpenServer & UnixWare > resellers > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mikeeusaa at yahoo.com Sun Dec 25 22:14:45 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Dec 25 22:32:43 2005 Subject: [crossfire] Banking system In-Reply-To: <200512251936.13751.eracclists@bellsouth.net> Message-ID: <20051226041445.88559.qmail@web32704.mail.mud.yahoo.com> Finished drawing. Bank card pic and arc have now been submitted to CVS. All that's needed is the code and we can be done with this silly talk of turning the coins into a 'stat' :). The bank card shall fulfill what is wanted without touching the wonderful coins. --- ERACC wrote: > On Sunday 25 December 2005 01:37 am > Miguel Ghobangieno wrote: > > > You want a checkbook. I can make the archtype face > pic > > and perhapse cave can do the code > > How about a bank card that is tied to the banking > system? There would > then be reason to deposit money in the banks. Could > charge a fee for > use of the card too, or not. I think keeping the > coins in the system > is a good thing. Removing them, not so good. For > very costly items > deposit in the bank and use a bank card in the > shops, etc. Also > making the existing bank notes work as cash would be > a good thing. > > Gene > -- > Mandriva Linux release 2006.0 (Official) for i586 > 19:31:37 up 10 days, 2:38, 10 users, load > average: 0.00, 0.02, 0.00 > ERA Computer Consulting - http://www.eracc.com/ > eComStation, Linux, FreeBSD, OpenServer & UnixWare > resellers > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From lalo.martins at gmail.com Mon Dec 26 21:31:17 2005 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon Dec 26 21:31:59 2005 Subject: [crossfire] Re: [patch] Large-denomination coins In-Reply-To: References: Message-ID: Mikee committed the arches to CVS this morning, but not the patch. PLEASE DON'T USE THEM IN MAPS YET. Without the patch, they will NOT WORK properly. Carrying one of these would make odd things happen. If you want them to work properly, meaning, be accepted in shops, but you don't want them to be *given* by shops (or appear in item value evaluation messages), then you need to apply the patch, with a small change. I can submit the modified patch if people agree that's the desired, er, thing. (On my tests while writing the patch, carrying one without the patch, made me able to walk out of shops with items, without paying anything at all. That's very Uncool (TM). The shop code needs to know about the coin for it to work.) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Mon Dec 26 21:58:00 2005 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon Dec 26 21:59:59 2005 Subject: [crossfire] Re: [patch] Large-denomination coins In-Reply-To: References: Message-ID: on the other hand, thanks for the better pics :-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Tue Dec 27 01:10:46 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Dec 27 01:11:59 2005 Subject: [crossfire] Banking system In-Reply-To: <20051226035952.40033.qmail@web32706.mail.mud.yahoo.com> References: <20051226035952.40033.qmail@web32706.mail.mud.yahoo.com> Message-ID: <43B0E8F6.9050103@sonic.net> A random thought is that if bank cards are used, and the shops can automatically add/debit them, then the question becomes how much different is that than just adding a stat. Although, I suppose a good case can be made the coins found in the dungeon would have to remain coins until you do get to town to deposit them (that said, life could be made easier - dropping a pile of coins in a shop automatically debits your card, etc). My only real point in all this is one should think of the long term plans and how this all works out. As for as deflating the economy, I see that as real difficult at current time. If we could go back in time, having copper coins or more valued coins make sense. But adding a new coin at 1/10th the price of the current silver makes no sense IMO. As it is, silver is already somewhat worthless (get a big enough pile, may be worth something, but you're never really going to use individual silver coins for much of anything. And to refactor all the current items in the games, those on maps, those in players inventories, etc, seems like a near impossible task. And this in itself doesn't help balance the economy much - I think it is fair to say the main source of money isn't gathering the coins, but rather selling the items you find, so it becomes more about the relation of those values. For that reason, reducing the money to a float, or conversion at load time, doesn't make a lot of sense. The minimum value being 1 is perfectly fine - at some level, you need some minimal value, and as things stand now, I can't see any reason something less than 1 is needed. It would be like adding a 1/10th cent to the US banking system - as things stand right now, the US 1 cent coin is pretty much worthless - what is the point add at 1/10th coin. From nicolas.weeger at laposte.net Tue Dec 27 03:41:04 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Dec 27 03:42:00 2005 Subject: [crossfire] Banking system In-Reply-To: References: Message-ID: <43B10C30.2080409@laposte.net> Hello. > Thinking about lalo's patch, an interesting idea would be to make a > patch that makes the banking system more useful by introducing the > following changes to the banks: (catching on mails, so replying to many things at once) I must say I like the coin system as it is - having pile of coins to buy items and such. Having enough strength to be able to carry the platinum you need to get that really nice item is a fun thing imo :) So if we want to change things, i'd go for a credit card / checkbook system, but only for small amounts - like under 1000 platinum. This way you wouldn't need to carry money for usual things, but only for high-priced ones. Rationale is that shopkeepers don't have any way to check whether your bank account really has all that money, so prefer to get the real hard coins :) Just my 2 cents (of euro) Nicolas From antonoussik at gmail.com Tue Dec 27 05:15:28 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Tue Dec 27 05:16:00 2005 Subject: [crossfire] Banking system In-Reply-To: <43B10C30.2080409@laposte.net> References: <43B10C30.2080409@laposte.net> Message-ID: On 27/12/05, Nicolas Weeger wrote: > So if we want to change things, i'd go for a credit card / checkbook > system, but only for small amounts - like under 1000 platinum. > This way you wouldn't need to carry money for usual things, but only for > high-priced ones. > Rationale is that shopkeepers don't have any way to check whether your > bank account really has all that money, so prefer to get the real hard > coins :) Also replying to several posts. Firstably card vs chequebook: I don't think there is plastic in CF, and so things should not be made out if it. For all purposes chequebook would work like one, since you would implicitly make a cheque in a shop. Secondly about dropping money in shops have the amount deposited to your account - this is not really how banking works - how will the money get to the bank? If I found some cash, I would not walk into a random shop, and give it to them (unless I was feeling especially nice that day). Thirdly about the amount alowed to use in shops - I was thinking the racist shopkeeper system could be extended to work with cheque books - the amount you can buy would depend on your race, religeon, and the type of chequebook you have. If you are not trustworthy enough, output a message along the lines of "the shopkeeper laughs at your cheque". Since Mikee said he was making some archetypes, it might be a good idea to make several, and once the amount you have reaches some number, say 1,000, 10,000, 100,000, 1,000,000, and 10,000,000, send out a new book to the player. Making them primary colours would also be a good idea, so something like white, red, green, blue, black would work. It is unclear if bank should charge for using the service or pay you interest. In the interests of deflating the economy I'd say they should charge something like 10plat/day for the basic card, 200/day once you get over 10,000, 3,000/day once you get over 100,000, 30,000/day to those entrusting their millions to the bank and, 400,000/day once you have more money than you know what to do with. I'n not entirely sure I like this idea though, and I think it will meet heavy resistance from others in this list, since it introduces a charge for a fixed amount of time, which a player may or may not actually spend in the game. Perhaps charging a one time payment when money are deposited would appeal to more people, but that can be exploited by dropping many small deposits (unless you argue that if you pay in a silver coin it should not be credited to your account). Allowing a player to inscribe a cheque to another player, which can be paid in at a bank by the player in question, or exchanged for cash at a bank would be a good idea. Also banks sending bank statements to the players every day/week is an interesting though. This all relies on a system that can send items through the post (I assume that is how people would get their cheque books? I guess the banks could also be arranged to do give out new books, by refusing to deposit money over a certain amount until you purchase the next expensive card. From antonoussik at gmail.com Tue Dec 27 05:30:03 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Tue Dec 27 05:30:00 2005 Subject: [crossfire] Banking system In-Reply-To: <7903f03c0512250959h16958a6fqa0bee00c8ae76352@mail.gmail.com> References: <7903f03c0512240535k1ee596c3i3b1a1fac0179a444@mail.gmail.com> <43ADA057.8000402@sonic.net> <43AE3E43.3020707@sonic.net> <7903f03c0512250959h16958a6fqa0bee00c8ae76352@mail.gmail.com> Message-ID: On 25/12/05, Brendan Lally wrote: > On 12/25/05, Anton Oussik wrote: > > I suspect this would also fix the client bug when the client crashes > > when it steps on a tile where something has nrof > 2^32. > > Wouldn't stepping on non-money items which have a sufficiantly high > nrof also trigger such a crash? Yes, it does. However you seldom encounter anything else in such quantities. From brenlally at gmail.com Tue Dec 27 07:26:53 2005 From: brenlally at gmail.com (Brendan Lally) Date: Tue Dec 27 07:28:01 2005 Subject: [crossfire] Banking system In-Reply-To: References: <43B10C30.2080409@laposte.net> Message-ID: <7903f03c0512270526t6bfd582eua69a0082baa4f73e@mail.gmail.com> On 12/27/05, Anton Oussik wrote: > Also replying to several posts. > Firstably card vs chequebook: I don't think there is plastic in CF, > and so things should not be made out if it. Why do you assume that credit cards /must/ be made out of plastic? They could be made out of wood, or copper. In fact, credit cards give a saner way to charge the player, because real loan sha^W^W banks do exactly the same thing. Charge a fixed amount each year/month, everytime you buy something, send a request for payment of an amount vaguely related to the amount owed. Every $STUPIDLY_SHORT_SPACE_OF_TIME increment by BIGNUM You could then have differing credit limits backed by the amount that you have in the bank (and, maybe, the level of the player). - These could also have differing costs. Maybe there could also be a few cards that offer gimmicks - like a free dragon flight after you spend above a certain limit. In case you couldn't gues, I don't like credit card companies very much. From nicolas.weeger at laposte.net Tue Dec 27 08:26:36 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Dec 27 08:27:23 2005 Subject: [crossfire] Banking system In-Reply-To: References: <7903f03c0512240535k1ee596c3i3b1a1fac0179a444@mail.gmail.com> <43ADA057.8000402@sonic.net> <43AE3E43.3020707@sonic.net> Message-ID: <43B14F1C.3090001@laposte.net> Hello. > I suspect this would also fix the client bug when the client crashes > when it steps on a tile where something has nrof > 2^32. I tried to reproduce that bug, and could crash the client, but with negative numbers. I just committed changes to make the item's nrof of the client uint32, like server-side. This could fix the issue :) Nicolas From mikeeusaa at yahoo.com Mon Dec 26 09:20:52 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Dec 27 10:02:26 2005 Subject: [crossfire] I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)? Message-ID: <20051226152052.85136.qmail@web32707.mail.mud.yahoo.com> I'll commit the large denomination coins (unless objections are raised), I'd like to edit the amber coin to look more ambery (any objections) (currently it looks kinda like copper rather then a solidified transparent liquid... it's a shame CF doesn't support PNG semi-transparency)? For the map aspect I don't think the scorn bank change with amber and jade coin converter tables should be added to CVS. I think for the code aspect there should be a list of regions where amber and jade coins may be given as change. If on a shopmap the region matches one of these then amber and jade may be given. I think this list should include azamuindo... but not much else. All shops should accept amber and jade. (Also, as errac noted, they should probably accept imperials, also I have committed the bank card arch so work can be done on that too :D). Thoughts? __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mwedel at sonic.net Tue Dec 27 01:17:03 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Dec 27 10:02:28 2005 Subject: [crossfire] Re: [Crossfire-devel] I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)? In-Reply-To: <20051226152052.85136.qmail@web32707.mail.mud.yahoo.com> References: <20051226152052.85136.qmail@web32707.mail.mud.yahoo.com> Message-ID: <43B0EA6F.1010509@sonic.net> Miguel Ghobangieno wrote: > I'll commit the large denomination coins (unless > objections are raised), I'd like to edit the amber > coin to look more ambery (any objections) (currently > it looks kinda like copper rather then a solidified > transparent liquid... it's a shame CF doesn't support > PNG semi-transparency)? I _think_ the opengl mode of the gtk v2 client does deal with semi transperancy correctly. I didn't have any images to actually check that with, but opengl should deal with it just fine, and it basically just passes in the raw data. The other clients don't - it's a fairly costly operation to do - its a lot simpler for the graphic hardware to just say 'overwrite some pixels with this data' than to actually blend the data. But its is really the fact that the X library/server doesn't really have any support to do it - you can do shape masks, but not transparencies - to do that, you'd basically need to do all the graphic operations yourself. > I think for the code aspect there should be a list of > regions where amber and jade coins may be given as > change. If on a shopmap the region matches one of > these then amber and jade may be given. I think this > list should include azamuindo... but not much else. > All shops should accept amber and jade. (Also, as > errac noted, they should probably accept imperials, > also I have committed the bank card arch so work can > be done on that too :D). If a more universal higher denomination coin was needed, I wonder if mithril coins would/could make sense? Within the game, that is sort of universal metal, and highly valued. Another random thought is to have some logic to use gems to pay for items. Gems have a fixed value, so one could make it easier that the shopkeeper will just take the gems directly instead of the player needing to sell them. That sort of fixes the problem at hand. But to do that, I think some new option like 'pay_with_gems' that the player can set is needed. > From mikeeusaa at yahoo.com Tue Dec 27 06:41:36 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Dec 27 10:02:32 2005 Subject: [crossfire] Banking system In-Reply-To: Message-ID: <20051227124136.30361.qmail@web32704.mail.mud.yahoo.com> /me thinks it's time to make nrof var a bigger int. Same with hp and maxhp... :) Note: I allready committed a bank card, CF did have paper back then. However once I get back from vaca (assuming so), I'll bust out a bankbook or few if you still want that. --- Anton Oussik wrote: > On 25/12/05, Brendan Lally > wrote: > > On 12/25/05, Anton Oussik > wrote: > > > I suspect this would also fix the client bug > when the client crashes > > > when it steps on a tile where something has nrof > > 2^32. > > > > Wouldn't stepping on non-money items which have a > sufficiantly high > > nrof also trigger such a crash? > > Yes, it does. However you seldom encounter anything > else in such quantities. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From lalo.martins at gmail.com Tue Dec 27 14:15:59 2005 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue Dec 27 14:18:00 2005 Subject: [crossfire] Re: I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)? In-Reply-To: <20051226152052.85136.qmail@web32707.mail.mud.yahoo.com> References: <20051226152052.85136.qmail@web32707.mail.mud.yahoo.com> Message-ID: And so says Miguel Ghobangieno on 26/12/05 23:20... > For the map aspect I don't think the scorn bank change > with amber and jade coin converter tables should be > added to CVS. Ok, maybe not Scorn since it's a starter city, but I'd like to see plat->jade in low-medium-level places such as Darcap and Lone Town, and jade->amber in medium and high level places, regardless of your idea below. (Unless we go for full local currencies.) > I think for the code aspect there should be a list of > regions where amber and jade coins may be given as > change. If on a shopmap the region matches one of > these then amber and jade may be given. I think this > list should include azamuindo... but not much else. Because it's your map? :-) In our world jade is associated with the east. In Crossfire, it's just a very rare material. It should be given in medium-level places. > All shops should accept amber and jade. (Also, as > errac noted, they should probably accept imperials, > also I have committed the bank card arch so work can > be done on that too :D). After you told me of this idea this morning (my timezone at least), I was checking the code, and actually I think we can do better, if that's the direction we want to go. 1: instead of a new file, it can just be a new field in the regions file. 2: it wouldn't be too hard to implement full local currencies. What do people think of that? So here's the detailed local currencies proposal. Local currencies ================= The player needs to have a field or force saying his region of citizenship. This would be used for appraisals. To do this, in the hall where you select starting city, the exits would be replaced with player changers (and the code needs to be updated to handle this new type of player changer). There should probably be ways to change your citizenship. For example, when you get the Pupland passport, you should be offered citizenship. Each region would have a field called "money", containing a comma-separated list of archetype names, in order of decreasing value. A region can omit this field (or have it blank), in which case it "inherits" from its parent. The "world" region would have: "money platinacoin goldcoin silvercoin" (unless we want to take the opportunity to change that too - it's ridiculous how little silver is worth on bigworld :-( but that's a separate issue) When you sell something at a store, it would pick the coins to give you from the region's money. UNDECIDED: shops may either accept any and all money (easy to do - instead of iterating over a list of money archs, it iterates over the money archs in the player's inventory), or they may accept only region money, forcing you to go to the bank first. Thoughts? If we go with the second, then "tourist-friendly" shops can have converters in a corner. Monster treasure would also pick from the region money, although I suppose we could allow a money field in the map too, if you want a map to give funny money. Then it's all fun... I'd suggest getting rid of the existing gold/silver/plat "generic" coins and replacing them with non-coined pieces (which probably explains their relatively low value). Then introducing the "scorn penny", "scorn shilling", "scorn pound", "navar cent", "navar dime", "navar dollar", "pupland marks", and so on ad infinitum. This can also support mwedel's notion of accepting gems as money, by simply stating in the appropriate code that type GEM is as acceptable as type MONEY. So if shops accept foreign currency, they will also accept gems; if they don't, you'll be able to put gems in the money field for a region or map. (Carrying gems would then be a good strategy when going to a new country - you'll never know if they have exchange service for the money you have...) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ GNU: never give up freedom http://www.gnu.org/ From eracclists at bellsouth.net Tue Dec 27 15:49:26 2005 From: eracclists at bellsouth.net (ERACC) Date: Tue Dec 27 15:50:01 2005 Subject: [crossfire] Banking system In-Reply-To: <7903f03c0512270526t6bfd582eua69a0082baa4f73e@mail.gmail.com> References: <7903f03c0512270526t6bfd582eua69a0082baa4f73e@mail.gmail.com> Message-ID: <200512271549.27139.eracclists@bellsouth.net> On Tuesday 27 December 2005 07:26 am Brendan Lally wrote: > In case you couldn't gues, I don't like credit card companies very > much. Nor do I. That is why I suggested a bank card that debits the bank account rather than a credit card. I don't think CF should implement a credit system. I see ways to exploit /that/ right now. Gene -- Mandriva Linux release 2006.0 (Official) for i586 15:48:07 up 11 days, 22:55, 10 users, load average: 0.00, 0.05, 0.07 ERA Computer Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer & UnixWare resellers From eracclists at bellsouth.net Tue Dec 27 15:55:55 2005 From: eracclists at bellsouth.net (ERACC) Date: Tue Dec 27 15:56:01 2005 Subject: [crossfire] Re: [Crossfire-devel] I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)? In-Reply-To: <43B0EA6F.1010509@sonic.net> References: <20051226152052.85136.qmail@web32707.mail.mud.yahoo.com> <43B0EA6F.1010509@sonic.net> Message-ID: <200512271555.56540.eracclists@bellsouth.net> On Tuesday 27 December 2005 01:17 am Mark Wedel wrote: > ? Another random thought is to have some logic to use gems to pay for items. > Gems have a fixed value, so one could make it easier that the shopkeeper will > just take the gems directly instead of the player needing to sell them. ?That > sort of fixes the problem at hand. ?But to do that, I think some new option like > 'pay_with_gems' that the player can set is needed. OOOOooooo! I truly /like/ this idea. That would solve some of the problems of paying for very expensive items. While you guys are looking at stuff like this could you please adjust the payment altars to accept more than 32767? I wanted to use a 50000 diamond altar in my Lone Town apartment map (for the various alchemy benches in the basement) but could not due to this limitation. Gene -- Mandriva Linux release 2006.0 (Official) for i586 15:51:07 up 11 days, 22:58, 10 users, load average: 0.24, 0.13, 0.09 ERA Computer Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer & UnixWare resellers From leaf at real-time.com Tue Dec 27 16:00:35 2005 From: leaf at real-time.com (Rick Tanner) Date: Tue Dec 27 16:02:02 2005 Subject: [crossfire] Banking system In-Reply-To: <200512271549.27139.eracclists@bellsouth.net> References: <7903f03c0512270526t6bfd582eua69a0082baa4f73e@mail.gmail.com> <200512271549.27139.eracclists@bellsouth.net> Message-ID: <43B1B983.1050509@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ERACC wrote: > > That is why I suggested a bank card that debits the bank > account rather than a credit card. I don't think CF should implement > a credit system. I see ways to exploit /that/ right now. Hmm.. I thought the discussion all along was for some sort of debit/check/cheque card that automatically deducts the money from your bank account *assuming* you have enough cash in there to cover the purchase. Otherwise you see some sort of message showing how much more money you need to make the purchase. I agree, I think it's a bad idea for a credit card or making purchases without cold hard cash to back it up. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDsbmDhHyvgBp+vH4RAqqqAKDNYdG9Psbcuw2XfLmwSujwwRon/wCg7O68 Y0Soiyofjh3eTWQ1wdnhcZ0= =zXPP -----END PGP SIGNATURE----- From mwedel at sonic.net Wed Dec 28 00:29:27 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Dec 28 00:30:01 2005 Subject: [crossfire] Banking system In-Reply-To: <43B14F1C.3090001@laposte.net> References: <7903f03c0512240535k1ee596c3i3b1a1fac0179a444@mail.gmail.com> <43ADA057.8000402@sonic.net> <43AE3E43.3020707@sonic.net> <43B14F1C.3090001@laposte.net> Message-ID: <43B230C7.2050808@sonic.net> My point about dropping money in the shop is more a convenience thing, not realism (using the 'r' word with crossfire is never a good idea). But my general thought is that if a bankkeeper is willing to accept usage of the check card (or whatever its called), it just makes it easier for players so they don't have to run to the bank every time they want to get rid of their coins. That's not one of the things I really like in real life, so could do without it in a game. As far as check books, various thoughts: 1) the bank itself could charge some fee (fixed percentage) of the money being deposited. After all, they are taking all those coins and storing them away. Number should probably be relatively low. 2) Shops could add some surcharge if using such a card. Perhaps make this a map property. Arguably, the bigger the purchase, the smaller (percentage wise) this charge would be. If you're buying something for 4 gp, its a bit of a bother for the shopkeeper to take that check and get the money. If you're spending 50,000 pp, the shop keeper would probably prefer that money get transferred directly to their bank account - they don't want 5 tons of platinum. If one was going to be more realistic, there really should be regional banks (scorn bank, navar city bank, etc), and you'd need to use the appropriate check book in the appropriate city (or the shops should demand a lot more money for using accounts of a foreign nature). Or perhaps the at the bank itself, you could transfer money, but with a fairly hefty fee (have to use magic after all to really confirm there is the money in that remote account, etc). But that really just makes things more a bother for the player. From mwedel at sonic.net Wed Dec 28 00:36:09 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Dec 28 00:38:00 2005 Subject: [crossfire] Re: [Crossfire-devel] I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)? In-Reply-To: <200512271555.56540.eracclists@bellsouth.net> References: <20051226152052.85136.qmail@web32707.mail.mud.yahoo.com> <43B0EA6F.1010509@sonic.net> <200512271555.56540.eracclists@bellsouth.net> Message-ID: <43B23259.7000009@sonic.net> ERACC wrote: > While you guys are looking at stuff like this could you please adjust > the payment altars to accept more than 32767? I wanted to use a 50000 > diamond altar in my Lone Town apartment map (for the various alchemy > benches in the basement) but could not due to this limitation. The problem is that converters use sp and food as the number to use/create, and these values are 16 bit right now. It's simple enough to change the type to be 32 bit - I'm just not sure what other side effects that might cause. From hv at crypt.org Fri Dec 30 16:20:32 2005 From: hv at crypt.org (hv@crypt.org) Date: Fri Dec 30 16:14:04 2005 Subject: [crossfire] server 1.8.0 SEGV Message-ID: <200512302220.jBUMKXg23360@zen.crypt.org> (In passing: the README in the v1.8.0 server release points at: http://crossfire.real-time.com/Website_Index/Mailing_Lists/mailing_lists.jhtml for the mailing lists, but a site reorganisation means it is now at: http://crossfire.real-time.com/mailinglists/index.html ) Running a local server for single player use under Redhat Linux 7.1, using v1.8.0 release of server and cfclient (under X with fvwm), compiled with gcc 2.96, configured with: --prefix=/opt/crossfire-1.8.0 --with-python=/opt/python-2.4.1 The server had been up 2-3 days, and had several hours of (single player) use in that time. I entered the first (random map) level of: maps/quests/peterm/quests/ogre_chief and hit a SEGV as described below within a minute of entering. Firing up gdb on the core file gave me: (gdb) where #0 monster_should_cast_spell (monster=0x908ec90, spell_ob=0x0) at monster.c:689 #1 0x0807e32a in monster_check_apply (mon=0x908ec90, item=0x8acff6c) at monster.c:1252 #2 0x0807e06b in monster_check_pickup (monster=0x908ec90) at monster.c:1084 #3 0x0807cc6d in move_monster (op=0x908ec90) at monster.c:329 #4 0x0809d765 in process_object (op=0x908ec90) at time.c:1312 #5 0x0807c061 in process_events (map=0x0) at main.c:1002 #6 0x0807c5bd in main (argc=1, argv=0xbffffbd4) at main.c:1232 #7 0x4009f1c4 in __libc_start_main () from /lib/libc.so.6 (gdb) up #1 0x0807e32a in monster_check_apply (mon=0x908ec90, item=0x8acff6c) at monster.c:1252 1252 if (monster_should_cast_spell(mon, item->inv)) (gdb) p *item $1 = {contr = 0x0, next = 0x8d5d2b4, prev = 0x91c8530, active_next = 0x0, active_prev = 0x0, below = 0x893ba88, above = 0x0, inv = 0x0, container = 0x0, env = 0x908ec90, more = 0x0, head = 0x0, map = 0x0, count = 2952096, refcount = 0, name = 0x82f23fc "scroll", name_pl = 0x826d384 "scrolls", title = 0x0, race = 0x826d384 "scrolls", slaying = 0x0, skill = 0x827baf4 "use magic item", msg = 0x0, lore = 0x0, x = 0, y = 0, ox = 0, oy = 0, speed = 0, speed_left = -0.100000001, nrof = 1, face = 0x81ad468, direction = 0 '\000', facing = 0 '\000', type = 111 'o', subtype = 0 '\000', client_type = 661, resist = { 0 }, attacktype = 0, path_attuned = 0, path_repelled = 0, path_denied = 0, material = 1, materialname = 0x83d2eac "paper", magic = 0 '\000', state = 0 '\000', value = 1, level = 0, last_heal = 0, last_sp = 0, last_grace = 0, last_eat = 0, invisible = 0, pick_up = 0 '\000', item_power = 0 '\000', gen_sp_armour = 0 '\000', weight = 200, weight_limit = 0, carrying = 0, glow_radius = 0 '\000', stats = {Str = 0 '\000', Dex = 0 '\000', Con = 0 '\000', Wis = 0 '\000', Cha = 0 '\000', Int = 0 '\000', Pow = 0 '\000', wc = 0 '\000', ac = 0 '\000', hp = 0, maxhp = 0, sp = 0, maxsp = 0, grace = 0, maxgrace = 0, exp = 0, food = 0, dam = 0, luck = 0 '\000'}, perm_exp = 0, current_weapon_script = 0x0, current_weapon = 0x0, weapontype = 0, tooltype = 0, body_info = '\000' , body_used = '\000' , owner = 0x0, ownercount = 0, enemy = 0x0, attacked_by = 0x0, attacked_by_count = 4294967295, randomitems = 0x0, run_away = 0, chosen_skill = 0x0, hide = 0, move_status = 0, move_type = 0, will_apply = 0 '\000', spellitem = 0x0, expmul = 1, duration = 0, duration_modifier = 0 '\000', casting_time = -1, spell = 0x0, start_holding = 0, spellarg = 0x0, dam_modifier = 0 '\000', range = 0 '\000', range_modifier = 0 '\000', arch = 0x83425a0, other_arch = 0x0, flags = {0, 0, 0, 0}, animation_id = 0, anim_speed = 0 '\000', last_anim = 0 '\000', elevation = 0, smoothlevel = 0 '\000', events = 0x0, custom_name = 0x0} (gdb) I'm happy to provide more info (or the core file) if it might help, but I'd suggest at the least a patch as below to avoid the crash. Hugo --- monster.c Sat Jul 30 09:23:27 2005 +++ monster.c Fri Dec 30 22:07:06 2005 @@ -686,6 +686,11 @@ static int monster_should_cast_spell(object *monster, object *spell_ob) { + /* sanity check */ + if (spell_ob == NULL) { + LOG(llevError, "monster_should_cast_spell: spell_ob is NULL\n"); + return 0; + } if (spell_ob->subtype == SP_BOLT || spell_ob->subtype == SP_BULLET || spell_ob->subtype == SP_EXPLOSION || spell_ob->subtype == SP_CONE || spell_ob->subtype == SP_BOMB || spell_ob->subtype == SP_SMITE || From mwedel at sonic.net Sat Dec 31 00:02:37 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Dec 31 00:06:05 2005 Subject: [crossfire] shops and stealing Message-ID: <43B61EFD.2010807@sonic.net> For a long time, the thief skill stealing has been available, but the only use was the limited ability to steal from monsters. With the addition of new fields in the map header for shops, it'd seem like it would not be possible to extend stealing to shops. Not that the current headers are really in any way useful, but in a sense, because they sort of give an example of extending the shop attributes. What I'd suggest then is fields like: steal_adjustment: Represents how hard/easy it is to steal from this shop. A positive value denotes it is easy, negative value means it is hard. max_steal_value: Maximum value of an object that can be stolen from this store. Thus, if someone drops a 10,000 pp item in a shop easy to steal from (which normally has junky stuff), one wouldn't be able to steal it, because this value for the shop may be something like 10 pp. jail_map: If the theif is caught, map where they are sent. At least scorn has a jail if I recall - not sure if other maps. But basically, get caught stealing, have to sit around for 5 (or more) minutes. Easier shops would probably sentence you to less time. This could be in the form of mapname@x,y to denote coordinates to put the player into. If you succeed, you get exp based on the value of the object as well as actual difficulty of the attempt. For difficulty, I would say it should be based on the weight of the object (we don't have a size, but generally these two are somewhat related). Harder to steal a suit of plate armor than a ring. But the value of the object should also have an adjustment - that shopkeeper is going to keep a closer eye on those expensive items. Also, stealing would only be allowed if some of those fields exist (maybe jail_map - allowing stealing on a map with no penalty seems like a bad idea, but I could certainly see steal_adjustment being zero and max_steal_value also not being set (but probably not on the same map)). I'd also add that no matter how good a thief the person is, there should always be some chance of being caught (a fumble) - since I think chances are percentage based, this could be 1% chance. Thus, in a sense, a player that tries to steal a lot as an alternative to adventuring for exp could do so, but is going to get caught now and again and have to spend time in jail. As for stealing, it may be easiest to have something like 'steal inventory' command, which attempts to steal the unpaid items currently in your inventory. If you succeed, the unpaid flag is cleared, if fail, go to jail. Probably limit it to 1 item per try just to reduce rate of stealing. thoughts? From mwedel at sonic.net Sat Dec 31 01:33:01 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Dec 31 01:36:05 2005 Subject: [crossfire] Re: I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)? In-Reply-To: References: <20051226152052.85136.qmail@web32707.mail.mud.yahoo.com> Message-ID: <43B6342D.10302@sonic.net> Lalo Martins wrote: > Local currencies > ================= As a note, while having local currencies add flavors, I'm not really sure if it is worth the complication/confusion it is likely to cause. This will likely be somewhat related to how many regions we have. But one can certainly see a case where a player becomes a citizen of a new region and is now really confused on those values. > > The player needs to have a field or force saying his region of > citizenship. This would be used for appraisals. To do this, in the > hall where you select starting city, the exits would be replaced with > player changers (and the code needs to be updated to handle this new > type of player changer). > When you sell something at a store, it would pick the coins to give you > from the region's money. To me, it would probably make more sense, but perhaps be more confusing, to get appraisals based on the region you are in. It perhaps seems a bit odd be in a shop, examining your objects, and being told it is worth 5 pp, 2 gp, but when you sell it, you get 2 amber coins & 2 copper ingots or something. > > UNDECIDED: shops may either accept any and all money (easy to do - > instead of iterating over a list of money archs, it iterates over the > money archs in the player's inventory), or they may accept only region > money, forcing you to go to the bank first. Thoughts? If we go with > the second, then "tourist-friendly" shops can have converters in a corner. Having to convert money to me just seems a bother (find I nice item in a shop I want to buy. Oh, I'm in pupland, have to leave the shop, find a bank, convert the right amount over, etc). And if the conversion isn't 1:1 (eg, the bank takes some percentage for service), then it becomes even more a pain, because you don't really want to convert more you need. You'd also perhaps get the the case that gems become the most stable money, presuming you can still sell them in the shops and get whatever money. > > Monster treasure would also pick from the region money, although I > suppose we could allow a money field in the map too, if you want a map > to give funny money. Note that right now, treasurelists are coded with actual coin types, and not a 'money' type. So making this change requires some mucking with the treasure generation code, and could be relatively complicated especially if the different regions don't have that 10:1 ratio (eg, region the uses copper, silver, gold, and platinum ningis, with 7:1 for each ration (copper ningi has base value 1, silver ningi 7, gold 49, platinum 343). Converting what as 500 gp now becomes 1 platinum, 3 gold, 1 silver, 3 copper ningis). If this change is made, I'd suggest all treasurelists need to be updated to have a 'money' metatype, with the nrof representing the total value of the goods. Any treasurelists that specifically mention coin types would use those coin types. That said, throwing in the odd foreign currency in a dungeon would make things interesting. Imagine those low level players adventuring around scorn and finding some ningis and asking what the heck are those. > > Then it's all fun... I'd suggest getting rid of the existing > gold/silver/plat "generic" coins and replacing them with non-coined > pieces (which probably explains their relatively low value). Then > introducing the "scorn penny", "scorn shilling", "scorn pound", "navar > cent", "navar dime", "navar dollar", "pupland marks", and so on ad > infinitum. Not until relative recent history did paper money really become popular. That said, if currency is changed, I'd suggest unique graphics (that are clearly distinguishable) are probably desired - having bunches of coins in my inventory that all look the same would be confusing/annoying, and remove some of the reason for doing this, which is to add character. That said, one could make some changes fairly simply - one region could use triangular 'coins' instead of round ones. Also, if the face was replaced by just a single large coin (vs the stack like there is now), this would allow more detail to be put into the image - perhaps even enough to put different images on the coin face itself. After all, for most all other objects, each imagine represents just one of that image, and not a pile. > > This can also support mwedel's notion of accepting gems as money, by > simply stating in the appropriate code that type GEM is as acceptable as > type MONEY. So if shops accept foreign currency, they will also accept > gems; if they don't, you'll be able to put gems in the money field for a > region or map. (Carrying gems would then be a good strategy when going > to a new country - you'll never know if they have exchange service for > the money you have...) As a note, I'd think any decent sized place (large enough to have its own currency) should have a bank to convert the currency. Simply because if it doesn't, this adds more bother (shoot, can't convert from navar dollars to ningis here, have to go back to scorn, convert the navar coin to scorn, then can come back here and convert to ningis). Map wise, this is actually quite easy to do - since objects can accept generic 'money' type things, you don't need to actually put in tables for all the possible currency people will deposit - you can just put in one table of 'drop foreign money here to convert to copper/silver/gold/platinum ningis (different tables depending what you want). Player comes in, drops whatever they have on the gold ningi table and it converts it for them. In fact, right now, the current scorn bank is outdated in this sense - there isn't need for the gold to platinum table - one could easily enough set up an 'money to platinum' table. This is how the identify tables and the like work - they don't care on the coin presented, they just care about the value. But that then leads into that other problem - with local currencies, you'd get your money when you sell stuff in these different currencies. But to change the behavior of how these tables and the like work adds a bit more complication also. > > best, > Lalo Martins > -- > So many of our dreams at first seem impossible, > then they seem improbable, and then, when we > summon the will, they soon become inevitable. > -- > personal: http://www.laranja.org/ > GNU: never give up freedom http://www.gnu.org/ > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Sat Dec 31 01:39:26 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Dec 31 01:42:33 2005 Subject: [crossfire] Wraith changes In-Reply-To: References: <43A36A35.3020405@sonic.net> <43A7A718.8040106@sonic.net> Message-ID: <43B635AE.10001@sonic.net> Anton Oussik wrote: > Another thing that could be done is to reduce the feding speed. What > is the proper way of reducing weapon speed of a skill? I looked around > briefly, but could not find it. I don't know if there is actually a way to do this - it may be hardcoded right now, but there must be some diffrence, as I know karate is faster than dragon clawing even at the same level. > >> If so, I wonder if it may be nice to give starting wraiths some like a staff >> of minor healing just so they can use it to get enough hp to go kill wimpy >> things. > > As it stands now, a newborn wraith at 0hp can quite happily clear a > room of kobolds and come out with full hp. I feel it is too powerful, > so perhaps doing both, scaling down the feeding speed (probably about > 5-10fold), and also not giving the wraith the skill until they reach > level 15 would be appropriate to balance the race. Well, I'd argue that if I can go into a room with 0 hp and be sure to survive fighting kobolds, something is a bit off. but my original point was also that if I'm at 0 (or near zero hp) and low level, what can I do? Arguably, fighting anything should have some danger, and given that hp level, a stray hit could kill me. Yet if I don't get hp back by waiting, I'm sort of stuck - I basically have to risk death to get the hp back. I wonder if level should also come into play? I could otherwise see more moderate level wraiths who have very few hp thinking 'hey, I should go to the newbie dungeon to suck up some hp', which probably isn't what we really want. That 8th level wraith probably shouldn't get nearly as many hp back fighting kobolds if we want to try and discourage that behaviour. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From hv at crypt.org Sat Dec 31 07:17:31 2005 From: hv at crypt.org (hv@crypt.org) Date: Sat Dec 31 07:12:06 2005 Subject: [crossfire] shops and stealing In-Reply-To: <43B61EFD.2010807@sonic.net> Message-ID: <200512311317.jBVDHVV25187@zen.crypt.org> Mark Wedel wrote: : For a long time, the thief skill stealing has been available, but the only use :was the limited ability to steal from monsters. : : With the addition of new fields in the map header for shops, it'd seem like it :would not be possible to extend stealing to shops. Not that the current headers :are really in any way useful, but in a sense, because they sort of give an :example of extending the shop attributes. : : What I'd suggest then is fields like: : :steal_adjustment: Represents how hard/easy it is to steal from this shop. A :positive value denotes it is easy, negative value means it is hard. : :max_steal_value: Maximum value of an object that can be stolen from this store. : Thus, if someone drops a 10,000 pp item in a shop easy to steal from (which :normally has junky stuff), one wouldn't be able to steal it, because this value :for the shop may be something like 10 pp. Maybe shops should refuse to buy such expensive items from players if they don't have the facilities to display them securely, or they should buy and immediately sell on to the nearest shop that does. :jail_map: If the theif is caught, map where they are sent. At least scorn has :a jail if I recall - not sure if other maps. But basically, get caught :stealing, have to sit around for 5 (or more) minutes. Easier shops would :probably sentence you to less time. This could be in the form of mapname@x,y :to denote coordinates to put the player into. I don't like the idea of automatic jail time - keep that for things that you *don't* want players to do, like pking and abusive behaviour. For game balance, I think it'd be enough to ban a thief from the local shops for a period of time (maybe around constant * (1 + log_2(item_value)) ticks). If more is needed, the shop keeper should call the guards - no loot, no exp, and guaranteed to be higher level than you. But I don't think it is needed. The rest sounds good to me. Hugo From brenlally at gmail.com Sat Dec 31 09:07:22 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Dec 31 09:08:06 2005 Subject: [crossfire] Re: I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)? In-Reply-To: <43B6342D.10302@sonic.net> References: <20051226152052.85136.qmail@web32707.mail.mud.yahoo.com> <43B6342D.10302@sonic.net> Message-ID: <7903f03c0512310707o2e4483feq49322ded9400b532@mail.gmail.com> On 12/31/05, Mark Wedel wrote: > Not until relative recent history did paper money really become popular. That > said, if currency is changed, I'd suggest unique graphics (that are clearly > distinguishable) are probably desired - having bunches of coins in my inventory > that all look the same would be confusing/annoying, and remove some of the > reason for doing this, which is to add character. This would also have to affect character generation, currently players that are generated get an amount of money when they choose a class, and before they exit the nexus. If the two destinations from the nexus have differing currencies, then the player could get the 'wrong' type. Moving the acquisition of money to the teleporters which the player stepped on might work, but since dead players return there until they get another savebed, this might be hard to guarentee to not be exploitable (at the least, every existing player who didn't set a savebed, would get some money next time they died). Making those teleporters damned could work, indeed, if they pointed to a relatively 'safe' place (scorn town hall maybe?) it might be considered a good thing anyway. From eracclists at bellsouth.net Sat Dec 31 18:33:58 2005 From: eracclists at bellsouth.net (ERACC) Date: Sat Dec 31 18:34:06 2005 Subject: [crossfire] shops and stealing In-Reply-To: <43B61EFD.2010807@sonic.net> References: <43B61EFD.2010807@sonic.net> Message-ID: <200512311833.59182.eracclists@bellsouth.net> On Saturday 31 December 2005 12:02 am Mark Wedel wrote: > [...] > ? With the addition of new fields in the map header for shops, it'd seem like it > would not be possible to extend stealing to shops. [...] Good ideas there. I would add that a player's luck score should have a lot of influence on ability to steal from a shop. So, a player that wants to PK /and/ steal is truly "out of luck" and will have a much more difficult time stealing from a shop. A 'luck 0' score would mean luck has no affect on the percentage chance of getting caught. A luck score of +1 or greater means the player has an exponentially greater chance of stealing successfully. A luck score of -1 or lower greatly increases the player's chance of being caught exponentially as the score goes down. So, someone with 2 PKs (luck -2) would have a much harder time stealing than someone with a luck of 0. Gene -- Mandriva Linux release 2006.0 (Official) for i586 18:27:34 up 16 days, 1:34, 10 users, load average: 0.20, 0.08, 0.02 ERA Computer Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer & UnixWare resellers From mikeeusaa at yahoo.com Sat Dec 31 11:47:53 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 1 12:40:12 2006 Subject: [crossfire] Re: I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)? In-Reply-To: <7903f03c0512310707o2e4483feq49322ded9400b532@mail.gmail.com> Message-ID: <20051231174753.30832.qmail@web32706.mail.mud.yahoo.com> the coin money will still exist, right? --- Brendan Lally wrote: > On 12/31/05, Mark Wedel wrote: > > Not until relative recent history did paper > money really become popular. That > > said, if currency is changed, I'd suggest unique > graphics (that are clearly > > distinguishable) are probably desired - having > bunches of coins in my inventory > > that all look the same would be > confusing/annoying, and remove some of the > > reason for doing this, which is to add character. > > This would also have to affect character generation, > currently players > that are generated get an amount of money when they > choose a class, > and before they exit the nexus. If the two > destinations from the nexus > have differing currencies, then the player could get > the 'wrong' type. > > Moving the acquisition of money to the teleporters > which the player > stepped on might work, but since dead players return > there until they > get another savebed, this might be hard to guarentee > to not be > exploitable (at the least, every existing player who > didn't set a > savebed, would get some money next time they died). > > Making those teleporters damned could work, indeed, > if they pointed to > a relatively 'safe' place (scorn town hall maybe?) > it might be > considered a good thing anyway. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mikeeusaa at yahoo.com Sat Dec 31 11:50:06 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 1 12:40:17 2006 Subject: [crossfire] Re: I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)? In-Reply-To: <43B6342D.10302@sonic.net> Message-ID: <20051231175006.93218.qmail@web32708.mail.mud.yahoo.com> The regional currencies should be paper money rather then coins. (Imperials would not be a regional currency). While regional currencies exchange values could change depending on factors that are not in the game yet the silver, plat, gold, jade, and amberonium coins should keep their absolute value forever. --- Mark Wedel wrote: > Lalo Martins wrote: > > Local currencies > > ================= > > As a note, while having local currencies add > flavors, I'm not really sure if > it is worth the complication/confusion it is likely > to cause. This will likely > be somewhat related to how many regions we have. > But one can certainly see a > case where a player becomes a citizen of a new > region and is now really confused > on those values. > > > > > The player needs to have a field or force saying > his region of > > citizenship. This would be used for appraisals. > To do this, in the > > hall where you select starting city, the exits > would be replaced with > > player changers (and the code needs to be updated > to handle this new > > type of player changer). > > > > > When you sell something at a store, it would pick > the coins to give you > > from the region's money. > > To me, it would probably make more sense, but > perhaps be more confusing, to > get appraisals based on the region you are in. It > perhaps seems a bit odd be in > a shop, examining your objects, and being told it is > worth 5 pp, 2 gp, but when > you sell it, you get 2 amber coins & 2 copper ingots > or something. > > > > > UNDECIDED: shops may either accept any and all > money (easy to do - > > instead of iterating over a list of money archs, > it iterates over the > > money archs in the player's inventory), or they > may accept only region > > money, forcing you to go to the bank first. > Thoughts? If we go with > > the second, then "tourist-friendly" shops can have > converters in a corner. > > Having to convert money to me just seems a bother > (find I nice item in a shop > I want to buy. Oh, I'm in pupland, have to leave > the shop, find a bank, convert > the right amount over, etc). And if the conversion > isn't 1:1 (eg, the bank > takes some percentage for service), then it becomes > even more a pain, because > you don't really want to convert more you need. > You'd also perhaps get the the > case that gems become the most stable money, > presuming you can still sell them > in the shops and get whatever money. > > > > > Monster treasure would also pick from the region > money, although I > > suppose we could allow a money field in the map > too, if you want a map > > to give funny money. > > Note that right now, treasurelists are coded with > actual coin types, and not a > 'money' type. So making this change requires some > mucking with the treasure > generation code, and could be relatively complicated > especially if the different > regions don't have that 10:1 ratio (eg, region the > uses copper, silver, gold, > and platinum ningis, with 7:1 for each ration > (copper ningi has base value 1, > silver ningi 7, gold 49, platinum 343). Converting > what as 500 gp now becomes 1 > platinum, 3 gold, 1 silver, 3 copper ningis). > > If this change is made, I'd suggest all > treasurelists need to be updated to > have a 'money' metatype, with the nrof representing > the total value of the > goods. Any treasurelists that specifically mention > coin types would use those > coin types. > > That said, throwing in the odd foreign currency in > a dungeon would make things > interesting. Imagine those low level players > adventuring around scorn and > finding some ningis and asking what the heck are > those. > > > > > Then it's all fun... I'd suggest getting rid of > the existing > > gold/silver/plat "generic" coins and replacing > them with non-coined > > pieces (which probably explains their relatively > low value). Then > > introducing the "scorn penny", "scorn shilling", > "scorn pound", "navar > > cent", "navar dime", "navar dollar", "pupland > marks", and so on ad > > infinitum. > > Not until relative recent history did paper money > really become popular. That > said, if currency is changed, I'd suggest unique > graphics (that are clearly > distinguishable) are probably desired - having > bunches of coins in my inventory > that all look the same would be confusing/annoying, > and remove some of the > reason for doing this, which is to add character. > > That said, one could make some changes fairly > simply - one region could use > triangular 'coins' instead of round ones. Also, if > the face was replaced by > just a single large coin (vs the stack like there is > now), this would allow more > detail to be put into the image - perhaps even > enough to put different images on > the coin face itself. After all, for most all other > objects, each imagine > represents just one of that image, and not a pile. > > > > > This can also support mwedel's notion of accepting > gems as money, by > > simply stating in the appropriate code that type > GEM is as acceptable as > > type MONEY. So if shops accept foreign currency, > they will also accept > > gems; if they don't, you'll be able to put gems in > the money field for a > > region or map. (Carrying gems would then be a > good strategy when going > > to a new country - you'll never know if they have > exchange service for > > the money you have...) > > As a note, I'd think any decent sized place (large > enough to have its own > currency) should have a bank to convert the > currency. Simply because if it > doesn't, this adds more bother (shoot, can't convert > from navar dollars to > ningis here, have to go back to scorn, convert the > navar coin to scorn, then can > come back here and convert to ningis). > > Map wise, this is actually quite easy to do - > since objects can accept generic > 'money' type things, you don't need to actually put > in tables for all the > possible currency people will deposit - you can just > put in one table of 'drop > foreign money here to convert to > copper/silver/gold/platinum ningis (different > tables depending what you want). Player comes in, > drops whatever they have on > the gold ningi table and it converts it for them. > > In fact, right now, the current scorn bank is > outdated in this sense - there > isn't need for the gold to platinum table - one > could easily enough set up an > 'money to platinum' table. > > This is how the identify tables and the like work > - they don't care on the > coin presented, they just care about the value. > > But that then leads into that other problem - with > local currencies, you'd get > your money when you sell stuff in these different > currencies. But to change the > behavior of how these tables and the like work adds > a bit more complication also. > > > > > > best, > > > Lalo Martins > > -- > > So many of our dreams at first seem > impossible, > > then they seem improbable, and then, when > we > === message truncated === __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mikeeusaa at yahoo.com Sat Dec 31 11:51:54 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 1 12:40:23 2006 Subject: [crossfire] Re: [Crossfire-devel] I'll commit the large denomination coin archtypes, I'd like to edit the amber coin to look more ambery (any objections)? In-Reply-To: <43B23259.7000009@sonic.net> Message-ID: <20051231175154.18290.qmail@web32714.mail.mud.yahoo.com> I agree with Eracc, this is something I've wanted too. Could you also make hp and maxhp a 32 bit int aswell? --- Mark Wedel wrote: > ERACC wrote: > > > While you guys are looking at stuff like this > could you please adjust > > the payment altars to accept more than 32767? I > wanted to use a 50000 > > diamond altar in my Lone Town apartment map (for > the various alchemy > > benches in the basement) but could not due to this > limitation. > > The problem is that converters use sp and food as > the number to use/create, > and these values are 16 bit right now. > > It's simple enough to change the type to be 32 bit > - I'm just not sure what > other side effects that might cause. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mikeeusaa at yahoo.com Sat Dec 31 12:03:25 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 1 12:40:26 2006 Subject: [crossfire] shops and stealing In-Reply-To: <43B61EFD.2010807@sonic.net> Message-ID: <20051231180325.98078.qmail@web32708.mail.mud.yahoo.com> I like the idea. --- Mark Wedel wrote: > > For a long time, the thief skill stealing has been > available, but the only use > was the limited ability to steal from monsters. > > With the addition of new fields in the map header > for shops, it'd seem like it > would not be possible to extend stealing to shops. > Not that the current headers > are really in any way useful, but in a sense, > because they sort of give an > example of extending the shop attributes. > > What I'd suggest then is fields like: > > steal_adjustment: Represents how hard/easy it is to > steal from this shop. A > positive value denotes it is easy, negative value > means it is hard. > > max_steal_value: Maximum value of an object that can > be stolen from this store. > Thus, if someone drops a 10,000 pp item in a shop > easy to steal from (which > normally has junky stuff), one wouldn't be able to > steal it, because this value > for the shop may be something like 10 pp. > > jail_map: If the theif is caught, map where they > are sent. At least scorn has > a jail if I recall - not sure if other maps. But > basically, get caught > stealing, have to sit around for 5 (or more) > minutes. Easier shops would > probably sentence you to less time. This could be > in the form of mapname@x,y > to denote coordinates to put the player into. > > If you succeed, you get exp based on the value of > the object as well as actual > difficulty of the attempt. > > For difficulty, I would say it should be based on > the weight of the object (we > don't have a size, but generally these two are > somewhat related). Harder to > steal a suit of plate armor than a ring. But the > value of the object should > also have an adjustment - that shopkeeper is going > to keep a closer eye on those > expensive items. > > Also, stealing would only be allowed if some of > those fields exist (maybe > jail_map - allowing stealing on a map with no > penalty seems like a bad idea, but > I could certainly see steal_adjustment being zero > and max_steal_value also not > being set (but probably not on the same map)). > > I'd also add that no matter how good a thief the > person is, there should > always be some chance of being caught (a fumble) - > since I think chances are > percentage based, this could be 1% chance. Thus, in > a sense, a player that > tries to steal a lot as an alternative to > adventuring for exp could do so, but > is going to get caught now and again and have to > spend time in jail. > > As for stealing, it may be easiest to have > something like 'steal inventory' > command, which attempts to steal the unpaid items > currently in your inventory. > If you succeed, the unpaid flag is cleared, if fail, > go to jail. Probably limit > it to 1 item per try just to reduce rate of > stealing. > > thoughts? > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From mikeeusaa at yahoo.com Sat Dec 31 12:04:25 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 1 12:40:29 2006 Subject: [crossfire] shops and stealing In-Reply-To: <43B61EFD.2010807@sonic.net> Message-ID: <20051231180425.7290.qmail@web32715.mail.mud.yahoo.com> I like the idea (note it shouldn't be that a lvl 115 player can usually steal an artifact item (or something of similar value) from a shop, that should still be ultra hard). --- Mark Wedel wrote: > > For a long time, the thief skill stealing has been > available, but the only use > was the limited ability to steal from monsters. > > With the addition of new fields in the map header > for shops, it'd seem like it > would not be possible to extend stealing to shops. > Not that the current headers > are really in any way useful, but in a sense, > because they sort of give an > example of extending the shop attributes. > > What I'd suggest then is fields like: > > steal_adjustment: Represents how hard/easy it is to > steal from this shop. A > positive value denotes it is easy, negative value > means it is hard. > > max_steal_value: Maximum value of an object that can > be stolen from this store. > Thus, if someone drops a 10,000 pp item in a shop > easy to steal from (which > normally has junky stuff), one wouldn't be able to > steal it, because this value > for the shop may be something like 10 pp. > > jail_map: If the theif is caught, map where they > are sent. At least scorn has > a jail if I recall - not sure if other maps. But > basically, get caught > stealing, have to sit around for 5 (or more) > minutes. Easier shops would > probably sentence you to less time. This could be > in the form of mapname@x,y > to denote coordinates to put the player into. > > If you succeed, you get exp based on the value of > the object as well as actual > difficulty of the attempt. > > For difficulty, I would say it should be based on > the weight of the object (we > don't have a size, but generally these two are > somewhat related). Harder to > steal a suit of plate armor than a ring. But the > value of the object should > also have an adjustment - that shopkeeper is going > to keep a closer eye on those > expensive items. > > Also, stealing would only be allowed if some of > those fields exist (maybe > jail_map - allowing stealing on a map with no > penalty seems like a bad idea, but > I could certainly see steal_adjustment being zero > and max_steal_value also not > being set (but probably not on the same map)). > > I'd also add that no matter how good a thief the > person is, there should > always be some chance of being caught (a fumble) - > since I think chances are > percentage based, this could be 1% chance. Thus, in > a sense, a player that > tries to steal a lot as an alternative to > adventuring for exp could do so, but > is going to get caught now and again and have to > spend time in jail. > > As for stealing, it may be easiest to have > something like 'steal inventory' > command, which attempts to steal the unpaid items > currently in your inventory. > If you succeed, the unpaid flag is cleared, if fail, > go to jail. Probably limit > it to 1 item per try just to reduce rate of > stealing. > > thoughts? > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From mikeeusaa at yahoo.com Sat Dec 31 16:50:11 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 1 12:40:31 2006 Subject: [crossfire] Banking system In-Reply-To: <43B1B983.1050509@real-time.com> Message-ID: <20051231225011.57512.qmail@web32701.mail.mud.yahoo.com> Checkbook arch committed. There is also a bankcard arch. --- Rick Tanner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ERACC wrote: > > > > That is why I suggested a bank card that debits > the bank > > account rather than a credit card. I don't think > CF should implement > > a credit system. I see ways to exploit /that/ > right now. > > Hmm.. I thought the discussion all along was for > some sort of > debit/check/cheque card that automatically deducts > the money from your > bank account *assuming* you have enough cash in > there to cover the > purchase. Otherwise you see some sort of message > showing how much more > money you need to make the purchase. > > I agree, I think it's a bad idea for a credit card > or making purchases > without cold hard cash to back it up. > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - > http://enigmail.mozdev.org > > iD8DBQFDsbmDhHyvgBp+vH4RAqqqAKDNYdG9Psbcuw2XfLmwSujwwRon/wCg7O68 > Y0Soiyofjh3eTWQ1wdnhcZ0= > =zXPP > -----END PGP SIGNATURE----- > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mikeeusaa at yahoo.com Sat Dec 31 17:11:11 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 1 12:40:34 2006 Subject: [crossfire] Banking system In-Reply-To: <43B230C7.2050808@sonic.net> Message-ID: <20051231231111.40850.qmail@web32706.mail.mud.yahoo.com> I think you should have to go to the bank to convert coins to other currencies etc. If people don't want to bother with money they can use the checkbook and have to put up with the small % fees. --- Mark Wedel wrote: > > My point about dropping money in the shop is more > a convenience thing, not > realism (using the 'r' word with crossfire is never > a good idea). > > But my general thought is that if a bankkeeper is > willing to accept usage of > the check card (or whatever its called), it just > makes it easier for players so > they don't have to run to the bank every time they > want to get rid of their > coins. That's not one of the things I really like > in real life, so could do > without it in a game. > > As far as check books, various thoughts: > > 1) the bank itself could charge some fee (fixed > percentage) of the money being > deposited. After all, they are taking all those > coins and storing them away. > Number should probably be relatively low. > > 2) Shops could add some surcharge if using such a > card. Perhaps make this a map > property. Arguably, the bigger the purchase, the > smaller (percentage wise) this > charge would be. If you're buying something for 4 > gp, its a bit of a bother for > the shopkeeper to take that check and get the money. > If you're spending 50,000 > pp, the shop keeper would probably prefer that money > get transferred directly to > their bank account - they don't want 5 tons of > platinum. > > If one was going to be more realistic, there > really should be regional banks > (scorn bank, navar city bank, etc), and you'd need > to use the appropriate check > book in the appropriate city (or the shops should > demand a lot more money for > using accounts of a foreign nature). Or perhaps the > at the bank itself, you > could transfer money, but with a fairly hefty fee > (have to use magic after all > to really confirm there is the money in that remote > account, etc). But that > really just makes things more a bother for the > player. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mikeeusaa at yahoo.com Sat Dec 31 17:15:31 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 1 12:40:37 2006 Subject: [crossfire] shops and stealing In-Reply-To: <200512311317.jBVDHVV25187@zen.crypt.org> Message-ID: <20051231231531.62613.qmail@web32709.mail.mud.yahoo.com> hv: remeber, each server has diffrent rules. PKing and "abusive behavior" is 100% happy-good on Cat2 while it is outlawed on MF. Hardcoding jail for such things would be bad. --- hv@crypt.org wrote: > Mark Wedel wrote: > : For a long time, the thief skill stealing has > been available, but the only use > :was the limited ability to steal from monsters. > : > : With the addition of new fields in the map header > for shops, it'd seem like it > :would not be possible to extend stealing to shops. > Not that the current headers > :are really in any way useful, but in a sense, > because they sort of give an > :example of extending the shop attributes. > : > : What I'd suggest then is fields like: > : > :steal_adjustment: Represents how hard/easy it is > to steal from this shop. A > :positive value denotes it is easy, negative value > means it is hard. > : > :max_steal_value: Maximum value of an object that > can be stolen from this store. > : Thus, if someone drops a 10,000 pp item in a shop > easy to steal from (which > :normally has junky stuff), one wouldn't be able to > steal it, because this value > :for the shop may be something like 10 pp. > > Maybe shops should refuse to buy such expensive > items from players if they don't > have the facilities to display them securely, or > they should buy and immediately > sell on to the nearest shop that does. > > :jail_map: If the theif is caught, map where they > are sent. At least scorn has > :a jail if I recall - not sure if other maps. But > basically, get caught > :stealing, have to sit around for 5 (or more) > minutes. Easier shops would > :probably sentence you to less time. This could be > in the form of mapname@x,y > :to denote coordinates to put the player into. > > I don't like the idea of automatic jail time - keep > that for things that > you *don't* want players to do, like pking and > abusive behaviour. > > For game balance, I think it'd be enough to ban a > thief from the local shops > for a period of time (maybe around constant * (1 + > log_2(item_value)) ticks). > If more is needed, the shop keeper should call the > guards - no loot, no exp, > and guaranteed to be higher level than you. But I > don't think it is needed. > > The rest sounds good to me. > > Hugo > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mikeeusaa at yahoo.com Sat Dec 31 20:00:47 2005 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 1 12:40:40 2006 Subject: [crossfire] shops and stealing In-Reply-To: <200512311833.59182.eracclists@bellsouth.net> Message-ID: <20060101020047.96068.qmail@web32711.mail.mud.yahoo.com> Could exponetially vs linerally be settable in the server config file. --- ERACC wrote: > On Saturday 31 December 2005 12:02 am > Mark Wedel wrote: > > > [...] > > With the addition of new fields in the map > header for shops, it'd seem like it > > would not be possible to extend stealing to shops. > [...] > > Good ideas there. I would add that a player's luck > score should have > a lot of influence on ability to steal from a shop. > So, a player that > wants to PK /and/ steal is truly "out of luck" and > will have a much > more difficult time stealing from a shop. A 'luck 0' > score would mean > luck has no affect on the percentage chance of > getting caught. A luck > score of +1 or greater means the player has an > exponentially greater > chance of stealing successfully. A luck score of -1 > or lower greatly > increases the player's chance of being caught > exponentially as the > score goes down. So, someone with 2 PKs (luck -2) > would have a much > harder time stealing than someone with a luck of 0. > > Gene > -- > Mandriva Linux release 2006.0 (Official) for i586 > 18:27:34 up 16 days, 1:34, 10 users, load > average: 0.20, 0.08, 0.02 > ERA Computer Consulting - http://www.eracc.com/ > eComStation, Linux, FreeBSD, OpenServer & UnixWare > resellers > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com