From leaf at real-time.com Sun Jan 1 00:07:37 2006 From: leaf at real-time.com (Rick Tanner) Date: Sun Jan 1 00:08:06 2006 Subject: [crossfire] Banking system In-Reply-To: <43B230C7.2050808@sonic.net> References: <7903f03c0512240535k1ee596c3i3b1a1fac0179a444@mail.gmail.com> <43ADA057.8000402@sonic.net> <43AE3E43.3020707@sonic.net> <43B14F1C.3090001@laposte.net> <43B230C7.2050808@sonic.net> Message-ID: <43B771A9.6090609@real-time.com> Post on behalf of Todd Mitchell (Avion): The Imperial Banking system was not intended to be a modern bank, more of an old fashioned type bank. The Imperial Note is not money, it is a credit note. Basically it was to allow players to carry and transfer large amounts of wealth between cities or as a way to pay for large ticket items (such as guilds) while avoiding inflation of value that large coins would bring. The coin system is based on weight and this is a good thing that limits the amount of treasure folks can carry. Because they are low weight and easy to carry, the Imperial notes are not supposed to be worth anything intrinsically and cannot be used as money, but can be used to transfer large sums of money (and always for a convenience fee). All this talk of large denomination coins seems to be to me misplaced since the point of the coins is to limit what can be hauled out of dungeons easily and limit wealth accumulation. Large coins will lead to inflation as they allow players to carry more cash on hand. As for 'credit cards' and other stuff to pay for big purchases? - why bother when you can easily make special altars (or use scripting) for expensive things that accept Imperial notes. They are already credit notes. Allowing their use as *money* however would simply make them into large coins and defeat their purpose. Also the bank code was designed to allow for alternate credit institutions and easily changable service fees. From mikeeusaa at yahoo.com Sun Jan 1 10:51:29 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 1 12:40:43 2006 Subject: [crossfire] Banking system In-Reply-To: <43B771A9.6090609@real-time.com> Message-ID: <20060101165129.69739.qmail@web32711.mail.mud.yahoo.com> Who said jade and amberonium coins would be in any duengons? I am not putting them as treasures in my maps atleast (and does anyone else map anymore besides me?). As for "we have gems/this/that which can be used instead" it's nice to have multiple ways to do things. The role of jade etc IMHO, since I'm not going to put them in my duengons as treasure (and hopefully others won't either) is to beable to have "10,000 dollar" notes kindof thing. All apprasals etc should be in silver, gold, plat and never jade and amber. I suggest an addum to the mappers handbook "don't put jade and amber coins in you duengons as rewards". Then will come the question "why have them then!" Well then why have most of the things we have in CF? We could probably chuck most of our archtypes.. why even have CF? CF isn't needed in the world etc. I'd also like copper coins, this will require value to have decemal points. Could we do that? --- Rick Tanner wrote: > > Post on behalf of Todd Mitchell (Avion): > > The Imperial Banking system was not intended to be a > modern bank, more > of an old fashioned type bank. The Imperial Note is > not money, it is a > credit note. Basically it was to allow players to > carry and transfer > large amounts of wealth between cities or as a way > to pay for large > ticket items (such as guilds) while avoiding > inflation of value that > large coins would bring. The coin system is based > on weight and this is > a good thing that limits the amount of treasure > folks can carry. > Because they are low weight and easy to carry, the > Imperial notes are > not supposed to be worth anything intrinsically and > cannot be used as > money, but can be used to transfer large sums of > money (and always for a > convenience fee). All this talk of large > denomination coins seems to be > to me misplaced since the point of the coins is to > limit what can be > hauled out of dungeons easily and limit wealth > accumulation. Large > coins will lead to inflation as they allow players > to carry more cash on > hand. As for 'credit cards' and other stuff to pay > for big purchases? - > why bother when you can easily make special altars > (or use scripting) > for expensive things that accept Imperial notes. > They are already > credit notes. Allowing their use as *money* however > would simply make > them into large coins and defeat their purpose. > Also the bank code was designed to allow for > alternate credit > institutions and easily changable service fees. > > _______________________________________________ > 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 Jan 1 12:58:26 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sun Jan 1 13:00:28 2006 Subject: [crossfire] shops and stealing In-Reply-To: <20051231231531.62613.qmail@web32709.mail.mud.yahoo.com> References: <200512311317.jBVDHVV25187@zen.crypt.org> <20051231231531.62613.qmail@web32709.mail.mud.yahoo.com> Message-ID: <7903f03c0601011058v1e6502e6u454482e7662d12c1@mail.gmail.com> On 12/31/05, Miguel Ghobangieno wrote: > 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. Well, in this case, imprisonment is considered as a game balance issue, rather than one that is related to an external set of 'rules' (or lack thereof). Nonetheless, I am inclined to think that a more workable implementation would be to introduce the aztec system of punishment for theft, that a thief should repay twice what they stole. This raises issues concerning /which/ price is used to determine that, but it would at least allow thieving to be something that could be penalised immediately, without having a would-be thief spending more time in prison than not. In the case of someone who couldn't pay, then of course locking them up seems a suitably unreasonable approach :) From brenlally at gmail.com Sun Jan 1 14:48:30 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sun Jan 1 14:50:07 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: <20051231175006.93218.qmail@web32708.mail.mud.yahoo.com> References: <43B6342D.10302@sonic.net> <20051231175006.93218.qmail@web32708.mail.mud.yahoo.com> Message-ID: <7903f03c0601011248h67b1f9f5ve7fa7edf61a4b4b8@mail.gmail.com> On 12/31/05, Miguel Ghobangieno wrote: > 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. Actually, something I think might be interesting would be to have major and minor currencies. Consider the (pre-decimalisation) British Currency. Prices were given in pounds, shillings and pence, 12 p made one shilling, and 20 shillings one pound There was a one penny coin, a one shilling coin, and a one pound note. In principle it was possible to use these, and only these, for purchasing items. However, there were a number of other coins of intermediate values which were extensively used to make up intermediate values, without prices being quoted in them. (note that I am referencing old British currancy, simply because there were so many coins of arbitrary values that were issued - http://en.wikipedia.org/wiki/British_coinage#Denominations_of_pre-decimal_coins_and_their_years_of_production looks to be a fairly good list). Now, what I am wondering, is if the coins with which shops make change couldn't be the thing that varied, so that money would be taken from one of 12 or so different types of coins, and change given in a similar manner (to take an example from the above list, an item which would require 50 shillings (gold) change might cause it to be given in the form of two unites and a half unite in one place, but one two guinea coin and two double florins somewhere else. These could all be legal tender everywhere, whilst causing a player who would travel in certain areas of the world to have different types of coins to someone else elsewhere. A modern form of this can be seen to a lesser extent with the euro coins and notes, whilst they lack the amusingly contradictory values, they have different designs on the reverse depending on which country they are from, so that a coin with a design from a country relatively far away is a mild curiosity on the occasions they are encountered. From mikeeusaa at yahoo.com Sun Jan 1 15:28:59 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 1 16:27:07 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: <7903f03c0601011248h67b1f9f5ve7fa7edf61a4b4b8@mail.gmail.com> Message-ID: <20060101212859.37283.qmail@web32714.mail.mud.yahoo.com> If we are to do this it should be in addition to the current (blank) coins. --- Brendan Lally wrote: > On 12/31/05, Miguel Ghobangieno > wrote: > > 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. > > Actually, something I think might be interesting > would be to have > major and minor currencies. > > Consider the (pre-decimalisation) British Currency. > Prices were given in pounds, shillings and pence, 12 > p made one > shilling, and 20 shillings one pound > > There was a one penny coin, a one shilling coin, and > a one pound note. > In principle it was possible to use these, and only > these, for > purchasing items. However, there were a number of > other coins of > intermediate values which were extensively used to > make up > intermediate values, without prices being quoted in > them. (note that I > am referencing old British currancy, simply because > there were so many > coins of arbitrary values that were issued - > http://en.wikipedia.org/wiki/British_coinage#Denominations_of_pre-decimal_coins_and_their_years_of_production > looks to be a fairly good list). > > Now, what I am wondering, is if the coins with which > shops make change > couldn't be the thing that varied, so that money > would be taken from > one of 12 or so different types of coins, and change > given in a > similar manner (to take an example from the above > list, an item which > would require 50 shillings (gold) change might cause > it to be given in > the form of two unites and a half unite in one > place, but one two > guinea coin and two double florins somewhere else. > > These could all be legal tender everywhere, whilst > causing a player > who would travel in certain areas of the world to > have different types > of coins to someone else elsewhere. > > A modern form of this can be seen to a lesser extent > with the euro > coins and notes, whilst they lack the amusingly > contradictory values, > they have different designs on the reverse depending > on which country > they are from, so that a coin with a design from a > country relatively > far away is a mild curiosity on the occasions they > are encountered. > > _______________________________________________ > 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 Sun Jan 1 17:00:30 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jan 1 17:03:04 2006 Subject: [crossfire] shops and stealing In-Reply-To: <20051231180425.7290.qmail@web32715.mail.mud.yahoo.com> References: <20051231180425.7290.qmail@web32715.mail.mud.yahoo.com> Message-ID: <43B85F0E.1020508@sonic.net> Miguel Ghobangieno wrote: > 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). But this is also where the max steal value comes in. Unless there are shops which let the players steal 100,000 pp items, this never really becomes an issue. While theoretically possible to make the formula something settable in a config file, I think it'd be more likely that certain parameters are set that way (base chance, difficulty increase, etc). Note also of course that your steal chance is based on your exp in the stealing skill. I'd imagine getting really high levels would be relatively difficult/time consuming. As far as punishments: Being banned from stores (for some time) is an interesting idea. Certainly, the shop maps could be set up to not allowed players that are banned from going into the store. And a force could be used to denote that the person is banned (ideally, they should just be banned in that region - navar isn't really going to know what happened in scorn). In fact, this force could be used to record number of times caught, with each time they have been caught decreasing the odds - a known thief is going to be watched pretty carefully after all. So even if the player isn't banned from the store, may still have a very hard time stealing. It could be interesting to tie this to the idea of reputation that has been bandied about before also. A known thief probably won't get as good prices selling stuff and pay more for buying stuff. This could be an incentive for that player to go out to another town where he isn't known. Perhaps tracking successes (or amount successfully stolen) could be interesting - a character could then become (in)famous as the legendary thief or something also. If we actually had a thieves guild, such status could be a requirement to get access to certain parts of it. Punishment in coins could be done. But then I suppose the players would decide on that tradeoff - if they don't want to loose money, they'd just drop what money they have in their apartment and then steal, risking the jail time. From mwedel at sonic.net Sun Jan 1 17:17:08 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jan 1 17:20:08 2006 Subject: [crossfire] Banking system In-Reply-To: <20060101165129.69739.qmail@web32711.mail.mud.yahoo.com> References: <20060101165129.69739.qmail@web32711.mail.mud.yahoo.com> Message-ID: <43B862F4.7010507@sonic.net> Miguel Ghobangieno wrote: > I suggest an addum to the mappers handbook "don't put > jade and amber coins in you duengons as rewards". Then > will come the question "why have them then!" Well then > why have most of the things we have in CF? We could > probably chuck most of our archtypes.. why even have > CF? CF isn't needed in the world etc. Updating the map guide could be done. I just wonder how many people read it :). That said, the map check scripts could be modified to look for unauthorized arches also - some cases may be acceptable, but noting that jade coin appears in map xyz coudl still be useful. > > I'd also like copper coins, this will require value to > have decemal points. > Could we do that? IMO, no. There will always need to be a minimum value, and keeping that minimum 1 to me makes perfect sense. Adding decimalization adds a fair amount of complication, and as is, a value 1 object really isn't worth anything. I'd much rather go the approach of revalueing the existing money. Make the new copper coin worth 1. Make silver coins worth 5. If gold (10) and platinum (50) coins keep the same value, such a change in valuation isn't likely to affect things very much (unless players make huge piles of silver to anticipate that change). Or perhaps one that seems like more a hack but wouldn't have that problem - create 'new' coin - new copper, new silver, new gold, new platinum, etc coins as new archetypes. Put whatever valuation you want in them. Update treasure lists (and perhaps maps, but I'm not sure how many maps actually have coins piled on them) Maybe change the existing coins to be 'old' coins or 'ancient' coins. Thus, all new coinage that shows up should be these new coins with new valuation. However, those old coins still exist and can still be used with no inflation in value, so a player that has stockpiled piles of them doesn't get anything more from them (and if they find them in maps or something, not a big deal - old coins sitting in a dungeon wouldn't be that odd). I say all this because, as I've said before, at some level, you need a minimum value on objects. You can't use floats to store value because the precision for high/low values isn't there, and you'll get into all sorts of errors. So the only way to do this is what Brendan (I think it was) described, which is to multiply and divide internally. But even then, you are still stuck with some minimum, based on the multiply/divide values that are set up (if for example it is 100, then your minimum value is .01 - anything less is lost). But really, it comes down to the fact (to me) that a value 1 object is pretty nearly worthless, and I can't see need to have stuff worth less than that. So this really becomes a matter of a new coin standard, and that can be done with just archetype changes, which to me seems like the much better way to go. From eracclists at bellsouth.net Sun Jan 1 17:33:49 2006 From: eracclists at bellsouth.net (ERACC) Date: Sun Jan 1 17:34:08 2006 Subject: [crossfire] shops and stealing In-Reply-To: <20060101020047.96068.qmail@web32711.mail.mud.yahoo.com> References: <20060101020047.96068.qmail@web32711.mail.mud.yahoo.com> Message-ID: <200601011733.50594.eracclists@bellsouth.net> On Saturday 31 December 2005 08:00 pm Miguel Ghobangieno wrote: > --- 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 [...] > > Could exponetially vs linerally be settable in the server config file. Making this server configurable would be good I think. Not everyone desires to have all the "features" be a hard-coded non-option. Gene -- Mandriva Linux release 2006.0 (Official) for i586 17:28:52 up 17 days, 35 min, 10 users, load average: 0.00, 0.01, 0.00 ERA Computer Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer & UnixWare resellers From lalo.martins at gmail.com Mon Jan 2 02:43:38 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon Jan 2 02:44:08 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: <20051231175006.93218.qmail@web32708.mail.mud.yahoo.com> References: <43B6342D.10302@sonic.net> <20051231175006.93218.qmail@web32708.mail.mud.yahoo.com> Message-ID: And so says Miguel Ghobangieno on 01/01/06 01:50... > The regional currencies should be paper money rather > then coins. I don't think paper money would make sense in the CF world... it's too recent a concept. What I'm talking about is "coins" as opposed to "pieces" - a gold coin is a small disc of gold with some image, number and words stamped in it, and is official money issued by a country. It's supposed to be worth more or less the intrinsic value of the gold in weight, but not always. On the other hand a gold piece, often used in fantasy worlds and ancient real world, is what we have now; a small disc of gold, not "coined". It's only worth its intrinsic value - by weight. > 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. If they are pieces rather than coins, yes. Whether they are accepted in shops or you have to "sell" them at a bank, is more or less what we're discussing. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From mikeeusaa at yahoo.com Sun Jan 1 20:57:01 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 2 20:47:04 2006 Subject: [crossfire] Banking system In-Reply-To: <43B862F4.7010507@sonic.net> Message-ID: <20060102025701.16023.qmail@web32712.mail.mud.yahoo.com> Changing the value of the metal coins isn't doable as silver has a set weight to value ratio... Perhapse it is best to forget about copper coins. --- Mark Wedel wrote: > Miguel Ghobangieno wrote: > > > I suggest an addum to the mappers handbook "don't > put > > jade and amber coins in you duengons as rewards". > Then > > will come the question "why have them then!" Well > then > > why have most of the things we have in CF? We > could > > probably chuck most of our archtypes.. why even > have > > CF? CF isn't needed in the world etc. > > Updating the map guide could be done. I just > wonder how many people read it > :). That said, the map check scripts could be > modified to look for unauthorized > arches also - some cases may be acceptable, but > noting that jade coin appears in > map xyz coudl still be useful. > > > > > I'd also like copper coins, this will require > value to > > have decemal points. > > Could we do that? > > IMO, no. There will always need to be a minimum > value, and keeping that > minimum 1 to me makes perfect sense. Adding > decimalization adds a fair amount > of complication, and as is, a value 1 object really > isn't worth anything. > > I'd much rather go the approach of revalueing the > existing money. Make the > new copper coin worth 1. Make silver coins worth 5. > If gold (10) and platinum > (50) coins keep the same value, such a change in > valuation isn't likely to > affect things very much (unless players make huge > piles of silver to anticipate > that change). > > Or perhaps one that seems like more a hack but > wouldn't have that problem - > create 'new' coin - new copper, new silver, new > gold, new platinum, etc coins as > new archetypes. Put whatever valuation you want in > them. Update treasure lists > (and perhaps maps, but I'm not sure how many maps > actually have coins piled on > them) Maybe change the existing coins to be 'old' > coins or 'ancient' coins. > > Thus, all new coinage that shows up should be > these new coins with new > valuation. However, those old coins still exist and > can still be used with no > inflation in value, so a player that has stockpiled > piles of them doesn't get > anything more from them (and if they find them in > maps or something, not a big > deal - old coins sitting in a dungeon wouldn't be > that odd). > > I say all this because, as I've said before, at > some level, you need a minimum > value on objects. You can't use floats to store > value because the precision for > high/low values isn't there, and you'll get into all > sorts of errors. So the > only way to do this is what Brendan (I think it was) > described, which is to > multiply and divide internally. But even then, you > are still stuck with some > minimum, based on the multiply/divide values that > are set up (if for example it > is 100, then your minimum value is .01 - anything > less is lost). > > But really, it comes down to the fact (to me) that > a value 1 object is pretty > nearly worthless, and I can't see need to have stuff > worth less than that. So > this really becomes a matter of a new coin standard, > and that can be done with > just archetype changes, which to me seems like the > much better way to go. > > > _______________________________________________ > 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 Mon Jan 2 09:50:39 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 2 20:47:07 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: Message-ID: <20060102155039.73477.qmail@web32712.mail.mud.yahoo.com> The regional coins shouldn't be made of valuable materials such as gold then. Copper would be better. --- Lalo Martins wrote: > And so says Miguel Ghobangieno on 01/01/06 01:50... > > The regional currencies should be paper money > rather > > then coins. > > I don't think paper money would make sense in the CF > world... it's too > recent a concept. > > What I'm talking about is "coins" as opposed to > "pieces" - a gold coin > is a small disc of gold with some image, number and > words stamped in it, > and is official money issued by a country. It's > supposed to be worth > more or less the intrinsic value of the gold in > weight, but not always. > > On the other hand a gold piece, often used in > fantasy worlds and ancient > real world, is what we have now; a small disc of > gold, not "coined". > It's only worth its intrinsic value - by weight. > > > 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. > > If they are pieces rather than coins, yes. Whether > they are accepted in > shops or you have to "sell" them at a bank, is more > or less what we're > discussing. > > best, > Lalo > Martins > -- > So many of our dreams at first seem > impossible, > then they seem improbable, and then, when we > summon the will, they soon become inevitable. > -- > personal: > http://www.laranja.org/ > technical: > http://lalo.revisioncontrol.net/ > GNU: never give up freedom > http://www.gnu.org/ > > > _______________________________________________ > crossfire mailing list > crossfire@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 brenlally at gmail.com Mon Jan 2 21:18:44 2006 From: brenlally at gmail.com (Brendan Lally) Date: Mon Jan 2 21:20:09 2006 Subject: [crossfire] Banking system In-Reply-To: <20060102025701.16023.qmail@web32712.mail.mud.yahoo.com> References: <43B862F4.7010507@sonic.net> <20060102025701.16023.qmail@web32712.mail.mud.yahoo.com> Message-ID: <7903f03c0601021918k61c0f6c5xeeb65cdc805ba740@mail.gmail.com> On 1/2/06, Miguel Ghobangieno wrote: > Changing the value of the metal coins isn't doable as > silver has a set weight to value ratio... Well, today silver has about 1/80th of the weight to value ratio of gold. So changing the relative prices is certainly possible. From mikeeusaa at yahoo.com Tue Jan 3 11:20:59 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 3 11:32:27 2006 Subject: [crossfire] How do I make an object give damage to the player (this is a carryable object). In-Reply-To: <7903f03c0601021918k61c0f6c5xeeb65cdc805ba740@mail.gmail.com> Message-ID: <20060103172059.79929.qmail@web32702.mail.mud.yahoo.com> Here is the current object's important parts: race gold and jewels attacktype 4 dam 5 speed 0.100000 color_fg grey nrof 1 type 73 material 2 identified 1 editable 2048 client_type 2005 It's not doing damage though... __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From mikeeusaa at yahoo.com Tue Jan 3 11:25:38 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 3 11:32:29 2006 Subject: [crossfire] Banking system In-Reply-To: <7903f03c0601021918k61c0f6c5xeeb65cdc805ba740@mail.gmail.com> Message-ID: <20060103172538.21835.qmail@web32710.mail.mud.yahoo.com> Yes I know, it's a buyers market right now :). Silver is, however, getting rarer. It is believed to be only 2 or 4x as abundant as gold now as the silver is used up as a rapid pace in industrial processes. If you want we could up silver to 2:10 or maybe even 4:10 rather then the 1:10 it is now and put copper at 1:10. Your thoughts? If you want to do this I'll be happy to change the archtypes. Someone will need to change the bank exchange tables though (I'll do mlab). So should we keep it at 1:10. Put it at 2:10 or 4:10 ? (or 3:10 ? (odd numbers are unfun at division though)) --- Brendan Lally wrote: > On 1/2/06, Miguel Ghobangieno > wrote: > > Changing the value of the metal coins isn't doable > as > > silver has a set weight to value ratio... > > Well, today silver has about 1/80th of the weight to > value ratio of > gold. So changing the relative prices is certainly > possible. > > _______________________________________________ > 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 Tue Jan 3 12:16:22 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue Jan 3 12:18:10 2006 Subject: [crossfire] Banking system In-Reply-To: <20060103172538.21835.qmail@web32710.mail.mud.yahoo.com> References: <7903f03c0601021918k61c0f6c5xeeb65cdc805ba740@mail.gmail.com> <20060103172538.21835.qmail@web32710.mail.mud.yahoo.com> Message-ID: <7903f03c0601031016gf874126rc06503702ac1d90e@mail.gmail.com> On 1/3/06, Miguel Ghobangieno wrote: > So should we keep it at 1:10. Put it at 2:10 or 4:10 ? > (or 3:10 ? (odd numbers are unfun at division though)) I'm inclined to think that if this is going to be done, then their would need to be a currency system independent of the values of the individual coins. Instead of using gold, silver and platinum, define a unit and one or two subunits, give them absolute values, and then make gold, silver and platinum coins worth some value relative to that. (maybe even a sliding value) so, if we take something like the old spanish system, where there is the dollar/peso, (or 'pieces of eight' as they were called), each being worth 8 reals, which in turn is worth 85 maraved?es (depending on /which/ real you are refering to, but you only need to pick one). In that case then, value 1 would be a maravedies, prices would be given in terms of dollars, reals, and maravedies, and silver gold and platinum would have values that floated about that, with a whole slew of other coins as well. To extend this line of reasoning further, if these were tied to areas of the game world, it would allow macro-economic effects, as various currancies became debased due to economic pressure (something that happened quite frequently in the past - the real was originally 3 maravedies). This would also lead to a somewhat evil way to control wealth acquisition, just hyper-inflate the coinage or commodities most of the wealth is being stored in. (not that anyone would do that of course.....) From mikeeusaa at yahoo.com Tue Jan 3 13:11:55 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 3 13:26:07 2006 Subject: [crossfire] Banking system In-Reply-To: <7903f03c0601031016gf874126rc06503702ac1d90e@mail.gmail.com> Message-ID: <20060103191155.25816.qmail@web32711.mail.mud.yahoo.com> gold and silver coins are not fiate currencies, their value can't be just inflated. You need paper money for that (or money who's value is more then the value of the material). I won't support inflating gold and silver etc. I will support creating paralell fiat currencies, and yes they did exist in the ancient world. --- Brendan Lally wrote: > On 1/3/06, Miguel Ghobangieno > wrote: > > So should we keep it at 1:10. Put it at 2:10 or > 4:10 ? > > (or 3:10 ? (odd numbers are unfun at division > though)) > > I'm inclined to think that if this is going to be > done, then their > would need to be a currency system independent of > the values of the > individual coins. > > Instead of using gold, silver and platinum, define a > unit and one or > two subunits, give them absolute values, and then > make gold, silver > and platinum coins worth some value relative to > that. (maybe even a > sliding value) > > so, if we take something like the old spanish > system, where there is > the dollar/peso, (or 'pieces of eight' as they were > called), each > being worth 8 reals, which in turn is worth 85 > maraved?es (depending > on /which/ real you are refering to, but you only > need to pick one). > > In that case then, value 1 would be a maravedies, > prices would be > given in terms of dollars, reals, and maravedies, > and silver gold and > platinum would have values that floated about that, > with a whole slew > of other coins as well. > > To extend this line of reasoning further, if these > were tied to areas > of the game world, it would allow macro-economic > effects, as various > currancies became debased due to economic pressure > (something that > happened quite frequently in the past - the real was > originally 3 > maravedies). > > This would also lead to a somewhat evil way to > control wealth > acquisition, just hyper-inflate the coinage or > commodities most of the > wealth is being stored in. (not that anyone would do > that of > course.....) > > _______________________________________________ > 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 brenlally at gmail.com Tue Jan 3 14:18:01 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue Jan 3 14:18:10 2006 Subject: [crossfire] Banking system In-Reply-To: <20060103191155.25816.qmail@web32711.mail.mud.yahoo.com> References: <7903f03c0601031016gf874126rc06503702ac1d90e@mail.gmail.com> <20060103191155.25816.qmail@web32711.mail.mud.yahoo.com> Message-ID: <7903f03c0601031218g220adeb8v49be1d9d15a0193d@mail.gmail.com> On 1/3/06, Miguel Ghobangieno wrote: > gold and silver coins are not fiate currencies, their > value can't be just inflated. You need paper money for > that (or money who's value is more then the value of > the material). > > I won't support inflating gold and silver etc. I will > support creating paralell fiat currencies, and yes > they did exist in the ancient world. Ah, but now you have to consider what is actually fluctuating. Is it that the value of gold is dropping, or the value of the currency is increasing. In recent history, it has tended to be the case that fluctuations in the prices of gold/silver etc, have overwhelmingly /not/ taken other prices with them. Just because the US dollar weakens against gold (or if you prefer that gold strengthens against the dollar) doesn't mean that the price of bread alters. Certainly it is fair to say that gold has traditionally been quite consistent with reference to other commodities but silver-backed currencies (and especially silver-backed currencies with a debased coinage, which is what I am describing here, rather than fiat currencies) have fluctuated over time with respect to the price of gold. Whether you make the 'value' field relative to a fixed commodity, or a currency, is really an irrelevant point, once you have the same relationship between them being expressed, however, if we take the consumer's-eye view of the economy, prices are significant relative to wages, which are fixed in a currency, not to a commodity that few of them will ever trade in (plus it involves modifying fewer object values). From mikeeusaa at yahoo.com Tue Jan 3 14:49:01 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 3 15:02:30 2006 Subject: [crossfire] Banking system In-Reply-To: <7903f03c0601031218g220adeb8v49be1d9d15a0193d@mail.gmail.com> Message-ID: <20060103204901.5742.qmail@web32710.mail.mud.yahoo.com> It would be nice to beable to set in for instance: Object goldbar name goldbar weight 10000 value gold Object goldcoin name goldcoin weight 10 (or whatever it is) value gold that way the value will be * by the current value to weight ration (in thiscase 1/1) --- Brendan Lally wrote: > On 1/3/06, Miguel Ghobangieno > wrote: > > gold and silver coins are not fiate currencies, > their > > value can't be just inflated. You need paper money > for > > that (or money who's value is more then the value > of > > the material). > > > > I won't support inflating gold and silver etc. I > will > > support creating paralell fiat currencies, and yes > > they did exist in the ancient world. > > Ah, but now you have to consider what is actually > fluctuating. Is it > that the value of gold is dropping, or the value of > the currency is > increasing. > > In recent history, it has tended to be the case that > fluctuations in > the prices of gold/silver etc, have overwhelmingly > /not/ taken other > prices with them. Just because the US dollar weakens > against gold (or > if you prefer that gold strengthens against the > dollar) doesn't mean > that the price of bread alters. > > Certainly it is fair to say that gold has > traditionally been quite > consistent with reference to other commodities but > silver-backed > currencies (and especially silver-backed currencies > with a debased > coinage, which is what I am describing here, rather > than fiat > currencies) have fluctuated over time with respect > to the price of > gold. > > Whether you make the 'value' field relative to a > fixed commodity, or a > currency, is really an irrelevant point, once you > have the same > relationship between them being expressed, however, > if we take the > consumer's-eye view of the economy, prices are > significant relative to > wages, which are fixed in a currency, not to a > commodity that few of > them will ever trade in (plus it involves modifying > fewer object > values). > > _______________________________________________ > 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 brenlally at gmail.com Tue Jan 3 17:10:42 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue Jan 3 17:12:10 2006 Subject: [crossfire] Banking system In-Reply-To: <20060103204901.5742.qmail@web32710.mail.mud.yahoo.com> References: <7903f03c0601031218g220adeb8v49be1d9d15a0193d@mail.gmail.com> <20060103204901.5742.qmail@web32710.mail.mud.yahoo.com> Message-ID: <7903f03c0601031510r52ada846r9d931c882b3d8fb0@mail.gmail.com> On 1/3/06, Miguel Ghobangieno wrote: > It would be nice to beable to set in for instance: > > Object goldbar > name goldbar > weight 10000 > value gold > > Object goldcoin > name goldcoin > weight 10 (or whatever it is) > value gold > > that way the value will be * by the current value to > weight ration (in thiscase 1/1) This is an interesting idea, and one I hadn't thought of before. Probably for ease of parsing however, it would need to be a new property 'valued_as'? maybe that should be in addition to the value field? For example, a gold necklace might have a fixed value based on the workmanship of the necklace, plus an inherent value based on the weight of the gold. The final value then would be the combination of the two. This would also scale nicely to enchanted weapons and the like. For example a sword could be valued_as steel, with a value of 20 (say) but a sword +1 might have a value of 1000, and a sword -1 a value of -500 (this would require negative values, but allow in principle that a player could make money by melting down cursed items, and reforming them. The questions then become, is it better to hijack the 'material' value for that, and what effect would that have on the things that material is currently used for? From mikeeusaa at yahoo.com Tue Jan 3 15:44:27 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 3 20:19:03 2006 Subject: [crossfire] How do I make an object give damage to the player (this is a carryable object). In-Reply-To: <20060103172059.79929.qmail@web32702.mail.mud.yahoo.com> Message-ID: <20060103214427.28426.qmail@web32710.mail.mud.yahoo.com> Any ideas? How do I make it do damage. Lava does damage... --- Miguel Ghobangieno wrote: > Here is the current object's important parts: > > race gold and jewels > attacktype 4 > dam 5 > speed 0.100000 > color_fg grey > nrof 1 > type 73 > material 2 > identified 1 > editable 2048 > client_type 2005 > > > > It's not doing damage though... > > > > > __________________________________ > 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! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From mikeeusaa at yahoo.com Tue Jan 3 18:57:21 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 3 20:19:06 2006 Subject: [crossfire] Banking system In-Reply-To: <7903f03c0601031510r52ada846r9d931c882b3d8fb0@mail.gmail.com> Message-ID: <20060104005721.7673.qmail@web32707.mail.mud.yahoo.com> :( The value of a gold bar shouldn't be it's setvalue and gold spot combination. It should only be the gold spot. That won't work. Also we shouldn't use the materials thing for value. --- Brendan Lally wrote: > On 1/3/06, Miguel Ghobangieno > wrote: > > It would be nice to beable to set in for instance: > > > > Object goldbar > > name goldbar > > weight 10000 > > value gold > > > > Object goldcoin > > name goldcoin > > weight 10 (or whatever it is) > > value gold > > > > that way the value will be * by the current value > to > > weight ration (in thiscase 1/1) > > This is an interesting idea, and one I hadn't > thought of before. > > Probably for ease of parsing however, it would need > to be a new > property 'valued_as'? > > maybe that should be in addition to the value field? > For example, a > gold necklace might have a fixed value based on the > workmanship of the > necklace, plus an inherent value based on the weight > of the gold. > > The final value then would be the combination of the > two. This would > also scale nicely to enchanted weapons and the like. > > For example a sword could be valued_as steel, with a > value of 20 (say) > > but a sword +1 might have a value of 1000, and a > sword -1 a value of > -500 (this would require negative values, but allow > in principle that > a player could make money by melting down cursed > items, and reforming > them. > > The questions then become, is it better to hijack > the 'material' value > for that, and what effect would that have on the > things that material > is currently used for? > > _______________________________________________ > 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 Tue Jan 3 19:02:37 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 3 20:19:09 2006 Subject: [crossfire] Banking system In-Reply-To: <7903f03c0601031510r52ada846r9d931c882b3d8fb0@mail.gmail.com> Message-ID: <20060104010237.27406.qmail@web32705.mail.mud.yahoo.com> I like my way better. I want to beable to set the value to gold gold14karat this would be looked up and the value computed. That way you could have flucuation gold etc values. if you add a valued_as then value should be ignored completely. etc. (nuggets aren't pure gold, by current weight/value ratio, and that makes sence as they're found just in the wild). --- Brendan Lally wrote: > On 1/3/06, Miguel Ghobangieno > wrote: > > It would be nice to beable to set in for instance: > > > > Object goldbar > > name goldbar > > weight 10000 > > value gold > > > > Object goldcoin > > name goldcoin > > weight 10 (or whatever it is) > > value gold > > > > that way the value will be * by the current value > to > > weight ration (in thiscase 1/1) > > This is an interesting idea, and one I hadn't > thought of before. > > Probably for ease of parsing however, it would need > to be a new > property 'valued_as'? > > maybe that should be in addition to the value field? > For example, a > gold necklace might have a fixed value based on the > workmanship of the > necklace, plus an inherent value based on the weight > of the gold. > > The final value then would be the combination of the > two. This would > also scale nicely to enchanted weapons and the like. > > For example a sword could be valued_as steel, with a > value of 20 (say) > > but a sword +1 might have a value of 1000, and a > sword -1 a value of > -500 (this would require negative values, but allow > in principle that > a player could make money by melting down cursed > items, and reforming > them. > > The questions then become, is it better to hijack > the 'material' value > for that, and what effect would that have on the > things that material > is currently used for? > > _______________________________________________ > 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 brenlally at gmail.com Tue Jan 3 20:29:50 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue Jan 3 20:30:12 2006 Subject: [crossfire] Banking system In-Reply-To: <20060104010237.27406.qmail@web32705.mail.mud.yahoo.com> References: <7903f03c0601031510r52ada846r9d931c882b3d8fb0@mail.gmail.com> <20060104010237.27406.qmail@web32705.mail.mud.yahoo.com> Message-ID: <7903f03c0601031829s14d25fdi27240f72b5fd90c6@mail.gmail.com> On 1/4/06, Miguel Ghobangieno wrote: > this would be looked up and the value computed. That > way you could have flucuation gold etc values. > > if you add a valued_as then value should be ignored > completely. But if you combined the two, it would be useful for many more items. Whilst a gold bar or gold dust would probably have value zero, a cursed gold ring should have that gold value minus an amount representing the badness of the curse - and making it worth melting down - of course the melting process shouldn't be entirely efficiant either.... That would allow both the price of gold bars to vary and the price of gold items to vary too From mwedel at sonic.net Tue Jan 3 22:33:18 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue Jan 3 22:36:10 2006 Subject: [crossfire] How do I make an object give damage to the player (this is a carryable object). In-Reply-To: <20060103214427.28426.qmail@web32710.mail.mud.yahoo.com> References: <20060103214427.28426.qmail@web32710.mail.mud.yahoo.com> Message-ID: <43BB500E.2080001@sonic.net> Miguel Ghobangieno wrote: > Any ideas? How do I make it do damage. Lava does > damage... Other than probably scripting, I don't think there is any way for a carryable object to do damage to a player. > > --- Miguel Ghobangieno wrote: > >> Here is the current object's important parts: >> >> race gold and jewels >> attacktype 4 >> dam 5 >> speed 0.100000 >> color_fg grey >> nrof 1 >> type 73 >> material 2 >> identified 1 >> editable 2048 >> client_type 2005 >> >> >> >> It's not doing damage though... >> >> >> >> >> __________________________________ >> 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! 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 From alex_sch at telus.net Tue Jan 3 23:23:55 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue Jan 3 23:26:09 2006 Subject: [crossfire] How do I make an object give damage to the player (this is a carryable object). In-Reply-To: <20060103214427.28426.qmail@web32710.mail.mud.yahoo.com> References: <20060103214427.28426.qmail@web32710.mail.mud.yahoo.com> Message-ID: <43BB5BEB.2000905@telus.net> Did you have the lava in the inventory while testing? If so, then the only way besides scripting to have an item in the inventory do damage, is by setting it's type to SPELL_EFFECT (something like that I think anyways, can't remember the number). Alex Schultz Miguel Ghobangieno wrote: >Any ideas? How do I make it do damage. Lava does >damage... > >--- Miguel Ghobangieno wrote: > > > >>Here is the current object's important parts: >> >>race gold and jewels >>attacktype 4 >>dam 5 >>speed 0.100000 >>color_fg grey >>nrof 1 >>type 73 >>material 2 >>identified 1 >>editable 2048 >>client_type 2005 >> >> >> >>It's not doing damage though... >> From mikeeusaa at yahoo.com Wed Jan 4 10:04:16 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Wed Jan 4 11:08:19 2006 Subject: [crossfire] How do I make an object give damage to the player (this is a carryable object). In-Reply-To: <43BB500E.2080001@sonic.net> Message-ID: <20060104160416.15332.qmail@web32713.mail.mud.yahoo.com> I guess I'll have to make a script then. But I don't know how. Could ... someone... make a quick python script that looks at the speed of the object and the dam of the object and the attacktype and damages the player thusly ever (speed) for (dam) of (damtype) ? --- Mark Wedel wrote: > Miguel Ghobangieno wrote: > > Any ideas? How do I make it do damage. Lava does > > damage... > > Other than probably scripting, I don't think there > is any way for a carryable > object to do damage to a player. > > > > > > --- Miguel Ghobangieno > wrote: > > > >> Here is the current object's important parts: > >> > >> race gold and jewels > >> attacktype 4 > >> dam 5 > >> speed 0.100000 > >> color_fg grey > >> nrof 1 > >> type 73 > >> material 2 > >> identified 1 > >> editable 2048 > >> client_type 2005 > >> > >> > >> > >> It's not doing damage though... > >> > >> > >> > >> > >> __________________________________ > >> 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! 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 > > > _______________________________________________ > 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 Wed Jan 4 10:06:51 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Wed Jan 4 11:08:22 2006 Subject: [crossfire] Banking system In-Reply-To: <7903f03c0601031829s14d25fdi27240f72b5fd90c6@mail.gmail.com> Message-ID: <20060104160651.24137.qmail@web32707.mail.mud.yahoo.com> Oh that sounds good. I'd also like to have valued_as gold18k, gold14k, and gold10k (nuggets are not pure gold by weight as it is (good idea IMHO, makes sence), so we need those aswell). gold18k etc should be computed by gold/(whatever it's ratio is). --- Brendan Lally wrote: > On 1/4/06, Miguel Ghobangieno > wrote: > > this would be looked up and the value computed. > That > > way you could have flucuation gold etc values. > > > > if you add a valued_as then value should be > ignored > > completely. > > But if you combined the two, it would be useful for > many more items. > Whilst a gold bar or gold dust would probably have > value zero, a > cursed gold ring should have that gold value minus > an amount > representing the badness of the curse - and making > it worth melting > down - of course the melting process shouldn't be > entirely efficiant > either.... > > That would allow both the price of gold bars to vary > and the price of > gold items to vary too > > _______________________________________________ > 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 brenlally at gmail.com Wed Jan 4 11:49:32 2006 From: brenlally at gmail.com (Brendan Lally) Date: Wed Jan 4 11:50:11 2006 Subject: [crossfire] How do I make an object give damage to the player (this is a carryable object). In-Reply-To: <20060104160416.15332.qmail@web32713.mail.mud.yahoo.com> References: <43BB500E.2080001@sonic.net> <20060104160416.15332.qmail@web32713.mail.mud.yahoo.com> Message-ID: <7903f03c0601040949n4eaada63o2cf1c95ac50a3621@mail.gmail.com> On 1/4/06, Miguel Ghobangieno wrote: > I guess I'll have to make a script then. > But I don't know how. > Could ... someone... make a quick python script that > looks at the speed of the object and the dam of the > object and the attacktype and damages the player > thusly ever (speed) for (dam) of (damtype) ? One thing you might be able to do, is create an object that decays after a short time (food = 1 or 2) and which has a treasure list containing itself, and a bullet (or something appropriate) that can do damage to the player on creation. This would continously damage the player, creating a new version each time. It is a bit of a hack however. From brenlally at gmail.com Thu Jan 5 22:01:58 2006 From: brenlally at gmail.com (Brendan Lally) Date: Thu Jan 5 22:02:11 2006 Subject: [crossfire] requestable spell lists. In-Reply-To: <43A6565C.8080204@sonic.net> References: <1134836084.c7d9c5dcyann.chachkoff@myrealbox.com> <43A6565C.8080204@sonic.net> Message-ID: <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> It took a little while, but I've now gone and implemented most of the suggestions from earlier in this thread. The server now sends the data in binary form, as well as a couple of other changes. The tracker item mentioned previously has had the associated patch uploaded. what follows is culled directly from my proposed change to doc/Developers/protocol. I propose: That there be a new setup option: + spellmon (0/1) + If set to 1 the client has indicated that it wishes to be + sent the spell list and updated when it changes. That the stats command additionally has: + -spell paths: if spellmon is set in setup, the bitmask of attuned, + repelled and denied paths is sent. These are all 32bits That the request_info command may additionally cope with: + spell_paths (no parameters) + This returns a list of all spell paths in the game, along with the + number associated with them. This should be used to parse spell_path + data in the stats command. The number is a bitmask but is sent as a + decimal value. + + All data is sent in text format. Format is: + number:name ! eg + 16:missiles That there be new commands as follows: S->C addspell + + Tells the client to add the spell(s) listed to the list of spells + the client knows about. This will be sent at login, and again whenever + new spells are sent. + + The fields are; + - (4 bytes - int) The ID number for the spell item. This is + going to be unique, for each spell and will be used to refer + to it henceforth. + + (2 bytes, signed int) + The level of the spell. + + (2 bytes, signed int) + The time it will take to cast the spell, in server ticks. + + (2 bytes, signed int) + The mana cost to cast the spell (may be zero) + + (2 bytes, signed int) + The grace cost to cast the spell (may be zero) + + (2 bytes, signed int) + The current damage done by the spell. Note that the meaning of + this number is to a large part spell dependent, what damage it + actually does will depend on how the spell works. + + (1 byte, unsigned int) + The skill that the spell uses to be cast, if zero, no skill is + used in the casting of this spell. + The numbers are the same as for request_info skill_info + + (4 bytes, unsigned integer) + The path that the spell belongs to. + The client should determine the effect of this by comparing + these values to both the spell_paths request_info data and the + stats info concerning attunement/repulsion, etc. + + (1 (non-zero) length byte, followed by that many bytes of ascii text) + This is the name of the spell, and should be sent to the server + in order to cast/invoke it. + + (1 length byte (which may be zero) followed by that + many bytes of ascii text) + This is the name to display to the player regarding the spell. + If length is zero, then the should be used instead. + + (2 length bytes (which may be zero) followed by that many + bytes of ascii text) + The description of the spell. Note that this has an extra length + byte because the messages may well be longer than 256 bytes in + length. + + S->C updspell + + + This updates some spell (of tag) with new values. The flags are 1 byte + and determine which values have been updated, and should be re-read. + Not all fields may be updated by this command, only those that can be + changed. + + If new fields are added in future, they will extend the flags bitmask + and the order will remain the LSB order of the flags - that is, the + value associated with bit 1 set is sent first, then bit 2, etc. + + The format of the values is same as the addspell command above. + + Only one spell can be updated with the updspell command. A spell + command should have been sent by the server before an updspell + command is set. + + S->C delspell + Tells the client to remove its information about the spell Tag is a 4 + byte value, the same as the one sent when the spell was added. Currently the checks for spell updates are in level_adjust and in fix_player, I think that covers any way for spells or damage to change, if I am missing any, please let me know. Other than that, please reply with comments/criticisms/suggestions/flames etc From mwedel at sonic.net Thu Jan 5 23:10:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 5 23:14:12 2006 Subject: [crossfire] requestable spell lists. In-Reply-To: <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> References: <1134836084.c7d9c5dcyann.chachkoff@myrealbox.com> <43A6565C.8080204@sonic.net> <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> Message-ID: <43BDFBDC.40907@sonic.net> Brendan Lally wrote: > It took a little while, but I've now gone and implemented most of the > suggestions from earlier in this thread. The server now sends the data > in binary form, as well as a couple of other changes. The tracker item > mentioned previously has had the associated patch uploaded. All looks good - just a one minor question: > + (1 (non-zero) length byte, followed by that many bytes > of ascii text) > + This is the name of the spell, and should be sent to the server > + in order to cast/invoke it. > + > + (1 length byte (which may be zero) followed by that > + many bytes of ascii text) > + This is the name to display to the player regarding the spell. > + If length is zero, then the should be used instead. Just curious what these these two names are far. As far as I know right now, each spell only has one name, so not sure why there are two. As an aside - it doesn't need to be part of this patch, but it might be nice to have the cast/invoke command be able to tag a numeric value instead of string name, eg: cast 12345 Which casts the spell associated with tag 12345. This provides a slightly more efficient way of the client communicating to the server what spell to cast, and also provides a fairly good optimized way for the server to find the spell (doesn't have to worry about duplicates - just has to see if an item with that tag exists in the inventory (of which there is already code that does it) and verify it is of type spell. From mikeeusaa at yahoo.com Thu Jan 5 23:25:15 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Thu Jan 5 23:31:34 2006 Subject: [crossfire] Lalo's Bigworld pupland :D In-Reply-To: <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> Message-ID: <20060106052515.73431.qmail@web32710.mail.mud.yahoo.com> http://cavetroll.uwcs.co.uk/pupland-new.png Looking great! One note: it would probably be best to put that in /maps/puplandworld as we have a /maps/world and a /maps/underworld (/me wishes an underworld was generated.. if he hacks the land.c to make one... should he? ). Pupland won't fit on the worldmap, which, IMHO, is fine as I've always thought of it as another contenent. We could connect /world and /puplandworld via a sliver of ocean, similar to how the elves in LOTR got back to their homeworld. I'm willing to do that part if wanted. Now pupland wouldn't have weather :( (as the weather code would have to beable to take into account other world areas). However the current pupland has no weather either (such a pristine landscape) Maybe it is a magical kingdom or something. If the weather system is overhauled it would be good to beable to set diff weather setting on diffrent /maps/*world s For instance maybe world would be set to lvl 5 while puplandworld was set to lvl 2 (so it gets rain, but it's land stays pristine). Nice job lalo btw :) __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From lalo.martins at gmail.com Fri Jan 6 05:15:42 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri Jan 6 05:16:13 2006 Subject: [crossfire] Re: Lalo's Bigworld pupland :D In-Reply-To: <20060106052515.73431.qmail@web32710.mail.mud.yahoo.com> References: <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> <20060106052515.73431.qmail@web32710.mail.mud.yahoo.com> Message-ID: And so says Miguel Ghobangieno on 06/01/06 13:25... > Pupland won't fit on the worldmap, which, IMHO, is fine as I've > always thought of it as another contenent. It is in another continent, and it is in the worldmap. There is a reason why the worldmap starts at 100_100 :-) if you read the info in maps/Info, you'll see mwedel's idea of how big the world could potentially be. Right now, my Pupland is in tiles world_075_023 to world_104_032, so, northwest of the Scorn continent. (In the previous thread we had about geography, I think we agreed that the Scorn continent is in the southern hemisphere, so this one is in the north.) So there is weather, but, hmm, :-) I put it on northwest because I thought the "poles" were on NE and SW, so this wouldn't affect the weather on the other continent too bad. But it turns out, seemingly, the "poles" are on NW and SE instead, which puts Lone Town pretty near one of them. This is not what I intended. I could move it to the NE, but then that would break the antarctic. So I see two options: 1. leave it where I put it; this will make things in the NW of the existing continent warmer than they are now, and things in the SE colder - notably Navar. Lone Town will be a very cold place. Well, that may explain why it's so Lone :-P I'm running the scripts from cfmaps.schmorp.de as I write this, when I have a browsable version of the "old continent", I'll post the url here. The reason I don't like this one so much, is because the Rainbow Islands are supposed to be tropical, or at least warm temperate - they are a beach/vacation resort after all. 2. change the weather code to put the poles somewhere more reasonable. We could be very revolutionary and put it, oh, I don't know, in the north and south? Or follow Exalted, rule that one direction (S or E?) is cold, another (N or W?) is warm, and the world is really flat, or even cylindrical. Or, my personal favorite, a reverse-discworld approach - the world is flat (rectangular or discoid) or even cylindrical, the outer edges are cold, the middle is warm. Any of these would require small changes to the weather system; not only to change the poles, but also (and almost more importantly), to know exactly how big the world is, and fill any tiles it has no map for with deep ocean. I believe I could do that without breaking the code too much. (Alternatively, just generate actual maps filled with deep ocean, this gives us the bonus of having more varied elevation.) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From won_fang at yahoo.com.au Fri Jan 6 05:58:29 2006 From: won_fang at yahoo.com.au (David Seikel) Date: Fri Jan 6 05:56:13 2006 Subject: [crossfire] Ice Castle up for grabs. Message-ID: <20060106215829.1dc7331b@cluster.meeting.humbug.org.au> I really should have done this a long time ago. I vaguely recall announcing that my life was too busy to do any Crossfire work some time ago. The situation is the same, and I haven't even had time to patch up the Ice Castle and hand it to someone. So I've dumped it to a server, and who ever wants it can take over ownership of it. If no one wants it, feel free to steal stuff from it, as there are some interesting things in it. There is an IceCastle.txt file with some notes about what needs fixing and stuff. http://matrix-rad.net/IceCastle.tar.bz2 -- Stuff I have no control over could be added after this line. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060106/97d5a163/attachment.pgp From brenlally at gmail.com Fri Jan 6 08:09:25 2006 From: brenlally at gmail.com (Brendan Lally) Date: Fri Jan 6 08:10:13 2006 Subject: [crossfire] requestable spell lists. In-Reply-To: <43BDFBDC.40907@sonic.net> References: <1134836084.c7d9c5dcyann.chachkoff@myrealbox.com> <43A6565C.8080204@sonic.net> <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> <43BDFBDC.40907@sonic.net> Message-ID: <7903f03c0601060609y3e44b45aq9d8f21335b1e8d81@mail.gmail.com> On 1/6/06, Mark Wedel wrote: > All looks good - just a one minor question: > > > + (1 (non-zero) length byte, followed by that many bytes > > of ascii text) > > + This is the name of the spell, and should be sent to the server > > + in order to cast/invoke it. > > + > > + (1 length byte (which may be zero) followed by that > > + many bytes of ascii text) > > + This is the name to display to the player regarding the spell. > > + If length is zero, then the should be used instead. > > Just curious what these these two names are far. As far as I know right now, > each spell only has one name, so not sure why there are two. gros wanted a way to do it, I think the reasoning was that there could be the 'internal' name of the spell, and a more flavourful display name. Currently I have it set up to send the name and then name_pl as the display name, but only if it is 1) present 2) different from name. I could of course use a different field instead ('title' maybe?) > As an aside - it doesn't need to be part of this patch, but it might be nice > to have the cast/invoke command be able to tag a numeric value instead of string > name, eg: > > cast 12345 > > Which casts the spell associated with tag 12345. This provides a slightly > more efficient way of the client communicating to the server what spell to cast, > and also provides a fairly good optimized way for the server to find the spell > (doesn't have to worry about duplicates - just has to see if an item with that > tag exists in the inventory (of which there is already code that does it) and > verify it is of type spell. This could be done quite easily, although to not break older clients, it would have to be the case that no spell names currently start with a number. I believe this is the case however. one other point, should I send the face number (if there is one) too? From mikeeusaa at yahoo.com Fri Jan 6 09:56:18 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Fri Jan 6 11:34:21 2006 Subject: [crossfire] Re: Lalo's Bigworld pupland :D In-Reply-To: Message-ID: <20060106155618.58925.qmail@web32706.mail.mud.yahoo.com> I strongly prefer keeping the poles as is. As they are now they are at poles on the map. If you're going to add to the magnetic north of the contenet(spelling error) could you also add water to the west so we keep having a square map. Having parts of pupland cold doesn't bother me much... what you could do is shift the important parts magnetic east. There are beach/vacation resorts in new jersy for some reason, even though it gets cold sometimes. Also could you test to make sure weather 5 works well etc (including the generated pictures). It may need a little revamp to recognise the new stuff. Crossfire's world, if it even is round, has it's axis at 45 degrees but it's magnetic north at 0 degrees. The old empire relied heavily on compasses, a technology first imported from the conqured region of Navar (navar was an outlying province then... they broke away since... like most areas). Magnetic north came to be known as simply "north". People usually don't venture into the strange super cold regions of the world, and take little note of true north. --- Lalo Martins wrote: > And so says Miguel Ghobangieno on 06/01/06 13:25... > > Pupland won't fit on the worldmap, which, IMHO, is > fine as I've > > always thought of it as another contenent. > > It is in another continent, and it is in the > worldmap. There is a > reason why the worldmap starts at 100_100 :-) if you > read the info in > maps/Info, you'll see mwedel's idea of how big the > world could > potentially be. > > Right now, my Pupland is in tiles world_075_023 to > world_104_032, so, > northwest of the Scorn continent. (In the previous > thread we had about > geography, I think we agreed that the Scorn > continent is in the southern > hemisphere, so this one is in the north.) > > So there is weather, but, hmm, :-) > > I put it on northwest because I thought the "poles" > were on NE and SW, > so this wouldn't affect the weather on the other > continent too bad. But > it turns out, seemingly, the "poles" are on NW and > SE instead, which > puts Lone Town pretty near one of them. This is not > what I intended. > > I could move it to the NE, but then that would break > the antarctic. > > So I see two options: > > 1. leave it where I put it; this will make things in > the NW of the > existing continent warmer than they are now, and > things in the SE colder > - notably Navar. Lone Town will be a very cold > place. Well, that may > explain why it's so Lone :-P > > I'm running the scripts from cfmaps.schmorp.de as I > write this, when I > have a browsable version of the "old continent", > I'll post the url here. > > The reason I don't like this one so much, is because > the Rainbow Islands > are supposed to be tropical, or at least warm > temperate - they are a > beach/vacation resort after all. > > 2. change the weather code to put the poles > somewhere more reasonable. > We could be very revolutionary and put it, oh, I > don't know, in the > north and south? Or follow Exalted, rule that one > direction (S or E?) > is cold, another (N or W?) is warm, and the world is > really flat, or > even cylindrical. Or, my personal favorite, a > reverse-discworld > approach - the world is flat (rectangular or > discoid) or even > cylindrical, the outer edges are cold, the middle is > warm. > > Any of these would require small changes to the > weather system; not only > to change the poles, but also (and almost more > importantly), to know > exactly how big the world is, and fill any tiles it > has no map for with > deep ocean. I believe I could do that without > breaking the code too > much. (Alternatively, just generate actual maps > filled with deep ocean, > this gives us the bonus of having more varied > elevation.) > > best, > Lalo > Martins > -- > So many of our dreams at first seem > impossible, > then they seem improbable, and then, when we > summon the will, they soon become inevitable. > -- > personal: > http://www.laranja.org/ > technical: > http://lalo.revisioncontrol.net/ > GNU: never give up freedom > http://www.gnu.org/ > > > _______________________________________________ > crossfire mailing list > crossfire@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 lalo.martins at gmail.com Fri Jan 6 20:30:25 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri Jan 6 20:32:14 2006 Subject: [crossfire] Re: Lalo's Bigworld pupland :D In-Reply-To: <20060106155618.58925.qmail@web32706.mail.mud.yahoo.com> References: <20060106155618.58925.qmail@web32706.mail.mud.yahoo.com> Message-ID: And so says Miguel Ghobangieno on 06/01/06 23:56... > I strongly prefer keeping the poles as is. As they are > now they are at poles on the map. You're missing a somewhat important point that has already been established: the existing landmass is a continent, or even an island, and not the entire planet. In that aspect, the weather system is broken to consider it the whole planet. A size that would be probably good is 150x150 squares, which leaves the current continent in the southern temperate zone. So if the code has to be changed anyway, it can be "fixed" in terms of putting the poles somewhere that makes more sense. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Fri Jan 6 20:38:17 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri Jan 6 20:40:03 2006 Subject: [crossfire] Re: Lalo's Bigworld pupland :D In-Reply-To: References: <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> <20060106052515.73431.qmail@web32710.mail.mud.yahoo.com> Message-ID: here's the previous thread we had on that topic: http://shadowknight.real-time.com/pipermail/crossfire/2005-November/thread.html#9667 best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From lalo.martins at gmail.com Fri Jan 6 21:12:49 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Fri Jan 6 21:25:40 2006 Subject: [crossfire] Re: Lalo's Bigworld pupland :D In-Reply-To: <20060107025001.62177.qmail@web32710.mail.mud.yahoo.com> References: <20060107025001.62177.qmail@web32710.mail.mud.yahoo.com> Message-ID: On 1/7/06, Miguel Ghobangieno wrote: > > The point of the poles has been established in the > code, I think the code speaks more loudly then any > musings that may have happened. The code, however, is incomplete, and it says so both on the source and the documentation. And it's based on an incorrect assumption, that needs to be fixed. It would be rather considerate of you if you did not > muck up where the poles are (45 degrees) as other maps > (esp maps I have made) take into account where the > weather is). I'm sorry, but the maps are wrong to take that into account, when the code clearly says it's incomplete. I for one do appreciate your effort. But we can't keep broken code around just because fixing it would mean you don't have to update your maps. If you really want to contribute, that means adding new things, but occasionally it also means modifying your existing things to cope with improvements to the game - that's what is called "maintaining". Moving the Antarctic would probably make it a better map - further away from the inhabited continent, where it makes sense, specially when ships are introduced and you can sail the ocean. You'd even be able to make it bigger. Heck, make a whole small continent, why not? best, Lalo Martins -- Those who trade freedom for security lose both and deserve neither. -- http://www.laranja.org/ mailto:lalo.martins@gmail.com pgp key: http://www.laranja.org/pessoal/pgp GNU: never give up freedom http://www.gnu.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060107/730cfcc6/attachment.htm From mikeeusaa at yahoo.com Fri Jan 6 21:33:23 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Fri Jan 6 21:42:29 2006 Subject: [crossfire] Re: Lalo's Bigworld pupland :D In-Reply-To: Message-ID: <20060107033323.99885.qmail@web32715.mail.mud.yahoo.com> I have no problem with the world expanding and antartica moving down more, however I like the 45 degree poles. I would like to keep that. --- Lalo Martins wrote: > On 1/7/06, Miguel Ghobangieno > wrote: > > > > The point of the poles has been established in the > > code, I think the code speaks more loudly then any > > musings that may have happened. > > > The code, however, is incomplete, and it says so > both on the source and the > documentation. And it's based on an incorrect > assumption, that needs to be > fixed. > > It would be rather considerate of you if you did not > > muck up where the poles are (45 degrees) as other > maps > > (esp maps I have made) take into account where the > > weather is). > > > I'm sorry, but the maps are wrong to take that into > account, when the code > clearly says it's incomplete. > > I for one do appreciate your effort. But we can't > keep broken code around > just because fixing it would mean you don't have to > update your maps. If > you really want to contribute, that means adding new > things, but > occasionally it also means modifying your existing > things to cope with > improvements to the game - that's what is called > "maintaining". > > Moving the Antarctic would probably make it a better > map - further away from > the inhabited continent, where it makes sense, > specially when ships are > introduced and you can sail the ocean. You'd even > be able to make it > bigger. Heck, make a whole small continent, why > not? > > best, > Lalo > Martins > -- > Those who trade freedom for security > lose both and deserve neither. > -- > http://www.laranja.org/ > mailto:lalo.martins@gmail.com > pgp key: http://www.laranja.org/pessoal/pgp > > GNU: never give up freedom > http://www.gnu.org/ > > _______________________________________________ > 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 Fri Jan 6 23:29:45 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat Jan 7 00:22:33 2006 Subject: [crossfire] requestable spell lists. In-Reply-To: <7903f03c0601060609y3e44b45aq9d8f21335b1e8d81@mail.gmail.com> References: <1134836084.c7d9c5dcyann.chachkoff@myrealbox.com> <43A6565C.8080204@sonic.net> <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> <43BDFBDC.40907@sonic.net> <7903f03c0601060609y3e44b45aq9d8f21335b1e8d81@mail.gmail.com> Message-ID: <43BF51C9.6000604@sonic.net> Brendan Lally wrote: > On 1/6/06, Mark Wedel wrote: >> All looks good - just a one minor question: >> >>> + (1 (non-zero) length byte, followed by that many bytes >>> of ascii text) >>> + This is the name of the spell, and should be sent to the server >>> + in order to cast/invoke it. >>> + >>> + (1 length byte (which may be zero) followed by that >>> + many bytes of ascii text) >>> + This is the name to display to the player regarding the spell. >>> + If length is zero, then the should be used instead. >> Just curious what these these two names are far. As far as I know right now, >> each spell only has one name, so not sure why there are two. > > gros wanted a way to do it, I think the reasoning was that there could > be the 'internal' name of the spell, and a more flavourful display > name. > > Currently I have it set up to send the name and then name_pl as the > display name, but only if it is > 1) present > 2) different from name. > > I could of course use a different field instead ('title' maybe?) Ok. I wonder if we should just not worry about it until there is actually a case where it is used (unless there is something on the drawing board right now?) As otherwise, we start going down the path of including all sorts of fields in all sorts of commands because they could be useful at some point - designing for that just becomes more complicated. In some sense, because it also comes down to what does the client do with this info? Unless there is a clear idea where this info comes from and how it will be used, it just seems like we shouldn't include it until we know that point. Otherwise, I can see the client not doing the right thing with it, so when it does become time to actually use that info for some purpose, the client needs to be updated to use it. At which point the question is - why not just wait until that point. > >> As an aside - it doesn't need to be part of this patch, but it might be nice >> to have the cast/invoke command be able to tag a numeric value instead of string >> name, eg: >> >> cast 12345 >> >> Which casts the spell associated with tag 12345. This provides a slightly >> more efficient way of the client communicating to the server what spell to cast, >> and also provides a fairly good optimized way for the server to find the spell >> (doesn't have to worry about duplicates - just has to see if an item with that >> tag exists in the inventory (of which there is already code that does it) and >> verify it is of type spell. > > This could be done quite easily, although to not break older clients, > it would have to be the case that no spell names currently start with > a number. I believe this is the case however. I believe that is the case also, and putting that in as rule would I think be fine. > > one other point, should I send the face number (if there is one) too? I'd say yes - I'm not sure how many spells have good icons set, but I could see it as being nice for the client using the icons in pull down menus/whatever to denote the spells. From mwedel at sonic.net Fri Jan 6 23:50:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat Jan 7 00:22:36 2006 Subject: Weather, was Re: [crossfire] Re: Lalo's Bigworld pupland :D In-Reply-To: References: <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> <20060106052515.73431.qmail@web32710.mail.mud.yahoo.com> Message-ID: <43BF56BC.3040305@sonic.net> I personally don't have much an issue with the poles being on a diagonal vs true vertical - a little odd, but whatever. That said, as far as weather goes, it may then be nice to be able to specify the theoretical location of the poles, even if a map for them doesn't exist. For example, it is somewhat obvious that the northwest pole should be at world_000_000 - simply because you can't go farther away than that. But there isn't any reason to make the hundreds of maps to fill that gap. The southeast pole gets odd/more complicated. IT depends to some extent if the world wraps around (if I sail east enough, does it wrap around west? What about north/south)? Because if we say the highest map would be world_150_150, those questions determine where the southeast pole should be. If you can say around the world east/west, than that pole should probably be at world_075_150, otherwise the poles on the axis don't work. If you can say around north/south as well as east/west, then you'd want the south pole at 75,75. Personally, I'm more inclined to think of the world as an infinite plan. That allows infinite expansion, and gets rid of any odd issues regarding world wrapping and compression you should really get. But in that model, it then makes sense to have bands of temperature - for example, at world_x_130 (far south) would be a band of ice/cold/whatever, but if we had a world_x_180, it might be nice that far down (starts to get warmer). In that model, I think it'd be much easier to deal with the bands being either horizontal or vertical than diagonal. Just from a mapmaker perspective, it is much easier to see that if the y coordinate of your map is in the 130 range, it should be cold - you shouldn't have to plot the odd diagonals (ok, the poles are here, which means this line here is cold, etc). The other reason for this is that as the world map grows, having bands make things a lot easier - the 130 area is always cold, no matter what the x range is (0 to 500). In comparison, as Lalo discovers, if you do poles, then as the world grows, those poles will get relocated again, causing yet another climate shift. The only way to prevent that is choose poles right now that are so far off they would never be moved - the problem with that is that if we say choose 0,0 and 500,500, the existing world area only occupies a small area of that overall space, and thus the weather it has wouldn't vary much. From brenlally at gmail.com Sat Jan 7 07:52:00 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sat Jan 7 13:19:00 2006 Subject: [crossfire] requestable spell lists. In-Reply-To: <43BF51C9.6000604@sonic.net> References: <1134836084.c7d9c5dcyann.chachkoff@myrealbox.com> <43A6565C.8080204@sonic.net> <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> <43BDFBDC.40907@sonic.net> <7903f03c0601060609y3e44b45aq9d8f21335b1e8d81@mail.gmail.com> <43BF51C9.6000604@sonic.net> Message-ID: <7903f03c0601070552o68a6287awc68f6bce7cfda75b@mail.gmail.com> On 1/7/06, Mark Wedel wrote: > Brendan Lally wrote: > > Currently I have it set up to send the name and then name_pl as the > > display name, but only if it is > > 1) present > > 2) different from name. > > > > I could of course use a different field instead ('title' maybe?) > > Ok. I wonder if we should just not worry about it until there is actually a > case where it is used (unless there is something on the drawing board right > now?) As otherwise, we start going down the path of including all sorts of > fields in all sorts of commands because they could be useful at some point - > designing for that just becomes more complicated. ok then, If I make spellcasting by number part of the same patch, then the protocol can specify that the client should use the number to cast spells with, rather than the name. At that point what name is sent doesn't much matter, as long as the client handles them according to spec. From lalo.martins at gmail.com Sat Jan 7 07:39:30 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat Jan 7 13:19:10 2006 Subject: [crossfire] Re: Weather, was Re: Re: Lalo's Bigworld pupland :D In-Reply-To: <43BF56BC.3040305@sonic.net> References: <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> <20060106052515.73431.qmail@web32710.mail.mud.yahoo.com> <43BF56BC.3040305@sonic.net> Message-ID: And so says Mark Wedel on 07/01/06 13:50... > Personally, I'm more inclined to think of the world as an infinite > plan. That allows infinite expansion, and gets rid of any odd issues > regarding world wrapping and compression you should really get. > > But in that model, it then makes sense to have bands of temperature - > for example, at world_x_130 (far south) would be a band of > ice/cold/whatever, but if we had a world_x_180, it might be nice that > far down (starts to get warmer). /me puts his fantasy writer hat Ok, here is one neat proposal. Oddly enough, nothing I have ever seen in-game mentions a sun. So, the world is an infinite plan. 0,0 is an arbitrary point, probably the further NW that the sailors of the Old Empire ever sailed. Light/heat sources are a number of fixed points in the sky (or on the top of high mountains even!). For reasons that the mages and priests spend their lives debating, their light goes off once a day (for the night), and it follows a cycle of strenghtening and weakening over a longer period that became known as an year. (The days have the same length on all known light sources. The seasons could be different if we wanted, but that's probably unnecessary complication on the weather code.) So each continent has one or more "suns" independent of the others. The reason we don't sail much between continents is that it's too cold, the water freezes, and even magic won't work. Only extremely skilled sailors with the help of extremely skilled mages can find the routes - like the navy of the Old Empire. (Oddly enough, spells of "teleportation" style work across these distances, so word of recall, town portal, etc isn't affected - this probably explains how the dragon hangars and Pupland transport work.) /me takes off the writer hat Codewise: any tile not mapped will be defaulted by the weather system to a large sheet of ice, which blocks spells, damned. Gamewise, we pick an arbitrary point of the existing continent. Personally, I kind of like the idea of putting the "sun" on the top of a high mountain, so somewhere to the northwest of the big range in the middle of the continent would be best - most places keep more or less the same climate, and even the Antarctic doesn't require moving. As for "my" continent, I'll take a good look at it and decide where to put the light source(s). best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From mikeeusaa at yahoo.com Sat Jan 7 22:04:30 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sat Jan 7 23:21:38 2006 Subject: [crossfire] Crossfire nolonger compiles Message-ID: <20060108040430.22991.qmail@web32711.mail.mud.yahoo.com> ranlib .libs/cfanim.a creating cfanim.la (cd .libs && rm -f cfanim.la && ln -s ../cfanim.la cfanim.la) make[2]: Leaving directory `/home/cfserver/cvs/crossfire/plugins/cfanim' make[2]: Entering directory `/home/cfserver/cvs/crossfire/plugins' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/home/cfserver/cvs/crossfire/plugins' make[1]: Leaving directory `/home/cfserver/cvs/crossfire/plugins' Making all in devel make[1]: Entering directory `/home/cfserver/cvs/crossfire/devel' gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -DDATADIR=\"/home/cfserver/cfservernew/share/crossfire\" -DCONFDIR=\"/home/cfserver/cfservernew/etc/crossfire\" -DLIBDIR=\"/home/cfserver/cfservernew/lib/crossfire\" -DLOCALDIR=\"/home/cfserver/cfservernew/var/crossfire\" -DPLUGIN_SUFFIX=\".so\" -g -O2 -c devel.c /bin/sh ../libtool --mode=link gcc -g -O2 -o crossfire-config devel.o -lcrypt -lm -lnsl mkdir .libs gcc -g -O2 -o crossfire-config devel.o -lcrypt -lm -lnsl make[1]: Leaving directory `/home/cfserver/cvs/crossfire/devel' Making all in crossedit make[1]: Entering directory `/home/cfserver/cvs/crossfire/crossedit' Making all in include make[2]: Entering directory `/home/cfserver/cvs/crossfire/crossedit/include' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/cfserver/cvs/crossfire/crossedit/include' Making all in Cnv make[2]: Entering directory `/home/cfserver/cvs/crossfire/crossedit/Cnv' gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvUtil.c gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvBrowse.c gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvNotify.c gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvMenu.c gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvFiles.c gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvPath.c gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I./../include -I../../include -g -O2 -c CnvPrompt.c CnvPrompt.c: In function `CnvPromptCb': CnvPrompt.c:37: parse error before `char' CnvPrompt.c:38: `t' undeclared (first use in this function) CnvPrompt.c:38: (Each undeclared identifier is reported only once CnvPrompt.c:38: for each function it appears in.) make[2]: *** [CnvPrompt.o] Error 1 make[2]: Leaving directory `/home/cfserver/cvs/crossfire/crossedit/Cnv' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cfserver/cvs/crossfire/crossedit' make: *** [all-recursive] Error 1 Filed bug report at http://sourceforge.net/tracker/index.php?func=detail&aid=1399546&group_id=13833&atid=113833 Also crossfire server crashes if a player enters four random maps in quick succession. http://sourceforge.net/tracker/index.php?func=detail&aid=1398239&group_id=13833&atid=113833 __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mikeeusaa at yahoo.com Sun Jan 8 00:02:51 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 8 00:44:10 2006 Subject: [crossfire] ...shouldn't one get drunk from wine and booze in CF? Message-ID: <20060108060251.65884.qmail@web32708.mail.mud.yahoo.com> ...shouldn't one get drunk from wine and booze in CF? mikee1988098048 (perhapse a intoxication var which can be 0 - 200 (ie: proof), .. or 0 - 100 (percentage of alcahol(sp), then you could use int8 and save some bytes) Rednaxela I think drunkeness would be a neat addition to crossfire =P mikee1988098048 I'd like if it would slur your speech depending on how drunk you were mikee1988098048 like when you did mikee1988098048 say mikee1988098048 or shout mikee1988098048 or tell mikee1988098048 etc mikee1988098048 it would make it sound drunk mikee1988098048 and if you got really drunk you would walk like you were confused mikee1988098048 (and throw up) Rednaxela Yeah XD Rednaxela drunkenness could be implimented as a non-contagious disease that one can't gain immunity to mikee1988098048 yes mikee1988098048 but that's alittle hacky Rednaxela True, but it would work mikee1988098048 since you shouldn't get it after 1 wine or beer mikee1988098048 should only get it after a few mikee1988098048 (and more then a few if your food is full (full stomach)) Rednaxela It might be possible to make only a certain precent of the bottles have the disease, but that wouldn't simulate the cumlative effect mikee1988098048 couldn't the key-value thing be used for the intoxication var Rednaxela So yeah, as it's own feature would probably work nicer mikee1988098048 or maybe it should be called alchpercent mikee1988098048 alchaholpercent rather, as alch could be confused with alchemy Rednaxela it could __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From kirschbaum at myrealbox.com Sun Jan 8 06:14:08 2006 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun Jan 8 06:14:14 2006 Subject: [crossfire] Crossfire nolonger compiles In-Reply-To: <20060108040430.22991.qmail@web32711.mail.mud.yahoo.com> References: <20060108040430.22991.qmail@web32711.mail.mud.yahoo.com> Message-ID: <20060108121408.GA12095@kirschbaum.myrealbox.com> Miguel Ghobangieno wrote: [...] > Filed bug report at > http://sourceforge.net/tracker/index.php?func=detail&aid=1399546&group_id=13833&atid=113833 > > Also crossfire server crashes if a player enters four > random maps in quick succession. > http://sourceforge.net/tracker/index.php?func=detail&aid=1398239&group_id=13833&atid=113833 Please do not duplicate these bug reports here. It is not useful because developers automatically receive a mail whenever a tracker item was added or modified. From kirschbaum at myrealbox.com Sun Jan 8 08:50:58 2006 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun Jan 8 08:52:17 2006 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: client In-Reply-To: References: Message-ID: <20060108145058.GA16083@kirschbaum.myrealbox.com> crossfire-cvs-admin@lists.sourceforge.net wrote: > Module Name: client > Committed By: ryo_saeba > Date: Tue Dec 27 14:26:29 UTC 2005 [...] > Log Message: > Make nrof uint32, like server-side. Fix a crash with get_number. [...] > ! char *get_number(uint32 i) { [...] > + if(i<0) > + { > + sprintf(buf,"negative"); > + return buf; > + } This check does not make sense to me: the variable i is a unsigned variable. Therefore the value never is negative, hence this code will never be executed. From nicolas.weeger at laposte.net Sun Jan 8 12:25:25 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Jan 8 12:26:15 2006 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: client In-Reply-To: <20060108145058.GA16083@kirschbaum.myrealbox.com> References: <20060108145058.GA16083@kirschbaum.myrealbox.com> Message-ID: <43C15915.8020005@laposte.net> > This check does not make sense to me: the variable i is a unsigned > variable. Therefore the value never is negative, hence this code will > never be executed. IIRC, I made a check because there were cases where the count actually was negative. But that may be before I fixed some things. I definitely had issues with a large items number, client would just crash because of that function (negative value => invalid array index). Nicolas From mikeeusaa at yahoo.com Sun Jan 8 02:41:20 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 8 14:37:54 2006 Subject: [crossfire] Does crossfire now support partial tranparancy of PNG? Message-ID: <20060108084120.55205.qmail@web32701.mail.mud.yahoo.com> I noticed that the edges of the puddles archen were alpha blended (THOUSANDS OF EXCLAIMATION POINTS AND ONES). It displayed correctly in the GTK-Too(?) client on my box. I wish to make the puddles more transparent so you can see the floor better (as it is a puddle..). Does CF support partal alpha now? __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From mikeeusaa at yahoo.com Sun Jan 8 11:36:46 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 8 14:37:56 2006 Subject: [crossfire] Crossfire nolonger compiles In-Reply-To: <20060108121408.GA12095@kirschbaum.myrealbox.com> Message-ID: <20060108173646.73255.qmail@web32703.mail.mud.yahoo.com> (Random map crash bug) >Resolution: Works For Me Ragnor may have fixed it, I heard he was working on it. The details are there are 3 random maps that exit to the same map. When you go into a 4th random map the server crashes, I know it's a server crash because when I went back on other players shouted "Mikeeeee!!" :P. Why use 3 random maps? Because there are a few bugs in the generator so that sometimes the path gets blocked (key not given for a door etc). I use 3 paths to important areas so the likelyhood of the player getting stuck is diminished. --- Andreas Kirschbaum wrote: > Miguel Ghobangieno wrote: > [...] > > Filed bug report at > > > http://sourceforge.net/tracker/index.php?func=detail&aid=1399546&group_id=13833&atid=113833 > > > > Also crossfire server crashes if a player enters > four > > random maps in quick succession. > > > http://sourceforge.net/tracker/index.php?func=detail&aid=1398239&group_id=13833&atid=113833 > > Please do not duplicate these bug reports here. It > is not useful because > developers automatically receive a mail whenever a > tracker item was > added or modified. > > _______________________________________________ > 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 Sun Jan 8 18:02:29 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jan 8 18:04:16 2006 Subject: [crossfire] Does crossfire now support partial tranparancy of PNG? In-Reply-To: <20060108084120.55205.qmail@web32701.mail.mud.yahoo.com> References: <20060108084120.55205.qmail@web32701.mail.mud.yahoo.com> Message-ID: <43C1A815.60409@sonic.net> Miguel Ghobangieno wrote: > I noticed that the edges of the puddles archen were > alpha blended (THOUSANDS OF EXCLAIMATION POINTS AND > ONES). It displayed correctly in the GTK-Too(?) client > on my box. I wish to make the puddles more transparent > so you can see the floor better (as it is a puddle..). > Does CF support partal alpha now? > As said previously, I believe the only client that supports this (at least in the standard C client distro) is the gtkv2 client in opengl mode. in SDL mode, it may be supported, and if that is the case, I'd expect it to be the same for both gtkv2 and gtk (v1) client. Basic display transpancy certainly is not supported. For images that do have alpha set in modes that don't support it, the current processing is that if that alpha value is 0 (fully transparent) then don't draw it, if not fully transparent, we do draw it. So thus, you could change the alpha value of puddles and it should still work just fine - it may just not look as good. I have no idea about the new java client. From mwedel at sonic.net Sun Jan 8 18:15:33 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jan 8 18:18:15 2006 Subject: [crossfire] Re: Weather, was Re: Re: Lalo's Bigworld pupland :D In-Reply-To: References: <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> <20060106052515.73431.qmail@web32710.mail.mud.yahoo.com> <43BF56BC.3040305@sonic.net> Message-ID: <43C1AB25.20303@sonic.net> Lalo Martins wrote: > And so says Mark Wedel on 07/01/06 13:50... >> Personally, I'm more inclined to think of the world as an infinite >> plan. That allows infinite expansion, and gets rid of any odd issues >> regarding world wrapping and compression you should really get. >> >> But in that model, it then makes sense to have bands of temperature - >> for example, at world_x_130 (far south) would be a band of >> ice/cold/whatever, but if we had a world_x_180, it might be nice that >> far down (starts to get warmer). > > /me puts his fantasy writer hat > > Ok, here is one neat proposal. Oddly enough, nothing I have ever seen > in-game mentions a sun. > > So, the world is an infinite plan. 0,0 is an arbitrary point, probably > the further NW that the sailors of the Old Empire ever sailed. > > Light/heat sources are a number of fixed points in the sky (or on the > top of high mountains even!). For reasons that the mages and priests > spend their lives debating, their light goes off once a day (for the > night), and it follows a cycle of strenghtening and weakening over a > longer period that became known as an year. > > (The days have the same length on all known light sources. The seasons > could be different if we wanted, but that's probably unnecessary > complication on the weather code.) > > So each continent has one or more "suns" independent of the others. The > reason we don't sail much between continents is that it's too cold, the > water freezes, and even magic won't work. Only extremely skilled > sailors with the help of extremely skilled mages can find the routes - > like the navy of the Old Empire. > > (Oddly enough, spells of "teleportation" style work across these > distances, so word of recall, town portal, etc isn't affected - this > probably explains how the dragon hangars and Pupland transport work.) > > /me takes off the writer hat > > Codewise: any tile not mapped will be defaulted by the weather system to > a large sheet of ice, which blocks spells, damned. > > Gamewise, we pick an arbitrary point of the existing continent. > Personally, I kind of like the idea of putting the "sun" on the top of a > high mountain, so somewhere to the northwest of the big range in the > middle of the continent would be best - most places keep more or less > the same climate, and even the Antarctic doesn't require moving. > > As for "my" continent, I'll take a good look at it and decide where to > put the light source(s). the other more 'traditional' belief is that it is the sun god who flies his chariot across the land which is the sun. That is of course why the sun moves accross the sky - at some point, he is just so far away, you can't see him anymore. That was more what I was thinking. And this works fine - no reason you can't have multiple sun gods (or maybe that one god has some helpers that travel the different lines). Multiple gods is interesting - one oculd imagine different gods one could worship in different areas - potential reason to start in other areas also. The oddity about doing single points of sun is that distance from that sun should determine the weather as well as light. Thus, if we put it in the middle of the existing continent, in practice, the center should be nice and warm and sunny, and the coastal areas (given the continent is somewhat round) should all be cold. I don't think that really works with the existing system. This can be solved by having multiple suns sprinkled around the continent, but this starts to get more complicated - especially as related to the weather, because the weather code has to know where these are. And you'd basically get the issues you have with lighting - dark (cold) areas wher the suns don't reach, and hot areas where they overlap, etc. It'd seem to be a fairly odd setup to me. The odd part about my plan is why you get seasons - I suppose one could state that for some reason, certain times of year the gods flaming chariot isn't as bright, this colder (and shorter days because it would disappear from sight sooner). From won_fang at yahoo.com.au Sun Jan 8 18:48:24 2006 From: won_fang at yahoo.com.au (David Seikel) Date: Sun Jan 8 18:46:17 2006 Subject: [crossfire] Re: Weather, was Re: Re: Lalo's Bigworld pupland :D In-Reply-To: <43C1AB25.20303@sonic.net> References: <7903f03c0601052001y12a5ae0at75790760192e72f@mail.gmail.com> <20060106052515.73431.qmail@web32710.mail.mud.yahoo.com> <43BF56BC.3040305@sonic.net> <43C1AB25.20303@sonic.net> Message-ID: <20060109104824.2eab6c2f@cluster.meeting.humbug.org.au> On Sun, 08 Jan 2006 16:15:33 -0800 Mark Wedel wrote: > the other more 'traditional' belief is that it is the sun god who > flies his chariot across the land which is the sun. That is of > course why the sun moves accross the sky - at some point, he is just > so far away, you can't see him anymore. When I was playing with having some parts of the weather code run as a separate application (for running on a different computer) I actually implemented it as just another client. This client controlled the actions of a weather god, moving it around the world changing the weather in the local area, then moving to the next area. Weather gods, sun gods, storm gods, lightning and thunder gods, etc. could match them up with actual Crossfire gods and increase their influence on aligned creatures when they are around etc. -- Stuff I have no control over could be added after this line. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060109/60f60986/attachment.pgp From fuchs.andy at gmail.com Mon Jan 9 16:41:51 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon Jan 9 16:42:16 2006 Subject: [crossfire] Old, junk files in archetypes? Message-ID: While taking care of obsolete parameters in the archetypes, I found some files, which don't seem to serve any purpose currently. It seems like they used to help specify colors for faces, when monochrome bitmaps where used. door/Locked/ldoor.face door/Locked/key.face floor/marble.face jewel/pretty_crystal.face spell/Golem/golem.face spell/Golem/avatar.face armour/helmet/crown_r.face monster/acid/bluesphere.face monster/angel/archangel.face monster/chaos/witch_chaos.face monster/troll/Troll/troll.face monster/troll/smalltroll.face monster/humanoid/Elf/spock.face monster/humanoid/Class/Warrior/warrior.face monster/elemental/elem.face monster/dragon/Hatchlings/grey_drag.face monster/goblin/ogre_r.face monster/undead/skree/skree.face ground/Wood/bforest.face ground/Pstone/rstone.face player/race/pl_dragon_blue.face player/race/pl_dragon_bl.face player/race/pl_dragon_g.face player/race/pl_dragon_r.face player/class/Wizardry/wizard.face talisman/ring.face weapon/sword/dager_r.face Are these files safe to delete? Do they currently serve any purpose? -- Andrew Fuchs From alex_sch at telus.net Mon Jan 9 23:37:48 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon Jan 9 23:38:17 2006 Subject: [crossfire] Wiki todo list Message-ID: <43C3482C.6000700@telus.net> Hi, Here's a little development todo list thing on the wiki, hopefully it might be a bit useful. Also, I'm thinking that for larger projects on the todo list (i.e. land plots), it can have it's own page in the dev_todo where comments and ideas about it can be explained, commented on, and evolve over time. http://wiki.metalforge.net/doku.php/dev_todo Alex Schultz From mwedel at sonic.net Tue Jan 10 00:30:58 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue Jan 10 00:38:17 2006 Subject: [crossfire] Old, junk files in archetypes? In-Reply-To: References: Message-ID: <43C354A2.2010006@sonic.net> Andrew Fuchs wrote: > While taking care of obsolete parameters in the archetypes, I found > some files, which don't seem to serve any purpose currently. It seems > like they used to help specify colors for faces, when monochrome > bitmaps where used. The real purpose of the .face files was to contain that color/magicmap information where you have images in the archetype directory but no archetype that uses them. If there are archetypes that use them, can put the magicmap information there. Otherwise, these are still needed to convey the magicmap color information. From nicolas.weeger at laposte.net Wed Jan 11 15:35:09 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Jan 11 15:36:19 2006 Subject: [crossfire] Hardening plugin system Message-ID: <43C57A0D.6000006@laposte.net> Hello. Currently, a plugin can easily crash the server, which doesn't check parameters (just call a function with a NULL pointer, nice crash guaranteed). Also, server doesn't checks parameters and such, which can lead to invalid values (Str of 50 for a player...). So should that be fixed in a way a plugin can *not* crash the server through a callback, or send invalid parameters? Note that preventing a plugin ever crashing the server is hard, since the plugin itself can crash leading to server crash (and that isn't something easy to avoid i think). IMO "no" is an acceptable answer. We can after all "trust" a plugin to do the right thing. If we choose the "yes, let's harden the plugin system" option, here's my suggestion for hardening: * when plugin requests an object/map/archetype, server keeps the pointer in an array and sends the index, which is used in subsequent functions * this way, it's easy to check the pointer's validity - check index, if inbounds ok, else issue * when the plugin returns, server knows what objects were affected (array can contain a "set_parameter" field, set when a setter is called), and can send updates to player accordingly - should also simplify plugin's code. Also can recalculate stuff when object is removed, whatever. Just my 2 cents :) Nicolas From antonoussik at gmail.com Thu Jan 12 08:56:37 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Thu Jan 12 08:58:38 2006 Subject: [crossfire] Wraith changes In-Reply-To: <43B635AE.10001@sonic.net> References: <43A36A35.3020405@sonic.net> <43A7A718.8040106@sonic.net> <43B635AE.10001@sonic.net> Message-ID: On 31/12/05, Mark Wedel wrote: > 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. I will have a look in a couple of weeks when I have time, when I have the time. Maybe I can just hardcode the actual hp adding code to only add hp randomly and sometimes as opposed to always. That will effectively slow down the skill. > > > >> 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. > > 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. Yes, as the patch stands that is the risk of being a wraith - you suck monsters dry with ease, yet you are very weak, so to keep alive you have to suck all the time. If you bump into a wall for 3-4 seconds your hp drops from full to 0 and next thing you know you are in a bed of reality. I guess it is wrong in a way, but a level 8 dragon I made to compare could do the same... just it had to run away when it got injured not turn around and start sucking at a kobold. > 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. That would be a quite easy thing to do - if you feed on something lower level than you you would not get any hp for it, and a message saying that this monster is too weak for you to feed on. This would also make it interesting at high level, as either you have to know where the high level "feeding grounds" - areas of easy to kill high level monsters are, or you start to rely on healing potions (and therefore a way of spending your disposable income :-D ) to survive. Also as a wraith I found when I played that you run from zombies and skeletons as if it were banishment itself. Since you can not feed on a zombie you have to use something that does not replenish you in combat, and so I imagine even at level 30 wraith running into something like a zombie tc would be equivalent to a suicide. It is an interesting side effect of the patch, but you automatically have to avoid killing your race. From antonoussik at gmail.com Thu Jan 12 13:37:06 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Thu Jan 12 13:38:30 2006 Subject: [crossfire] Re: Lalo's Bigworld pupland :D In-Reply-To: <20060107033323.99885.qmail@web32715.mail.mud.yahoo.com> References: <20060107033323.99885.qmail@web32715.mail.mud.yahoo.com> Message-ID: I'm jumping in completely off-topic, but since there is now more water, and parts only reachable by sea, it would be a good idea to add player driven boats to replace the merchant ones. Maybe some sea monsters too? From antonoussik at gmail.com Thu Jan 12 21:21:56 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Thu Jan 12 21:22:20 2006 Subject: [crossfire] ...shouldn't one get drunk from wine and booze in CF? In-Reply-To: <20060108060251.65884.qmail@web32708.mail.mud.yahoo.com> References: <20060108060251.65884.qmail@web32708.mail.mud.yahoo.com> Message-ID: I'm pretty sure making an alcoholic drink would need server code changes. I have tried before to make a booze that casts confusion on the drinker, but the best I could manage is a booze that would get everyone around you drunk (confused) when consumed. Another interesting potion/disease that could be introduced is amnesia - a random forgetting of a spell, and if you know no spells, of a skill. From mikeeusaa at yahoo.com Fri Jan 13 14:27:04 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Fri Jan 13 14:36:45 2006 Subject: [crossfire] ...shouldn't one get drunk from wine and booze in CF? In-Reply-To: Message-ID: <20060113202704.76025.qmail@web32702.mail.mud.yahoo.com> Yes it would need server additions to work well, Red and I came to the same conclusion. It is a good little thing to add, however, for anyone who has time and wishes to code on CF but doesn't want to start a long protracted saga of code (long protected sagas are, however, brightly smiled upon). --- Anton Oussik wrote: > I'm pretty sure making an alcoholic drink would need > server code > changes. I have tried before to make a booze that > casts confusion on > the drinker, but the best I could manage is a booze > that would get > everyone around you drunk (confused) when consumed. > > Another interesting potion/disease that could be > introduced is amnesia > - a random forgetting of a spell, and if you know no > spells, of a > skill. > > _______________________________________________ > 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 Sat Jan 14 22:15:47 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat Jan 14 22:18:23 2006 Subject: [crossfire] Hardening plugin system In-Reply-To: <43C57A0D.6000006@laposte.net> References: <43C57A0D.6000006@laposte.net> Message-ID: <43C9CC73.5040505@sonic.net> Nicolas Weeger wrote: > Hello. > > Currently, a plugin can easily crash the server, which doesn't check > parameters (just call a function with a NULL pointer, nice crash > guaranteed). Also, server doesn't checks parameters and such, which can > lead to invalid values (Str of 50 for a player...). > > So should that be fixed in a way a plugin can *not* crash the server > through a callback, or send invalid parameters? > Note that preventing a plugin ever crashing the server is hard, since > the plugin itself can crash leading to server crash (and that isn't > something easy to avoid i think). > > IMO "no" is an acceptable answer. We can after all "trust" a plugin to > do the right thing. > > If we choose the "yes, let's harden the plugin system" option, here's my > suggestion for hardening: > * when plugin requests an object/map/archetype, server keeps the pointer > in an array and sends the index, which is used in subsequent functions > * this way, it's easy to check the pointer's validity - check index, if > inbounds ok, else issue > * when the plugin returns, server knows what objects were affected > (array can contain a "set_parameter" field, set when a setter is > called), and can send updates to player accordingly - should also > simplify plugin's code. Also can recalculate stuff when object is > removed, whatever. Presumably for that last point to work, all the functions the change values in the plugin code would need to set some flag. Otherwise, I don't see how the server can know an object changes. For example, plugin is called with an object whose object pointer is deadbeef. The plugin makes some changes (say changes name) and returns. The object pointer is still deadbeef. Unless the server keeps a copy of the object, and then runs a comparison, I don't see how the server can really know the object has changed. And keeping a copy, running a comparison, and updating it would seem to be a fairly costly operation (maybe not a big deal, but I could potentially see that as preventing really wide spread use of the plugin if the performance is bad). I personally do think that the plugin should do basic checking - making sure set values are valid, etc. I don't think that stuff is too hard. And I think that may catch errors object comparison can't do. For example, if a field in the object type is an sint16, the valid value is -32768 to 32767. If something tries to set the valid beyond that, it is bad. However, object comparison won't catch that - some plugin sets the value to 123,456. The value gets truncated, so is a legal value, but probably no what the plugin wants, and thus causes problems. OTOH, if the actual plugin code checks the valid for the -32768 to 32767 range, it can log an error right there. Another thing (unrelated to this) is plugin verification of compatibility. More than once on my own working copy, I've done a make but not done a make install, only to track it down to the plugin being out of date. What I think could be done is that the plugin code has code someplace like: #define PY_OB_SIZE sizeof(object) #define PY_PL_SIZE sizeof(player) etc for major structures. The server could have similar code, but different name. In the server init code, it could initialize some global variables to those values. The plugin could then compare the size it thinks the structures should be with what the server thinks they are, and if any difference, logs an error and either exits (because it is sure to crash otherwise), or disables itself. This isn't foolproof - if fields are moved in the structure but size remains the same, that won't catch the difference (if really paranoid, could add some offset checks). However, I think the case of fields moving about is low - the more common case is new fields being added or old fields being removed, and sizeof checks should catch that. From nicolas.weeger at laposte.net Sun Jan 15 03:32:14 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Jan 15 03:34:23 2006 Subject: [crossfire] Hardening plugin system In-Reply-To: <43C9CC73.5040505@sonic.net> References: <43C57A0D.6000006@laposte.net> <43C9CC73.5040505@sonic.net> Message-ID: <43CA169E.7040501@laposte.net> > Presumably for that last point to work, all the functions the change > values in the plugin code would need to set some flag. Otherwise, I > don't see how the server can know an object changes. Exactly. But remember plugin isn't supposed to access object's fields directly but use callbacks which can set such a flag. > I personally do think that the plugin should do basic checking - making > sure set values are valid, etc. I don't think that stuff is too hard. > And I think that may catch errors object comparison can't do. True, but for instance in the case of the Python plugin at what point? In the Python-C wrappers, ie Python plugin side, in the plugin_common code, or in the server-side code? 3rd case is the more foolproof, but can be a pain to propagate back (how will the C/Python code know the value is invalid? Special integer value for return? Parameter by reference?) > Another thing (unrelated to this) is plugin verification of > compatibility. More than once on my own working copy, I've done a make > but not done a make install, only to track it down to the plugin being > out of date. That could possibly be done. I'd then suggest sending those values at plugin init, or something like that - maybe have the plugin init function take a "long struct_size, struct* plugin_info". The structure contains basic info (version, some sizes), and the struct_size ensures you're compatible at least with the structure sent :) Nicolas From nicolas.weeger at laposte.net Sun Jan 15 07:45:42 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Jan 15 07:48:24 2006 Subject: [crossfire] (Python) script distribution Message-ID: <43CA5206.4030702@laposte.net> Hello. There are a few (Python) scripts i'd like to write, to extend Crossfire. Merely thinking something like a "visit card" system (to let other players know your level or skill), or something to autorejoin party at login time. So I'm wondering where to put those scripts. Should I put them in the python subdirectory in maps, and assume everyone will want them? Should we create a new subdirectory with "optional scripts"? Should I put'em on some web page and let interested people download? Note that this can in some ways apply to existing scripts (occidental stuff scripts, for instance). I'd say either put in python subdir, or create a new subdirectory - it's the simplest way to distribute things imo. Nicolas From nicolas.weeger at laposte.net Sun Jan 15 07:50:15 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Jan 15 07:54:26 2006 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <43CA5317.5070207@laposte.net> Hello. I'm wondering about moving some parts of the code to plugins. IMO things like weather system (excluding darkness-related things) could be moved to a plugin, and just hook to server core. Random maps generation too could imo be moved. (particularly weather, as it's really optional, setting for that). Actually, shouldn't the server be just a "core" with basic rules, and everything else moved to plugins? Nicolas From hv at crypt.org Sun Jan 15 08:38:32 2006 From: hv at crypt.org (hv@crypt.org) Date: Sun Jan 15 08:32:24 2006 Subject: [crossfire] directing detectors? Message-ID: <200601151438.k0FEcXQ28071@zen.crypt.org> In server/time.c:process_object(), the final switch statement has: case DETECTOR: move_detector(op); case DIRECTOR: if (op->stats.maxsp) animate_turning(op); return 0; (in both 1.8.0 release and current cvs). Is this intended to fall through to the DIRECTOR case? If so I'd recommend a /* fall through */ comment to clarify that. No other cases within the switch fall through, and I couldn't find an example in the maps of a detector with maxsp, so I suspect it is unintentional. Hugo From mikeeusaa at yahoo.com Sun Jan 15 10:29:42 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 15 12:49:03 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43CA5317.5070207@laposte.net> Message-ID: <20060115162942.46049.qmail@web32707.mail.mud.yahoo.com> Why? That's just extra useless busy work. You could code in drunkenness (see previous post) if you're itching for something to do. --- Nicolas Weeger wrote: > Hello. > > I'm wondering about moving some parts of the code to > plugins. > IMO things like weather system (excluding > darkness-related things) could > be moved to a plugin, and just hook to server core. > Random maps generation too could imo be moved. > (particularly weather, as it's really optional, > setting for that). > > Actually, shouldn't the server be just a "core" with > basic rules, and > everything else moved to plugins? > > Nicolas > > _______________________________________________ > 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 mikeeusaa at yahoo.com Sun Jan 15 10:32:30 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 15 12:49:07 2006 Subject: [crossfire] (Python) script distribution In-Reply-To: <43CA5206.4030702@laposte.net> Message-ID: <20060115163230.91765.qmail@web32710.mail.mud.yahoo.com> Assume everyone will want them. If a person spazes out for downloading 2kB of extra stuff ... who cares? Not I, nor should you. --- Nicolas Weeger wrote: > Hello. > > There are a few (Python) scripts i'd like to write, > to extend Crossfire. > Merely thinking something like a "visit card" system > (to let other > players know your level or skill), or something to > autorejoin party at > login time. > > So I'm wondering where to put those scripts. Should > I put them in the > python subdirectory in maps, and assume everyone > will want them? Should > we create a new subdirectory with "optional > scripts"? Should I put'em on > some web page and let interested people download? > Note that this can in some ways apply to existing > scripts (occidental > stuff scripts, for instance). > > I'd say either put in python subdir, or create a new > subdirectory - it's > the simplest way to distribute things imo. > > Nicolas > > _______________________________________________ > 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 yann.chachkoff at myrealbox.com Sun Jan 15 13:11:35 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun Jan 15 13:12:24 2006 Subject: [crossfire] (Python) script distribution Message-ID: <1137352295.c7d605dcyann.chachkoff@myrealbox.com> I think the webpage idea isn't very good - most people will simply ignore/dismiss them. I'd rather see "harmless" scripts get directly into the python subdirectory of the map repository, while the more controversial ones could get into an optional package, available at the same download location as the maps or the server. Controversed scripts could also get into /maps/python-optional - even if it means people will download some files they'll never use, I think that the space overhead is really negligible. As long as the added functionalities don't disturb the play balance (and are not too bugged :)), I think they should get into the maps CVS repository. That's exactly what we do when we add new functionalities coded in C, so there's no reason to handle this differently. -----Original Message----- From: Nicolas Weeger To: Crossfire Discussion Mailing List Date: Sun, 15 Jan 2006 14:45:42 +0100 Subject: [crossfire] (Python) script distribution Hello. There are a few (Python) scripts i'd like to write, to extend Crossfire. Merely thinking something like a "visit card" system (to let other players know your level or skill), or something to autorejoin party at login time. So I'm wondering where to put those scripts. Should I put them in the python subdirectory in maps, and assume everyone will want them? Should we create a new subdirectory with "optional scripts"? Should I put'em on some web page and let interested people download? Note that this can in some ways apply to existing scripts (occidental stuff scripts, for instance). I'd say either put in python subdir, or create a new subdirectory - it's the simplest way to distribute things imo. Nicolas _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire From yann.chachkoff at myrealbox.com Sun Jan 15 13:19:29 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun Jan 15 13:20:25 2006 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1137352769.c7d605dcyann.chachkoff@myrealbox.com> >Hello. Hi :) > I'm wondering about moving some parts of the code to plugins. > IMO things like weather system (excluding darkness-related things) could be moved to a plugin, and just hook to server core. > Random maps generation too could imo be moved. (particularly weather, as it's really optional, setting for that). > I agree - that's exactly for such purposes that I created the plugin system in the first place. It would allow to make a very clear separation between the "important", core code, and the fluff-n-fuzz glued around it. In the long run, I think it would contribute to make the code easier to maintain and to expand, as it would be divided in smaller chunks for a lot of tasks. > Actually, shouldn't the server be just a "core" with basic rules, and everything else moved to plugins? *I* think it should, even if it is not a trivial task for everything. From mikeeusaa at yahoo.com Sun Jan 15 15:06:17 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 15 19:41:59 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1137352769.c7d605dcyann.chachkoff@myrealbox.com> Message-ID: <20060115210617.4048.qmail@web32714.mail.mud.yahoo.com> Wouldn't what would happen is that the 'plugin' stuff is ignored and gets broken and only things that are used on MF worked on? That sounds like what this is for, to slowly jettison that which MF does not use. --- Yann Chachkoff wrote: > >Hello. > > Hi :) > > > I'm wondering about moving some parts of the code > to plugins. > > IMO things like weather system (excluding > darkness-related things) could be moved to a plugin, > and just hook to server core. > > Random maps generation too could imo be moved. > (particularly weather, as it's really optional, > setting for that). > > > > I agree - that's exactly for such purposes that I > created the plugin system in the first place. It > would allow to make a very clear separation between > the "important", core code, and the fluff-n-fuzz > glued around it. In the long run, I think it would > contribute to make the code easier to maintain and > to expand, as it would be divided in smaller chunks > for a lot of tasks. > > > Actually, shouldn't the server be just a "core" > with basic rules, and everything else moved to > plugins? > > *I* think it should, even if it is not a trivial > task for everything. > > > _______________________________________________ > 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 Mon Jan 16 00:42:19 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jan 16 00:44:24 2006 Subject: [crossfire] directing detectors? In-Reply-To: <200601151438.k0FEcXQ28071@zen.crypt.org> References: <200601151438.k0FEcXQ28071@zen.crypt.org> Message-ID: <43CB404B.5020408@sonic.net> hv@crypt.org wrote: > In server/time.c:process_object(), the final switch statement has: > case DETECTOR: > move_detector(op); > > case DIRECTOR: > if (op->stats.maxsp) > animate_turning(op); > return 0; > (in both 1.8.0 release and current cvs). > > Is this intended to fall through to the DIRECTOR case? If so I'd > recommend a /* fall through */ comment to clarify that. > > No other cases within the switch fall through, and I couldn't find > an example in the maps of a detector with maxsp, so I suspect it is > unintentional. I suspect it is intentional, as the arch/connect/Director/director.arc does have maxsp set. That said, since detectors detect object above them and then trigger something else, it is unclear to me what that point to having them point in a specific direction serves. It looks like the movers were basically just grabbed and copied over - in the case of movers, a direction makes sense for them. From mwedel at sonic.net Mon Jan 16 01:09:50 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jan 16 01:12:23 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43CA5317.5070207@laposte.net> References: <43CA5317.5070207@laposte.net> Message-ID: <43CB46BE.3070303@sonic.net> Nicolas Weeger wrote: > Hello. > > I'm wondering about moving some parts of the code to plugins. > IMO things like weather system (excluding darkness-related things) could > be moved to a plugin, and just hook to server core. > Random maps generation too could imo be moved. > (particularly weather, as it's really optional, setting for that). > > Actually, shouldn't the server be just a "core" with basic rules, and > everything else moved to plugins? The harder part is to define what are the core/basic rules and what are options. Taken to an extreme, you could say just write the entire thing in python/perl/whatever. There isn't much a reason to do that (you're basically re-writing anything, so only point would be to try to remain some compatibility). I personally don't see much reason to rewrite existing code that is working fine as a plugin. There are just enough things that could be/should be done than rewriting working code doesn't make sense. All that said, could probably make some general rules for a plugin/built in test: 1) Speed - I'm sure the plugin is slower to some extent - ignoring the actual plugin language, the fact that access of a lot of data is done through callback functions vs direct access has to hurt a bit. This isn't an issue if a plugin isn't used very often, but probably would become an issue if the plugin is used multiple times every tick. 2) Complexity - I'd make the case that debugging very complex pieces is done if all is in native C - don't have to debug accross languages, etc. > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Mon Jan 16 01:25:32 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jan 16 01:28:24 2006 Subject: [crossfire] Hardening plugin system In-Reply-To: <43CA169E.7040501@laposte.net> References: <43C57A0D.6000006@laposte.net> <43C9CC73.5040505@sonic.net> <43CA169E.7040501@laposte.net> Message-ID: <43CB4A6C.90806@sonic.net> Nicolas Weeger wrote: >> Presumably for that last point to work, all the functions the change >> values in the plugin code would need to set some flag. Otherwise, I >> don't see how the server can know an object changes. > > Exactly. But remember plugin isn't supposed to access object's fields > directly but use callbacks which can set such a flag. The question is then why not just check for the sanity at that time? If its a choice of: a) when callback to set value is used, we set the value and then mark a flag that the object has been modified, and when function is finished, we check sanity of object, or b) when callback to set value is made, we check the validity I'd personally choose b - detecting the error right when it happens is always better - it makes it easier to fix the problem. > True, but for instance in the case of the Python plugin at what point? > In the Python-C wrappers, ie Python plugin side, in the plugin_common > code, or in the server-side code? 3rd case is the more foolproof, but > can be a pain to propagate back (how will the C/Python code know the > value is invalid? Special integer value for return? Parameter by reference?) Depends on the value. In your initial post, you mentioned scripts setting the Str value to 50. Well, there is a MAX_STAT defined, which the Python-C wrappers could check (or plugin common code). Some things are certainly harder- not everything has a clear define for min/max value. but at some level, it can never be 100% foolproof. The fact the server crashes occasionally is proof that even the C code isn't foolproof. You get the complications of some value being valid for one object type, but not another, and I don't think there is any real way that can ever be checked (but that same problem occurs in maps also - mapmaker could set some value to something invalid) From yann.chachkoff at myrealbox.com Mon Jan 16 02:15:12 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Mon Jan 16 02:16:24 2006 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1137399312.c7c8911cyann.chachkoff@myrealbox.com> > Wouldn't what would happen is that the 'plugin' stuff is ignored and gets broken and only things that are used on MF worked on? That sounds like what this is for, to slowly jettison that which MF does not use. That's ridiculous. The distinction between what is part of the core and what is not would have to be defined at a technical level, not at a 'political' one. If the anser to "can the game work without functionality X still work ?" is yes, then X isn't core. We can start nit-picking endlessly on the details of the definition of the core, but it changes nothing to the base idea. So things like weather or python are not part of the core, because they "only" extend the game functionalities. Note that splitting the code into plugins never meant that the content of those plugins would suddenly leave the codebase or be "left in the cold". Now, if you think that a functionality you feel important is put aside, then start supporting it - everybody is free to contribute to the Crossfire code. From yann.chachkoff at myrealbox.com Mon Jan 16 02:45:50 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Mon Jan 16 02:46:24 2006 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1137401150.c7c8911cyann.chachkoff@myrealbox.com> > The harder part is to define what are the core/basic rules and what are options. Definitely. But I'm not sure such a definition is really needed. I think that if a functionality is clearly "optional" or isn't strongly tied with the rest of the code (as it appears to be the case for random maps or the weather system), then it should at some point be modularized. I'm not sure I'd like to see a "let's define what the core is" debate being open - it will lead to endless sterile discussions, because everybody has its own idea, and that there are multiple definition of what the core should include, depending on how you perceive the problem. > Taken to an extreme, you could say just write the entire thing in python/perl/whatever. There isn't much a reason to do that (you're basically re-writing anything, so only point would be to try to remain some compatibility). The idea is not to "rewrite everything" - but to move existing code into plugins. Sure, the "accessors" will have to be rewritten - but there's no reason to rewrite the whole internal code logic to do such a move. > I personally don't see much reason to rewrite existing code that is working fine as a plugin. There are just enough things that could be/should be done than rewriting working code doesn't make sense. Again, there is nothing like rewriting whole sections of the code - only the "glue"-related stuff would have to be. As for the other important things to be done first, I tend to think that making the code more resistant and easier to debug should be our top priority, above the addition of new functionalities. In this respect, I think that modularizing things is a way to improve code maintainability on the long run. > 1) Speed - I'm sure the plugin is slower to some extent - ignoring the actual plugin language, the fact that access of a lot of data is done through callback functions vs direct access has to hurt a bit. This isn't an issue if a plugin isn't used very often, but probably would become an issue if the plugin is used multiple times every tick. I'm doubtful it hurts "a bit" - most of the overhead comes (a) from the analysis of the parameters passed by plugins to the server through va_args and (b) from the call to registered local plugin events. (a) is hardly an issue, even when dealings with hundreds of calls per second (unless we still want to consider 1997 machines as a relevant target architecture...). (b) is indeed an issue, as the server currently has to browse a list of objects to be able to call a plugin function. At some point, I think that besides the events currently available, plugins should be able to directly register callbacks that would be stored in lists and called at specific places in the code - "code events", thus, that would get called when a given server function is called, to modify or change its result. > 2) Complexity - I'd make the case that debugging very complex pieces is done if all is in native C - don't have to debug accross languages, etc. Who said that the intend was to write plugins in another language than C ? It would be *possible* of course, but it doesn't mean that it is what we *want*. I don't see why you'd need to debug "across languages" - the base idea of a modularized system is to allow separate debugging of the modules and the core. And finally, given that the whole codebase is currently written in C, its modularization would lead to modules written in C as well. The whole question comes down to: "is a monolithic code easier or harder to debug and maintain than a modularized one ?". My personal opinion on this is that the answer is "it is harder". From antonoussik at gmail.com Mon Jan 16 06:07:12 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Mon Jan 16 06:08:25 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1137401150.c7c8911cyann.chachkoff@myrealbox.com> References: <1137401150.c7c8911cyann.chachkoff@myrealbox.com> Message-ID: Throwing in my two pennies: In general modularisiation of the code will improve maintainability, as the core will be smaller, and tidier. Modules can then be compiled in or left out as the person running the server wishes. This would make debugging easier if anything, as then as long as the core is stable (which should not be too hard if it is made small) it will be always possible to isolate the modules that are causing trouble and either fix them or not use them until they are made more stable. On the other hand modularising the code will result in many changes, may introduce new bugs into the code, and is in general a lot of work whilst the benefits are questionable (this will only be useful if core is really small and most things are out in modules which can be configured at configure stage). If someone has a desire to do all that they are welcome to (it is an open source project :-) ), but in my opinion implementing new features would be more beneficial to the project. If you are going to go ahead with it, before you do anything to the code you will need to define what goes out to what modules, and what depends on what. Since CF was not designed to be modular you may also find recursive dependancies which will need resolving first. But I suspect you knew this already... From brenlally at gmail.com Mon Jan 16 07:01:51 2006 From: brenlally at gmail.com (Brendan Lally) Date: Mon Jan 16 07:02:25 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: References: <1137401150.c7c8911cyann.chachkoff@myrealbox.com> Message-ID: <7903f03c0601160501h56710e1uca1999ed995e8646@mail.gmail.com> On 1/16/06, Anton Oussik wrote: > On the other hand modularising the code will result in many changes, > may introduce new bugs into the code, and is in general a lot of work > whilst the benefits are questionable (this will only be useful if core > is really small and most things are out in modules which can be > configured at configure stage). If someone has a desire to do all that > they are welcome to (it is an open source project :-) ), but in my > opinion implementing new features would be more beneficial to the > project. You forgot the other important point, modularity reduces speed of development, sometimes catastroptically, you only need to look at GNU Hurd for an example of that. It strikes me that crossfire is (still) not yet mature enough to have a fixed interface to all the modules that would be used, only a couple of months ago all the python scripts were broken by a plugin change, and I know I for one wouldn't want to attempt to fix the weather 'module' the next time the interface to it was broken. If there is going to be breakages, how about breaking the things that are already obsolete? There is a lot of old code in crossfire that has long since become redundent, which nonetheless increases complexity, the most obvious of these (to my mind) are: the original 'map' command, which doesn't support big faces at all. code to convert spells into regular objects, which was a conversion that happened years ago. the gnome client, which doesn't work (ok, that's client side, but still) stats support for the old skill system polymorphism (most of it is #if 0'ed out, but I'd prefer removed completely) 32 bit exp support (surely no one still uses that?) cfsndserver (it doesn't work) From tchize at myrealbox.com Mon Jan 16 07:32:10 2006 From: tchize at myrealbox.com (tchize) Date: Mon Jan 16 07:32:25 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: References: <1137401150.c7c8911cyann.chachkoff@myrealbox.com> Message-ID: <200601161432.11133.tchize@myrealbox.com> Le Lundi 16 Janvier 2006 13:07, Anton Oussik a ?crit : > Throwing in my two pennies: > > In general modularisiation of the code will improve maintainability, That's also my opinion. > On the other hand modularising the code will result in many changes, > may introduce new bugs into the code, and is in general a lot of work > whilst the benefits are questionable (this will only be useful if core > is really small and most things are out in modules which can be > configured at configure stage). If someone has a desire to do all that > they are welcome to (it is an open source project :-) ), but in my > opinion implementing new features would be more beneficial to the > project. Speaking of my experience with crossfire code. I have developped a few add-ons to crossfire in the past (don't remember the list). From my point of view, adding new features in the code is currently a pain in the ass. I have dropped features add-ons which took me lots of time simply because it has become nearly impossible to find something in the code. If you add a new arch type, you have to register it in a define list, register it in the movement function if it is active, register it in the attack code if it can attack player, maybe register it with weather system if it can interact with it, register it to spell casting system if, for example, it represents a spell modifier. Can you imagine today creating an item which has as characteristic 'owner can walk over water' without modifying piece of code everywhere? In a modularized system, you could have something like that (it's just an idea, it still has obvious flaws in aglorithms) when trying to move object from squareX to squareY, you trigger a move_request event on squareX listeners, on squareY listeners and on object listeners. Each listener can respond with NEUTRAL(0), ALLOW(1), REJECT(-1) if there is an allow, then allow movement else if there are no reject then allow movement else refuse movement water would be REJECT non swimming obj, your item, registered in player when applied) would allow on every square with water. The exact same idea can be used to create complex check_inv, confusion spells, director, no_movement traps . You just 'plugs' in the movement code. Also this system can improve server performances. Currently, one of the main 'lag' problem of server is meteor swarm in the open areas. thousands of fire elements are checking the object list on a given square (that is other fire elements) at a given tick, and this until fire dies a few seconds later. Now imagine this. create a 'fire' arch at square X. When inserted, arch code register a move_event for the square and also analyse immediatly content of square. when new things are added to the square, the fire can check immediatly if this item can burn. Most of the time, there is nothing to burn. when the fire element gets activated avery X ticks, it does not have to explore a list of 100 other fire object to know there is nothing burnable where it belongs. Saying it's more important to add new features than modularize the code is simply a short term view. Since am part of this projects, i saw new features coming on a regular basis. Today the code, imho, is far less maintanable then it was 5 years ago. And if we continue to focus on features without architecture the code will be a blotted piece of unmaintanable code in a few years. If i remember well, Mark Wedel already had in the past to request from developper they spend more time on fixing the server code then add new features. There are tons of features in code map maker simply don't know about. Moreover there are tons of security issues in the code. They could be isolated and identified far more easily during a reorganisation process. I hope we will ge to an agreement on this subject. > > If you are going to go ahead with it, before you do anything to the > code you will need to define what goes out to what modules, and what > depends on what. Since CF was not designed to be modular you may also > find recursive dependancies which will need resolving first. But I > suspect you knew this already... > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From tchize at myrealbox.com Mon Jan 16 09:45:42 2006 From: tchize at myrealbox.com (tchize) Date: Mon Jan 16 09:46:25 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <7903f03c0601160501h56710e1uca1999ed995e8646@mail.gmail.com> References: <1137401150.c7c8911cyann.chachkoff@myrealbox.com> <7903f03c0601160501h56710e1uca1999ed995e8646@mail.gmail.com> Message-ID: <200601161645.42852.tchize@myrealbox.com> > You forgot the other important point, modularity reduces speed of > development, sometimes catastroptically, you only need to look at GNU > Hurd for an example of that. i see the exact opposite of behaviour at work. Project initiated in a modular way, or migrated to a modular approach are easier to manage for the following reasons 1) You don't need to have knowledge of how the whole code works to be able to work on parts of it 2) You can isolate changes in only a part of the code > > It strikes me that crossfire is (still) not yet mature enough to have > a fixed interface to all the modules that would be used, only a couple > of months ago all the python scripts were broken by a plugin change, > and I know I for one wouldn't want to attempt to fix the weather > 'module' the next time the interface to it was broken. > Architecture must be handled from the very beginning and currently there is no architecture design on crossfire project. A way to structure things here is suggested. This may not be the best approach, but it's far better then what we currently have. And nobody in the last year did propose anything to fix architecture problems in crossfire. And in modularized projects, the interfaces between modules are not always clear, they are not fixed and would probably never been. Some code migrate from one module to another after experience show it is needed nearer to the core, or on the opposite, it get further from the core because it is not as multipurpose as we may have thought in the begin. Some modules sometimes get gathered as a unique module. Some other gets splitted in sub modules. That's the lifecycle of a project. It works, and well. Yes sometimes there are clash, sometimes a very big change in a module is a pain in the ass for all people using the modules. But considering the gain, in development speed, in code learning curve and bugs hunting, it is clearly worth it. You argue a change in 'core' could interfer with 'weather' and you don't want to fix weather if it gets broken by that change in core? Well i claim, with current organisation of code, a change *anywhere* in code (not only what we could define as core) can break the weather. (Or potentially break anything else). That is something a modularized approach tends to prevent as much as possible. And am not speaking of compilation here. Compilation problems are easy to solve. You could argue, currently, you can't make a change in core that would make weather uncompilable, which with a plugin system could be possible. But, this is not a difficult fix, the most difficult bugs to fix are those which let the code compilable but with subtle invalid logic. And the last one happends a lot in crossfire. regards From mikeeusaa at yahoo.com Mon Jan 16 11:29:30 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 16 12:02:17 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601161432.11133.tchize@myrealbox.com> Message-ID: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> I have to do the same thing when I am adding things to my perl rpg (which is not smaller in lines of code then crossfire). It's not a big hassle, and how else will the code know what's going on? Use grep. --- tchize wrote: > Le Lundi 16 Janvier 2006 13:07, Anton Oussik a ?crit > : > > Throwing in my two pennies: > > > > In general modularisiation of the code will > improve maintainability, > > That's also my opinion. > > > On the other hand modularising the code will > result in many changes, > > may introduce new bugs into the code, and is in > general a lot of work > > whilst the benefits are questionable (this will > only be useful if core > > is really small and most things are out in modules > which can be > > configured at configure stage). If someone has a > desire to do all that > > they are welcome to (it is an open source project > :-) ), but in my > > opinion implementing new features would be more > beneficial to the > > project. > > Speaking of my experience with crossfire code. I > have developped > a few add-ons to crossfire in the past (don't > remember the list). > From my point of view, adding new features in the > code is currently > a pain in the ass. I have dropped features add-ons > which took > me lots of time simply because it has become nearly > impossible to find > something in the code. > If you add a new arch type, you have to register it > in a define list, register > it in the movement function if it is active, > register it in the attack code > if it can attack player, maybe register it with > weather system if it can > interact with it, register it to spell casting > system if, for example, it > represents a spell modifier. Can you imagine today > creating an item which has > as characteristic 'owner can walk over water' > without modifying piece of code > everywhere? > > In a modularized system, you could have something > like that (it's just an > idea, it still has obvious flaws in aglorithms) > > when trying to move object from squareX to squareY, > you trigger a move_request > event on squareX listeners, on squareY listeners and > on object listeners. > Each listener can respond with NEUTRAL(0), ALLOW(1), > REJECT(-1) > if there is an allow, then allow movement > else if there are no reject then allow movement > else refuse movement > water would be REJECT non swimming obj, your item, > registered in player when > applied) would allow on every square with water. > The exact same idea can be used to create complex > check_inv, confusion spells, > director, no_movement traps . You just 'plugs' in > the movement code. > > Also this system can improve server performances. > Currently, one of the main > 'lag' problem of server is meteor swarm in the open > areas. thousands of fire > elements are checking the object list on a given > square (that is other fire > elements) at a given tick, and this until fire dies > a few seconds later. > Now imagine this. > create a 'fire' arch at square X. > When inserted, arch code register a move_event for > the square and also analyse > immediatly content of square. > when new things are added to the square, the fire > can check immediatly if this > item can burn. Most of the time, there is nothing to > burn. > when the fire element gets activated avery X ticks, > it does not have to > explore a list of 100 other fire object to know > there is nothing burnable > where it belongs. > > Saying it's more important to add new features than > modularize the code is > simply a short term view. Since am part of this > projects, i saw new features > coming on a regular basis. Today the code, imho, is > far less maintanable > then it was 5 years ago. And if we continue to focus > on features without > architecture the code will be a blotted piece of > unmaintanable code in a few > years. > > If i remember well, Mark Wedel already had in the > past to request from > developper they spend more time on fixing the server > code then add new > features. There are tons of features in code map > maker simply don't know > about. > > Moreover there are tons of security issues in the > code. They could be isolated > and identified far more easily during a > reorganisation process. > > I hope we will ge to an agreement on this subject. > > > > > If you are going to go ahead with it, before you > do anything to the > > code you will need to define what goes out to what > modules, and what > > depends on what. Since CF was not designed to be > modular you may also > > find recursive dependancies which will need > resolving first. But I > > suspect you knew this already... > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > _______________________________________________ > 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 mikeeusaa at yahoo.com Mon Jan 16 11:47:16 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 16 12:02:20 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601161645.42852.tchize@myrealbox.com> Message-ID: <20060116174716.65116.qmail@web32711.mail.mud.yahoo.com> That is what the hurd project thought at the begining, the reality is diffrent. --- tchize wrote: > > > You forgot the other important point, modularity > reduces speed of > > development, sometimes catastroptically, you only > need to look at GNU > > Hurd for an example of that. > > i see the exact opposite of behaviour at work. > Project initiated in a modular > way, or migrated to a modular approach are easier to > manage for the following > reasons > 1) You don't need to have knowledge of how the whole > code works to be able to > work on parts of it > 2) You can isolate changes in only a part of the > code > > > > It strikes me that crossfire is (still) not yet > mature enough to have > > a fixed interface to all the modules that would be > used, only a couple > > of months ago all the python scripts were broken > by a plugin change, > > and I know I for one wouldn't want to attempt to > fix the weather > > 'module' the next time the interface to it was > broken. > > > > Architecture must be handled from the very beginning > and currently there is no > architecture design on crossfire project. A way to > structure things here is > suggested. This may not be the best approach, but > it's far better then what > we currently have. And nobody in the last year did > propose anything to fix > architecture problems in crossfire. > > And in modularized projects, the interfaces between > modules are not always > clear, they are not fixed and would probably never > been. Some code migrate > from one module to another after experience show it > is needed nearer to the > core, or on the opposite, it get further from the > core because it is not as > multipurpose as we may have thought in the begin. > Some modules sometimes get > gathered as a unique module. Some other gets > splitted in sub modules. That's > the lifecycle of a project. It works, and well. Yes > sometimes there are > clash, sometimes a very big change in a module is a > pain in the ass for all > people using the modules. But considering the gain, > in development speed, in > code learning curve and bugs hunting, it is clearly > worth it. > > You argue a change in 'core' could interfer with > 'weather' and you don't want > to fix weather if it gets broken by that change in > core? Well i claim, with > current organisation of code, a change *anywhere* in > code (not only what we > could define as core) can break the weather. (Or > potentially break anything > else). That is something a modularized approach > tends to prevent as much as > possible. And am not speaking of compilation here. > Compilation problems are > easy to solve. > > You could argue, currently, you can't make a change > in core that would make > weather uncompilable, which with a plugin system > could be possible. But, this > is not a difficult fix, the most difficult bugs to > fix are those which let > the code compilable but with subtle invalid logic. > And the last one happends > a lot in crossfire. > > regards > > _______________________________________________ > 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 yann.chachkoff at myrealbox.com Mon Jan 16 12:32:46 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Mon Jan 16 12:34:24 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <20060116174716.65116.qmail@web32711.mail.mud.yahoo.com> References: <20060116174716.65116.qmail@web32711.mail.mud.yahoo.com> Message-ID: <200601161932.54412.yann.chachkoff@myrealbox.com> Le Lundi 16 Janvier 2006 18:47, Miguel Ghobangieno a ?crit : > That is what the hurd project thought at the begining, > the reality is diffrent. > The Hurd project thought a microkernel architecture was interesting for reasons other than maintainability. It is also a stalling project for reasons unrelated to the concept of modularization itself. If you're to use examples to illustrate your thoughts, try to use one you really know and have an in-depth understanding of. -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060116/84e3d0e5/attachment.pgp From mikeeusaa at yahoo.com Mon Jan 16 14:20:14 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 16 14:31:12 2006 Subject: [crossfire] Polymorph etc Message-ID: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> About polymorph, I'd like that spell to be fixed/redone rather then removed. Would this be possible? (I suggest doing it the nethack way, the users doesn't have controll of what he morphs into and he morphs into a few things during the course of the spell). I also see no point in making working things plugins, it will make things slow, break things (and then it will be like "most servers (IE: not MF) don't use this, it's broken, let's chuck it). If Ryo etc want to work on something, as it seems he's itching to do, how about add a alchaholpercent variable and add the ability to get drunk? Or perhapse fix earthwall and the invisiblity spell (> tracker)? Better to fix what's broken then fix what's working (rather then break it and slow the server down). If someone want's to write plugin stuff how about add perl to the list of CF scripting languages? Any of these things would be a much more usefull waste of time, rather then breaking the server and slowing it down." __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaa at yahoo.com Mon Jan 16 14:24:14 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 16 14:31:15 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601161932.54412.yann.chachkoff@myrealbox.com> Message-ID: <20060116202414.80257.qmail@web32709.mail.mud.yahoo.com> Try not to dismiss things solely because they disagree with your opinion. Modularizing the server would create a ton of problems, breakage, and solve nothing and add even less: it is busy work. If you must be busy be busy on some new feature rather then scrapping the last 10 years of work (and that is what would happen if we seriously went on the modularizing war path). Things you can help add: plots (with red). drunkeness. work on regional fiat currencies. pilotable boats (new arch in addition to the exit boats we have), horses, etc. perl plugin? --- Yann Chachkoff wrote: > Le Lundi 16 Janvier 2006 18:47, Miguel Ghobangieno a > ?crit : > > That is what the hurd project thought at the > begining, > > the reality is diffrent. > > > The Hurd project thought a microkernel architecture > was interesting for > reasons other than maintainability. It is also a > stalling project for reasons > unrelated to the concept of modularization itself. > > If you're to use examples to illustrate your > thoughts, try to use one you > really know and have an in-depth understanding of. > -- > Yann Chachkoff > ----------------------- > Garden Dwarf's Best Friend > ----------------------- > GPG Key : > http://keyserver.veridis.com:11371/export?id=9080288987474372064 > Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 > AAB9 844D 25E0 > > _______________________________________________ > 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 fuchs.andy at gmail.com Mon Jan 16 14:58:46 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon Jan 16 15:00:25 2006 Subject: [crossfire] Polymorph etc In-Reply-To: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> References: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> Message-ID: On 1/16/06, Miguel Ghobangieno wrote: > About polymorph, I'd like that spell to be > fixed/redone rather then > removed. Would this be possible? (I suggest doing it > the nethack way, > the users doesn't have controll of what he morphs into > and he morphs > into a few things during the course of the spell). Players are unable to morph with the spell in its current state afaik. The spell can morph monsters and objects, and changes them into an other random arch (that is a monster or object respectively). It currently only morphs what it was casted on only once. > I also see no point in making working things plugins, > it will make > things slow, break things (and then it will be like > "most servers (IE: > not MF) don't use this, it's broken, let's chuck it). I would think that would be more of an issue of if it is used in the maps distributed with the game. As a side note, cat2 and MF seem to have around the same amount of active players (excluding bots) atm. > If Ryo etc want to work on something, as it seems he's > itching to do, > how about add a alchaholpercent variable and add the > ability to get > drunk? I wonder if that would be a good test case for moving things to plugins... > Or perhapse fix earthwall and the invisiblity > spell (> > tracker)? Better to fix what's broken then fix what's > working (rather > then break it and slow the server down). Its broken? Going to check when my brother gets off of the other box. > If someone want's to write plugin stuff how about add > perl to the list > of CF scripting languages? Any of these things would > be a much more > usefull waste of time, rather then breaking the server > and slowing it > down." Umm, afaik scripts slow the server down, when used. I think it may be a good idea to only have one or two scripting languages availibe for use with crossfire. (at least without a 3rd party plugin/patch) If two are used one should be made to execute more quickly and efficiently, but doesn't have to have many features, the other would have more capabilities. -- Andrew Fuchs From yann.chachkoff at myrealbox.com Mon Jan 16 15:23:05 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Mon Jan 16 15:24:25 2006 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1137446585.c7de7edcyann.chachkoff@myrealbox.com> > Try not to dismiss things solely because they disagree with your opinion. I dismissed a flawed analogy, based on wrong technical assumptions. It is not an opinion point, but rather the rebuttal of an out-of-topic flambait. > Modularizing the server would create a ton of >problems, Tons ? Name them, then, and we'll have something to debate. > breakage, Just as there is with *each* code change. Are you suggesting that we stop changing the code ? > and solve nothing As I (and others) argumented, it eases a couple of development issues. It could be a flawed view - but then, demonstrate it, and suggest other solutions. Note that those points weren't based on air, but on significant experience in other projects, not on "taste" or other egocentric or sentimental feelings. > and add even less: it is busy work. If you must be busy be busy on some new feature Given that you are not a coder, you have no right to decide for me what I should work on (Note that I usually don't follow such a philosophy - but since you expressed the exact same reasoning not so long ago, I find it appropriate to provide the same kind of answer now). >rather then scrapping the last 10 years of work (and that is what would happen if we seriously went on the modularizing war path). Why ? I see a rant based on a pure sentimental feeling from somebody who has little knowledge of the Crossfire code, or of C coding in general. Provide technical arguments, and we'll have a serious discussion. If you cannot, then stop spamming the list. Just as a side note, scrapping the whole code has never been the intend. Next time, try to understand the emails you read before flaming their content. > Things you can help add: Out-of-topic - we're discussing the pros/cons of modularization, not about your personal wishes about the code. From mwedel at sonic.net Mon Jan 16 15:29:17 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jan 16 15:32:25 2006 Subject: [crossfire] Polymorph etc In-Reply-To: References: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> Message-ID: <43CC102D.2060604@sonic.net> The main reason polymorph was disabled is that it was a money abuse. You get a pile of junk and polymorph it into something else that was worth more money. Various changes were put in place, so cursed items remained cursed, etc. But then it became that polymorph became pretty useless because you'd just get complete crap. Now, given past discussions about money and wealth, perhaps there isn't much a reason to be concerned about that items become marginally more valuable. As far as monsters - because there is no global list of monsters by level, it would just find all the monsters and choose one randomly. I think there was also the problem, at least related to monsters, that you'd zap that tough monster that is suppose to protect that super good treasure into some wimp you easily kill. If polymorph is redone, I'd suggest these changes: 1) Make up treasure lists (at least for monsters) in what things turn into. Thus, you could have a polymorph_monster_low (level 1-5), medium (5-10), etc. In that way, you'd get something different, but it wouldn't be really easy. As an aside, polymorph never worked with multipart monsters (either to/from) - would probably make sense to fix that. However, some flag would need to be added to say this monster can't be polymorphed, so you can't polymorph the super tough custom monsters into something else (maybe check the level of the wand/rod, and it can only polymorph things of lower level?) 2) For players, I don't think we can/should mess with the skills, as it gets tricky to set those back properly. It'd be fairly annoying to get a skill scroll of sorcery, but already having the skill, you toss it. But then you get polymorphed, and lose that skill, since it was a starting skill? Better to say that mentally, you have/know all the same stuff. I think you could change the race of a character - you could look at the archetype and stat bonuses and give the player new stat bonuses. 3) For objects, the old code would transform a weapon to a weapon, shield to shield, etc. The problem again was that there was no list, so it would just find all the armors in the archetypes and choose one randomly (thus, artifact weapons were much more likely to show up than you'd see in a map). What I'd suggest is use the treasurelist for the general store when transforming these objects. So that food may turn into a sword - it is polymorph after all. Have some objects just go away (evaporate). Some chance of a monster being created. Sure, the person may make some money off the deal, but this would probably be one of the less abusive ways. Perhaps limit the number of objects the wand will do on any space, so you can't pile 400 things on one space hoping for that one object - if it only did say 5 objects/space, given the value of the wand itself, might not be a money maker. Rods of polymorph should probably be strictly prohibited. From mwedel at sonic.net Mon Jan 16 15:48:42 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jan 16 15:50:25 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> Message-ID: <43CC14BA.2040306@sonic.net> Sorry, in the initial post I presumed it would be python, but a C plugin seems like a reasonable idea. For one thing, I can't imagine a C plugin ever not being able to be installed (unlike python where people could be lacking the libraries) That said, trying to figure out what is optional or not is difficult. I'd venture to say a lot of people would say the random maps really are not optional (or if those are optional, what else is optional, like shops, monsters, etc) I'd think that if there is a C plugin, aside from the different passing in of the values, and using appropriate callbacks for functions instead of calling them directly, it could access the function data directly? Eg, it should need to do a plugin callback to set the dam of an object, it could just set ob->dam? That said, the plugin itself won't fix all the ills. To do that, more radical changes are needed in the basic functions as is, and that will break things. For example, it was brought up the idea of meteor swarms and/or swimming. Doing those in plugins don't really fix anything. The basic problem here is that insert_ob_in_map() does a lot more than just puts the object on the map and links it up. It checks for move_on/move_off flags. It checks for merging. It checks if the object glows, and thus updates lighting, checks to see if it blocks movement/line of sight. It is those things which make a consistent behavior difficult (and also what causes meteor swarm to slow down the server). To be redesigned, insert_ob_in_map should just do only that. The functions that call it should make the other checks (can we merge with something on this space? should we check move_on status, etc). But making those type of changes is likely to result in breakage in various places (insert_ob_in_map is called in 146 places for example). Although, perhaps at a first pass, a new flag like INS_OBJ_ONLY_AND_DONT_DO_ANYTHING_ELSE could be added (ok, maybe a littler shorter, but you get the point). all that said, I do think it is fair to discuss other work to be done - if you have limited resources, it makes sense to discuss where those resources go. Yet at the same time, given this is a volunteer project, one can't really force anyone to do anything. From nicolas.weeger at laposte.net Mon Jan 16 15:53:30 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Jan 16 15:56:24 2006 Subject: [crossfire] Hardening plugin system In-Reply-To: <43CB4A6C.90806@sonic.net> References: <43C57A0D.6000006@laposte.net> <43C9CC73.5040505@sonic.net> <43CA169E.7040501@laposte.net> <43CB4A6C.90806@sonic.net> Message-ID: <43CC15DA.3070200@laposte.net> > If its a choice of: > > a) when callback to set value is used, we set the value and then mark a > flag that the object has been modified, and when function is finished, > we check sanity of object, > > or > > b) when callback to set value is made, we check the validity > > I'd personally choose b - detecting the error right when it happens is > always better - it makes it easier to fix the problem. Actually, i'd chose b too - i think i meant that, when plugin finished, server can send fix_player or fix_object to the client, meaning the plugin can just not care. > but at some level, it can never be 100% foolproof. The fact the server > crashes occasionally is proof that even the C code isn't foolproof. You > get the complications of some value being valid for one object type, but > not another, and I don't think there is any real way that can ever be > checked (but that same problem occurs in maps also - mapmaker could set > some value to something invalid) True. Guess there should be checks at many levels in the plugin code :) (server <-> common plugin lib <-> Pyhton plugin for instance) Nicolas From nicolas.weeger at laposte.net Mon Jan 16 16:06:11 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Jan 16 16:06:43 2006 Subject: [crossfire] Polymorph etc In-Reply-To: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> References: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> Message-ID: <43CC18D3.2090602@laposte.net> > If Ryo etc want to work on something, as it seems he's > itching to do, > how about add a alchaholpercent variable and add the > ability to get > drunk? Or perhapse fix earthwall and the invisiblity > spell (> > tracker)? Better to fix what's broken then fix what's > working (rather > then break it and slow the server down). > > If someone want's to write plugin stuff how about add > perl to the list > of CF scripting languages? Any of these things would > be a much more > usefull waste of time, rather then breaking the server > and slowing it > down." Sure, i'll do it - lemme just confirm the money has correctly been transferred from your account to mine :) Nicolas From nicolas.weeger at laposte.net Mon Jan 16 16:13:06 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Jan 16 16:14:25 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43CB46BE.3070303@sonic.net> References: <43CA5317.5070207@laposte.net> <43CB46BE.3070303@sonic.net> Message-ID: <43CC1A72.4030305@laposte.net> > I personally don't see much reason to rewrite existing code that is > working fine as a plugin. There are just enough things that could > be/should be done than rewriting working code doesn't make sense. As Yann said, i was not really mentioning rewriting stuff - apologies for the confusion. Weather system, for instance, could be put in a plugin, and still retain its functionnality - talking about it because it's currently half broken, and not always enabled, depending on servers. Nicolas From yann.chachkoff at myrealbox.com Mon Jan 16 17:11:31 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Mon Jan 16 17:12:25 2006 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1137453091.c7d9bd9cyann.chachkoff@myrealbox.com> > Sorry, in the initial post I presumed it would be python, but a C plugin seems like a reasonable idea. Yep, I easily understand the confusion, given that for the most part, the Python plugin was the only one widely used (Actually, it is the Crossfire-Python "bridge" itself that is the plugin, not the scripts it allows to run). > For one thing, I can't imagine a C plugin ever not being able to be installed (unlike python where people could be lacking the libraries) Well, it really depends on what the C code requires as dependencies - the Python plugin has one with the python libs for example. But stuff that was initially in the server code would have no such external dependencies indeed. > That said, trying to figure out what is optional or not is difficult. I'd venture to say a lot of people would say the random maps really are not optional (or if those are optional, what else is optional, like shops, monsters, etc) Well, I don't think we should actually draw a line between what is optional or not in gaming terms, because basically nearly everything actually in the server code could be considered as "core" in that respect. On the other hand, I think splitting the code in "logical entities", more or less independent of the others, would be a path of thinking to try. As such, random maps would appear as a good target for modularization, since it doesn't really depend on anything else, apart from very basical operations, and is called only at a few places. Alchemy would be another good candidate - both are very important in the game, yet are working very much like "black boxes" - complex code with relatively limited interactions with the rest of the code. > I'd think that if there is a C plugin, aside from the different passing in of the values, and using appropriate callbacks for functions instead of calling them directly, it could access the function data directly? Eg, it should need to do a plugin callback to set the dam of an object, it could just set ob->dam? Theorically, yes: there's nothing preventing such a thing. Wrapping such access behind functions was basically to allow checking that the values passed were in the correct range, and to provide encapsulation of the data (so that a plugin wouldn't get tempted to directly change fields it wasn't supposed to change without a high risk) > That said, the plugin itself won't fix all the ills. That's true. It is a way to make some things easier, but it is definitely not a magical answer to all problems. My opinion is that it would make the code cleaning/maintenance easier, but it will certainly not do that maintenance by itself. > To do that, more radical changes are needed in the basic functions as is, and that will break things. Sure ! But I think such changes would be easier to make if the code was, in a way or another, "split" into smaller entities, so that they affect only a limited part of it. And indeed, a lot of functions would benefit from some in-depth rebuilding. Also, part of the problems of code debugging/maintenance come to how things are distributed all around the code - finding where to add/change things is a rather complex task. Making small changes to make the code more "readable" and "editable" would thus be another important point to achieve, IMHO. > all that said, I do think it is fair to discuss other work to be done - if you have limited resources, it makes sense to discuss where those resources go. Indeed, it does - as long as it stays a reasoned discussion attempting to find the best solution, and not a collection of ignorant rants and ridiculous analogies. I'm tired of having to read such useless things, which (un)surprizingly always come from the same person. > Yet at the same time, given this is a volunteer project, one can't really force anyone to do anything. Yes, although I understand the urge that many people have to see some funny/interesting ideas implemented. Simply, there is a civilized way to ask for those, a way that unfortunately not everybody seems to have understood. From brenlally at gmail.com Mon Jan 16 17:55:48 2006 From: brenlally at gmail.com (Brendan Lally) Date: Mon Jan 16 17:56:30 2006 Subject: [crossfire] gcfclient options deathlist Message-ID: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> I have been poking around gcfclient recently, and found a lot of options that seem to be at best of limited use, and possibly never used by anyone, so what I have done, is created a list of the options in gcfclient's settings menus which I believe are unused, or always set to the same value. I am going to list the option, as well as what I think it should be set to. If anyone wishes an option listed here kept, they can reply claiming their use/need of it. If after 2 weeks, no one has 'claimed' an option, then I argue that it can be assumed to be safe to remove. As long as each change is made as a seperate CVS commit, it is still going to be relatively easy to revert any such changes made, should someone wish to have a setting return: The list; Automatically re-applies a container when you use apply to close it. If off, when you use apply to close the container, it stays unapplied - set to always be on Colored Inventory Lists - set to always on. Colored Information Text - set to always on Options on how to display resistances: - remove all options, set to "Display all resistances in a single column, will use a single scrollbar." Print Grid Overlay (SDL only, Slow, useful for debugging/development) - set to off Cache Images - set to on Split Information Window (Takes effect next run) - set to on From leaf at real-time.com Mon Jan 16 18:05:10 2006 From: leaf at real-time.com (Rick Tanner) Date: Mon Jan 16 18:06:25 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> References: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> Message-ID: <43CC34B6.6030108@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Would it be OT or out of scope to ask for the "File -> Quit Character" option in the menu to be renamed to "File -> Delete Character" ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDzDS1hHyvgBp+vH4RAjEfAJ4mH8tcfuQsSYaqlTCvIyZZTli7SQCg/XZp l+8IIsamAYZooFHSSJEvWw4= =tDFE -----END PGP SIGNATURE----- From brenlally at gmail.com Mon Jan 16 19:06:01 2006 From: brenlally at gmail.com (Brendan Lally) Date: Mon Jan 16 19:06:25 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <43CC34B6.6030108@real-time.com> References: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> <43CC34B6.6030108@real-time.com> Message-ID: <7903f03c0601161706k77f808c5n813b1a4800fb759b@mail.gmail.com> On 1/17/06, Rick Tanner wrote: > Would it be OT or out of scope to ask for the "File -> Quit Character" > option in the menu to be renamed to "File -> Delete Character" ? Well, it wouldn't be if you instead suggested that the menu entry be removed altogether. I'm inclined to think that the better option, it isn't as though the quit command should be used particularly often. From mikeeusaa at yahoo.com Mon Jan 16 19:51:49 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 16 22:13:21 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1137446585.c7de7edcyann.chachkoff@myrealbox.com> Message-ID: <20060117015149.14824.qmail@web32704.mail.mud.yahoo.com> I suggest you not implement a huge worthless code change that is nothing but busy work. I reject your assertion that cave's analogy is flawed as it is not. If you want to code code something new useful rather then breaking the server as is what will happen if you go forward with this plan. You also will be holding off any new large codechanges for months as they wait for you to be done with this not-needed reshuffling. --- Yann Chachkoff wrote: > > Try not to dismiss things solely because they > disagree with your opinion. > > I dismissed a flawed analogy, based on wrong > technical assumptions. It is not an opinion point, > but rather the rebuttal of an out-of-topic flambait. > > > Modularizing the server would create a ton of > >problems, > > Tons ? Name them, then, and we'll have something to > debate. > > > breakage, > > Just as there is with *each* code change. Are you > suggesting that we stop changing the code ? > > > and solve nothing > > As I (and others) argumented, it eases a couple of > development issues. It could be a flawed view - but > then, demonstrate it, and suggest other solutions. > > Note that those points weren't based on air, but on > significant experience in other projects, not on > "taste" or other egocentric or sentimental feelings. > > > and add even less: it is busy work. If you must be > busy be busy on some new feature > > Given that you are not a coder, you have no right to > decide for me what I should work on (Note that I > usually don't follow such a philosophy - but since > you expressed the exact same reasoning not so long > ago, I find it appropriate to provide the same kind > of answer now). > > >rather then scrapping the last 10 years of work > (and that is what would happen if we seriously went > on the modularizing war path). > > Why ? I see a rant based on a pure sentimental > feeling from somebody who has little knowledge of > the Crossfire code, or of C coding in general. > Provide technical arguments, and we'll have a > serious discussion. If you cannot, then stop > spamming the list. > > Just as a side note, scrapping the whole code has > never been the intend. Next time, try to understand > the emails you read before flaming their content. > > > Things you can help add: > > Out-of-topic - we're discussing the pros/cons of > modularization, not about your personal wishes about > the code. > > > _______________________________________________ > 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 mikeeusaa at yahoo.com Mon Jan 16 19:53:37 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 16 22:13:24 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1137446585.c7de7edcyann.chachkoff@myrealbox.com> Message-ID: <20060117015337.27907.qmail@web32706.mail.mud.yahoo.com> I suggest you not implement a huge worthless code change that is nothing but busy work. I reject your assertion that cave's analogy is flawed as it is not. If you want to code then code something new useful rather then breaking the server as is what will happen if you go forward with this plan. You also will be holding off any new large codechanges for months as they wait for you to be done with this not-needed reshuffling. --- Yann Chachkoff wrote: > > Try not to dismiss things solely because they > disagree with your opinion. > > I dismissed a flawed analogy, based on wrong > technical assumptions. It is not an opinion point, > but rather the rebuttal of an out-of-topic flambait. > > > Modularizing the server would create a ton of > >problems, > > Tons ? Name them, then, and we'll have something to > debate. > > > breakage, > > Just as there is with *each* code change. Are you > suggesting that we stop changing the code ? > > > and solve nothing > > As I (and others) argumented, it eases a couple of > development issues. It could be a flawed view - but > then, demonstrate it, and suggest other solutions. > > Note that those points weren't based on air, but on > significant experience in other projects, not on > "taste" or other egocentric or sentimental feelings. > > > and add even less: it is busy work. If you must be > busy be busy on some new feature > > Given that you are not a coder, you have no right to > decide for me what I should work on (Note that I > usually don't follow such a philosophy - but since > you expressed the exact same reasoning not so long > ago, I find it appropriate to provide the same kind > of answer now). > > >rather then scrapping the last 10 years of work > (and that is what would happen if we seriously went > on the modularizing war path). > > Why ? I see a rant based on a pure sentimental > feeling from somebody who has little knowledge of > the Crossfire code, or of C coding in general. > Provide technical arguments, and we'll have a > serious discussion. If you cannot, then stop > spamming the list. > > Just as a side note, scrapping the whole code has > never been the intend. Next time, try to understand > the emails you read before flaming their content. > > > Things you can help add: > > Out-of-topic - we're discussing the pros/cons of > modularization, not about your personal wishes about > the code. > > > _______________________________________________ > 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 mikeeusaa at yahoo.com Mon Jan 16 19:56:07 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 16 22:13:27 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43CC1A72.4030305@laposte.net> Message-ID: <20060117015607.18626.qmail@web32705.mail.mud.yahoo.com> It is not half broken as far as I can tell. Yes it's not running on MF, that doesn't mean it's broken. It gives few problems on Cat2. This whole thing is about slowly dumping whatever MF doesn't use. Open your eyes, the 2nd biggest server runs weather code at it's most extreme, in terms of players that's not "a few". (Sure most servers don't run weather, but most servers are at 0 players also). --- Nicolas Weeger wrote: > > I personally don't see much reason to rewrite > existing code that is > > working fine as a plugin. There are just enough > things that could > > be/should be done than rewriting working code > doesn't make sense. > > As Yann said, i was not really mentioning rewriting > stuff - apologies > for the confusion. > Weather system, for instance, could be put in a > plugin, and still retain > its functionnality - talking about it because it's > currently half > broken, and not always enabled, depending on > servers. > > Nicolas > > _______________________________________________ > 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 mikeeusaa at yahoo.com Mon Jan 16 20:06:15 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 16 22:13:33 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> Message-ID: <20060117020615.22637.qmail@web32705.mail.mud.yahoo.com> Cached images are bad (for me). I always have this set off so I get updates from the server. So keep that. I also set the container thing too, the default setting doesn't work well and I set it to whatever the other setting is. SDL grid doesn't work IIRC (last time I tried). > Options on how to display resistances: - remove all > options, set to > "Display all resistances in a single column, will > use a single > scrollbar." I use these. Some people do use the split window stuff. I'd say keep the client as is. What new users seem to want is better mouse support in it (click here, go here). --- Brendan Lally wrote: > I have been poking around gcfclient recently, and > found a lot of > options that seem to be at best of limited use, and > possibly never > used by anyone, so what I have done, is created a > list of the options > in gcfclient's settings menus which I believe are > unused, or always > set to the same value. I am going to list the > option, as well as what > I think it should be set to. > > If anyone wishes an option listed here kept, they > can reply claiming > their use/need of it. If after 2 weeks, no one has > 'claimed' an > option, then I argue that it can be assumed to be > safe to remove. As > long as each change is made as a seperate CVS > commit, it is still > going to be relatively easy to revert any such > changes made, should > someone wish to have a setting return: > > The list; > > Automatically re-applies a container when you use > apply to close it. > If off, when you use apply to close the container, > it stays unapplied > - set to always be on > > Colored Inventory Lists - set to always on. > > Colored Information Text - set to always on > > Options on how to display resistances: - remove all > options, set to > "Display all resistances in a single column, will > use a single > scrollbar." > > Print Grid Overlay (SDL only, Slow, useful for > debugging/development) > - set to off > > Cache Images - set to on > > Split Information Window (Takes effect next run) - > set to on > > _______________________________________________ > 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 mikeeusaa at yahoo.com Mon Jan 16 20:08:14 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 16 22:13:36 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> Message-ID: <20060117020814.42167.qmail@web32710.mail.mud.yahoo.com> Update about cached images, if we have checksumming (not sure if we do) that will update the cached image if said image is out of date, then cached images should be set to on as that will decrease bandwith usage. --- Brendan Lally wrote: > I have been poking around gcfclient recently, and > found a lot of > options that seem to be at best of limited use, and > possibly never > used by anyone, so what I have done, is created a > list of the options > in gcfclient's settings menus which I believe are > unused, or always > set to the same value. I am going to list the > option, as well as what > I think it should be set to. > > If anyone wishes an option listed here kept, they > can reply claiming > their use/need of it. If after 2 weeks, no one has > 'claimed' an > option, then I argue that it can be assumed to be > safe to remove. As > long as each change is made as a seperate CVS > commit, it is still > going to be relatively easy to revert any such > changes made, should > someone wish to have a setting return: > > The list; > > Automatically re-applies a container when you use > apply to close it. > If off, when you use apply to close the container, > it stays unapplied > - set to always be on > > Colored Inventory Lists - set to always on. > > Colored Information Text - set to always on > > Options on how to display resistances: - remove all > options, set to > "Display all resistances in a single column, will > use a single > scrollbar." > > Print Grid Overlay (SDL only, Slow, useful for > debugging/development) > - set to off > > Cache Images - set to on > > Split Information Window (Takes effect next run) - > set to on > > _______________________________________________ > 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 mikeeusaa at yahoo.com Mon Jan 16 20:11:07 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 16 22:13:38 2006 Subject: [crossfire] Polymorph etc In-Reply-To: <43CC18D3.2090602@laposte.net> Message-ID: <20060117021107.25230.qmail@web32703.mail.mud.yahoo.com> When you break the server with this plugin idea besure to send us all 3 thousand dollars. :) (sarcastic smiley face). If it's going to be like that it goes both ways. --- Nicolas Weeger wrote: > > If Ryo etc want to work on something, as it seems > he's > > itching to do, > > how about add a alchaholpercent variable and add > the > > ability to get > > drunk? Or perhapse fix earthwall and the > invisiblity > > spell (> > > tracker)? Better to fix what's broken then fix > what's > > working (rather > > then break it and slow the server down). > > > > If someone want's to write plugin stuff how about > add > > perl to the list > > of CF scripting languages? Any of these things > would > > be a much more > > usefull waste of time, rather then breaking the > server > > and slowing it > > down." > > Sure, i'll do it - lemme just confirm the money has > correctly been > transferred from your account to mine :) > > Nicolas > > _______________________________________________ > 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 alex_sch at telus.net Mon Jan 16 22:45:29 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon Jan 16 22:46:25 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> References: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> Message-ID: <43CC7669.9080805@telus.net> Brendan Lally wrote: >I have been poking around gcfclient recently, and found a lot of >options that seem to be at best of limited use, and possibly never >used by anyone, so what I have done, is created a list of the options >in gcfclient's settings menus which I believe are unused, or always >set to the same value. I am going to list the option, as well as what >I think it should be set to. > >.... > >Split Information Window (Takes effect next run) - set to on > I used to use "Split Information Window", though I've changed my mind since then, however it might be worth considering keeping as there might be some people who prefer it like I used to. Not really sure, but I would say it's probably more useful to change than the others in the list. Alex Schultz From alex_sch at telus.net Mon Jan 16 23:03:02 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon Jan 16 23:04:25 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> Message-ID: <43CC7A86.8060208@telus.net> Frankly, I have to agree with mikee to some degree on this point. I generally have little trouble finding something after a combination of getting a feel for the code, which I have gotten pretty good for a while now, as well as skilled grepping. However aside from some things like this, I do find modularization can have merits, it just depends on 1) How much effort it takes to modularize, 2) How effective the modularization API is designed (i.e. currently the existing plugin API is vastly insufficient for server modularization) and 3) Where we draw the line of what to modularize. Personally, I don't think we should modularize very much, but if the API is good enough (which I would likely be picky about myself), then it might be worth doing for a limited number of things. Alex Schultz Miguel Ghobangieno wrote: >I have to do the same thing when I am adding things to >my perl rpg (which is not smaller in lines of code >then crossfire). It's not a big hassle, and how else >will the code know what's going on? Use grep. > >--- tchize wrote: > >>Speaking of my experience with crossfire code. I >>have developped >>a few add-ons to crossfire in the past (don't >>remember the list). >>From my point of view, adding new features in the >>code is currently >>a pain in the ass. I have dropped features add-ons >>which took >>me lots of time simply because it has become nearly >>impossible to find >>something in the code. >> From alex_sch at telus.net Mon Jan 16 23:12:20 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon Jan 16 23:12:24 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43CC14BA.2040306@sonic.net> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <43CC14BA.2040306@sonic.net> Message-ID: <43CC7CB4.8070602@telus.net> Mark Wedel wrote: > That said, trying to figure out what is optional or not is > difficult. I'd venture to say a lot of people would say the random > maps really are not optional (or if those are optional, what else is > optional, like shops, monsters, etc) Indeed. On this example, IMHO random maps are not optional, as they are essential to some quests, and also soon would be used by land plots (though land plots would in my opinion be a relatively good thing to implement as an optional-but-defaultly-on C plugin) > > I'd think that if there is a C plugin, aside from the different > passing in of the values, and using appropriate callbacks for > functions instead of calling them directly, it could access the > function data directly? Eg, it should need to do a plugin callback to > set the dam of an object, it could just set ob->dam? Personally, I think that a C plugin interface for modularization, it should provide full direct access to the data, though recommend use of wrappers functions unless you know it's safe. > > That said, the plugin itself won't fix all the ills. > > To do that, more radical changes are needed in the basic functions as > is, and that will break things. > > For example, it was brought up the idea of meteor swarms and/or > swimming. Doing those in plugins don't really fix anything. Indeed. Alex Schultz From alex_sch at telus.net Mon Jan 16 23:20:00 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon Jan 16 23:20:25 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <20060117020615.22637.qmail@web32705.mail.mud.yahoo.com> References: <20060117020615.22637.qmail@web32705.mail.mud.yahoo.com> Message-ID: <43CC7E80.6080206@telus.net> Miguel Ghobangieno wrote: >Cached images are bad (for me). I always have this set >off so I get updates from the server. So keep that > Umm.... It seems you're unaware that the protocol is set up so the client always looks at a checksum of the image in case it's been updated. Alex Schultz From eracclists at bellsouth.net Mon Jan 16 23:19:33 2006 From: eracclists at bellsouth.net (ERACC) Date: Mon Jan 16 23:20:29 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> References: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> Message-ID: <200601162319.34976.eracclists@bellsouth.net> On Monday 16 January 2006 05:55 pm Brendan Lally wrote: [...] > Options on how to display resistances: - remove all options, set to > "Display all resistances in a single column, will use a single > scrollbar." [...] I use a double column with a scroll bar. I do not like the single column. Gene -- Mandriva Linux release 2006.0 (Official) for i586 23:18:28 up 3 days, 6:11, 10 users, load average: 0.06, 0.07, 0.03 ERA Computer Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer & UnixWare resellers From mikeeusaa at yahoo.com Mon Jan 16 22:26:55 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon Jan 16 23:32:48 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <7903f03c0601161706k77f808c5n813b1a4800fb759b@mail.gmail.com> Message-ID: <20060117042655.52470.qmail@web32708.mail.mud.yahoo.com> Yes, it would be best to remove that option from the menu IMHO. Could we also make quit ask the person if they really want to delete their character (and then ask again for confirmation)? (server side). --- Brendan Lally wrote: > On 1/17/06, Rick Tanner wrote: > > Would it be OT or out of scope to ask for the > "File -> Quit Character" > > option in the menu to be renamed to "File -> > Delete Character" ? > > Well, it wouldn't be if you instead suggested that > the menu entry be > removed altogether. > > I'm inclined to think that the better option, it > isn't as though the > quit command should be used particularly often. > > _______________________________________________ > 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 Tue Jan 17 01:00:41 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue Jan 17 01:02:24 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1137453091.c7d9bd9cyann.chachkoff@myrealbox.com> References: <1137453091.c7d9bd9cyann.chachkoff@myrealbox.com> Message-ID: <43CC9619.1000202@sonic.net> Yann Chachkoff wrote: > > Well, it really depends on what the C code requires as dependencies - the > Python plugin has one with the python libs for example. But stuff that was > initially in the server code would have no such external dependencies indeed. True. I imagine dependencies to be fairly standard C dependencies. But I could imagine someone writing a plugin in C++ with appropriate wrappers. > > On the other hand, I think splitting the code in "logical entities", more or > less independent of the others, would be a path of thinking to try. As such, > random maps would appear as a good target for modularization, since it > doesn't really depend on anything else, apart from very basical operations, > and is called only at a few places. Alchemy would be another good candidate - > both are very important in the game, yet are working very much like "black > boxes" - complex code with relatively limited interactions with the rest of > the code. Agree. And in fact, any object that does something 'interesting' when applied could be a plugin, since most such objects are also very well self contained. However, I'd counter that if it is just 20 lines of C code to do that 'whatever', it could be more convenient to just add that 20 lines to apply.c I say this because I imagine plugins would probably be organized by plugin/C/. Maybe have one directory for basic plugins (one in which the entier plugin is in one file). But if plugin grows to the extent that there are 50 'trivial' plugins, one could say finding the code there isn't any more convenient than having it sit in apply.c > >> I'd think that if there is a C plugin, aside from the different passing in >> of the values, and using appropriate callbacks for functions instead of >> calling > them directly, it could access the function data directly? Eg, it should need > to do a plugin callback to set the dam of an object, it could just set > ob->dam? > > Theorically, yes: there's nothing preventing such a thing. Wrapping such > access behind functions was basically to allow checking that the values > passed were in the correct range, and to provide encapsulation of the data > (so that a plugin wouldn't get tempted to directly change fields it wasn't > supposed to change without a high risk) I'd imagine it is more important for the plugin wrapper to provide a consistent interface to the various functions, so that if a function handling changes in the C code (say a function now takes another argument), that all the plugins don't have to be rewritten - they can keep using the existing code, with the wrapper just passing in some default value. > > Sure ! But I think such changes would be easier to make if the code was, in a > way or another, "split" into smaller entities, so that they affect only a > limited part of it. And indeed, a lot of functions would benefit from some > in-depth rebuilding. Also, part of the problems of code debugging/maintenance > come to how things are distributed all around the code - finding where to > add/change things is a rather complex task. Making small changes to make the > code more "readable" and "editable" would thus be another important point to > achieve, IMHO. True - some functions have grown a bit in complexity and could certainly use a rewrite. And I could envision doing some things as plugins would make some things easier/more modular (Going back to what someone said, objects that the player uses are complicated - need to update the apply code, but depending on the object, may also need to update the code that actually describes the item - I could see with appropriate plugin support, all that could be done in the plugin, so all code related to that object is in one place) From mwedel at sonic.net Tue Jan 17 01:09:56 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue Jan 17 01:12:25 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> References: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> Message-ID: <43CC9844.5070707@sonic.net> Brendan Lally wrote: I have to admit that I've put most of those options in, but I've been using the gtkv2 client recently, so don't care as much ,but some notes: > The list; > > Automatically re-applies a container when you use apply to close it. > If off, when you use apply to close the container, it stays unapplied > - set to always be on I like it so that if I apply the container when it is open, it goes closed. It going to the applied state I found annoying. Not sure if that is what you describe. > > Colored Inventory Lists - set to always on. > > Colored Information Text - set to always on Can't see much an issue. These _might_ have been left over back in the day when you could play crossfire on a black and white screen. I don't know if anyone even has black and white screens anymore. That said, in my ideal world, you could set the color/font _you_ want to use for the different messages. And if that is done, this really isn't important - you'd just set your config so text is always black or whatever. > > Options on how to display resistances: - remove all options, set to > "Display all resistances in a single column, will use a single > scrollbar." I personally used two columns for output on my system. From yann.chachkoff at myrealbox.com Tue Jan 17 01:45:03 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Tue Jan 17 01:46:25 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> References: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> Message-ID: <200601170845.08377.yann.chachkoff@myrealbox.com> Le Mardi 17 Janvier 2006 00:55, Brendan Lally a ?crit : > I have been poking around gcfclient recently, and found a lot of > options that seem to be at best of limited use, and possibly never > used by anyone, so what I have done, is created a list of the options > in gcfclient's settings menus which I believe are unused, or always > set to the same value. I am going to list the option, as well as what > I think it should be set to. > > If anyone wishes an option listed here kept, they can reply claiming > their use/need of it. If after 2 weeks, no one has 'claimed' an > option, then I argue that it can be assumed to be safe to remove. As > long as each change is made as a seperate CVS commit, it is still > going to be relatively easy to revert any such changes made, should > someone wish to have a setting return: > > The list; > > Automatically re-applies a container when you use apply to close it. > If off, when you use apply to close the container, it stays unapplied > - set to always be on > - I've always preferred to deactivate this. > Colored Inventory Lists - set to always on. > Colored Information Text - set to always on > - Agree with those. > Options on how to display resistances: - remove all options, set to > "Display all resistances in a single column, will use a single > scrollbar." > - Disagree - I prefer being able to hide that information completely. Maybe it would also be nice to display that information in two columns, so that it takes less space vertically. > Print Grid Overlay (SDL only, Slow, useful for debugging/development) > - set to off > > Cache Images - set to on > > Split Information Window (Takes effect next run) - set to on > Agree with those. I'd also suggest to remove the "Splash Window" option (and set it to "on" by default): I'm doubtful it is highly used. -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060117/e8171e98/attachment.pgp From yann.chachkoff at myrealbox.com Tue Jan 17 02:49:07 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Tue Jan 17 02:50:26 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43CC7A86.8060208@telus.net> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <43CC7A86.8060208@telus.net> Message-ID: <200601170949.13597.yann.chachkoff@myrealbox.com> Le Mardi 17 Janvier 2006 06:03, Alex Schultz a ?crit : > Frankly, I have to agree with mikee to some degree on this point. I > generally have little trouble finding something after a combination of > getting a feel for the code, which I have gotten pretty good for a while > now, as well as skilled grepping. > "Finding something" is not really that difficult. However, adding new things often is, because it is not uncommon to have to modify the code at several different places. I see this as inherently bad - if I want to implement a new object type for example, I'd prefer putting its whole code in a single place than having to edit several source files (some being in common/, others being in server/). Of course, a skilled coder that has got a good knowledge of the Crossfire code generally has little difficulty to find its way through the code - but not every contributor can/wants to afford the time required to get that in-depth knowledge of the code; besides that, having to play with grep to find the relevant piece of code is already a failure in itself, IMHO: if even somebody used to the source has to rely on a search engine to find its way through it, can we consider there is no problem ? > However aside from some things like this, I do find modularization can > have merits, it just depends on 1) How much effort it takes to > modularize, > It actually depends on the level of control you want to grant to the plugins. The most extreme case would be to export all the functions currently in the code - to do that, you'll have to provide a wrapper for each function you want to export. That's a lot of functions, but let's not forget that a significant part of those are only used by specific pieces of the code, so the actual useful number is definitely lower than that by a significant margin. As for the code located in the module itself, there would be little to change; at most, the function names being called (to call the wrappers instead), and the initialization/termination code (which will quite probably be the same in most cases). > 2) How effective the modularization API is designed (i.e. > currently the existing plugin API is vastly insufficient for server > modularization) > I think it is unsufficient for two reasons: (a) The API provided to plugins is not complete enough; (b) There are no ways for a plugin to interact with the server outside of the local/global events. I think (a) can be completed as modularization advances - if I tried to make a plugin out of alchemy, I'd check all the "external dependencies", then move them into the plugin API if required. It however means that the API will be an evolving target as long as modularization is in its early stages, though. As for (b), as I said earlier, I think it can be solved by offering to plugins the possibility to hook themselves to some often used functions in the code. In such a case, I think the plugin code should get hooked by callbacks contained in objects whenever possible (so, instead of calling apply(op) and make a switch(op->type) in apply, the specific behavior of op would be directly bound into the object as a callback and called by op->apply(op)). In that scenario, there would be no overhead involved when compared to the current situation - it would basically replace a switch statement by a function call. > and 3) Where we draw the line of what to modularize. > I'm not sure a line has to be drawn to what/what not modularize. I think a more important question is: to what level should the modularization take place ? I don't think there are simple answer to those questions. I'm not even sure answering them in a definitive, strict way is really required. > Personally, I don't think we should modularize very much, but if the API > is good enough (which I would likely be picky about myself), then it > might be worth doing for a limited number of things. > > Indeed. On this example, IMHO random maps are not optional, as they are > essential to some quests, and also soon would be used by land plots > (though land plots would in my opinion be a relatively good thing to > implement as an optional-but-defaultly-on C plugin) > Note that "optional/necessary for some quests" should not be a critera for modularization IMHO, because it is one you can use to justify nearly every function implemented in the game. On the other hand, the "optional/necessary for the server to run" sounds much more relevant. Can the server work without random maps ? Of course - it simply means that the maps using that feature will not work, but the others will be completely unaffected. It has no impact on the gaming rules, and no influence on the characters. > Personally, I think that a C plugin interface for modularization, it > should provide full direct access to the data, though recommend use of > wrappers functions unless you know it's safe. > Nothing currently prevents a plugin to modify the data it has access to directly - but of course, that's unsafe access, so if the plugin makes a bad modification to the data, or forgets to notify the server of it if necessary, then it will probably crash the server. Accessing data directly or through wrappers is basically a tradeoff between performances and security. In the case of modularization of the existing code, I'd say that direct access wherever possible should be kept - accessors for such data modifications would probably be used only for debugging purposes (as a wrapper can check if the data modification is "legal" or not, and thus can help detecting a whole range of errors). -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060117/b55430ba/attachment.pgp From yann.chachkoff at myrealbox.com Tue Jan 17 03:09:04 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Tue Jan 17 03:10:26 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <20060117015607.18626.qmail@web32705.mail.mud.yahoo.com> References: <20060117015607.18626.qmail@web32705.mail.mud.yahoo.com> Message-ID: <200601171009.05273.yann.chachkoff@myrealbox.com> Le Mardi 17 Janvier 2006 02:56, Miguel Ghobangieno a ?crit : > It is not half broken as far as I can tell. Yes it's > not running on MF, that doesn't mean it's broken. > So having trees growing on sea squares isn't broken ? > It gives few problems on Cat2. This whole thing is about > slowly dumping whatever MF doesn't use. > It is not about "moving code out of Crossfire", but about "re-organizing it so it is easier to manage". Which, as a side note, should help debugging chunks like the weather system and provide fixes without even having to rebuild and restart the whole server. If you read what I typed earlier, you'd note that I think random maps should get modularized as well - and AFAIK, it is used extensively on MF. Let's repeat it again: modularizing code is *not* about removing functionalities; it is *not* about scrapping code out of the main CVS tree. It is mostly a structural change to make an easier maintenance for those wanting to work on such pieces of code - so it is in fact a way to make them *better* supported. > Open your eyes, the 2nd biggest server runs weather code at it's > most extreme, in terms of players that's not "a few". > That there are many players on Cat2 doesn't make the weather system less broken. > I suggest you not implement a huge worthless code change that is nothing but busy work. > That's indeed an opinion based on emotion rather than facts, unfortunately. > I reject your assertion that cave's analogy is flawed as it is not. > Tell me how it isn't, then, or stop the "nah, nah, nah" song. > If you want to code code something new useful rather then breaking the server as is what will happen if you go forward with this plan. > Breaking the server always occur when a new functionality that is larger than a few lines of code is implemented (everybody makes mistakes, even skilled coders). And given that I see it as useful, I would have no problem "breaking it". > You also will be holding off any new large codechanges for months as they wait for you to be done with this not-needed reshuffling. > I don't see why. Moving existing parts of the code into modules doesn't mean development on other parts of the code would suddenly be halted "for months". And I could return you the argument: the completely optional "get drunk when drinking" functionality you suggested would block the more important restructuration of the code, probably for a couple of weeks - where's the difference ? You could of course object that "players want to get drunk, but don't give a damn about an obscure change in the code". Presented like that, sure. But wouldn't a server that is easier to maintain, debug, and extend have a more in-depth impact on the players in particular, and the game interest in general ? I think it does, even if it means that the priority is set on changes that are not immediately visible to players. -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060117/19945b4c/attachment-0001.pgp From tchize at myrealbox.com Tue Jan 17 04:05:10 2006 From: tchize at myrealbox.com (tchize) Date: Tue Jan 17 04:06:35 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43CC7CB4.8070602@telus.net> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <43CC14BA.2040306@sonic.net> <43CC7CB4.8070602@telus.net> Message-ID: <200601171105.10762.tchize@myrealbox.com> Le Mardi 17 Janvier 2006 06:12, Alex Schultz a ?crit : > Indeed. On this example, IMHO random maps are not optional, as they are > essential to some quests, and also soon would be used by land plots > (though land plots would in my opinion be a relatively good thing to > implement as an optional-but-defaultly-on C plugin) > IMHO they are optional, they are mandatory to use the current map set, that is true, but that just mean a random maps module is a requirement for using bigworld maps. I my opinion, those are optional, even if they may appear mandatory to run current maps. Imho it should even be possible to pickup the crossfire core and create a brand new world out of it. - communication protocol (should be interchangeable, it can be driven by object modification events in server, this also would help dissociate rules from socket events, it would make also easy to put several protocol modules, eg, one for bots or another one for a scorn webcam) - weather system (it's main architecture is, on a regular time do calculations and update world maps) - python scripting (is a requirement to run big world, but not to run server) - random maps, in a more general point, map loading / saving, this would give the possibility to have other means of generating maps and saving maps. We could think of separate modules for random maps, user specific permanent maps, underworld? (it has been suggested the underworld could be based on what exist on upper world) The fact is, a server would be able to start without map loading, without scripts, without communication protocol. It would just have a bunch of rules and nothing to do. But that also mean we could start it with only communication protocol plugged in and a dummy map loading module, this only in the purpose of testing protocol behaviour, maybe in an automated way. From delbd at oma.be Tue Jan 17 04:16:14 2006 From: delbd at oma.be (David Delbecq) Date: Tue Jan 17 04:18:59 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43CC7A86.8060208@telus.net> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <43CC7A86.8060208@telus.net> Message-ID: <200601171116.15007.delbd@oma.be> Le Mardi 17 Janvier 2006 06:03, Alex Schultz a ?crit : > Frankly, I have to agree with mikee to some degree on this point. I > generally have little trouble finding something after a combination of > getting a feel for the code, which I have gotten pretty good for a while > now, as well as skilled grepping. Crossfire is the only project i have worked with either on my spare time, either at work, which needs grepping in the code to understand it! This just proves how much a mess it is. > > However aside from some things like this, I do find modularization can > have merits, it just depends on 1) How much effort it takes to > modularize, 2) How effective the modularization API is designed (i.e. > currently the existing plugin API is vastly insufficient for server > modularization) and 3) Where we draw the line of what to modularize. > Personally, I don't think we should modularize very much, but if the API > is good enough (which I would likely be picky about myself), then it > might be worth doing for a limited number of things. > 1) It would be, in my opinion, a progressive effort. Modularize one piece, then another one then another one. This woudln't prevent current commiter to do their add-ons too. 2) modularization api should simply progress along with modules. If you need core to export something new, then simply have it export it. Please not i don't consider plugin based modules as the only solution. It would be good in the sense it force code to have clean way to access datas. To get back to provided example, what if modules whant to change object->dam? Well i would say then it must register a dam modifier methode to object :) Simply because you can't be sure another module don't want also to interfer with dam imagine this rule "with this item weared, player does twice dam when standing on fire" and this one "this weapon does half damage when player is wearing a helmet" It's up to core to gather rules exception registered for object and do a calculation chain based on it. mdifying object->dam directly would then be dangerous :) 3) the line will be found in a progressive way. Depending on needs. > Alex Schultz > > Miguel Ghobangieno wrote: > > >I have to do the same thing when I am adding things to > >my perl rpg (which is not smaller in lines of code > >then crossfire). It's not a big hassle, and how else > >will the code know what's going on? Use grep. > > > >--- tchize wrote: > > > >>Speaking of my experience with crossfire code. I > >>have developped > >>a few add-ons to crossfire in the past (don't > >>remember the list). > >>From my point of view, adding new features in the > >>code is currently > >>a pain in the ass. I have dropped features add-ons > >>which took > >>me lots of time simply because it has become nearly > >>impossible to find > >>something in the code. > >> > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -- David Delbecq Royal Meteorological Institute of Belgium - Pingouins dans les champs, hiver m?chant From delbd at oma.be Tue Jan 17 04:28:41 2006 From: delbd at oma.be (David Delbecq) Date: Tue Jan 17 04:34:25 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43CC9619.1000202@sonic.net> References: <1137453091.c7d9bd9cyann.chachkoff@myrealbox.com> <43CC9619.1000202@sonic.net> Message-ID: <200601171128.42096.delbd@oma.be> Le Mardi 17 Janvier 2006 08:00, Mark Wedel a ?crit : > Yann Chachkoff wrote: > > > > > Well, it really depends on what the C code requires as dependencies - the > > Python plugin has one with the python libs for example. But stuff that was > > initially in the server code would have no such external dependencies indeed. > > True. I imagine dependencies to be fairly standard C dependencies. But I > could imagine someone writing a plugin in C++ with appropriate wrappers. > > > > > On the other hand, I think splitting the code in "logical entities", more or > > less independent of the others, would be a path of thinking to try. As such, > > random maps would appear as a good target for modularization, since it > > doesn't really depend on anything else, apart from very basical operations, > > and is called only at a few places. Alchemy would be another good candidate - > > both are very important in the game, yet are working very much like "black > > boxes" - complex code with relatively limited interactions with the rest of > > the code. > > Agree. And in fact, any object that does something 'interesting' when applied > could be a plugin, since most such objects are also very well self contained. > > However, I'd counter that if it is just 20 lines of C code to do that > 'whatever', it could be more convenient to just add that 20 lines to apply.c > > I say this because I imagine plugins would probably be organized by > plugin/C/. Maybe have one directory for basic plugins (one in > which the entier plugin is in one file). But if plugin grows to the extent that > there are 50 'trivial' plugins, one could say finding the code there isn't any > more convenient than having it sit in apply.c Nothing would prevent all those 'basic plugins' to be gathered together. eg all kind of current exit in a module along with walls, grounds, name this module 'basicLayout' anotherone for movment stuffs another module regrouping monster stuffs anotherone for all kind of traps ... Common lifecycle is 'add new feature in existing code, when it becomes lots of line, move it to it's own module', unless of course you know from the start it will contain lots of code ;) > > > > >> I'd think that if there is a C plugin, aside from the different passing in > >> of the values, and using appropriate callbacks for functions instead of > >> calling > > them directly, it could access the function data directly? Eg, it should need > > to do a plugin callback to set the dam of an object, it could just set > > ob->dam? > > > > Theorically, yes: there's nothing preventing such a thing. Wrapping such > > access behind functions was basically to allow checking that the values > > passed were in the correct range, and to provide encapsulation of the data > > (so that a plugin wouldn't get tempted to directly change fields it wasn't > > supposed to change without a high risk) > > I'd imagine it is more important for the plugin wrapper to provide a > consistent interface to the various functions, so that if a function handling > changes in the C code (say a function now takes another argument), that all the > plugins don't have to be rewritten - they can keep using the existing code, with > the wrapper just passing in some default value. principles of methods polymorphism in object oriented programming ;) > > > > > Sure ! But I think such changes would be easier to make if the code was, in a > > way or another, "split" into smaller entities, so that they affect only a > > limited part of it. And indeed, a lot of functions would benefit from some > > in-depth rebuilding. Also, part of the problems of code debugging/maintenance > > come to how things are distributed all around the code - finding where to > > add/change things is a rather complex task. Making small changes to make the > > code more "readable" and "editable" would thus be another important point to > > achieve, IMHO. > > True - some functions have grown a bit in complexity and could certainly use a > rewrite. And I could envision doing some things as plugins would make some > things easier/more modular (Going back to what someone said, objects that the > player uses are complicated - need to update the apply code, but depending on > the object, may also need to update the code that actually describes the item - > I could see with appropriate plugin support, all that could be done in the > plugin, so all code related to that object is in one place) Well you put the finger on it. Adding a new object is generally adding a 2 lines code to apply which calls myObjectType_apply(). and same to describe, sometimes, also for some same to move_object(). Damn this looks to me like the pattern of registering listeners to some events :D > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -- David Delbecq Royal Meteorological Institute of Belgium - Pingouins dans les champs, hiver m?chant From delbd at oma.be Tue Jan 17 04:36:20 2006 From: delbd at oma.be (David Delbecq) Date: Tue Jan 17 04:37:43 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <20060117015149.14824.qmail@web32704.mail.mud.yahoo.com> References: <20060117015149.14824.qmail@web32704.mail.mud.yahoo.com> Message-ID: <200601171136.20184.delbd@oma.be> Le Mardi 17 Janvier 2006 02:51, Miguel Ghobangieno a ?crit : > I suggest you not implement a huge worthless code > change that is nothing but busy work. I reject your > assertion that cave's analogy is flawed as it is not. > If you want to code code something new useful rather > then breaking the server as is what will happen if you > go forward with this plan. You also will be holding > off any new large codechanges for months as they wait > for you to be done with this not-needed reshuffling. Why would other coders have to wait? Nobody did mention freezing the CVS at anytime. If you don't want to work on modularization, nobody forces you to do so, work on implementing new features. It's the sole responsability of the one modularizing a feature to ensure there is no conflict when he commits. When the commit is done, it's the responsability of other code to take into account this change. That's how CVS based development work. Crossfire had deep changes in code in the past (object based skills is one of the most recent). This has never prevented other people to do their change. That's the magic of teamworking. -- David Delbecq Royal Meteorological Institute of Belgium From tchize at myrealbox.com Tue Jan 17 06:09:55 2006 From: tchize at myrealbox.com (tchize) Date: Tue Jan 17 06:12:31 2006 Subject: [crossfire] Polymorph etc In-Reply-To: <43CC18D3.2090602@laposte.net> References: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> <43CC18D3.2090602@laposte.net> Message-ID: <200601171309.55949.tchize@myrealbox.com> Le Lundi 16 Janvier 2006 23:06, Nicolas Weeger a ?crit : > > Sure, i'll do it - lemme just confirm the money has correctly been > transferred from your account to mine :) > OMG, i think it ended in my account. Well better luck next time ryo. /me going out to buy a new ipod with that money From brenlally at gmail.com Tue Jan 17 11:15:06 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue Jan 17 11:19:13 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43CC9619.1000202@sonic.net> References: <1137453091.c7d9bd9cyann.chachkoff@myrealbox.com> <43CC9619.1000202@sonic.net> Message-ID: <7903f03c0601170915i10d3b194k7c23b4ef297dbca2@mail.gmail.com> On 1/17/06, Mark Wedel wrote: > True. I imagine dependencies to be fairly standard C dependencies. But I > could imagine someone writing a plugin in C++ with appropriate wrappers. This point (more than any other) is potentially alarming. Currently crossfire is written in C and python, with some perl scripts doing some minor things. If this range of languages is increased, there is a danger that it would include languages outside the range of competence of the existing developers, or outside the range of languages which are well supported on some of crossfire's target platforms. Whilst it might be that $NEW_WHIZZY_FEATURE would be very easy to write in D, for example (or some other $OBSCURE_LANGUAGE) it is unlikely that most systems running servers have a suitable compiler installed or that most existing developers would be able to adequately maintain code written in it. Whilst C++ on its own isn't greatly objectionable, there must be some guidelines as to which languages would be permissible so that we don't end up with 20 different modules in a dozen different languages half of which were known only to their original author who has since disappeared. From brenlally at gmail.com Tue Jan 17 11:46:06 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue Jan 17 11:48:37 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <200601170845.08377.yann.chachkoff@myrealbox.com> References: <7903f03c0601161555j36506531wd99bebc4e2e2fd9a@mail.gmail.com> <200601170845.08377.yann.chachkoff@myrealbox.com> Message-ID: <7903f03c0601170946ifaa8092m696813744eca7972@mail.gmail.com> Ok, to try and summarise from this. (this is how I'm reading the existing responses, yell if you think this isn't a fair summary). Not a target for removal: Split Information Window (Takes effect next run) Automatically re-applies a container when you use apply to close it. Still targeted for removal: (on) Colored Inventory Lists (on) Colored Information Text - maybe to be replaced by some future feature (off) Print Grid Overlay (on) Cache Images (on) splash window (gros' suggestion) Options on how to display resistances: - keeping the two options involving scroll bars, but still haven't heard from an advocate of the no-scrollbar option (if this were removed, it could go from 3 buttons to 1) the options in the list above need someone to claim the use of them sometime within the next fortnight. From tchize at myrealbox.com Tue Jan 17 12:04:20 2006 From: tchize at myrealbox.com (tchize) Date: Tue Jan 17 12:06:29 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <7903f03c0601170915i10d3b194k7c23b4ef297dbca2@mail.gmail.com> References: <1137453091.c7d9bd9cyann.chachkoff@myrealbox.com> <43CC9619.1000202@sonic.net> <7903f03c0601170915i10d3b194k7c23b4ef297dbca2@mail.gmail.com> Message-ID: <200601171904.25372.tchize@myrealbox.com> Le Mardi 17 Janvier 2006 18:15, Brendan Lally a ?crit : >On 1/17/06, Mark Wedel wrote: >> True. I imagine dependencies to be fairly standard C dependencies. But >> I could imagine someone writing a plugin in C++ with appropriate wrappers. > > Things written in other languages then C should always be considered as optionnal. This is the case of python scripts. They are usefull but not all platform do support them very well. In all cases, things like writting a plugin in C++ or Fortran or ADA or anything else should require prior discussion on ML. It's too early for a discussion about languages in which plugins are written. I understood the current idea is to move C code to plugin still in C (just structural reorganisation). -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060117/143a7855/attachment.pgp From mikeeusaa at yahoo.com Tue Jan 17 10:22:06 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 17 12:13:14 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601171116.15007.delbd@oma.be> Message-ID: <20060117162206.38462.qmail@web32705.mail.mud.yahoo.com> You haven't worked on many complex projects then. The upset this will cause in crossfire development (and devs will wait untill it's done before committing again because they don't want their new code to be broken) will be very large. I would like to see plots etc in crossfire in my lifetime, your "AWSOME KAWABUNGA!" idea of ripping apart the server will stall development for no freaking reason except that you think that you are above using grep. --- David Delbecq wrote: > Le Mardi 17 Janvier 2006 06:03, Alex Schultz a ?crit > : > > Frankly, I have to agree with mikee to some degree > on this point. I > > generally have little trouble finding something > after a combination of > > getting a feel for the code, which I have gotten > pretty good for a while > > now, as well as skilled grepping. > > Crossfire is the only project i have worked with > either on my spare time, > either at work, which needs grepping in the code to > understand it! This just > proves how much a mess it is. > > > > > However aside from some things like this, I do > find modularization can > > have merits, it just depends on 1) How much effort > it takes to > > modularize, 2) How effective the modularization > API is designed (i.e. > > currently the existing plugin API is vastly > insufficient for server > > modularization) and 3) Where we draw the line of > what to modularize. > > Personally, I don't think we should modularize > very much, but if the API > > is good enough (which I would likely be picky > about myself), then it > > might be worth doing for a limited number of > things. > > > > 1) It would be, in my opinion, a progressive effort. > Modularize one piece, > then another one then another one. This woudln't > prevent current commiter to > do their add-ons too. > > 2) modularization api should simply progress along > with modules. If you need > core to export something new, then simply have it > export it. Please not i > don't consider plugin based modules as the only > solution. It would be good in > the sense it force code to have clean way to access > datas. To get back to > provided example, what if modules whant to change > object->dam? Well i would > say then it must register a dam modifier methode to > object :) Simply because > you can't be sure another module don't want also to > interfer with dam > imagine this rule "with this item weared, player > does twice dam when standing > on fire" and this one "this weapon does half damage > when player is wearing a > helmet" It's up to core to gather rules exception > registered for object and > do a calculation chain based on it. mdifying > object->dam directly would then > be dangerous :) > > 3) the line will be found in a progressive way. > Depending on needs. > > > Alex Schultz > > > > Miguel Ghobangieno wrote: > > > > >I have to do the same thing when I am adding > things to > > >my perl rpg (which is not smaller in lines of > code > > >then crossfire). It's not a big hassle, and how > else > > >will the code know what's going on? Use grep. > > > > > >--- tchize wrote: > > > > > >>Speaking of my experience with crossfire code. I > > >>have developped > > >>a few add-ons to crossfire in the past (don't > > >>remember the list). > > >>From my point of view, adding new features in > the > > >>code is currently > > >>a pain in the ass. I have dropped features > add-ons > > >>which took > > >>me lots of time simply because it has become > nearly > > >>impossible to find > > >>something in the code. > > >> > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > -- > David Delbecq > Royal Meteorological Institute of Belgium > > - > Pingouins dans les champs, hiver m?chant > > _______________________________________________ > 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 mikeeusaa at yahoo.com Tue Jan 17 10:46:34 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 17 12:13:19 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601171136.20184.delbd@oma.be> Message-ID: <20060117164634.42845.qmail@web32701.mail.mud.yahoo.com> Did you not read my post. If you are screwing around with the code structure of the server then other programmers do have to wait untill you are done as they do not want their code to suddenly break when it intersects with your massive changes. You must not be at all experianced in these matters (as you indicated before in fingering crossfire for the sin of you having to grep through it). This will hold up usefull game development for months all because you and friends believe that you are above grep. --- David Delbecq wrote: > Le Mardi 17 Janvier 2006 02:51, Miguel Ghobangieno a > ?crit : > > I suggest you not implement a huge worthless code > > change that is nothing but busy work. I reject > your > > assertion that cave's analogy is flawed as it is > not. > > If you want to code code something new useful > rather > > then breaking the server as is what will happen if > you > > go forward with this plan. You also will be > holding > > off any new large codechanges for months as they > wait > > for you to be done with this not-needed > reshuffling. > > Why would other coders have to wait? Nobody did > mention freezing the CVS at > anytime. If you don't want to work on > modularization, nobody forces you to do > so, work on implementing new features. It's the sole > responsability of the > one modularizing a feature to ensure there is no > conflict when he commits. > When the commit is done, it's the responsability of > other code to take into > account this change. That's how CVS based > development work. > Crossfire had deep changes in code in the past > (object based skills is one of > the most recent). This has never prevented other > people to do their change. > That's the magic of teamworking. > > -- > David Delbecq > Royal Meteorological Institute of Belgium > > _______________________________________________ > 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 mikeeusaa at yahoo.com Tue Jan 17 10:40:35 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 17 12:13:22 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601170949.13597.yann.chachkoff@myrealbox.com> Message-ID: <20060117164035.47347.qmail@web32703.mail.mud.yahoo.com> How about not modularizing and thus not having to make a trade off. How about not screwing up the server for months just because you are itchting for busy work. --- Yann Chachkoff wrote: > Nothing currently prevents a plugin to modify the > data it has access to > directly - but of course, that's unsafe access, so > if the plugin makes a bad > modification to the data, or forgets to notify the > server of it if necessary, > then it will probably crash the server. Accessing > data directly or through > wrappers is basically a tradeoff between > performances and security. > > In the case of modularization of the existing code, > I'd say that direct access > wherever possible should be kept - accessors for > such data modifications > would probably be used only for debugging purposes > (as a wrapper can check if > the data modification is "legal" or not, and thus > can help detecting a whole > range of errors). > > -- > Yann Chachkoff > ----------------------- > Garden Dwarf's Best Friend > ----------------------- > GPG Key : > http://keyserver.veridis.com:11371/export?id=9080288987474372064 > Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 > AAB9 844D 25E0 > > _______________________________________________ > 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 mikeeusaa at yahoo.com Tue Jan 17 10:54:01 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 17 12:13:26 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601171105.10762.tchize@myrealbox.com> Message-ID: <20060117165401.39242.qmail@web32713.mail.mud.yahoo.com> Why oh why do you want to do this useless crap? We have a real game, we don't have to make an "engine". How about adding some new features rather then ripping the things apart. This is why I hate CF devel, rather then improving the game most suggestions are "oh let's fuck shit up or delete this or drop that". How about adding things? It's fun, people don't get angry at you as you aren't breaking or throwing out what they've made aswell. tchize can you modulize the server? no? so how about not suggesting screwing it up for every other developer? Ryo? no aswell? This is busy work, it is useless, and it slows down game improvements. --- tchize wrote: > > Le Mardi 17 Janvier 2006 06:12, Alex Schultz a ?crit > : > > Indeed. On this example, IMHO random maps are not > optional, as they are > > essential to some quests, and also soon would be > used by land plots > > (though land plots would in my opinion be a > relatively good thing to > > implement as an optional-but-defaultly-on C > plugin) > > > > IMHO they are optional, they are mandatory to use > the current map set, that is true, but that just > mean a random maps module is a requirement for using > bigworld maps. > I my opinion, those are optional, even if they may > appear mandatory to run current maps. Imho it should > even be possible to pickup the crossfire core and > create a brand new world out of it. > - communication protocol (should be interchangeable, > it can be driven by object modification events in > server, this also would help dissociate rules from > socket events, it would make also easy to put > several protocol modules, eg, one for bots or > another one for a scorn webcam) > - weather system (it's main architecture is, on a > regular time do calculations and update world maps) > - python scripting (is a requirement to run big > world, but not to run server) > - random maps, in a more general point, map loading > / saving, this would give the possibility to have > other means of generating maps and saving maps. We > could think of separate modules for random maps, > user specific permanent maps, underworld? (it has > been suggested the underworld could be based on what > exist on upper world) > > The fact is, a server would be able to start without > map loading, without scripts, without communication > protocol. It would just have a bunch of rules and > nothing to do. > But that also mean we could start it with only > communication protocol plugged in and a dummy map > loading module, this only in the purpose of testing > protocol behaviour, maybe in an automated way. > > _______________________________________________ > 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 mikeeusaa at yahoo.com Tue Jan 17 12:17:39 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 17 12:31:40 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601171904.25372.tchize@myrealbox.com> Message-ID: <20060117181739.89331.qmail@web32705.mail.mud.yahoo.com> Current idea? I must have missed something, I didn't know you decided, above all the objections, to go ahead and rip apart the server anyway. I will be waiting for my 3 thousand dollar cheque in the mail (along with everyone else who would like to add new stuff to CF but will have to wait untill you tire of ripping apart the server and revert the CVS tree). Why should all work have to stop because YOU want to restructure the server.. because you can't figure out grep... --- tchize wrote: > Le Mardi 17 Janvier 2006 18:15, Brendan Lally a > ?crit : > >On 1/17/06, Mark Wedel wrote: > >> True. I imagine dependencies to be fairly > standard C dependencies. But > >> I could imagine someone writing a plugin in C++ > with appropriate wrappers. > > > > > Things written in other languages then C should > always be considered as > optionnal. This is the case of python scripts. They > are usefull but not all > platform do support them very well. > In all cases, things like writting a plugin in C++ > or Fortran or ADA or > anything else should require prior discussion on ML. > It's too early for a > discussion about languages in which plugins are > written. I understood the > current idea is to move C code to plugin still in C > (just structural > reorganisation). > > -- > -- > Tchize (David Delbecq) > tchize@myrealbox.com > Public PGP KEY FINGERPRINT: > F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 > C17C > Public PGP KEY location: > http://wwwkeys.pgp.net/pgpnet/wwwkeys.html > > _______________________________________________ > 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 mikeeusaa at yahoo.com Tue Jan 17 12:13:29 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 17 12:31:44 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <7903f03c0601161706k77f808c5n813b1a4800fb759b@mail.gmail.com> Message-ID: <20060117181329.44726.qmail@web32702.mail.mud.yahoo.com> Yes, it would be best to remove that option from the menu IMHO. Could we also make quit ask the person if they really want to delete their character (and then ask again for confirmation)? (server side). --- Brendan Lally wrote: > On 1/17/06, Rick Tanner wrote: > > Would it be OT or out of scope to ask for the > "File -> Quit Character" > > option in the menu to be renamed to "File -> > Delete Character" ? > > Well, it wouldn't be if you instead suggested that > the menu entry be > removed altogether. > > I'm inclined to think that the better option, it > isn't as though the > quit command should be used particularly often. > > _______________________________________________ > 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 yann.chachkoff at myrealbox.com Tue Jan 17 15:12:11 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Tue Jan 17 15:12:26 2006 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1137532331.c7dde81cyann.chachkoff@myrealbox.com> > If this range of languages is increased, there is a danger that it would include languages outside the range of competence of the existing developers, or outside the range of languages which are well supported on some of crossfire's target platforms. > That is true - I'm not myself in favor of a system in which several languages would get used. Introducing something else than C in the server code would definitely create a lot of issues, and isn't something I'd like to see without a prior discussion. Probably the best rules is: code in C, and if you *really* think another language is needed, then ask the mailing list first, so the case gets discussed. Just because it can technically be done doesn't mean it is a good idea. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire From yann.chachkoff at myrealbox.com Tue Jan 17 15:40:34 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Tue Jan 17 15:45:27 2006 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1137534034.c7dde81cyann.chachkoff@myrealbox.com> > Current idea? I must have missed something, I didn't know you decided, above all the objections, to go ahead and rip apart the server anyway. Idea != Decision. Besides that, I don't think anybody requires your permission to code. > Why should all work have to stop because YOU want to restructure the server.. because you can't figure out grep... I can assure you that tchize is skilled enough to use grep, by far. The whole point was that a properly structured code should *never* require using grep. Yes, even large-scale enterprise projects. --- tchize wrote: > Le Mardi 17 Janvier 2006 18:15, Brendan Lally a > ?crit : > >On 1/17/06, Mark Wedel wrote: > >> True. I imagine dependencies to be fairly > standard C dependencies. But > >> I could imagine someone writing a plugin in C++ > with appropriate wrappers. > > > > > Things written in other languages then C should > always be considered as > optionnal. This is the case of python scripts. They > are usefull but not all > platform do support them very well. > In all cases, things like writting a plugin in C++ > or Fortran or ADA or > anything else should require prior discussion on ML. > It's too early for a > discussion about languages in which plugins are > written. I understood the > current idea is to move C code to plugin still in C > (just structural > reorganisation). > > -- > -- > Tchize (David Delbecq) > tchize@myrealbox.com > Public PGP KEY FINGERPRINT: > F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 > C17C > Public PGP KEY location: > http://wwwkeys.pgp.net/pgpnet/wwwkeys.html > > _______________________________________________ > 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 _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire From eracclists at bellsouth.net Tue Jan 17 15:53:57 2006 From: eracclists at bellsouth.net (ERACC) Date: Tue Jan 17 15:54:26 2006 Subject: [crossfire] On moving the Lone Town apartment Message-ID: <200601171553.58290.eracclists@bellsouth.net> Greetings all, It was pointed out to me on IRC that the Lone Town apartment does not fit the Lone Town story line. Specifically the apartment is too big and ostentatious for Lone Town. So, I propose moving that set of maps to a "country villa" setting somewhere. I still want an apartment in, or near, Lone Town and intend to make a single map to fit in with the original Lone Town idea (as far as I understand it). I will also leave the build shop in Lone Town but scale it down a touch. If moved I want the country villa to be near somewhere that does not currently have a permanent apartment. It does not matter if the town nearby is small since a country villa is intended to be rural. Feed me some suggestions please. I was thinking perhaps in the world maps to the near East of Lake Country? Or even in the pup land maps near Lone Town would be ok I think. I could then just remove the apartment in Lone Town. IMO the Regular Army people would be living in big country villa's (or town apartments ;-) and the Freedom folk would be the poor and downtrodden types. So perhaps access to the country villa (or apartment if it stays in Lone Town) should depend on owning a Regular Army Passport. "Feed me Seymour!" As I already stated I do not want to put this somewhere near a city that already has a permanent apartment. I also do not want to place it so far out in the wilderness that it is impractical to own. I want to make this change (if everyone agrees I need to move that thing) before too many players buy them. I do not want to create more of an administration headache than necessary. TIA Gene -- Mandriva Linux release 2006.0 (Official) for i586 15:30:37 up 3 days, 22:23, 10 users, load average: 0.06, 0.05, 0.06 ERA Computer Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer & UnixWare resellers From mikeeusaa at yahoo.com Tue Jan 17 18:00:33 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 17 18:23:46 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1137532331.c7dde81cyann.chachkoff@myrealbox.com> Message-ID: <20060118000033.18628.qmail@web32709.mail.mud.yahoo.com> Indeed. Just because the server can be modularized thus blocking any other new development whilst that takes place doesn't mean it's a good idea. I for one frown on the idea of making the server slower and blocking other development. --- Yann Chachkoff wrote: > > If this range of languages is increased, there is > a danger that it would include languages outside the > range of competence of the existing developers, or > outside the range of languages which are well > supported on some of crossfire's target platforms. > > > That is true - I'm not myself in favor of a system > in which several languages would get used. > Introducing something else than C in the server code > would definitely create a lot of issues, and isn't > something I'd like to see without a prior > discussion. > > Probably the best rules is: code in C, and if you > *really* think another language is needed, then ask > the mailing list first, so the case gets discussed. > Just because it can technically be done doesn't mean > it is a good idea. > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > _______________________________________________ > 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 mikeeusaa at yahoo.com Tue Jan 17 18:04:10 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 17 18:23:49 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1137534034.c7dde81cyann.chachkoff@myrealbox.com> Message-ID: <20060118000410.75105.qmail@web32711.mail.mud.yahoo.com> Oh if that's the case let me just commit all the mlab maps in their current uni-directory form over the objections of everyone else that prefers multi-directory. Know why I don't do that; because everyone else prefers multi-directory. Try mucking in the linux kernel without grep, tell me how that goes. --- Yann Chachkoff wrote: > > Current idea? I must have missed something, I > didn't know you decided, above all the objections, > to go > ahead and rip apart the server anyway. > > Idea != Decision. > > Besides that, I don't think anybody requires your > permission to code. > > > Why should all work have to stop because YOU want > to restructure the server.. because you can't figure > out grep... > > I can assure you that tchize is skilled enough to > use grep, by far. The whole point was that a > properly structured code should *never* require > using grep. Yes, even large-scale enterprise > projects. > > --- tchize wrote: > > > Le Mardi 17 Janvier 2006 18:15, Brendan Lally a > > ?crit : > > >On 1/17/06, Mark Wedel wrote: > > >> True. I imagine dependencies to be fairly > > standard C dependencies. But > > >> I could imagine someone writing a plugin in C++ > > with appropriate wrappers. > > > > > > > > Things written in other languages then C should > > always be considered as > > optionnal. This is the case of python scripts. > They > > are usefull but not all > > platform do support them very well. > > In all cases, things like writting a plugin in C++ > > or Fortran or ADA or > > anything else should require prior discussion on > ML. > > It's too early for a > > discussion about languages in which plugins are > > written. I understood the > > current idea is to move C code to plugin still in > C > > (just structural > > reorganisation). > > > > -- > > -- > > Tchize (David Delbecq) > > tchize@myrealbox.com > > Public PGP KEY FINGERPRINT: > > F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 > > C17C > > Public PGP KEY location: > > http://wwwkeys.pgp.net/pgpnet/wwwkeys.html > > > _______________________________________________ > > 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 > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > _______________________________________________ > 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 mikeeusaa at yahoo.com Tue Jan 17 18:05:14 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue Jan 17 18:23:52 2006 Subject: [crossfire] On moving the Lone Town apartment [bigworldized pupland] In-Reply-To: <200601171553.58290.eracclists@bellsouth.net> Message-ID: <20060118000514.68199.qmail@web32707.mail.mud.yahoo.com> lalo is bigworldizing pupland, the villas could be placed somewhere on said bigworldized pupland (note: how long untill it's done?). --- ERACC wrote: > Greetings all, > > It was pointed out to me on IRC that the Lone Town > apartment does not > fit the Lone Town story line. Specifically the > apartment is too big > and ostentatious for Lone Town. So, I propose moving > that set of maps > to a "country villa" setting somewhere. I still want > an apartment in, > or near, Lone Town and intend to make a single map > to fit in with the > original Lone Town idea (as far as I understand it). > I will also > leave the build shop in Lone Town but scale it down > a touch. > > If moved I want the country villa to be near > somewhere that does not > currently have a permanent apartment. It does not > matter if the town > nearby is small since a country villa is intended to > be rural. Feed > me some suggestions please. I was thinking perhaps > in the world maps > to the near East of Lake Country? Or even in the pup > land maps near > Lone Town would be ok I think. I could then just > remove the apartment > in Lone Town. > > IMO the Regular Army people would be living in big > country villa's > (or town apartments ;-) and the Freedom folk would > be the poor and > downtrodden types. So perhaps access to the country > villa (or > apartment if it stays in Lone Town) should depend on > owning a Regular > Army Passport. "Feed me Seymour!" > > As I already stated I do not want to put this > somewhere near a city > that already has a permanent apartment. I also do > not want to place > it so far out in the wilderness that it is > impractical to own. I want > to make this change (if everyone agrees I need to > move that thing) > before too many players buy them. I do not want to > create more of an > administration headache than necessary. > > TIA > Gene > -- > Mandriva Linux release 2006.0 (Official) for i586 > 15:30:37 up 3 days, 22:23, 10 users, load average: > 0.06, 0.05, 0.06 > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mwedel at sonic.net Wed Jan 18 00:06:38 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed Jan 18 00:08:26 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <20060117181329.44726.qmail@web32702.mail.mud.yahoo.com> References: <20060117181329.44726.qmail@web32702.mail.mud.yahoo.com> Message-ID: <43CDDAEE.8020201@sonic.net> Miguel Ghobangieno wrote: > Yes, it would be best to remove that option from the > menu IMHO. > Could we also make quit ask the person if they really > want to delete their character (and then ask again for > confirmation)? (server side). I just tried this out. If I select the 'Quit Character' option from the file list, it does ask if I want to quit or not. From mwedel at sonic.net Wed Jan 18 00:30:27 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed Jan 18 00:32:27 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601170949.13597.yann.chachkoff@myrealbox.com> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <43CC7A86.8060208@telus.net> <200601170949.13597.yann.chachkoff@myrealbox.com> Message-ID: <43CDE083.1080207@sonic.net> Gros wrote: > It actually depends on the level of control you want to grant to the plugins. > The most extreme case would be to export all the functions currently in the > code - to do that, you'll have to provide a wrapper for each function you > want to export. That's a lot of functions, but let's not forget that a > significant part of those are only used by specific pieces of the code, so > the actual useful number is definitely lower than that by a significant > margin. One danger of providing wrappers to too many functions is danger of infinite recursive loops. There is already that potential - the apply code always has such a check. But the danger could be that if module writers see a list of functions they can use, they may think it is safe to call it back at any time. Not that is really any different than current code, but just a thought. David Delbecq wrote: > Nothing would prevent all those 'basic plugins' to be gathered together. > eg all kind of current exit in a module along with walls, grounds, name this > module 'basicLayout' > anotherone for movment stuffs > another module regrouping monster stuffs > anotherone for all kind of traps > ... > > Common lifecycle is 'add new feature in existing code, when it becomes lots of > line, move it to it's own module', unless of course you know from the start > it will contain lots of code ;) However, I think if you start grouping all that stuff together, you start loosing some of the advantages. I think there are also some limitations regarding the actual use of the shared libraries (modules) - for example, each one can only have one initialization function I believe, so if you have say 20 object types in one module, you'd have to mix all the code they need for initialization in one function (or have a list of the 20 function calls it makes). > Well you put the finger on it. Adding a new object is generally adding a 2 > lines code to apply which calls myObjectType_apply(). and same to describe, > sometimes, also for some same to move_object(). Damn this looks to me like > the pattern of registering listeners to some events :D But one could do that to some extent without plugins. You could for example set up something like: struct object_type_description { functype apply_func; functype describe_func; functype .... } object_actions[MAX_OBJECT_TYPE Then in the code, you could do things like: if (object_actions[op->type].apply_func) object_actions[op->type].apply_func(...) In a sense, a poor mans/specialized plugin. You then just need one initialization function, but all the specialized code related to object type itself could be in one place. From yann.chachkoff at myrealbox.com Wed Jan 18 02:00:43 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Wed Jan 18 02:01:27 2006 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1137571243.c7f31f9cyann.chachkoff@myrealbox.com> > Oh if that's the case let me just commit all the mlab maps in their current uni-directory form over the objections of everyone else that prefers multi-directory. Know why I don't do that; because everyone else prefers multi-directory. Did you need the permission of anybody to write those maps ? No. So I don't think we need your permission to explore new coding ideas, even if they finally appear to be dead-ends. Making proposals, coding a prototype, submitting a patch to the mailing list, all this doesn't mean the code will finally get into the CVS (actually, there are examples in Crossfire itself of proposals that were extensively discussed and with some code created that never got into the CVS). > Try mucking in the linux kernel without grep, tell me how that goes. Pretty well, actually - the Linux kernel source code is extensively documented and is highly structured. I've worked on the kernel in the past, and never needed grep to find my way through the code. Besides that, compare what can be compared: the Linux kernel is more than 6 million lines of code. The Crossfire code is way smaller than that. Your example suggests that using a map to go buying my newspaper every day is perfectly normal, since I'd need one to go into holidays in a faraway country. From yann.chachkoff at myrealbox.com Wed Jan 18 02:16:36 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Wed Jan 18 02:16:27 2006 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1137572196.c7f31f9cyann.chachkoff@myrealbox.com> > Indeed. Just because the server can be modularized thus blocking any other new development whilst that takes place doesn't mean it's a good idea. There is no reason to block any other development. I suppose you know that the "C" in "CVS" means "Concurrent" ? > I for one frown on the idea of making the server slower There is no reason that it would be slower than it is now. There are no reason for a modularized system to be slower than the current version. The only overhead would be when connecting callbacks to objects - and that's hardly something you'd notice, unless if you're running Crossfire on a 8086@8Mhz... > and blocking other development. I think I already said it, but there is no reason to "block other developments". Everybody who has already worked in large-scale software projects knows that parallel development on different parts of the code is a rather common practice. That you believe that only a single task can be performed at once on something like the Crossfire code shows that you urgently need to get better informed on software development/engineering techniques and more generally on modern teamwork methods. For what is worth, I could already be working on a code prototype on my personal workstation - would you ever notice it before I submit a patch ? Would it prevent somebody else to add something in the code in the meantime ? The answer to both of those questions would appear obvious, I think, to every reasonable person. From antonoussik at gmail.com Wed Jan 18 02:44:49 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Wed Jan 18 02:46:27 2006 Subject: [crossfire] Re: Polymorph etc In-Reply-To: <200601171309.55949.tchize@myrealbox.com> References: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> <43CC18D3.2090602@laposte.net> <200601171309.55949.tchize@myrealbox.com> Message-ID: On the note of adding/fixing spells, could some high level spells be added into CF, which need higher levels (like 40, 60, 80, 100) in a skill to be able to cast them? At the moment there is little point in levelling things like sourcery beyond level 15, when you can cast town portal. Either re-shuffling spells about or adding some more spells to fill the gaps would be needed for that. Adding fighting levels to weapons would also make sense, and in my opinion would be more consistent for things like swords and bows than item power is. Thoughts/comments? On 17/01/06, tchize wrote: > Le Lundi 16 Janvier 2006 23:06, Nicolas Weeger a ?crit : > > > > Sure, i'll do it - lemme just confirm the money has correctly been > > transferred from your account to mine :) > > > > OMG, i think it ended in my account. Well better luck next time ryo. > > /me going out to buy a new ipod with that money > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From brenlally at gmail.com Wed Jan 18 03:10:10 2006 From: brenlally at gmail.com (Brendan Lally) Date: Wed Jan 18 03:10:26 2006 Subject: [crossfire] gcfclient options deathlist In-Reply-To: <43CDDAEE.8020201@sonic.net> References: <20060117181329.44726.qmail@web32702.mail.mud.yahoo.com> <43CDDAEE.8020201@sonic.net> Message-ID: <7903f03c0601180110v70024a25l1e3648c95bac4d35@mail.gmail.com> On 1/18/06, Mark Wedel wrote: > Miguel Ghobangieno wrote: > > Yes, it would be best to remove that option from the > > menu IMHO. > > I just tried this out. If I select the 'Quit Character' option from the file > list, it does ask if I want to quit or not. Regardless of that, I would suggest that it is something that is something that is so infrequently the intended course of action, that making the player issue the command themselves would be desirable. From brenlally at gmail.com Wed Jan 18 03:21:23 2006 From: brenlally at gmail.com (Brendan Lally) Date: Wed Jan 18 03:23:36 2006 Subject: [crossfire] Re: Polymorph etc In-Reply-To: References: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> <43CC18D3.2090602@laposte.net> <200601171309.55949.tchize@myrealbox.com> Message-ID: <7903f03c0601180121k4acbb7ccr82f3eeedf8aaa5a4@mail.gmail.com> On 1/18/06, Anton Oussik wrote: > Adding fighting levels to weapons would also make sense, and in my > opinion would be more consistent for things like swords and bows than > item power is. Having a minimum level for every object that can be applied wouldn't be that difficult, I'd be inclined to say it could work well with item power as well. (to wield sword of foo you must be level n at one_handed_weapons and have x spare item power) From antonoussik at gmail.com Wed Jan 18 03:28:17 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Wed Jan 18 03:30:09 2006 Subject: [crossfire] Re: gcfclient options deathlist In-Reply-To: <43CDDAEE.8020201@sonic.net> References: <20060117181329.44726.qmail@web32702.mail.mud.yahoo.com> <43CDDAEE.8020201@sonic.net> Message-ID: Yes, it asks you something like "Are you sure you want want to quit the character?", not "WARNING: You are about to delete the character! Are you sure you want to completely delete the character and entirely and irreversably remove all evidence that the character ever existed for ever and ever?". I think what Mikee was referring to is that the comfirmation message does not look threatening enough. I agree, it is how I lost my first ever two characters. :-) Mark, would it be possible to make the "-split" option work on gtk-v2 client? It effectively allows the client to run on any screen resolution, and allows users to position controls the way they like it. I think the main reason so many people are still using gtk-v1 client is because it is able to better fit their needs. On 18/01/06, Mark Wedel wrote: > Miguel Ghobangieno wrote: > > Yes, it would be best to remove that option from the > > menu IMHO. > > Could we also make quit ask the person if they really > > want to delete their character (and then ask again for > > confirmation)? (server side). > > I just tried this out. If I select the 'Quit Character' option from the > file > list, it does ask if I want to quit or not. > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From mikeeusaa at yahoo.com Wed Jan 18 08:42:05 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Wed Jan 18 10:43:35 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1137572196.c7f31f9cyann.chachkoff@myrealbox.com> Message-ID: <20060118144205.48785.qmail@web32709.mail.mud.yahoo.com> Except that you are not working on one section of the code, you are restructuring the whole server into diffrent modules. This means that if you develop in cvs there will be breakage with any and everyone else as you sweeping edits touch every facet of the glory that is crossfire. The C in CVS may mean concurrent but it doesn't mean perfect. If you want to make the sweeping changes on your own system; enjoy. But please, before committing to cvs do extensive bugtesting so that it 1) doesn't make the code any slower, 2) doesn't break anything, and 3) maybe makes MS less of a hog? --- Yann Chachkoff wrote: > > Indeed. Just because the server can be modularized > thus blocking any other new development whilst that > takes place doesn't mean it's a good idea. > > There is no reason to block any other development. I > suppose you know that the "C" in "CVS" means > "Concurrent" ? > > > I for one frown on the idea of making the server > slower > > There is no reason that it would be slower than it > is now. There are no reason for a modularized system > to be slower than the current version. The only > overhead would be when connecting callbacks to > objects - and that's hardly something you'd notice, > unless if you're running Crossfire on a 8086@8Mhz... > > > and blocking other development. > > I think I already said it, but there is no reason to > "block other developments". Everybody who has > already worked in large-scale software projects > knows that parallel development on different parts > of the code is a rather common practice. > > That you believe that only a single task can be > performed at once on something like the Crossfire > code shows that you urgently need to get better > informed on software development/engineering > techniques and more generally on modern teamwork > methods. > > For what is worth, I could already be working on a > code prototype on my personal workstation - would > you ever notice it before I submit a patch ? Would > it prevent somebody else to add something in the > code in the meantime ? The answer to both of those > questions would appear obvious, I think, to every > reasonable person. > > > _______________________________________________ > 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 mikeeusaa at yahoo.com Wed Jan 18 08:45:42 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Wed Jan 18 10:43:39 2006 Subject: [crossfire] Re: Polymorph etc In-Reply-To: <7903f03c0601180121k4acbb7ccr82f3eeedf8aaa5a4@mail.gmail.com> Message-ID: <20060118144542.34814.qmail@web32708.mail.mud.yahoo.com> I have this disabled on Cat2, item power restrictions allready exist. As for higer lvl spells, how about those circular spells I was talking about awhile back. Oh and a month or so ago I committed a necro book pic and spell symbol. A spell in necromancy should be to animate flesh (similar to animate weapon). Another raise dead (if you have a pile of 4 or so diff parts from a certain archtype it will raise that into a pet of that type (with race undead set aswell). --- Brendan Lally wrote: > On 1/18/06, Anton Oussik > wrote: > > Adding fighting levels to weapons would also make > sense, and in my > > opinion would be more consistent for things like > swords and bows than > > item power is. > > Having a minimum level for every object that can be > applied wouldn't > be that difficult, I'd be inclined to say it could > work well with item > power as well. (to wield sword of foo you must be > level n at > one_handed_weapons and have x spare item power) > > _______________________________________________ > 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 antonoussik at gmail.com Wed Jan 18 11:25:45 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Wed Jan 18 11:36:27 2006 Subject: [crossfire] Re: Moving server towards a modularized system? In-Reply-To: <1137572196.c7f31f9cyann.chachkoff@myrealbox.com> References: <1137572196.c7f31f9cyann.chachkoff@myrealbox.com> Message-ID: On 18/01/06, Yann Chachkoff wrote: > > I for one frown on the idea of making the server slower > > There is no reason that it would be slower than it is now. There are no > reason for a modularized system to be slower than the current version. The > only overhead would be when connecting callbacks to objects - and that's > hardly something you'd notice, unless if you're running Crossfire on a > 8086@8Mhz... Actually, this will depend on how modular the code will be. Going back to Hurd analogy for a second, one of the reasons has not become widely used yet is not because it is modular, but because being so modular makes IPC (Inter-Process Communication) slow (using the GNUMach microkernel), as processes are forced to make frequent calls to the kernel, and therefore the whole thing runs about 66% slower [than Linux]. There is a theoretical design with will make it only 15% slower or so (Hurd on L4), but it seems to have other problems, so the project is no longer sure what kernel it will run on when the Hurd gets released. Effectively, most of the development is spent looking for an architecture that is both modular and fast, and therefore it may look like real "development" is not happening. The same thing can be done to Crossfire, making one "core" module, which will be tasked with starting up, parsing command line arguments, and starting up all other things as modules, provide a way of synchronising them and provide Inter-Module communication. If a message is sent to a module that is not currently there the core would then try to load that module before failing, so the random map generator only gets loaded after someone decides to enter a random map. This feature will also make handling errors easier, so if a person enters a random map, and random map generator is not avaliable, it will be possible to display an error to the player, like "The total chaos inside prevents you from entering". The player could then decide to build and install just the random map generator, and the server would not need to be restarted to apply the changes. Likewise for all other components, so applying a security update will not mean restarting the server. Also if some module segfaults, it will not need a restart of the whole server, but simply of that module. This should aid the server stability, as "something wrong when casting meteor swarm resulting in the spell not working" will not disturb someone else killing dragons in a dungeon. Having the code highly modular also will mean each module can be started as a seperate process (or thread, but that is slightly less portable, if somewhat faster), making it possible to run the server usefully on SMP systems (or even clusters), and therefore potentially much faster than the speed at which the current server runs. I don't know if this is what is wanted, but the advantages seem tempting to me. From tchize at myrealbox.com Wed Jan 18 12:42:45 2006 From: tchize at myrealbox.com (tchize) Date: Wed Jan 18 12:48:28 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43CDE083.1080207@sonic.net> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <200601170949.13597.yann.chachkoff@myrealbox.com> <43CDE083.1080207@sonic.net> Message-ID: <200601181942.51303.tchize@myrealbox.com> Le Mercredi 18 Janvier 2006 07:30, Mark Wedel a ?crit : > > However, I think if you start grouping all that stuff together, you start >loosing some of the advantages. > Depends once again on the size of things you regroup and how much they have in common. if you start making 80 modules for what is current server i think you also miss the point on managability :) > But one could do that to some extent without plugins. > > You could for example set up something like: > >struct object_type_description { > functype apply_func; > functype describe_func; > functype .... >} object_actions[MAX_OBJECT_TYPE > > Then in the code, you could do things like: > > if (object_actions[op->type].apply_func) > object_actions[op->type].apply_func(...) > > In a sense, a poor mans/specialized plugin. You then just need one >initialization function, but all the specialized code related to object type >itself could be in one place. > > You said it, it's the poor man version ;) If we modularize things, it is a good thing to have a plugin part in it. Even if some of things currently in core could be done as module not plugins (like let's say, binding a libCrossfireRandomMap.a at link time) you will probably get into the case when someone want to add new behaviours in plugins. -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060118/d281da76/attachment.pgp From tchize at myrealbox.com Wed Jan 18 12:54:38 2006 From: tchize at myrealbox.com (tchize) Date: Wed Jan 18 12:55:56 2006 Subject: [crossfire] Re: Moving server towards a modularized system? In-Reply-To: References: <1137572196.c7f31f9cyann.chachkoff@myrealbox.com> Message-ID: <200601181954.38610.tchize@myrealbox.com> Le Mercredi 18 Janvier 2006 18:25, Anton Oussik a ?crit : >Also if some module segfaults, it will not need a restart of the whole >server, but simply of that module. This should aid the server >stability, as "something wrong when casting meteor swarm resulting in >the spell not working" will not disturb someone else killing dragons >in a dungeon. > Well ,technically, as a plugin is loaded in the process memory area and share the process pid, a segfault in module mean a segfault in whole server (we are not in java where you cant do a catch (Throwable t) >Having the code highly modular also will mean each module can be >started as a seperate process (or thread, but that is slightly less >portable, if somewhat faster), making it possible to run the server >usefully on SMP systems (or even clusters), and therefore potentially >much faster than the speed at which the current server runs. > Of course when code is modular at this point you can think about multiprocesses interaction and all sort of stuff ;) but that's not, i think an immediate aim :) (and yes, in this case a segfault in a module is not a segfault in core processe :p) >I don't know if this is what is wanted, but the advantages seem tempting to > me. to me too, but for having already explored possibilities of multithreading cf, you have to fix before lots of potential concurrency issues :) > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060118/abe98287/attachment.pgp From tchize at myrealbox.com Wed Jan 18 13:10:30 2006 From: tchize at myrealbox.com (tchize) Date: Wed Jan 18 13:12:28 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <20060118144205.48785.qmail@web32709.mail.mud.yahoo.com> References: <20060118144205.48785.qmail@web32709.mail.mud.yahoo.com> Message-ID: <200601182010.30478.tchize@myrealbox.com> Le Mercredi 18 Janvier 2006 15:42, Miguel Ghobangieno a ?crit : >Except that you are not working on one section of the >code, you are restructuring the whole server into >diffrent modules. This means that if you develop in >cvs there will be breakage with any and everyone else >as you sweeping edits touch every facet of the glory >that is crossfire. > >The C in CVS may mean concurrent but it doesn't mean >perfect. > >If you want to make the sweeping changes on your own >system; enjoy. But please, before committing to cvs do >extensive bugtesting so that it 1) doesn't make the >code any slower, 2) doesn't break anything, and 3) >maybe makes MS less of a hog? > First, it will be a step by step change. For the obvious reason, a patch changing 40% of server code would take weeks to create and during this change, developper of the patch would have to do a regular 'cvs update' to incorporate other developpers change and would have to adapt each of their change to new modular system. Second, indeed cvs isn't perfect. It's written in there doc, nothing can replace the coder in case of a conflict (eg we are moving away the whole parts of move_apply() somewhere else and at same time another developper is trying to add new object type). This is not a problem. After cvs update, the guys trying to add things to move_apply() will see a conflict in move_apply() and will see the other coder comment saying "this code has been mainly moved to xyz". Just also move your new add-on. Once again, there has been restructurations in the past. This of course lead to conflicts during cvs update process. Then what? Just fix the conflict. That's how teamworks goes. Team is adapting you code changes during their development process, when team has commited adapt your uncommited changes to what team commited. Unless you work on a 'checkout, work on my stuff for 2 months locally, try to commit', the conflicts shouldn't be a big deal as, once again, it is very difficult to commit big patches. If it is really needed, i suppose the change could be done in a branch. This would allow people who want to explore the idea of modularized system to work in team and try different paths without fearing the 'try not to break the existing'. This head should then be merged on this branch in a regular basis. This is lots of additionnal work. But it also has it's gains imho. And when modularized system is ok, move it to the head. But there, this mean when branch is finally moved to the head (if idea does not proves to be a dead end), people will indeed see a 40% of server code patch coming. -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060118/06adc2f6/attachment.pgp From tchize at myrealbox.com Wed Jan 18 13:17:39 2006 From: tchize at myrealbox.com (tchize) Date: Wed Jan 18 13:19:37 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <20060118000410.75105.qmail@web32711.mail.mud.yahoo.com> References: <20060118000410.75105.qmail@web32711.mail.mud.yahoo.com> Message-ID: <200601182017.39853.tchize@myrealbox.com> Le Mercredi 18 Janvier 2006 01:04, Miguel Ghobangieno a ?crit : >Try mucking in the linux kernel without grep, tell me >how that goes. > I did, for school. And at that time the block device part of kernel was considered a mess by most developpers. However i used grep far less then i had to do with cf. (sometimes i did as it was faster to know where an error message came from :p) Considering line number ratio, kernel is far more structured than cf :) -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060118/2360b30d/attachment.pgp From tchize at myrealbox.com Wed Jan 18 13:30:22 2006 From: tchize at myrealbox.com (tchize) Date: Wed Jan 18 13:30:26 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1137534034.c7dde81cyann.chachkoff@myrealbox.com> References: <1137534034.c7dde81cyann.chachkoff@myrealbox.com> Message-ID: <200601182030.23049.tchize@myrealbox.com> Le Mardi 17 Janvier 2006 22:40, Yann Chachkoff a ?crit : >> Current idea? I must have missed something, I didn't know you decided, >> above all the objections, to go > >ahead and rip apart the server anyway. > >Idea != Decision. Thanks to specify Yann :) > >Besides that, I don't think anybody requires your permission to code. > Democracy, we require team approval, not not every individuals approval (or code would never evolved :p ). However, i listen to every suggestion and critics (as far as i am able to find time to read them all ;) ) >> Why should all work have to stop because YOU want to restructure the >> server.. because you can't figure out grep... > >I can assure you that tchize is skilled enough to use grep, by far. The > whole point was that a properly structured code should *never* require > using grep. Yes, even large-scale enterprise projects. > man grep | grep -E '^[ ]*-|^[ ]*grep \[' usefull help shortcut :p -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060118/c18226b8/attachment.pgp From tchize at myrealbox.com Wed Jan 18 13:40:42 2006 From: tchize at myrealbox.com (tchize) Date: Wed Jan 18 13:40:45 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <20060117164634.42845.qmail@web32701.mail.mud.yahoo.com> References: <20060117164634.42845.qmail@web32701.mail.mud.yahoo.com> Message-ID: <200601182040.42333.tchize@myrealbox.com> Le Mardi 17 Janvier 2006 17:46, Miguel Ghobangieno a ?crit : >Did you not read my post. If you are screwing around >with the code structure of the server then other >programmers do have to wait untill you are done as >they do not want their code to suddenly break when it >intersects with your massive changes. You must not be >at all experianced in these matters (as you indicated >before in fingering crossfire for the sin of you >having to grep through it). > Ho yes am experimented in big refactoring of team project. Once again there won't be something as a 40% server code change in a row (unless we work on a branch and then have to merge it in head) >This will hold up usefull game development for months >all because you and friends believe that you are above >grep. I use grep on a regular basis. But for scripts or unstructured text searching. Moreover, you are assuming all people wanting to contribute to crossfire: 1) know how to handle grep 2) have a grep tool at disposal crossfire is multiplatform, not every windows coder have djgnu or wygwin installed on their system, and not every coder is skilled like you in grep. Having to grep throught to code to guess where you have to add your new features is a symptom of upcoming code management problems. From tchize at myrealbox.com Wed Jan 18 13:56:20 2006 From: tchize at myrealbox.com (tchize) Date: Wed Jan 18 13:58:28 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <20060117165401.39242.qmail@web32713.mail.mud.yahoo.com> References: <20060117165401.39242.qmail@web32713.mail.mud.yahoo.com> Message-ID: <200601182056.20998.tchize@myrealbox.com> Le Mardi 17 Janvier 2006 17:54, Miguel Ghobangieno a ?crit : >. How about >adding things? It's fun, people don't get angry at you >as you aren't breaking or throwing out what they've >made aswell. > lot's of 'things' added did break things (weather code made the server simply uncompilable in the beginings, led to duplicate items. Town portal led to people able to acces other people's appartments and get stuck. polymorphing monsters lets to demons inside newbie house... For most of slight or more important breakages of game logic, there is a common factor. Side effects unexpected from the add-on coder. Regulating what add-on has access to does allow it a wider range of possible improvments (as it is easier to find where in core you have to interact) while giving coder more insurance on possible side effects of it's calls (documented list of callable methods). -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060118/8661847b/attachment.pgp From brenlally at gmail.com Wed Jan 18 13:57:44 2006 From: brenlally at gmail.com (Brendan Lally) Date: Wed Jan 18 13:58:34 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601182040.42333.tchize@myrealbox.com> References: <20060117164634.42845.qmail@web32701.mail.mud.yahoo.com> <200601182040.42333.tchize@myrealbox.com> Message-ID: <7903f03c0601181157q54a3a55an75f6d5d5e65b6850@mail.gmail.com> On 1/18/06, tchize wrote: > Having to grep throught to code to guess where you have to add your new > features is a symptom of upcoming code management problems. I agree on this point, however I suspect that much of this could be avoided by simply shifting a few functions and #define's around, much of what exists currently has been grandfathered into various parts of the code (look at include/define.h for a good example of this) moving these into more logical locations (or maybe even just documented locations) would help in finding various parts of the source code. Likewise moving things around could probably reduce the number of functions which are called from different files, improving the usefulness of text-editor based find tools. From yann.chachkoff at myrealbox.com Wed Jan 18 14:43:00 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Wed Jan 18 14:44:27 2006 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1137616980.c7d1251cyann.chachkoff@myrealbox.com> > Except that you are not working on one section of the code, you are restructuring the whole server into diffrent modules. This means that if you develop in cvs there will be breakage with any and everyone else as you sweeping edits touch every facet of the glory that is crossfire. Well, the required editing is, for the most part, moving existing code rather than change it. Algorithms will stay the same, execution paths as well, etc. What will change is the way various functions are called - so for example, calling "apply(this_object)" would become "this_object->manual_apply(this_object)" (This is only an illustration :)). Only in a few cases will new code be needed - mostly to bind the modules content to the code. So basically, you'd expect problems in: - The module loading/unloading (a clearly separate, specific piece of code); - Improperly converted calls (which can be avoided if we're careful enough). So no heavy breakage is expected. > The C in CVS may mean concurrent but it doesn't mean perfect. I never said the contrary. It just means that no, even a refactoring of that scale wouldn't block the whole project for months, that's all. > If you want to make the sweeping changes on your own system; enjoy. But please, before committing to cvs do extensive bugtesting so that it 1) doesn't make the code any slower, 2) doesn't break anything, and 3) maybe makes MS less of a hog? I think all Crossfire coders perform quite some tests before committing to CVS - nobody would want to be responsible of severely damaging the server. Simply understand that coders are not perfect, and that they cannot think about all possible cases. To take a recent example, there was a library-related bug in the new plugin code that I didn't spot on time; was that because I didn't test that bit of code ? Of course not - but on the architecture I was trying it on, it simply didn't exist. Also, let's not forget that the CVS codebase wasn't meant to be used on "production" servers: the CVS is (theorically) the repository in which the "work in progress" server code is stored. Stable versions are distributed in the various packages available on the SF website. Now, it is true that if some big changes are to be done, it would probably be a good idea to release a new "stable" version first, so that server administrators like you can get all the recent features without having to struggle through the possibly stability-threatening changes. Regarding possible performance issues, I think that there are ways to ensure that nothing noticeable happens. Most of the time lost would probably get when the plugin/module gets initialized and loaded - and that's unimportant for the running speed of the server. From mikeeusaa at yahoo.com Wed Jan 18 15:52:09 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Wed Jan 18 16:29:28 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1137616980.c7d1251cyann.chachkoff@myrealbox.com> Message-ID: <20060118215209.94014.qmail@web32711.mail.mud.yahoo.com> Well enjoy raping the server. I'm retiring from CF untill a certain unnamed feature I was promised 1/2 a year ago (no not plots) is in. See you soon or never. --- Yann Chachkoff wrote: > > Except that you are not working on one section of > the > code, you are restructuring the whole server into > diffrent modules. This means that if you develop in > cvs there will be breakage with any and everyone > else > as you sweeping edits touch every facet of the glory > that is crossfire. > > Well, the required editing is, for the most part, > moving existing code rather than change it. > Algorithms will stay the same, execution paths as > well, etc. What will change is the way various > functions are called - so for example, calling > "apply(this_object)" would become > "this_object->manual_apply(this_object)" (This is > only an illustration :)). Only in a few cases will > new code be needed - mostly to bind the modules > content to the code. > > So basically, you'd expect problems in: > - The module loading/unloading (a clearly separate, > specific piece of code); > - Improperly converted calls (which can be avoided > if we're careful enough). > > So no heavy breakage is expected. > > > The C in CVS may mean concurrent but it doesn't > mean > perfect. > > I never said the contrary. It just means that no, > even a refactoring of that scale wouldn't block the > whole project for months, that's all. > > > If you want to make the sweeping changes on your > own system; enjoy. But please, before committing to > cvs do extensive bugtesting so that it 1) doesn't > make the code any slower, 2) doesn't break anything, > and 3) maybe makes MS less of a hog? > > I think all Crossfire coders perform quite some > tests before committing to CVS - nobody would want > to be responsible of severely damaging the server. > Simply understand that coders are not perfect, and > that they cannot think about all possible cases. To > take a recent example, there was a library-related > bug in the new plugin code that I didn't spot on > time; was that because I didn't test that bit of > code ? Of course not - but on the architecture I was > trying it on, it simply didn't exist. > > Also, let's not forget that the CVS codebase wasn't > meant to be used on "production" servers: the CVS is > (theorically) the repository in which the "work in > progress" server code is stored. Stable versions are > distributed in the various packages available on the > SF website. Now, it is true that if some big changes > are to be done, it would probably be a good idea to > release a new "stable" version first, so that server > administrators like you can get all the recent > features without having to struggle through the > possibly stability-threatening changes. > > Regarding possible performance issues, I think that > there are ways to ensure that nothing noticeable > happens. Most of the time lost would probably get > when the plugin/module gets initialized and loaded - > and that's unimportant for the running speed of the > server. > > > _______________________________________________ > 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 Thu Jan 19 00:44:53 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 19 00:46:28 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601181942.51303.tchize@myrealbox.com> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <200601170949.13597.yann.chachkoff@myrealbox.com> <43CDE083.1080207@sonic.net> <200601181942.51303.tchize@myrealbox.com> Message-ID: <43CF3565.709@sonic.net> tchize wrote: > Le Mercredi 18 Janvier 2006 07:30, Mark Wedel a ?crit : > >> However, I think if you start grouping all that stuff together, you start >> loosing some of the advantages. >> > > Depends once again on the size of things you regroup and how much they have in > common. if you start making 80 modules for what is current server i think you > also miss the point on managability :) Right, but you have to keep this in mind. For example, there are probably about 100 different object types out there. So if we take the module example, you either get 100 different modules for all those objects, or a fairly big/complex module that handles those 100 different object types. It is unclear to me right now which is the better case. This gets especially messy if say 10 object types are complex enough that they really should be in their own module. So now you have those 10 separate modules + common module for other 90 types. This then starts to get away from making things easy to find (is it in the common module, or one of those other 10) > >> But one could do that to some extent without plugins. >> >> You could for example set up something like: >> >> struct object_type_description { >> functype apply_func; >> functype describe_func; >> functype .... >> } object_actions[MAX_OBJECT_TYPE >> >> Then in the code, you could do things like: >> >> if (object_actions[op->type].apply_func) >> object_actions[op->type].apply_func(...) >> >> In a sense, a poor mans/specialized plugin. You then just need one >> initialization function, but all the specialized code related to object type >> itself could be in one place. >> >> > You said it, it's the poor man version ;) > If we modularize things, it is a good thing to have a plugin part in it. Even > if some of things currently in core could be done as module not plugins (like > let's say, binding a libCrossfireRandomMap.a at link time) you will probably > get into the case when someone want to add new behaviours in plugins. True. However, I'd think that to do this by true plugins, the objects/archetypes have to get updated, eg, hooks added for describe item, apply item, etc. My poor mans version avoids that. Another question is whether a plugin can call another plugin - that in itself could perhaps limit the ability of some things to be in plugins. From mwedel at sonic.net Thu Jan 19 00:51:27 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 19 00:54:28 2006 Subject: [crossfire] Re: Polymorph etc In-Reply-To: References: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> <43CC18D3.2090602@laposte.net> <200601171309.55949.tchize@myrealbox.com> Message-ID: <43CF36EF.2080905@sonic.net> Anton Oussik wrote: > On the note of adding/fixing spells, could some high level spells be > added into CF, which need higher levels (like 40, 60, 80, 100) in a > skill to be able to cast them? At the moment there is little point in > levelling things like sourcery beyond level 15, when you can cast town > portal. Either re-shuffling spells about or adding some more spells to > fill the gaps would be needed for that. Reshuffling of spells may make sense. The current spell levels where set back in the days when I believe max level was much lower. I'd be a bit concerned about adding new spells that are even more powerful - a fair number of the spells are already pretty powerful at high levels, and adding more powerful spells doesn't necessarily seem like it would help things out much. And I think most spells already have pretty large areas of effect - making even bigger fireballs/cones are likely to get to the point where one spell covers the entier map. > > Adding fighting levels to weapons would also make sense, and in my > opinion would be more consistent for things like swords and bows than > item power is. item_power currently does that. total item power was deemed a better approach - for one reasons, races that can not equip all the items otherwise get sort of screwed if they are limited to wearing items below there level or something - item power helps balance that to some extent by letting those characters equip same power of items. From mwedel at sonic.net Thu Jan 19 00:56:10 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 19 01:00:28 2006 Subject: [crossfire] Re: gcfclient options deathlist In-Reply-To: References: <20060117181329.44726.qmail@web32702.mail.mud.yahoo.com> <43CDDAEE.8020201@sonic.net> Message-ID: <43CF380A.5040604@sonic.net> Anton Oussik wrote: > Yes, it asks you something like > > "Are you sure you want want to quit the character?", > > not > > "WARNING: You are about to delete the character! > Are you sure you want to completely delete the character and entirely > and irreversably remove all evidence that the character ever existed > for ever and ever?". > > I think what Mikee was referring to is that the comfirmation message > does not look threatening enough. I agree, it is how I lost my first > ever two characters. :-) > > Mark, would it be possible to make the "-split" option work on gtk-v2 > client? It effectively allows the client to run on any screen > resolution, and allows users to position controls the way they like > it. I think the main reason so many people are still using gtk-v1 > client is because it is able to better fit their needs. Anything is possible. It'd be a bit of work if you want to load/save window size and position. I'm also not 100% sure how well suited it is to do that - the layout is all done by glade, and I don't know if there is any reasonable way to do split windows and keep the glade interface design. From delbd at oma.be Thu Jan 19 03:08:16 2006 From: delbd at oma.be (David Delbecq) Date: Thu Jan 19 03:08:28 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43CF3565.709@sonic.net> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <200601181942.51303.tchize@myrealbox.com> <43CF3565.709@sonic.net> Message-ID: <200601191008.17065.delbd@oma.be> Le Jeudi 19 Janvier 2006 07:44, Mark Wedel a ?crit : > For example, there are probably about 100 different object types out there. > So if we take the module example, you either get 100 different modules for all > those objects, or a fairly big/complex module that handles those 100 different > object types. I think there are more object types than this! > > It is unclear to me right now which is the better case. > none of both solutions :) > This gets especially messy if say 10 object types are complex enough that they > really should be in their own module. So now you have those 10 separate modules > + common module for other 90 types. This then starts to get away from making > things easy to find (is it in the common module, or one of those other 10) > Let's say i've got a problem with a buggy trap. This is how i see it: 1) i do a 'dump' in dm mode to get info on buggy archetype. Server says me type xyz (the trape type) and maybe also in the dump the is a list of plugins linked to this object. 2) i go in the code of this (or those) module and start trying to fix the bug :) (please note, currently to fix an object, the procedure is something like dm -> get type -> open define.h -> get the associated #TYPE for this type -> issue a grep on this type to find where there is specific code.) Also, having a simple document of which module does what would be interresting. It's easy to manage (a module X -> description chapter and a item type -> module chapter) > > True. However, I'd think that to do this by true plugins, the > objects/archetypes have to get updated, eg, hooks added for describe item, apply > item, etc. My poor mans version avoids that. Or we can have a plugin, in initialisation code do a 'plug those callbacks to type x, thosr to type y, and those to skill z'. Ideally, in this idea, if you omit the 'traps' plugin from server code, you can have a server which knows nothing about traps :p (an we could imagine the traps module handling trap objects and trap related skills :p). If you omit the all spells modules, you could have a server in which casting spells is impossible (only bash and crash) > > Another question is whether a plugin can call another plugin - that in itself > could perhaps limit the ability of some things to be in plugins. Very good point. Plugins put aside for a few seconds, in modular project, there is usually a notion of modules dependencies (module X depends on module Y and core, module Y depends on core). I think we need to handle this dependencies system or we lose a bit part of interest in modularization. Back to plugins, that means we need plugin X to be able to do calls on plugin X. This shouldn't be difficult to do. Simply a plugin would link a list of callback in initialization but would also provide core a list of 'public callback' (that is a list a named method). Core will the provide every plugin depending on X the possibility to access them. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -- David Delbecq Royal Meteorological Institute of Belgium - Pingouins dans les champs, hiver m?chant From antonoussik at gmail.com Thu Jan 19 03:24:49 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Thu Jan 19 03:32:30 2006 Subject: [crossfire] Re: Polymorph etc In-Reply-To: <43CF36EF.2080905@sonic.net> References: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> <43CC18D3.2090602@laposte.net> <200601171309.55949.tchize@myrealbox.com> <43CF36EF.2080905@sonic.net> Message-ID: On 19/01/06, Mark Wedel wrote: > Anton Oussik wrote: > > On the note of adding/fixing spells, could some high level spells be > > added into CF, which need higher levels (like 40, 60, 80, 100) in a > > skill to be able to cast them? At the moment there is little point in > > levelling things like sourcery beyond level 15, when you can cast town > > portal. Either re-shuffling spells about or adding some more spells to > > fill the gaps would be needed for that. > > Reshuffling of spells may make sense. The current spell levels where set back > in the days when I believe max level was much lower. > > I'd be a bit concerned about adding new spells that are even more powerful - a > fair number of the spells are already pretty powerful at high levels, and adding > more powerful spells doesn't necessarily seem like it would help things out > much. And I think most spells already have pretty large areas of effect - > making even bigger fireballs/cones are likely to get to the point where one > spell covers the entier map. I did not necessarily mean more powerful spells. Some existing spells can get moved up the chain, and intermediate "interesting" spells can be added to fill the gaps, so a player always has a new spell "just within reach". Either that, or spell could be made to not get more powerful with level, and then players could learn more powerful versions of a spell they already know, which would exist every 5-10 levels. From brenlally at gmail.com Thu Jan 19 05:46:22 2006 From: brenlally at gmail.com (Brendan Lally) Date: Thu Jan 19 05:46:27 2006 Subject: [crossfire] Re: Polymorph etc In-Reply-To: References: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> <43CC18D3.2090602@laposte.net> <200601171309.55949.tchize@myrealbox.com> <43CF36EF.2080905@sonic.net> Message-ID: <7903f03c0601190346i5c5d00b8y55030c87d4765003@mail.gmail.com> On 1/19/06, Anton Oussik wrote: > I did not necessarily mean more powerful spells. Some existing spells > can get moved up the chain, and intermediate "interesting" spells can > be added to fill the gaps, so a player always has a new spell "just > within reach". Either that, or spell could be made to not get more > powerful with level, and then players could learn more powerful > versions of a spell they already know, which would exist every 5-10 > levels. The problem with that is that skills already scale with level, icestorm is one of the best cold spells at any level, because of how well its damage and range scale, so unless you want to nerf the scaling of all the low level spells, they are going to remain the best option, especially if the base level of the supposedly 'better' spells is increased, because then they will have fewer levels to scale over. From mikeeusaa at yahoo.com Thu Jan 19 04:30:02 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Thu Jan 19 09:39:37 2006 Subject: [crossfire] Re: Polymorph etc In-Reply-To: Message-ID: <20060119103002.60697.qmail@web32707.mail.mud.yahoo.com> Could add some circular spells like in diablo... the object to make that possible was added a few months ago. --- Anton Oussik wrote: > On 19/01/06, Mark Wedel wrote: > > Anton Oussik wrote: > > > On the note of adding/fixing spells, could some > high level spells be > > > added into CF, which need higher levels (like > 40, 60, 80, 100) in a > > > skill to be able to cast them? At the moment > there is little point in > > > levelling things like sourcery beyond level 15, > when you can cast town > > > portal. Either re-shuffling spells about or > adding some more spells to > > > fill the gaps would be needed for that. > > > > Reshuffling of spells may make sense. The > current spell levels where set back > > in the days when I believe max level was much > lower. > > > > I'd be a bit concerned about adding new spells > that are even more powerful - a > > fair number of the spells are already pretty > powerful at high levels, and adding > > more powerful spells doesn't necessarily seem like > it would help things out > > much. And I think most spells already have pretty > large areas of effect - > > making even bigger fireballs/cones are likely to > get to the point where one > > spell covers the entier map. > > I did not necessarily mean more powerful spells. > Some existing spells > can get moved up the chain, and intermediate > "interesting" spells can > be added to fill the gaps, so a player always has a > new spell "just > within reach". Either that, or spell could be made > to not get more > powerful with level, and then players could learn > more powerful > versions of a spell they already know, which would > exist every 5-10 > levels. > > _______________________________________________ > 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 mikeeusaa at yahoo.com Thu Jan 19 15:07:26 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Thu Jan 19 18:50:14 2006 Subject: [crossfire] Re: Polymorph etc In-Reply-To: <7903f03c0601190346i5c5d00b8y55030c87d4765003@mail.gmail.com> Message-ID: <20060119210726.5397.qmail@web32714.mail.mud.yahoo.com> One could add new spells... like circular spells. --- Brendan Lally wrote: > On 1/19/06, Anton Oussik > wrote: > > I did not necessarily mean more powerful spells. > Some existing spells > > can get moved up the chain, and intermediate > "interesting" spells can > > be added to fill the gaps, so a player always has > a new spell "just > > within reach". Either that, or spell could be > made to not get more > > powerful with level, and then players could learn > more powerful > > versions of a spell they already know, which would > exist every 5-10 > > levels. > > The problem with that is that skills already scale > with level, > icestorm is one of the best cold spells at any > level, because of how > well its damage and range scale, so unless you want > to nerf the > scaling of all the low level spells, they are going > to remain the best > option, especially if the base level of the > supposedly 'better' spells > is increased, because then they will have fewer > levels to scale over. > > _______________________________________________ > 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 eracclists at bellsouth.net Fri Jan 20 10:46:59 2006 From: eracclists at bellsouth.net (ERACC) Date: Fri Jan 20 10:48:34 2006 Subject: [crossfire] On moving the Lone Town apartment [bigworldized pupland] In-Reply-To: <20060118000514.68199.qmail@web32707.mail.mud.yahoo.com> References: <20060118000514.68199.qmail@web32707.mail.mud.yahoo.com> Message-ID: <200601201047.00674.eracclists@bellsouth.net> On Tuesday 17 January 2006 06:05 pm Miguel Ghobangieno wrote: > lalo is bigworldizing pupland, the villas could be > placed somewhere on said bigworldized pupland (note: > how long untill it's done?). Lalo? Are you there? I would like to know how this is progressing and when you think you will have it done. I don't want to move the Lone Town apartment yet if you are actually doing this. I'd rather like to see his merged maps first. If you want to collaborate on merging pup land into big world you can write me off-list using the address below. Gene -- Mandriva Linux release 2006.0 (Official) for i586 10:43:01 up 6 days, 17:35, 11 users, load average: 0.13, 0.11, 0.09 ERA Computer Consulting - http://www.eracc.com/ eComStation, Linux, FreeBSD, OpenServer & UnixWare resellers From tchize at myrealbox.com Fri Jan 20 12:46:18 2006 From: tchize at myrealbox.com (tchize) Date: Fri Jan 20 12:46:29 2006 Subject: [crossfire] the marvels of miscommunication :) Message-ID: <1137782778.c7b781dctchize@myrealbox.com> Done a long time ago, never used due to misunderstandings :), new crossfire banner proposal Design by Yann Chachkoff (alias Gros alias Lauwenmark) Colors by David Delbecq (alias Tchize) licence terms of picture to be clarified in future mail. Need to find suitable artistic licence which is gpl compatible... From alex_sch at telus.net Fri Jan 20 16:04:25 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri Jan 20 16:04:29 2006 Subject: [crossfire] the marvels of miscommunication :) In-Reply-To: <1137782778.c7b781dctchize@myrealbox.com> References: <1137782778.c7b781dctchize@myrealbox.com> Message-ID: <43D15E69.2040607@telus.net> tchize wrote: >Done a long time ago, never used due to misunderstandings :), new crossfire banner proposal > >Design by Yann Chachkoff (alias Gros alias Lauwenmark) >Colors by David Delbecq (alias Tchize) > >licence terms of picture to be clarified in future mail. Need to find suitable artistic licence which is gpl compatible... > > I see no attachment or link to an image ;P The irony of the subject. :) Alex Schultz From yann.chachkoff at myrealbox.com Fri Jan 20 16:24:32 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Fri Jan 20 16:25:31 2006 Subject: [crossfire] the marvels of miscommunication :) In-Reply-To: <1137782778.c7b781dctchize@myrealbox.com> References: <1137782778.c7b781dctchize@myrealbox.com> Message-ID: <200601202324.45971.yann.chachkoff@myrealbox.com> Le Vendredi 20 Janvier 2006 19:46, tchize a ?crit : > Done a long time ago, never used due to misunderstandings :), new crossfire > banner proposal > > Design by Yann Chachkoff (alias Gros alias Lauwenmark) > Colors by David Delbecq (alias Tchize) > > licence terms of picture to be clarified in future mail. Need to find > suitable artistic licence which is gpl compatible... > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire I'd like to put the original pencil artwork under the following terms. It is basically the Free Art License rendered GPL-compatible by removing the Article 3 (which prevented to include FAL-covered works into non-FAL work). Also note that for practical reasons, I used the Belgian Law as the legal reference, not the French one (practically, there are no difference in this specific case, except that it makes me easier to solve possible legal issues). Tchize: Given that, according to the reference law, the license doesn't apply retroactively, you'll have to explicitly agree to put your coloring job under it (as a "subsequent work" of the original). Note that none of the drawings (be pencil or the digital version) requires an explicit (C) on it - the Belgian law ensures proper copyright property even in the absence of it. Thus, no change in the pictures is required; the license text simply needs to be accessible alongside the picture (either by a text file shipped with the code in the case of the image is used in the client, or by an hyperlink/webpage if used on the website). Any legal expert to confirm the compatibility of this text to the GPL, please ? Lauwenmark's License Proposal: Version: 1.0 ??? DEFINITIONS - The work of art : A communal work which includes the initial artwork as well as all subsequent contributions (subsequent originals and copies). It is created at the initiative of the original artist who, by this license, defines the conditions according to which the contributions are made. - The original work of art : This is the artwork created by the initiator of the communal work, of which copies will be modified by whosoever wishes. - Subsequent works : These are the additions put forward by the artists who contribute to the formation of the work by taking advantage of the right to reproduction, distribution and modification that this license confers on them. - The Original (the work's source or resource) : A dated example of the work, of its definition, of its partition or of its program which the originator provides as the reference for all future updatings, interpretations, copies or reproductions. - Copy : Any reproduction of an original as defined by this license. - The author or the artist of the original work of art: This is the person who created the work which is at the heart of the ramifications of this modified work of art. By this license, the author determines the conditions under which these modifications are made. - Contributor: Any person who contributes to the creation of the work of art. He is the author or the artist of an original art object resulting from the modification of a copy of the initial artwork or the modification of a copy of a subsequent work of art. ??? 1. AIMS The aim of this license is to define the conditions according to which you can use this work freely. 2. EXTENT OF THE USAGE This work of art is subject to copyright, and the author, by this license, specifies the extent to which you can copy, distribute and modify it. 2.1 FREEDOM TO COPY (OR OF REPRODUCTION) You have the right to copy this work of art for your personal use, for your friends or for any other person, by employing whatever technique you choose. 2.2 FREEDOM TO DISTRIBUTE, TO INTERPRET (OR OF REPRESENTATION) You can freely distribute the copies of these works, modified or not, whatever their medium, wherever you wish, for a fee or for free, if you observe all the following conditions: - attach this license, in its entirety, to the copies or indicate precisely where the license can be found, - specify to the recipient the name of the author of the originals, - specify to the recipient where he will be able to access the originals (original and subsequent). The author of the original may, if he wishes, give you the right to broadcast/distribute the original under the same conditions as the copies. 2.3 FREEDOM TO MODIFY You have the right to modify the copies of the originals (original and subsequent), partially or otherwise, respecting the conditions set out in article 2.2 , in the event of distribution (or representation) of the modified copy. The author of the original may, if he wishes, give you the right to modify the original under the same conditions as the copies. 3. YOUR AUTHOR'S RIGHTS The object of this license is not to deny your author's rights on your contribution. By choosing to contribute to the evolution of this work of art, you only agree to give to others the same rights with regard to your contribution as those which were granted to you by this license. 4. DURATION OF THE LICENCE This license takes effect as of your acceptance of its provisions. The fact of copying, distributing, or of modifying the work constitutes a tacit agreement. This license will remain in force for as long as the copyright which is attached to the work of art. If you do not respect the terms of this license, you automatically lose the rights that it confers. If the legal status to which you are subject makes it impossible for you to respect the terms of this license, you may not make use of the rights which it confers. 5. VARIOUS VERSIONS OF THE LICENCE This license may undergo periodic modifications to incorporate improvements by its authors (instigators of the "copyleft attitude" movement) by way of new, numbered versions. You will have the choice of accepting the provisions contained in the version under which the copy was communicated to you, or alternatively, to use the provisions of one of the subsequent versions. 6. SUB-LICENSING Sub-licenses are not authorized by the present license. Any person who wishes to make use of the rights that it confers will be directly bound to the author of the original work. 7. THE LAW APPLICABLE TO THIS CONTRACT This license is subject to Belgian law. -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060120/37b8cc7a/attachment.pgp From tchize at myrealbox.com Fri Jan 20 17:51:11 2006 From: tchize at myrealbox.com (tchize) Date: Fri Jan 20 17:54:31 2006 Subject: [crossfire] the marvels of miscommunication :) Message-ID: <1137801071.c7c6799ctchize@myrealbox.com> Strange, i did attach it. anyway sending again. -----Original Message----- From: Alex Schultz To: Crossfire Discussion Mailing List Date: Fri, 20 Jan 2006 15:04:25 -0700 Subject: Re: [crossfire] the marvels of miscommunication :) tchize wrote: >Done a long time ago, never used due to misunderstandings :), new crossfire banner proposal > >Design by Yann Chachkoff (alias Gros alias Lauwenmark) >Colors by David Delbecq (alias Tchize) > >licence terms of picture to be clarified in future mail. Need to find suitable artistic licence which is gpl compatible... > > I see no attachment or link to an image ;P The irony of the subject. :) Alex Schultz _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire -------------- next part -------------- A non-text attachment was scrubbed... Name: crossfirebanner.png Type: image/png Size: 112157 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060121/2f8ce7b4/crossfirebanner-0001.png From mikeeusaa at yahoo.com Sat Jan 21 04:53:43 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sat Jan 21 12:45:28 2006 Subject: [crossfire] the marvels of miscommunication :) In-Reply-To: <1137782778.c7b781dctchize@myrealbox.com> Message-ID: <20060121105343.58060.qmail@web32707.mail.mud.yahoo.com> BSD or... the GPL. You don't need an artistic license. --- tchize wrote: > Done a long time ago, never used due to > misunderstandings :), new crossfire banner proposal > > Design by Yann Chachkoff (alias Gros alias > Lauwenmark) > Colors by David Delbecq (alias Tchize) > > licence terms of picture to be clarified in future > mail. Need to find suitable artistic licence which > is gpl compatible... > > > _______________________________________________ > 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 yann.chachkoff at myrealbox.com Sun Jan 22 01:53:15 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun Jan 22 01:54:31 2006 Subject: [crossfire] the marvels of miscommunication :) In-Reply-To: <20060121105343.58060.qmail@web32707.mail.mud.yahoo.com> References: <20060121105343.58060.qmail@web32707.mail.mud.yahoo.com> Message-ID: <200601220853.21534.yann.chachkoff@myrealbox.com> Le Samedi 21 Janvier 2006 11:53, Miguel Ghobangieno a ?crit : > BSD or... the GPL. > You don't need an artistic license. > Both BSD and GPL are based on the definition of "source" and "binary" forms of the product. Those definition are unsuitable for work like visual art, because defining what the "source" and the "binary" forms of a picture are is just about impossible and questionable. That's the reason why the FSF invented the GFDL for written documentation instead of using the GPL, for example: the application of the GPL to such works was simply too difficult. Besides that, the BSD licence is not compatible with the GPL and I don't agree with its terms, so that would have been a no-no even if it was applicable to a picture. One may of course nit-pick about complex ways of defining the "source" and the "binaries" of a visual artwork - but relying on obscure interpretations of a license to protect your work is definitely a bad strategy. -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060122/cbdbaa35/attachment.pgp From tchize at myrealbox.com Sun Jan 22 08:17:43 2006 From: tchize at myrealbox.com (tchize) Date: Sun Jan 22 08:18:34 2006 Subject: [crossfire] the marvels of miscommunication :) In-Reply-To: <200601202324.45971.yann.chachkoff@myrealbox.com> References: <1137782778.c7b781dctchize@myrealbox.com> <200601202324.45971.yann.chachkoff@myrealbox.com> Message-ID: <200601221517.53994.tchize@myrealbox.com> Le Vendredi 20 Janvier 2006 23:24, Yann Chachkoff a ?crit : >Le Vendredi 20 Janvier 2006 19:46, tchize a ?crit : >> Done a long time ago, never used due to misunderstandings :), new >> crossfire banner proposal >> >> Design by Yann Chachkoff (alias Gros alias Lauwenmark) >> Colors by David Delbecq (alias Tchize) >> >> licence terms of picture to be clarified in future mail. Need to find >> suitable artistic licence which is gpl compatible... >> >> >> _______________________________________________ >> crossfire mailing list >> crossfire@metalforge.org >> http://mailman.metalforge.org/mailman/listinfo/crossfire > >I'd like to put the original pencil artwork under the following terms. It is >basically the Free Art License rendered GPL-compatible by removing the >Article 3 (which prevented to include FAL-covered works into non-FAL work). >Also note that for practical reasons, I used the Belgian Law as the legal >reference, not the French one (practically, there are no difference in this >specific case, except that it makes me easier to solve possible legal >issues). > >Tchize: Given that, according to the reference law, the license doesn't > apply retroactively, you'll have to explicitly agree to put your coloring > job under it (as a "subsequent work" of the original). yup, agreed only if removal of 'copyleft attitude movement' reference in article 5, to prevent problems of confusong this artwrok licence with the FAL one. > >Note that none of the drawings (be pencil or the digital version) requires > an explicit (C) on it - the Belgian law ensures proper copyright property > even in the absence of it. Thus, no change in the pictures is required; the > license text simply needs to be accessible alongside the picture (either by > a text file shipped with the code in the case of the image is used in the > client, or by an hyperlink/webpage if used on the website). > >Any legal expert to confirm the compatibility of this text to the GPL, >please ? > >Lauwenmark's License Proposal: > >Version: 1.0 >??? > DEFINITIONS >- The work of art : > A communal work which includes the initial artwork as well as all > subsequent contributions (subsequent originals and copies). It is created > at the initiative of the original artist who, by this license, defines the > conditions according to which the contributions are made. >- The original work of art : > This is the artwork created by the initiator of the communal work, of which >copies will be modified by whosoever wishes. >- Subsequent works : > These are the additions put forward by the artists who contribute to the >formation of the work by taking advantage of the right to reproduction, >distribution and modification that this license confers on them. >- The Original (the work's source or resource) : > A dated example of the work, of its definition, of its partition or of its >program which the originator provides as the reference for all future >updatings, interpretations, copies or reproductions. >- Copy : > Any reproduction of an original as defined by this license. >- The author or the artist of the original work of art: > This is the person who created the work which is at the heart of the >ramifications of this modified work of art. By this license, the author >determines the conditions under which these modifications are made. >- Contributor: > Any person who contributes to the creation of the work of art. He is the >author or the artist of an original art object resulting from the >modification of a copy of the initial artwork or the modification of a copy >of a subsequent work of art. >??? > >1. AIMS >The aim of this license is to define the conditions according to which you > can use this work freely. > >2. EXTENT OF THE USAGE >This work of art is subject to copyright, and the author, by this license, >specifies the extent to which you can copy, distribute and modify it. > >2.1 FREEDOM TO COPY (OR OF REPRODUCTION) >You have the right to copy this work of art for your personal use, for your >friends or for any other person, by employing whatever technique you choose. > >2.2 FREEDOM TO DISTRIBUTE, TO INTERPRET (OR OF REPRESENTATION) >You can freely distribute the copies of these works, modified or not, > whatever their medium, wherever you wish, for a fee or for free, if you > observe all the following conditions: > - attach this license, in its entirety, to the copies or indicate precisely >where the license can be found, > - specify to the recipient the name of the author of the originals, > - specify to the recipient where he will be able to access the originals >(original and subsequent). The author of the original may, if he wishes, > give you the right to broadcast/distribute the original under the same > conditions as the copies. > >2.3 FREEDOM TO MODIFY >You have the right to modify the copies of the originals (original and >subsequent), partially or otherwise, respecting the conditions set out in >article 2.2 , in the event of distribution (or representation) of the >modified copy. The author of the original may, if he wishes, give you the >right to modify the original under the same conditions as the copies. > >3. YOUR AUTHOR'S RIGHTS >The object of this license is not to deny your author's rights on your >contribution. By choosing to contribute to the evolution of this work of > art, you only agree to give to others the same rights with regard to your > contribution as those which were granted to you by this license. > >4. DURATION OF THE LICENCE >This license takes effect as of your acceptance of its provisions. The fact > of copying, distributing, or of modifying the work constitutes a tacit > agreement. This license will remain in force for as long as the copyright > which is attached to the work of art. If you do not respect the terms of > this license, you automatically lose the rights that it confers. If the > legal status to which you are subject makes it impossible for you to > respect the terms of this license, you may not make use of the rights which > it confers. > >5. VARIOUS VERSIONS OF THE LICENCE >This license may undergo periodic modifications to incorporate improvements > by its authors (instigators of the "copyleft attitude" movement) by way of > new, numbered versions. >You will have the choice of accepting the provisions contained in the > version under which the copy was communicated to you, or alternatively, to > use the provisions of one of the subsequent versions. > >6. SUB-LICENSING >Sub-licenses are not authorized by the present license. Any person who > wishes to make use of the rights that it confers will be directly bound to > the author of the original work. > >7. THE LAW APPLICABLE TO THIS CONTRACT >This license is subject to Belgian law. -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060122/00afe477/attachment.pgp From yann.chachkoff at myrealbox.com Sun Jan 22 10:59:11 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun Jan 22 11:00:32 2006 Subject: [crossfire] the marvels of miscommunication :) In-Reply-To: <200601221517.53994.tchize@myrealbox.com> References: <1137782778.c7b781dctchize@myrealbox.com> <200601202324.45971.yann.chachkoff@myrealbox.com> <200601221517.53994.tchize@myrealbox.com> Message-ID: <200601221759.15866.yann.chachkoff@myrealbox.com> > >Tchize: Given that, according to the reference law, the license doesn't > > apply retroactively, you'll have to explicitly agree to put your coloring > > job under it (as a "subsequent work" of the original). > > yup, agreed only if removal of 'copyleft attitude movement' reference in > article 5, to prevent problems of confusong this artwrok licence with the > FAL one. > Done. Ok, so if nobody finds an incompatibility with the GPL before Wednesday, 0:00 GMT, the following license text will apply to the banner. Notice that it is in no way legally related to the FAL. For the record, the original banner concept ("original" as defined in this document) is (C)2003 by myself and a copy of it is available freely on demand. The CG'ed banner thus falls under the "subsequent work" case and is thus covered by the same text, which should grant its use in GPL programs. Lauwenmark's Artistic License 1.0: ??? DEFINITIONS - The work of art : A communal work which includes the initial artwork as well as all subsequent contributions (subsequent originals and copies). It is created at the initiative of the original artist who, by this license, defines the conditions according to which the contributions are made. - The original work of art : This is the artwork created by the initiator of the communal work, of which copies will be modified by whosoever wishes. - Subsequent works : These are the additions put forward by the artists who contribute to the formation of the work by taking advantage of the right to reproduction, distribution and modification that this license confers on them. - The Original (the work's source or resource) : A dated example of the work, of its definition, of its partition or of its program which the originator provides as the reference for all future updatings, interpretations, copies or reproductions. - Copy : Any reproduction of an original as defined by this license. - The author or the artist of the original work of art: This is the person who created the work which is at the heart of the ramifications of this modified work of art. By this license, the author determines the conditions under which these modifications are made. - Contributor: Any person who contributes to the creation of the work of art. He is the author or the artist of an original art object resulting from the modification of a copy of the initial artwork or the modification of a copy of a subsequent work of art. ??? 1. AIMS The aim of this license is to define the conditions according to which you can use this work freely. 2. EXTENT OF THE USAGE This work of art is subject to copyright, and the author, by this license, specifies the extent to which you can copy, distribute and modify it. 2.1 FREEDOM TO COPY (OR OF REPRODUCTION) You have the right to copy this work of art for your personal use, for your friends or for any other person, by employing whatever technique you choose. 2.2 FREEDOM TO DISTRIBUTE, TO INTERPRET (OR OF REPRESENTATION) You can freely distribute the copies of these works, modified or not, whatever their medium, wherever you wish, for a fee or for free, if you observe all the following conditions: - attach this license, in its entirety, to the copies or indicate precisely where the license can be found, - specify to the recipient the name of the author of the originals, - specify to the recipient where he will be able to access the originals (original and subsequent). The author of the original may, if he wishes, give you the right to broadcast/distribute the original under the same conditions as the copies. 2.3 FREEDOM TO MODIFY You have the right to modify the copies of the originals (original and subsequent), partially or otherwise, respecting the conditions set out in article 2.2 , in the event of distribution (or representation) of the modified copy. The author of the original may, if he wishes, give you the right to modify the original under the same conditions as the copies. 3. YOUR AUTHOR'S RIGHTS The object of this license is not to deny your author's rights on your contribution. By choosing to contribute to the evolution of this work of art, you only agree to give to others the same rights with regard to your contribution as those which were granted to you by this license. 4. DURATION OF THE LICENCE This license takes effect as of your acceptance of its provisions. The fact of copying, distributing, or of modifying the work constitutes a tacit agreement. This license will remain in force for as long as the copyright which is attached to the work of art. If you do not respect the terms of this license, you automatically lose the rights that it confers. If the legal status to which you are subject makes it impossible for you to respect the terms of this license, you may not make use of the rights which it confers. 5. VARIOUS VERSIONS OF THE LICENCE This license may undergo periodic modifications to incorporate improvements by its author (Y. Chachkoff) by way of new, numbered versions. You will have the choice of accepting the provisions contained in the version under which the copy was communicated to you, or alternatively, to use the provisions of one of the subsequent versions. 6. SUB-LICENSING Sub-licenses are not authorized by the present license. Any person who wishes to make use of the rights that it confers will be directly bound to the author of the original work. 7. THE LAW APPLICABLE TO THIS CONTRACT This license is subject to Belgian law. -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060122/801c88eb/attachment-0001.pgp From mikeeusaa at yahoo.com Sun Jan 22 17:12:02 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun Jan 22 20:29:33 2006 Subject: [crossfire] the marvels of miscommunication :) In-Reply-To: <200601220853.21534.yann.chachkoff@myrealbox.com> Message-ID: <20060122231202.63692.qmail@web32709.mail.mud.yahoo.com> I've heard people complaining about the GFDL, what is the controversy over it? --- Yann Chachkoff wrote: > Le Samedi 21 Janvier 2006 11:53, Miguel Ghobangieno > a ?crit : > > BSD or... the GPL. > > You don't need an artistic license. > > > Both BSD and GPL are based on the definition of > "source" and "binary" forms of > the product. Those definition are unsuitable for > work like visual art, > because defining what the "source" and the "binary" > forms of a picture are is > just about impossible and questionable. That's the > reason why the FSF > invented the GFDL for written documentation instead > of using the GPL, for > example: the application of the GPL to such works > was simply too difficult. > > Besides that, the BSD licence is not compatible with > the GPL and I don't agree > with its terms, so that would have been a no-no even > if it was applicable to > a picture. > > One may of course nit-pick about complex ways of > defining the "source" and the > "binaries" of a visual artwork - but relying on > obscure interpretations of a > license to protect your work is definitely a bad > strategy. > -- > Yann Chachkoff > ----------------------- > Garden Dwarf's Best Friend > ----------------------- > GPG Key : > http://keyserver.veridis.com:11371/export?id=9080288987474372064 > Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 > AAB9 844D 25E0 > > _______________________________________________ > 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 Mon Jan 23 00:18:33 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jan 23 00:20:33 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601191008.17065.delbd@oma.be> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <200601181942.51303.tchize@myrealbox.com> <43CF3565.709@sonic.net> <200601191008.17065.delbd@oma.be> Message-ID: <43D47539.5040406@sonic.net> David Delbecq wrote: >> This gets especially messy if say 10 object types are complex enough that > they >> really should be in their own module. So now you have those 10 separate > modules >> + common module for other 90 types. This then starts to get away from > making >> things easy to find (is it in the common module, or one of those other 10) >> > > Let's say i've got a problem with a buggy trap. This is how i see it: > 1) i do a 'dump' in dm mode to get info on buggy archetype. Server says me > type xyz (the trape type) and maybe also in the dump the is a list of plugins > linked to this object. > 2) i go in the code of this (or those) module and start trying to fix the > bug :) > > (please note, currently to fix an object, the procedure is something like dm > -> get type -> open define.h -> get the associated #TYPE for this type -> > issue a grep on this type to find where there is specific code.) Well, one could change that behavior without resulting to plugins - to give meaningful names to object types just requires an array that has the names. And for everyone out there currently using grep - download cscope and use that - it is a vastly superior solution (even going to plugins or whatever else, cscope is a very handy tool - just run 'cscope -R' in the top level directory. > > Also, having a simple document of which module does what would be > interresting. It's easy to manage (a module X -> description chapter and a > item type -> module chapter) But that sort of sidesteps the point, doesn't it? Isn't one of the issues right now that code is hard to find? If we have to document the new code, that doesn't seem to be going in the right direction - for that matter, a document could be written right now of 'these are steps to do to make a new object'. While current code isn't particularly well organized, at the same time, it is only in a few files, so it is not like you have to visit 30 files. > >> True. However, I'd think that to do this by true plugins, the >> objects/archetypes have to get updated, eg, hooks added for describe item, > apply >> item, etc. My poor mans version avoids that. > > Or we can have a plugin, in initialisation code do a 'plug those callbacks to > type x, thosr to type y, and those to skill z'. Ideally, in this idea, if you > omit the 'traps' plugin from server code, you can have a server which knows > nothing about traps :p (an we could imagine the traps module handling trap > objects and trap related skills :p). If you omit the all spells modules, you > could have a server in which casting spells is impossible (only bash and > crash) True, but that goes more back to my 'poor mans version' of plugins. At some level, I think a poor mans version with callback registration is actually more flexible. One could have a registration function like: set_type_callback(object_type, event_type, callback()) The advantage of registration of that form (instead of true event plugs in the object) is that adding new event type callbacks doesn't require any change to the objects. Another advantage is that registration above sort of provides a self documentation of what function is going to be used just in that callback function (and presumably, proper function naming, can be pretty clear where function is located, eg apply_.. would be in apply.c, describe_.. in describe.c, etc). Lastly, it could be very easy (even within the game) to disable certain plugins, eg, just a call like: set_type_callback(.., .., NULL) Where with true plugins, I don't think there would be any easy way, as you'd need to update all the objects with event_.. hooks (or keep a table someplace saying to ignore hooks, but that would seem to get pretty messy). > >> Another question is whether a plugin can call another plugin - that in > itself >> could perhaps limit the ability of some things to be in plugins. > > Very good point. > Plugins put aside for a few seconds, in modular project, there is usually a > notion of modules dependencies (module X depends on module Y and core, module > Y depends on core). I think we need to handle this dependencies system or we > lose a bit part of interest in modularization. Back to plugins, that means we > need plugin X to be able to do calls on plugin X. This shouldn't be difficult > to do. Simply a plugin would link a list of callback in initialization but > would also provide core a list of 'public callback' (that is a list a named > method). Core will the provide every plugin depending on X the possibility to > access them. That is one consideration. Another is whether the any of the plugin logic itself would prevent proper re-entry (eg, static values in wrapper functions, in case of python plugin, is there anything to prevent two python scripts from running properly at the same time, etc). Of course, ideally, in all cases, the answer should be no - if/when crossfire becomes multithreaded, those things would likely need to be fixed anyways. From mwedel at sonic.net Mon Jan 23 00:20:51 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jan 23 00:24:32 2006 Subject: [crossfire] Re: Polymorph etc In-Reply-To: <7903f03c0601190346i5c5d00b8y55030c87d4765003@mail.gmail.com> References: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> <43CC18D3.2090602@laposte.net> <200601171309.55949.tchize@myrealbox.com> <43CF36EF.2080905@sonic.net> <7903f03c0601190346i5c5d00b8y55030c87d4765003@mail.gmail.com> Message-ID: <43D475C3.8080705@sonic.net> Brendan Lally wrote: > On 1/19/06, Anton Oussik wrote: >> I did not necessarily mean more powerful spells. Some existing spells >> can get moved up the chain, and intermediate "interesting" spells can >> be added to fill the gaps, so a player always has a new spell "just >> within reach". Either that, or spell could be made to not get more >> powerful with level, and then players could learn more powerful >> versions of a spell they already know, which would exist every 5-10 >> levels. > > The problem with that is that skills already scale with level, > icestorm is one of the best cold spells at any level, because of how > well its damage and range scale, so unless you want to nerf the > scaling of all the low level spells, they are going to remain the best > option, especially if the base level of the supposedly 'better' spells > is increased, because then they will have fewer levels to scale over. Well, perhaps the scaling is too powerful then. I'd make the case that icestorm (a pretty low level spell) shouldn't be the best spell in the game. Other possiblity is to put caps on scaling, ala dungeons & dragons - ice storm goes up in damage until skill level 20 or something, and then stops, where as large ice storm scales up to level 50, etc. I really should do a dump so all this can be reasonably compared. From yann.chachkoff at myrealbox.com Mon Jan 23 01:34:29 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Mon Jan 23 01:36:32 2006 Subject: [crossfire] the marvels of miscommunication :) In-Reply-To: <20060122231202.63692.qmail@web32709.mail.mud.yahoo.com> References: <20060122231202.63692.qmail@web32709.mail.mud.yahoo.com> Message-ID: <200601230834.35033.yann.chachkoff@myrealbox.com> Le Lundi 23 Janvier 2006 00:12, Miguel Ghobangieno a ?crit : > I've heard people complaining about the GFDL, what is > the controversy over it? > If I am correct, there is a controversy about the GFDL in Debian: the GFDL seems to be considered "non-free" according to the Debian Social Contract, which would force Debian to put all the GFDL'd docs into its "non-free" repository. It seems that the Debian legal experts themselves are not sure if the GFDL conflicts with the DFSG or not. Given that Crossfire is not related in any way to Debian, the GFDL is not a problem that we'd need to worry about, though. -- Yann Chachkoff ----------------------- Garden Dwarf's Best Friend ----------------------- GPG Key : http://keyserver.veridis.com:11371/export?id=9080288987474372064 Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 AAB9 844D 25E0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20060123/024e8609/attachment.pgp From tchize at myrealbox.com Mon Jan 23 03:14:25 2006 From: tchize at myrealbox.com (tchize) Date: Mon Jan 23 03:16:34 2006 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43D47539.5040406@sonic.net> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <200601191008.17065.delbd@oma.be> <43D47539.5040406@sonic.net> Message-ID: <200601231014.26027.tchize@myrealbox.com> Le Lundi 23 Janvier 2006 07:18, Mark Wedel a ?crit : > > Well, one could change that behavior without resulting to plugins - to give > meaningful names to object types just requires an array that has the names. I was just showing with plugins it would be easier then currently. Of course there are plenty of other possiblitie to solve that particular problem of identifying code related to a type. But plugins provides also other advantages: - third party add-ons - easy deactivation of parts of code - ensure there are no modules boundaries crossing (go thru a single access point) - even if a non plug-in modularization is used, we would have to map it to a plugin system to be able to upgrade current existing plugins to it. > > And for everyone out there currently using grep - download cscope and use that > - it is a vastly superior solution (even going to plugins or whatever else, > cscope is a very handy tool - just run 'cscope -R' in the top level directory. Am not sure it's a good idea to have de developper dependency on cscope or grep. > > While current code isn't particularly well organized, at the same time, it is > only in a few files, so it is not like you have to visit 30 files. > It's a few file but it's spaghetti code! Not to mention the length of some files or even the length of some methods :) > True, but that goes more back to my 'poor mans version' of plugins. > > At some level, I think a poor mans version with callback registration is > actually more flexible. You'd have to issue a 'patch' if you want to add third party specific features (like a server having it's own crossfire -> html stats system). You'd have to 'patch' the code if you want to disable compilation of a problematic piece of code. > > One could have a registration function like: > > set_type_callback(object_type, event_type, callback()) > > The advantage of registration of that form (instead of true event plugs in the > object) is that adding new event type callbacks doesn't require any change to > the objects. What's the difference with set_type_callback(object_type, event_type, somePluginMethod()) ? the fact of adding plugin event to object instead of type, is just a generalization of what is currently done for existing script and is needed to keep backward compatibility (not to mention it also allow plugin to have some methods triggered only on demand). Moreover before thinking of the specific ways to modularize things, questions to be answered must be - Do we want a modularized system? - If yes, who would lead this process, how will he lead this, and who would team with him. > > Another advantage is that registration above sort of provides a self > documentation of what function is going to be used just in that callback > function (and presumably, proper function naming, can be pretty clear where > function is located, eg apply_.. would be in apply.c, describe_.. in describe.c, > etc). > I don't see how it documents itself. > Lastly, it could be very easy (even within the game) to disable certain > plugins, eg, just a call like: > > set_type_callback(.., .., NULL) > > Where with true plugins, I don't think there would be any easy way, as you'd > need to update all the objects with event_.. hooks (or keep a table someplace > saying to ignore hooks, but that would seem to get pretty messy). > See my previous comment. > > That is one consideration. Another is whether the any of the plugin logic > itself would prevent proper re-entry (eg, static values in wrapper functions, in > case of python plugin, is there anything to prevent two python scripts from > running properly at the same time, etc). That's tipically a problem associated with multithreading. I don't think it's a good idea to mix the ideas of multithreaded core and the ideas of modularized system. One big change at a time :) > > Of course, ideally, in all cases, the answer should be no - if/when crossfire > becomes multithreaded, those things would likely need to be fixed anyways. We are still far from multhreading. However, a modularized system would help a lot in future such changes. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From mwedel at sonic.net Tue Jan 24 00:38:43 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 23 Jan 2006 22:38:43 -0800 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601231014.26027.tchize@myrealbox.com> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <200601191008.17065.delbd@oma.be> <43D47539.5040406@sonic.net> <200601231014.26027.tchize@myrealbox.com> Message-ID: <43D5CB73.4080504@sonic.net> tchize wrote: >> And for everyone out there currently using grep - download cscope and use > that >> - it is a vastly superior solution (even going to plugins or whatever else, >> cscope is a very handy tool - just run 'cscope -R' in the top level > directory. > > Am not sure it's a good idea to have de developper dependency on cscope or > grep. But at some level, you will always have some dependencies on other tools - compiler, linker, editor, etc. I was mostly pointing out that if people are currently using grep, there are much better tools available. >> True, but that goes more back to my 'poor mans version' of plugins. >> >> At some level, I think a poor mans version with callback registration is >> actually more flexible. > > You'd have to issue a 'patch' if you want to add third party specific features > (like a server having it's own crossfire -> html stats system). You'd have to > 'patch' the code if you want to disable compilation of a problematic piece of > code. True, but a plugin for object actions would be a pretty critical piece of code - you just can't disable the players from applying all items (or not compile that bit) and have a working system. Now the counter is that you'd just disable it for the specific bad object type, but then, if one plugin is covering 30 object types, that still isn't much an option. IMO, compiling/not compiling something isn't an issue - if something is so broken that it doesn't even compile, it should be fixed ASAP or be removed. the issue would more likely be disabling them once problems start, which would be same regardless of method used, but registered callbacks are probably easier. > >> One could have a registration function like: >> >> set_type_callback(object_type, event_type, callback()) >> >> The advantage of registration of that form (instead of true event plugs in > the >> object) is that adding new event type callbacks doesn't require any change > to >> the objects. > > What's the difference with > > set_type_callback(object_type, event_type, somePluginMethod()) ? > > the fact of adding plugin event to object instead of type, is just a > generalization of what is currently done for existing script and is needed to > keep backward compatibility (not to mention it also allow plugin to have some > methods triggered only on demand). Well, you can't have a single list of all the set_type_callbacks() unless all the functions are in the same module. For example, you can't have any such callbacks in the server code if they reference functions in plugins that are called later. Likewise, for the plugin itself, it will only know about the functions in the plugin itself. This isn't directly a problem except that these callbacks would be spread across several plugins, which makes finding the actual details more difficult (have to do a grep to see which file is registering that callback). For most plugins, that probably isn't a problem - if one were to think of the random map code, it really only needs to register one callback, so big deal. OTOH, the random map code is already pretty well modularized, so I don't see much point to convert that to plugin logic. > > Moreover before thinking of the specific ways to modularize things, questions > to be answered must be > - Do we want a modularized system? > - If yes, who would lead this process, how will he lead this, and who would > team with him. I think the term plugin vs module probably needs to be clarified, as well as clarification what approach we are really taking. To me, module is like the .a files currently used (random maps, socket, etc) - code is logically grouped in one place, but linked in at compile time. plugin is code that isn't loaded until run time by explicit calls to load shared libraries. In this case, the server (or other code) doesn't know about anything in the plugin until the plugin is loaded. Now a separate question may be which method should be used - modules are certainly simpler to do, but harder to control usage of that code. I guess for the object code handling, I'm more inclined to do a module type approach - that code is already compiled in, and I don't see much in the way of compelling advantage to making it an actual plugin - the code can be made a lot easier to maintain and find stuff without making it an actual plugin. That said, I can certainly see the need for plugins. It just becomes harder to figure out what approach works best for what. >> That is one consideration. Another is whether the any of the plugin logic >> itself would prevent proper re-entry (eg, static values in wrapper > functions, in >> case of python plugin, is there anything to prevent two python scripts from >> running properly at the same time, etc). > > That's tipically a problem associated with multithreading. I don't think it's > a good idea to mix the ideas of multithreaded core and the ideas of > modularized system. One big change at a time :) But it can be relevant. Imagine a case where object A is applied. plugin for A is called. As part of what A does, it applies object B. So plugin for B needs to be called. A real world case right now is things like altars that push buttons that perhaps activate something else. If the plugin code is not properly re-entrant, this fails. Right now, with the limited use of plugins, this isn't much a problem. But if a lot more stuff moves to plugins, we may run into that issue sooner and not later. The current code can of course have the same problems. query_name() has a pretty horrible hack. multithreading certainly is a different issue, but I think relative to current code, the current hacks are well known and in place to make things work. I don't really know if the plugin code will have any of the problems I mention. It it just something that should be investigated/programmed correctly so it isn't a problem. From tchize at myrealbox.com Tue Jan 24 04:28:34 2006 From: tchize at myrealbox.com (tchize) Date: Tue, 24 Jan 2006 11:28:34 +0100 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43D5CB73.4080504@sonic.net> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <200601231014.26027.tchize@myrealbox.com> <43D5CB73.4080504@sonic.net> Message-ID: <200601241128.35938.tchize@myrealbox.com> Le Mardi 24 Janvier 2006 07:38, Mark Wedel a ?crit : > > True, but a plugin for object actions would be a pretty critical piece of code > - you just can't disable the players from applying all items (or not compile > that bit) and have a working system. > 'Using object' is a core feature imho, while the behaviour of a specific object or object type when applied should be left to appropriate plugin I agree but with following reserve: - you are assuming 1 module is managing the apply while it would probably be 1 module is managing a defined range of object type (eg: applying handles, applying readables, applying wearables) and it could be interresting at some point to remove module for a specific category of items, like removing magic items management (applying , recharge, other stuffs) if you dedice you don't want spells in your server. - A developper could be interrested in removing parts of the server for testing purpose. If i have a specific problem loading a given map and i don't know if it's because of objects inside map, or because of map loading code, I could easily disable lots of plugins to get only core + maploading code + protocol and check if the problem is still there. Sure you couldn't do much ingame, but it is interresting for developping purpose. This also help you isolate your code. If core+your module+maybe a tester module (which could, for example, fake a user connection and load a test map) isn't enough to have your module working in test environment, then you might need to consider your module has other dependencies. > Now the counter is that you'd just disable it for the specific bad object > type, but then, if one plugin is covering 30 object types, that still isn't much > an option. Additional reason not to group together spells, monsters, alchemy and random map! > > IMO, compiling/not compiling something isn't an issue - if something is so > broken that it doesn't even compile, it should be fixed ASAP or be removed. Yes, assuming it's easily fixable (does not take 3 days of work). > > the issue would more likely be disabling them once problems start, which would > be same regardless of method used, but registered callbacks are probably easier. > Well removing a .so or .dll from a dir is also easy. > > Well, you can't have a single list of all the set_type_callbacks() unless all > the functions are in the same module. > > For most plugins, that probably isn't a problem - if one were to think of the > random map code, it really only needs to register one callback, so big deal. > OTOH, the random map code is already pretty well modularized, so I don't see > much point to convert that to plugin logic. I suppose you are refering to the problem of storing callback informations in mapfile (because at runtime a pointer is just a pointer, you would just need to update it if module is reloaded, already the case in current plugin code). That could be done using pluginname+declared plugin callback name. It's implementation details. For item type it's even easier as it's not stored in file. It's the plugin which declares at load time it want to have given listeners on given types. > > I think the term plugin vs module probably needs to be clarified, as well as > clarification what approach we are really taking. If you don't put the modules in plugins (at least what we could modularize from current server code) you would have two things - 1) code to manage hard linked modules (eg arrays of module callbacks to explores and so on) - 2) code to manage additionnal behaviour which could be requested by plugins (be it python, animator or another one) That mean during modularization process, at each place we consider splitting appart code in modules we have to handle separetly - main server module - plugin managment code This is twice the effort during the modularization process. > > To me, module is like the .a files currently used (random maps, socket, etc) - > code is logically grouped in one place, but linked in at compile time. This isn't enough for modules. Of course modules can be gathered .a and gathered a link time. But you also need to clearly separate them. Currently it has nothing of modularized. A piece of code in random map can call functions present in the socket, a piece of code in weather can call functions in maploader. Same for piece of code in protocol which makes call to maploader.c You could do modules in .a (and even suggest current plugins be converted to .a and gathered at link time, you would only lose the runtime reloading facilities). But you must ensure each module has it's separate .h files. Also, you must ensure you don't have cyclic modules dependencies and ensure you use only modules you depend on (that is only include .h of modules you depend on) To me, be it link time modules (.a) or runtime modules (.so), the work to do is the same, except this - plugin will need a bit of 'load library code' mainly already present in code - in .a it will be difficult to enforce strict separation in the future. > I guess for the object code handling, I'm more inclined to do a module type > approach - that code is already compiled in, and I don't see much in the way of > compelling advantage to making it an actual plugin - the code can be made a lot > easier to maintain and find stuff without making it an actual plugin. Plugin is a way of modularization like another. To me it is the less cumbersome. > > That said, I can certainly see the need for plugins. It just becomes harder > to figure out what approach works best for what. > If you have modularization in form 'plugin +sth else' you have to do twice the job as plugin will mainly need to plug at same places the modules will need to interact. > > Imagine a case where object A is applied. plugin for A is called. > > As part of what A does, it applies object B. So plugin for B needs to be > called. A real world case right now is things like altars that push buttons > that perhaps activate something else. > > If the plugin code is not properly re-entrant, this fails.. If current server code is not reentrant, at most places, it fails also, even in non multithreaded environments :) But it can be stated in plugin specification that each callback is presumed to be reentrant safe. > > Right now, with the limited use of plugins, this isn't much a problem. But if > a lot more stuff moves to plugins, we may run into that issue sooner and not later. If a plugin is forced to be 'thead safe' this mean each manipulation of plugin global data must be surrounded by mutex. This mean even if server is not yet multithreaded, we would have the plugins (or .a modules) have dependecies on threading libraries :) > > The current code can of course have the same problems. query_name() has a > pretty horrible hack. > Yes! > multithreading certainly is a different issue, but I think relative to current > code, the current hacks are well known and in place to make things work. They are 'known to work' but certainly not safe! > > I don't really know if the plugin code will have any of the problems I > mention. It it just something that should be investigated/programmed correctly > so it isn't a problem. > Damn i should read mail 'til the end before defending my position. Consider answer as hypothetical solutions to hypothetical problems then :p -- Tchize From mikeeusaa at yahoo.com Mon Jan 23 10:20:31 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon, 23 Jan 2006 08:20:31 -0800 (PST) Subject: [crossfire] the marvels of miscommunication :) In-Reply-To: <200601230834.35033.yann.chachkoff@myrealbox.com> Message-ID: <20060123162031.29983.qmail@web32710.mail.mud.yahoo.com> You shouldn't GFDL it if deb considers it non free. Stick with the GPL that crossfire uses. I make alot of art for crossfire and I don't insist on a new license... you can do the same. Otherwise... why do we need a new welcome screen? --- Yann Chachkoff wrote: > Le Lundi 23 Janvier 2006 00:12, Miguel Ghobangieno a > ?crit : > > I've heard people complaining about the GFDL, what > is > > the controversy over it? > > > > If I am correct, there is a controversy about the > GFDL in Debian: the GFDL > seems to be considered "non-free" according to the > Debian Social Contract, > which would force Debian to put all the GFDL'd docs > into its "non-free" > repository. It seems that the Debian legal experts > themselves are not sure if > the GFDL conflicts with the DFSG or not. > > Given that Crossfire is not related in any way to > Debian, the GFDL is not a > problem that we'd need to worry about, though. > > -- > Yann Chachkoff > ----------------------- > Garden Dwarf's Best Friend > ----------------------- > GPG Key : > http://keyserver.veridis.com:11371/export?id=9080288987474372064 > Fingerprint: 6616 2E02 BAD2 4AEF C90A F1EB 7E03 > AAB9 844D 25E0 > > _______________________________________________ > crossfire mailing list > crossfire at 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 alex_sch at telus.net Tue Jan 24 11:47:45 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 24 Jan 2006 10:47:45 -0700 Subject: [crossfire] Polymorph etc In-Reply-To: <43D475C3.8080705@sonic.net> References: <20060116202014.83658.qmail@web32713.mail.mud.yahoo.com> <43CC18D3.2090602@laposte.net> <200601171309.55949.tchize@myrealbox.com> <43CF36EF.2080905@sonic.net> <7903f03c0601190346i5c5d00b8y55030c87d4765003@mail.gmail.com> <43D475C3.8080705@sonic.net> Message-ID: <43D66841.4090404@telus.net> Mark Wedel wrote: > Brendan Lally wrote: > >> On 1/19/06, Anton Oussik wrote: >> >>> I did not necessarily mean more powerful spells. Some existing spells >>> can get moved up the chain, and intermediate "interesting" spells can >>> be added to fill the gaps, so a player always has a new spell "just >>> within reach". Either that, or spell could be made to not get more >>> powerful with level, and then players could learn more powerful >>> versions of a spell they already know, which would exist every 5-10 >>> levels. >> >> >> The problem with that is that skills already scale with level, >> icestorm is one of the best cold spells at any level, because of how >> well its damage and range scale, so unless you want to nerf the >> scaling of all the low level spells, they are going to remain the best >> option, especially if the base level of the supposedly 'better' spells >> is increased, because then they will have fewer levels to scale over. > > > Well, perhaps the scaling is too powerful then. I'd make the case > that icestorm (a pretty low level spell) shouldn't be the best spell > in the game. > > Other possiblity is to put caps on scaling, ala dungeons & dragons - > ice storm goes up in damage until skill level 20 or something, and > then stops, where as large ice storm scales up to level 50, etc. > > I really should do a dump so all this can be reasonably compared. Hmm... I'm not sure icestorm is so powerful. In my experience, it is virtually useless against monsters (can barely be used to kill a red dragon), but is very very effective against players. Also, when was the last time that burning hands was useful at high levels? And such things. Personally, I find that at the high levels, magic is increasingly useless if you are fighting monsters similar to your level (for this, I think the fact that magic doesn't get Wc bonuses for levels is at fault) Alex Schultz From yann.chachkoff at myrealbox.com Tue Jan 24 13:55:43 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Tue, 24 Jan 2006 20:55:43 +0100 Subject: [crossfire] the marvels of miscommunication :) Message-ID: <1138132543.c7d9c69cyann.chachkoff@myrealbox.com> > You shouldn't GFDL it if deb considers it non free. > I never considered using the GFDL, since it was meant to be used for text or documentation material, not artistic pictures. The "Debian sees it as non-free" point was never considered, since the GFDL obviously didn't fit well artwork. > Stick with the GPL that crossfire uses. > At the risk of sounding repetitive, the GPL is *not* suited for "artistic" pictures ! It uses definitions that *cannot* be applied in a clear, unambiguous way to that kind of work. So no, I'll *never* use it for anything else than code (and other similar works). Note that it doesn't mean that I want to create a special case that would make the picture not compatible with the GPL - quite the contrary, I think my proposal protects correctly the work done, while allowing free redistribution and compatibility with GPL-based softwares. > I make alot of art for crossfire and I don't insist > on a new license... you can do the same. > No. The GPL wouldn't correctly protect that work in most countries. Simply because you accepted such a situation doesn't make a clunky solution more efficient or appliable. > Otherwise... why do we need a new welcome screen? > Because the current one is not very nice ? Because it depicts monsters whose design completely changed ? Because a change or two is often refreshing ? Besides that, I posted the license proposal so that if a GPL-incompatibility had slipped in, others may spot it, allowing to solve the issue. The decision of not using the GNU-GPLv2 or the GFDL has already been taken, and there is no point of reopening that debate, especially when nothing but sentimental feelings can justify the rediscussion. From mwedel at sonic.net Wed Jan 25 02:50:38 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 25 Jan 2006 00:50:38 -0800 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601241128.35938.tchize@myrealbox.com> References: <20060116172930.14539.qmail@web32713.mail.mud.yahoo.com> <200601231014.26027.tchize@myrealbox.com> <43D5CB73.4080504@sonic.net> <200601241128.35938.tchize@myrealbox.com> Message-ID: <43D73BDE.9090104@sonic.net> tchize wrote: I agree that removing/disabling code is a valuable feature. I'm just not sure that any of the methods either of us have talked about is really a good method. From my point of view, making it really easy/convenient for developers to disable code is less important than a method where it can be done on the server. And when I say 'on the server', I mean literally through a running crossfire server, and not by shell login. I'd see the most likely scenariou that a DM on a server that does not have shell access seeing that applying an item (or some other action) is causing the server to crash, and thus wants to disable that. IMO, having the server unlink .so files probably isn't a great solution (and in fact, may not always work, as the .so files may be installed with a uid different than what the server runs under). Also, disabling at an entire module level may not be desirable. In my example above, you may want to disable the applying of items, but still want ot be able to get descriptions of items, identify them, etc. Likewise, any disabling of functions should be persistent accross runs until re-enable. Disabling that apply function doesn't do much good if something else crashes the server and it is enable again. So what I started thinking was you could have a module control, with things like: , eg: function scroll:apply disable (operation name would be module:function name, with potential wildcards, so you could do something like) function scroll: disable to disable all scroll code. This then allows other things like: variable scroll:max_level 25 To set module values to various things. this requires support of the module initialization code (checking to see if it shouldn't set the callback, change global variable, etc). If callbacks aren't used, the first line of various functions could be things like: if (!module.apply) return; That is marginally more complex than other methods we have talked about, but probably more flexible (I do especially like the clearer documentation of setting variables and how they effect things). I'd also think that once this glue code was written for one module, it could pretty easily be re-used for everything else. >> IMO, compiling/not compiling something isn't an issue - if something is so >> broken that it doesn't even compile, it should be fixed ASAP or be >> removed. > > Yes, assuming it's easily fixable (does not take 3 days of work). Well, if it takes 3 days of work to fix, then perhaps it should be removed, or disabled from the make system. After all, right now at least, the current built environment isn't especially graceful about continuing when it fails to compile a file (you can always do make -k) And I'd personally be concerned anytime I see something failing to compile. But as modules, it should at least be able to disable compilation of that one problematic file without affecting anything else. > > If you don't put the modules in plugins (at least what we could modularize > from current server code) you would have two things - 1) code to manage hard > linked modules (eg arrays of module callbacks to explores and so on) - 2) > code to manage additionnal behaviour which could be requested by plugins (be > it python, animator or another one) > > That mean during modularization process, at each place we consider splitting > appart code in modules we have to handle separetly - main server module - > plugin managment code > > This is twice the effort during the modularization process. I disagree it would be twice the effort. It _may_ be more work - it certainly wouldn't be quite as consistent. But if you pluginize a lot of code, I'd say there is more code that would need to be rewitten/changed than if it was modularized. > This isn't enough for modules. Of course modules can be gathered .a and > gathered a link time. But you also need to clearly separate them. Currently > it has nothing of modularized. A piece of code in random map can call > functions present in the socket, a piece of code in weather can call > functions in maploader. Same for piece of code in protocol which makes call > to maploader.c I don't see how you can avoid that. At the most basic level, almost any module of code is going need to talk to the socket (draw_info commands at most basic, but I can also see need for lots of update object commands). Now you can perhaps wrap some of those functions or use callbacks, but that really isn't changing anything. If we are talking about apply code again, the module will need to know about the NDI_ values as well as perhaps the UPD_ values. Now the plugin could have its own private file, but then somewhere in that plugin logic, it has to convert those values (PG_BLUE to NDI_BLUE or whatever). And unfortunately, I'm not really sure how many of the current top level include files have dependencies removed. Certainly, some clean up and seperation could be done (files like includes.h, define.h are pretty meaningless names). But there is the mess that maps need to know about objects, objects need to know about maps, player need to know about objects and vice versa. > > To me, be it link time modules (.a) or runtime modules (.so), the work to do > is the same, except this - plugin will need a bit of 'load library code' > mainly already present in code - in .a it will be difficult to enforce strict > separation in the future. One question I don't know the answer to is duplicate symbol names. For example, I write a module and have a function called apply(). There is another module that also has a function called apply(). I know in linking at compile time will catch this - I'm not sure what will happen with dlopen. > If you have modularization in form 'plugin +sth else' you have to do twice > the job as plugin will mainly need to plug at same places the modules will > need to interact. Maybe. But there are lots of places right now where there is no plugin glue for various actions. So in that case, you have to add the event plugin glue, convert the existing code to be 'plugin compliant', which may or may not be a big deal depending on what that means. In comparison, converting to a module may just be a simple test/make callback type of thing But this is more a case by case issue - depends on the operation in question. All that said, I think we can discuss this a long time, but that isn't helping any of this get done. What I'd personally suggest: 1) Make a list, in priority order, what we are trying to accomplish. Is it making the code easier to deal with? How important is being able to disable portions of the code? I'd think that a solution that can be done in small steps is better than one that requires a single major rewirte. Estimate the time to do this. A perfect solution that will take years to complete isn't very useful. A solution that covers 80% (or top 3 points/whatever) that can be done in 3 months becomes more appealing. 2) From your discussion in this, does that mean you're willing to lead/take on this project? Is there someone else? All this discussion is basically meaningless unless someone is out there that is going to do the work. 3) When person from point #2 is identified, I'd say they should do the following: A) Roll all this up and make a proposal of what they plan to do (or at least do first). This should include some fairly detailed description - saying something like 'I'm going to pluginize objects' is pretty meaningless. B) Part of A, provide an example of the code to be used, if reasonable. For example, if redoing the object code, provide code of redoing one object type (it could even be a fairly trivial object), just so everyone can see what the final form is really going to look like. C) Presuming good agreement on point B, go ahead and start working on this on a more major fashion. This may be a bit cumbersome, but if we're going to do this, I think it is really important it be done in a way that is going to be clearly better an easier to use. While the current code isn't all that good, at least I, and probably the other old hand developers, do know where things are. It'd be stupid to rearrange the code so that virtually no one knows where anything is anymore, and it not really being any easier to find stuff under the new code. From mikeeusaa at yahoo.com Wed Jan 25 06:16:14 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Wed, 25 Jan 2006 04:16:14 -0800 (PST) Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43D73BDE.9090104@sonic.net> Message-ID: <20060125121614.48573.qmail@web32706.mail.mud.yahoo.com> We want to cross module boundries and there is no reason for us to want 3rd party "module" additions (unless one is pro-proprietary). Modules would do 2 things: disallow use of code across module boundries (as they aren't loaded yet), let proproprietary addons be created and work over more then 1 release cycle. Both are bad. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tchize at myrealbox.com Wed Jan 25 09:51:28 2006 From: tchize at myrealbox.com (tchize) Date: Wed, 25 Jan 2006 16:51:28 +0100 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <20060125121614.48573.qmail@web32706.mail.mud.yahoo.com> References: <20060125121614.48573.qmail@web32706.mail.mud.yahoo.com> Message-ID: <200601251651.29095.tchize@myrealbox.com> Le Mercredi 25 Janvier 2006 13:16, Miguel Ghobangieno a ?crit : > We want to cross module boundries and there is no aka spaghetti code > reason for us to > want 3rd party "module" additions (unless one is > pro-proprietary). > no comment. From mikeeusaa at yahoo.com Wed Jan 25 17:17:39 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Wed, 25 Jan 2006 15:17:39 -0800 (PST) Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <200601251651.29095.tchize@myrealbox.com> Message-ID: <20060125231739.69654.qmail@web32709.mail.mud.yahoo.com> Yes, "spagetti code", if that's what you wish to call it. Some CF programmers, such as Cave, would like to beable to reuse their code without having to recopy and paste what they have allready done (which would create bloated code if it was required). Modules would disallow this (bad) as they are not loaded untill they are called. Call it what you will but this is why subroutienes were invented (subroutines, in assembly, are basically gotos... :) ) so you didn't have to paste the same code everywhere. Oh and I just got a yamaha midi guitar (EZ-AG) :) (I now have a midi keyboard and a midi guitar :D, the keyboard is recognised by linux through USB and rosebud4, I still have yet to get a midi-cable-usb adapter which the geeetar needs). __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From antonoussik at gmail.com Wed Jan 25 18:03:42 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Thu, 26 Jan 2006 00:03:42 +0000 Subject: [crossfire] Lag Message-ID: When a player moves, there is currently a delay of one round trip until anything starts happening. Whilst for most modern Internet connections this does not pose a significant problem, when interacting with other players the lag seems to accumulate. They have 900ms lag, I have 1200ms lag, now between us we suddenly have 2100ms lag. Since a player can cover many tiles in 2100ms, it becomes very difficult to keep track of any other player when travelling, and in general to coordiante with others successfuly. This limits the useful multiplayernes of crossfire. Parties 5-6 players in size start to fall apart as players can not keep track of each other. Similar problems exist for persise stopping of movement. Laggy connections tend to make you overrun your destination. For example if I am running, and want to stop, it will take another 3-4 screens (at 20x20 tiles) before I come to a halt. Is there anything that can be done to improve movement on laggy connections? Could the server send the client a matrix of what tiles on the map can be moved to, and send updates of that as they change for example? Any better ideas? From brenlally at gmail.com Wed Jan 25 18:57:02 2006 From: brenlally at gmail.com (Brendan Lally) Date: Thu, 26 Jan 2006 00:57:02 +0000 Subject: [crossfire] Lag In-Reply-To: References: Message-ID: <7903f03c0601251657v5d2d8d44q42c39b0b7d07b7a8@mail.gmail.com> On 1/26/06, Anton Oussik wrote: > Is there anything that can be done to improve movement on laggy > connections? Could the server send the client a matrix of what tiles > on the map can be moved to, and send updates of that as they change > for example? Any better ideas? One thing that might work for this, is something I have been idling toying with concerning movement. I was looking a few weeks ago at adding a 'goto' command so that the player could send a command goto (relative to the player) and then, as long as they had no further commands sent, they would go towards that point. (in terms of controls, this would map to clicking on the map view somewhere). - the stupid implementation of this is quite straightforward, getting the routing to work properly is harder. In any case if that became the defacto standard way of moving (as it is in most graphical RPGs), then it would be possible to figure out what route the player would take, and send the moves they would make to the other players in the room early. - this would still lead to the ocassional de-sync issue (when they change direction, or something moves in the way) but it would be a noticable improvement over what is currently there. (the extension to that would be to have an attackto command (or a flag to goto) so that monsters could be targeted to get the player to follow them and attack when they are in range. - probably such advance telling of commands should only occur if the ping time is bigger than the tick time though. In general though, if your ping time is over a second, you need a better internet connection, most games are difficult to play when you are that laggy. From mwedel at sonic.net Thu Jan 26 00:46:38 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 25 Jan 2006 22:46:38 -0800 Subject: [crossfire] Lag In-Reply-To: <7903f03c0601251657v5d2d8d44q42c39b0b7d07b7a8@mail.gmail.com> References: <7903f03c0601251657v5d2d8d44q42c39b0b7d07b7a8@mail.gmail.com> Message-ID: <43D8704E.7050308@sonic.net> Brendan Lally wrote: > On 1/26/06, Anton Oussik wrote: >> Is there anything that can be done to improve movement on laggy >> connections? Could the server send the client a matrix of what tiles >> on the map can be moved to, and send updates of that as they change >> for example? Any better ideas? I'm not sure that helps out. What it gains is that the client can 'move' the player to the space they are attempting to go to so that client is slightly more up to date. However, you will get syncrhonization issues - if your lag is 500 ms, any update on that array of spaces is still 4 ticks out of date. So you can certainly get the case where the client thinks it can move to some space, but someone else has already moved there, and thus what the client displays is not just out of date, but erroneous. > > One thing that might work for this, is something I have been idling > toying with concerning movement. > > I was looking a few weeks ago at adding a 'goto' command so that the > player could send a command goto (relative to the player) and > then, as long as they had no further commands sent, they would go > towards that point. (in terms of controls, this would map to clicking > on the map view somewhere). - the stupid implementation of this is > quite straightforward, getting the routing to work properly is harder. I'd think the straightforward approach would be a good first step. Routing is more difficult, but there is already code that monsters use for this type of thing. IF anything, using that same code for players would just be a good thing - it would probably mean that code would become better as players would see actual bad routing issues. The slightly more complicated part is that ideally, you'd want the server to send the client the proposed route (so the client could display it in some format, so if it is completely bogus, the player can interrupt it and re-route manually. One consideration is the case of alternate routes. One tricky part also, relative to players using that code, is you don't want the player to cheat too much. IF the player is in a maze, they shouldn't be able to click some spaces away and the server now routes them there even though as a player they had no clue. > > In any case if that became the defacto standard way of moving (as it > is in most graphical RPGs), then it would be possible to figure out > what route the player would take, and send the moves they would make > to the other players in the room early. - this would still lead to the > ocassional de-sync issue (when they change direction, or something > moves in the way) but it would be a noticable improvement over what is > currently there. (the extension to that would be to have an attackto > command (or a flag to goto) so that monsters could be targeted to get > the player to follow them and attack when they are in range. - > probably such advance telling of commands should only occur if the > ping time is bigger than the tick time though. I think goto would be very good - simply if when loaded down and heading to a shop that is going to take moment, being able to click it and have your character end up there is certainly more convenient than having to hit the run in that direction. > > In general though, if your ping time is over a second, you need a > better internet connection, most games are difficult to play when you > are that laggy. Yes, but here are some other random thoughts: 1) Player movement is perhaps to fast - with most all players moving about 1 space/tick, this obviously results in keeping in sync harder. 2) A 'follow ' command could be added such that you follow player . Maybe just allow it in parties, with commands like 'lead party' and 'follow party'. Everyone who did 'follow' follows the 'lead'er. The leader would automatically slow down as needed so as not to get too far ahead. 3) Currently, the server processes all the objects/players, sleeps for 120 ms, then does that again. Lag could be reduced by some amount (average 60 ms) if we process data from players immediately when it arrives. However, this only helps out in cases where the player is idle (basically has an action to use). If you're running, it won't make a difference - in that case, the code will look for commands from the socket before it has the players character do anything, so there is the entire 120ms for that to arrive. > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From antonoussik at gmail.com Thu Jan 26 02:07:54 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Thu, 26 Jan 2006 08:07:54 +0000 Subject: [crossfire] Lag In-Reply-To: <43D8704E.7050308@sonic.net> References: <7903f03c0601251657v5d2d8d44q42c39b0b7d07b7a8@mail.gmail.com> <43D8704E.7050308@sonic.net> Message-ID: On 26/01/06, Mark Wedel wrote: > Brendan Lally wrote: > > On 1/26/06, Anton Oussik wrote: > >> Is there anything that can be done to improve movement on laggy > >> connections? Could the server send the client a matrix of what tiles > >> on the map can be moved to, and send updates of that as they change > >> for example? Any better ideas? > > I'm not sure that helps out. What it gains is that the client can 'move' the > player to the space they are attempting to go to so that client is slightly more > up to date. However, you will get syncrhonization issues - if your lag is 500 > ms, any update on that array of spaces is still 4 ticks out of date. So you can > certainly get the case where the client thinks it can move to some space, but > someone else has already moved there, and thus what the client displays is not > just out of date, but erroneous. Yes, I too see that flaw. However most other online RPGs deal with that issue in a similar way to this, using server updates as the reference, and it seems to work for them. > > > > One thing that might work for this, is something I have been idling > > toying with concerning movement. > > > > I was looking a few weeks ago at adding a 'goto' command so that the > > player could send a command goto (relative to the player) and > > then, as long as they had no further commands sent, they would go > > towards that point. I like that idea. > The slightly more complicated part is that ideally, you'd want the server to > send the client the proposed route (so the client could display it in some > format, so if it is completely bogus, the player can interrupt it and re-route > manually. Is there really much point in this? Clicking anywhere you can see should (travelling in more-less straight line) get you there in about a second, which is not enough time to cancel a route. > One consideration is the case of alternate routes. One tricky part also, > relative to players using that code, is you don't want the player to cheat too > much. IF the player is in a maze, they shouldn't be able to click some spaces > away and the server now routes them there even though as a player they had no clue. Maybe limit the length of route to 20 or 30 tiles? > > In any case if that became the defacto standard way of moving (as it > > is in most graphical RPGs), then it would be possible to figure out > > what route the player would take, and send the moves they would make > > to the other players in the room early. - this would still lead to the > > ocassional de-sync issue (when they change direction, or something > > moves in the way) but it would be a noticable improvement over what is > > currently there. (the extension to that would be to have an attackto > > command (or a flag to goto) so that monsters could be targeted to get > > the player to follow them and attack when they are in range. - > > probably such advance telling of commands should only occur if the > > ping time is bigger than the tick time though. Sounds like a good idea, but complicated. > > In general though, if your ping time is over a second, you need a > > better internet connection, most games are difficult to play when you > > are that laggy. Runescape and AO work wel over my connection... > Yes, but here are some other random thoughts: > 1) Player movement is perhaps to fast - with most all players moving about 1 > space/tick, this obviously results in keeping in sync harder. Slowing down players is a bad idea. Slower movement gives the impression of lag, as players see no notification that their character intends to move for a while. This is to do with the fact that movements in cf are quantum, and therefore there is no smooth transition when moving from tile to tile. Maybe one solution to that would be to make all tiles one pixel, and all objects into multi-tile things? Then speed up all movement speeds 30-fold or so, and maybe one day you end up with something with nice smooth movement, and appearance of no lag. > 2) A 'follow ' command could be added such that you follow player . Maybe > just allow it in parties, with commands like 'lead party' and 'follow party'. > Everyone who did 'follow' follows the 'lead'er. The leader would automatically > slow down as needed so as not to get too far ahead. I'm sure pet code could be used for that... > 3) Currently, the server processes all the objects/players, sleeps for 120 ms, > then does that again. > > Lag could be reduced by some amount (average 60 ms) if we process data from > players immediately when it arrives. This sounds like a great idea for reducing lag in low latency conditions, making cf pretty much real-time for the user. I think all the people playing on private servers will want this implemented. Now if everyone could get a low latency connection... How about distributing the server? This is at the moment not viable to implement, but maybe some time in the future, could a number of servers in geographically distant points act as one super-server, and allow clients to join to any of them, and be part of the same world? They would only need to send updates from time to timeand only when several players (on different servers) are on the same map. Then they would need to solve issues like what random items resolve to, and what a state of a particular object is. Random map synchronisation would also be an issue. From brenlally at gmail.com Thu Jan 26 06:39:49 2006 From: brenlally at gmail.com (Brendan Lally) Date: Thu, 26 Jan 2006 12:39:49 +0000 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <20060125231739.69654.qmail@web32709.mail.mud.yahoo.com> References: <200601251651.29095.tchize@myrealbox.com> <20060125231739.69654.qmail@web32709.mail.mud.yahoo.com> Message-ID: <7903f03c0601260439ha1dff42yd7bb774cb4b00ad8@mail.gmail.com> On 1/25/06, Miguel Ghobangieno wrote: > Some CF programmers, such as Cave, would like to > beable to reuse their code without having to recopy > and paste what they have allready done (which would > create bloated code if it was required). The idea of separating the code into fairly well defined areas is something I would support wholeheartedly, I don't think the current tangle of functions is a desirable thing and would much rather some functions were rearranged between files, to better reflect what they do. In this I do not disagree with Tchize and Gros, however I am still unconvinced by the case for a complex API to enforce such separation, a well constructed layout of functions within files, created according to how they are called in various places, would, I feel, help almost as much without adding yet another thing to support that will quickly become outdated. > Modules would > disallow this (bad) as they are not loaded untill they > are called. In an organisational change that would achieve the same effect, these same functions would be marked static anyway, so this is a non-point. From tchize at myrealbox.com Thu Jan 26 09:02:56 2006 From: tchize at myrealbox.com (tchize) Date: Thu, 26 Jan 2006 16:02:56 +0100 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <20060125231739.69654.qmail@web32709.mail.mud.yahoo.com> References: <20060125231739.69654.qmail@web32709.mail.mud.yahoo.com> Message-ID: <200601261602.57001.tchize@myrealbox.com> Le Jeudi 26 Janvier 2006 00:17, Miguel Ghobangieno a ?crit : > Yes, "spagetti code", if that's what you wish to call > it. Some CF programmers, such as Cave, would like to > beable to reuse their code without having to recopy > and paste what they have allready done (which would > create bloated code if it was required). Modules would > disallow this (bad) as they are not loaded untill they > are called. Call it what you will but this is why > subroutienes were invented (subroutines, in assembly, > are basically gotos... :) ) so you didn't have to > paste the same code everywhere. That goes in modules dependencies, helper methods gets on a common root. Spaghetti code happens when this occurs without limits (eg a method in loader call a method in socket which itself calls a methods in player which itself calls back the socket!) Code reuse happens in modularized code too! From yann.chachkoff at myrealbox.com Thu Jan 26 16:28:31 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Thu, 26 Jan 2006 23:28:31 +0100 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1138314511.c7fc799cyann.chachkoff@myrealbox.com> > In this I do not disagree with Tchize and Gros, however I am still unconvinced by the case for a complex API to enforce such separation, I never suggested to make a complex API to enforce such separation. Quite the contrary, I think that the API should be kept simple, organized and rather straightforward. If the resulting API is complex (either in structure or to maintain), then it is indeed a failure, as one of the goal is to make the code easier to interface, not harder. > a well constructed layout of functions within files, created according to how they are called in various places, would, I feel, help almost as much without adding yet another thing to support that will quickly become outdated. Such a layout is indeed one of the points to achieve, and is the first step to do (one cannot expect to define a solid API without a clear and global view over the existing code). On the other hand, let's not forget that "cleaner code" is *one* point a modularized system with a generic API for objects is meant to address. A modular system would allow easier interfacing with other libraries, languages or software, would make possible integration of new classes of objects alongside the maps themselves; if properly done, it could allow upgrades and fixes in the modules code to be integrated in a running server without having to stop it; on-demand loading/unloading of code, with the possibility of creating auto-downloadable chunks, etc. It would basically make Crossfire a game framework that could effectively be used as a workbasis for all kinds of square-based multiplayer RPGs, something a monolithic code will *never* be able to achieve. Of course, you may object that "this is pure conjecture, that would get only results on the long-term, if they ever get any". Sure - this is an important change. I think that it all comes down to asking the question: do we want to polish the current infrastructure, keeping adding details to it, or do we want it to evolve into something more ambitious ? I think that we should, at some point, clearly put on the table the future direction we want Crossfire to go to, goals we want it to achieve not today or the next month, but on a long-term perspective. From yann.chachkoff at myrealbox.com Thu Jan 26 16:27:42 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Thu, 26 Jan 2006 23:27:42 +0100 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1138314462.c7fc799cyann.chachkoff@myrealbox.com> > In this I do not disagree with Tchize and Gros, however I am still unconvinced by the case for a complex API to enforce such separation, I never suggested to make a complex API to enforce such separation. Quite the contrary, I think that the API should be kept simple, organized and rather straightforward. If the resulting API is complex (either in structure or to maintain), then it is indeed a failure, as one of the goal is to make the code easier to interface, not harder. > a well constructed layout of functions within files, created according to how they are called in various places, would, I feel, help almost as much without adding yet another thing to support that will quickly become outdated. Such a layout is indeed one of the points to achieve, and is the first step to do (one cannot expect to define a solid API without a clear and global view over the existing code). On the other hand, let's not forget that "cleaner code" is *one* point a modularized system with a generic API for objects is meant to address. A modular system would allow easier interfacing with other libraries, languages or software, would make possible integration of new classes of objects alongside the maps themselves; if properly done, it could allow upgrades and fixes in the modules code to be integrated in a running server without having to stop it; on-demand loading/unloading of code, with the possibility of creating auto-downloadable chunks, etc. It would basically make Crossfire a game framework that could effectively be used as a workbasis for all kinds of square-based multiplayer RPGs, something a monolithic code will *never* be able to achieve. Of course, you may object that "this is pure conjecture, that would get only results on the long-term, if they ever get any". Sure - this is an important change. I think that it all comes down to asking the question: do we want to polish the current infrastructure, keeping adding details to it, or do we want it to evolve into something more ambitious ? I think that we should, at some point, clearly put on the table the future direction we want Crossfire to go to, goals we want it to achieve not today or the next month, but on a long-term perspective. From mwedel at sonic.net Fri Jan 27 00:53:20 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 26 Jan 2006 22:53:20 -0800 Subject: [crossfire] Lag In-Reply-To: References: <7903f03c0601251657v5d2d8d44q42c39b0b7d07b7a8@mail.gmail.com> <43D8704E.7050308@sonic.net> Message-ID: <43D9C360.5040608@sonic.net> Anton Oussik wrote: > On 26/01/06, Mark Wedel wrote: >> Brendan Lally wrote: >>> On 1/26/06, Anton Oussik wrote: >>>> Is there anything that can be done to improve movement on laggy >>>> connections? Could the server send the client a matrix of what tiles >>>> on the map can be moved to, and send updates of that as they change >>>> for example? Any better ideas? >> I'm not sure that helps out. What it gains is that the client can 'move' the >> player to the space they are attempting to go to so that client is slightly more >> up to date. However, you will get syncrhonization issues - if your lag is 500 >> ms, any update on that array of spaces is still 4 ticks out of date. So you can >> certainly get the case where the client thinks it can move to some space, but >> someone else has already moved there, and thus what the client displays is not >> just out of date, but erroneous. > > Yes, I too see that flaw. However most other online RPGs deal with > that issue in a similar way to this, using server updates as the > reference, and it seems to work for them. There are a few differences in crossfire. One is that in crossfire, the client is presumed insecure - the server shouldn't trust anything the client says The other is that in crossfire is the amount of real estate covered. If you have 500 ms lag (4 ticks) that means you can be 4 spaces behind. If you are running with a 25x25 space display, you see 12 spaces in each direction from the central player, which means you move 1/3 of your visible spaces just from lag. Compared to most all the other games, I think this is a huge portion of the display. One problem with the array of spaces is also the case of how this really works. For example, the player is running east. The player stops running, at say space 15,5. By the time the server receives that the player has stopped moving, the server thinks the player is at 19,5. You can't really undone that change - imagine any exits, traps, or other special spaces the player runs over (as well as what other players see) - so in this case, the server really has to keep the player at 19,5. Sending the grid of spaces to the client I don't think actually makes much difference - as I think about it, I am not really sure how it helps anything - the only thing it really helps out on is if the player is running into a wall - the player can change direction a bit faster. >> The slightly more complicated part is that ideally, you'd want the server to >> send the client the proposed route (so the client could display it in some >> format, so if it is completely bogus, the player can interrupt it and re-route >> manually. > > Is there really much point in this? Clicking anywhere you can see > should (travelling in more-less straight line) get you there in about > a second, which is not enough time to cancel a route. You're probably right in that regard. > >> One consideration is the case of alternate routes. One tricky part also, >> relative to players using that code, is you don't want the player to cheat too >> much. IF the player is in a maze, they shouldn't be able to click some spaces >> away and the server now routes them there even though as a player they had no clue. > > Maybe limit the length of route to 20 or 30 tiles? Or a very stupid code could be used - basically, the 'move to x,y code' doesn't look beyond one space. IT looks where the player currently is and figures out the best space to move to to get the player closer to the goal by basically using a direct line method. Thus, such a goto x,y would probably avoid simple blockages, but not anything very tricky. >> Yes, but here are some other random thoughts: >> 1) Player movement is perhaps to fast - with most all players moving about 1 >> space/tick, this obviously results in keeping in sync harder. > > Slowing down players is a bad idea. Slower movement gives the > impression of lag, as players see no notification that their character > intends to move for a while. This is to do with the fact that > movements in cf are quantum, and therefore there is no smooth > transition when moving from tile to tile. Maybe one solution to that > would be to make all tiles one pixel, and all objects into multi-tile > things? Then speed up all movement speeds 30-fold or so, and maybe one > day you end up with something with nice smooth movement, and > appearance of no lag. One issue right now is very fast players are really very fast, and slow players are really very slow. A player have a 1.5+ speed probably isn't that uncommon, but a slow player could have a 0.2 speed. I'd personally like to moderate those, so typical speed range is 0.25 to about 0.75, with magic allow that extra speed, but perhaps still capping it at 1.0 Splitting spaces into smaller pieces has been talked about before, but gets into other complicated/odd issues. One of the big ones is objects still have to belong to a specific space - not an issue for object, but gets more complicated regarding players or monsters - if a player is moving onto a space (and say is 0.4 there) and another monsters moves onto that space (0.6), the player can't move there anymore, but the placement could still appear odd. I think a major rewrite of the code would be needed to support partial/smooth movement. To do it right, it isn't as much what space creatures are on, but rather, keeping a proper gap between monsters and player (thus a player at 24.5, 18 is fine if the monster is at 25.5, 18 as there is still that 1 space gap). >> 3) Currently, the server processes all the objects/players, sleeps for 120 ms, >> then does that again. >> >> Lag could be reduced by some amount (average 60 ms) if we process data from >> players immediately when it arrives. > > This sounds like a great idea for reducing lag in low latency > conditions, making cf pretty much real-time for the user. I think all > the people playing on private servers will want this implemented. Yes, but it adds some complication. On the bright side, it could have other nice effects. > > Now if everyone could get a low latency connection... How about > distributing the server? This is at the moment not viable to > implement, but maybe some time in the future, could a number of > servers in geographically distant points act as one super-server, and > allow clients to join to any of them, and be part of the same world? > They would only need to send updates from time to timeand only when > several players (on different servers) are on the same map. Then they > would need to solve issues like what random items resolve to, and what > a state of a particular object is. Random map synchronisation would > also be an issue. This has been talked about, but gets very complicated. It wouldn't be that hard to have these different servers take care of different parts of the world (server A does scorn, server B navar city, etc), and thus, as the player moves about, they automatically get transferred to different servers. But having two different servers handle the same area gets into all sorts of synchronization issues - the ones discussed above still apply (player on server 1 moves to 5,5, and player on server 2 also moves there, but because the inter server lag is 500 ms, so each server thinks it is fine, etc). I'd say for the complication trying to handle that adds, it really isn't worth it. Another random thought: Right now, the server processes player events as the player has time execute them, and processes them in sequential order. It adds some complication, but ideally it would be nice for the server to read all the pending commands from the client and see about executing some commands out of order. I'm not sure how this would work - it's almost like you would want to allow some handling of priority to the player (eg, the apply healing potion should be a top priority most likely). But one could also envision a 'cancel' type command to ignore all the previous commands. Thus, if you're moving slow and do something like 'east, east, east, apply, east, say chain, ..' and something interrupts that flow, you could hit the cancel but and it discards all the queued commands. that doesn't really help in lag, but does help on slow connections when something bad happens. From mwedel at sonic.net Fri Jan 27 02:08:30 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 27 Jan 2006 00:08:30 -0800 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1138314462.c7fc799cyann.chachkoff@myrealbox.com> References: <1138314462.c7fc799cyann.chachkoff@myrealbox.com> Message-ID: <43D9D4FE.5070308@sonic.net> Yann Chachkoff wrote: > > Of course, you may object that "this is pure conjecture, that would get only > results on the long-term, if they ever get any". Sure - this is an important > change. I think that it all comes down to asking the question: do we want to > polish the current infrastructure, keeping adding details to it, or do we > want it to evolve into something more ambitious ? I think that we should, at > some point, clearly put on the table the future direction we want Crossfire > to go to, goals we want it to achieve not today or the next month, but on a > long-term perspective. That is a fair point - what is the long term goals of crossfire, and perhaps just as much to the point, how do we get there. One problem is that I think lots of different things are being discussed without any real concrete/clear examples. Broad strokes are being drawn, and this results in each person having a different interpretation of what the final picture may look like and whether or not they will like it. In terms of making crossfire completely modular so it can be a game framework, once again a nice idea. I'm not sure however if it wouldn't be easier/better to start from a clean slate - probably a lot of crossfire code could be re-used, but there is lots of code in crossfire right now to handle case X so maps that use that feature don't break, etc. A clean slate could get rid of those hacks and then have a clean well understood interface. The problem there is this becomes more an exercise of a good design with it not immediately applicable to anything - that cleanup is likely to make it work too oddly with lots of crossfire maps and/or objects. One could say that right now, a good cleanup effort in the code could be made to get rid of those hacks - I think in many cases, a programmatic fix has been done because it was deemed easier/faster than fixing/modifying say 20 maps. I've also seen some past discussion about cleaning up function calls within function calls, dependencies, etc. That also sounds great to clean up, but I'm also wondering how that can be done. I doubt people writing the code are just calling functions they don't need to call, so I am not sure right now how that gets fixed up without other more broad changes. But I think in total, there is some level of agreement that a code clean up/modularization is a good idea. What is less clear is what is the best way to do it, and what form it will take. So as I said in a previous message, it may be a good idea for those that are wanting/willing to do this to post some more specific examples of what they are talking about doing. From mikeeusaa at yahoo.com Fri Jan 27 15:52:38 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Fri, 27 Jan 2006 13:52:38 -0800 (PST) Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <43D9D4FE.5070308@sonic.net> Message-ID: <20060127215238.46939.qmail@web32709.mail.mud.yahoo.com> I don't think it would be wise to remove the hacks, the hacks make things work as they should. If someone want's to create a RPG engine crossfire, in my opinion, is not the place to do it. Crossfire is a game in it's own right, we should be concerned with our game, not some theoretical developers who might want to make their own game. We have media, we are beyond framework. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From yann.chachkoff at myrealbox.com Fri Jan 27 18:39:40 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat, 28 Jan 2006 01:39:40 +0100 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1138408780.c7ff7d5cyann.chachkoff@myrealbox.com> > I don't think it would be wise to remove the hacks, the hacks make things work as they should. Hacks are what the name imply: "dirty fixes". By "removing hacks", it simply means "replacing them by something cleaner that does the same job". Which benefits from code clarity, ease of debugging, and probably performances as well. We already removed some in the past, so that's simply a restatement that the efforts in that should continue. > If someone want's to create a RPG engine crossfire, in my opinion, is not the place to do it. > It is the exact place where to discuss about what we want to do with Crossfire, being maintaining it in its current state, expanding it or making it more generic. See the description of the list: "This list is used for general discussion and questions, answers, and latest changes and updates." This is general discussion around the game, so that discussion is perfectly in sync with that definition. If you don't like it, don't answer to it - simple as that. > Crossfire is a game in it's own right, I never said the contrary. > we should be concerned with our game, not some theoretical developers who might want to make their own game. I'm not speaking about "theoretical developers" - I'm speaking about those who (hopefully) will still play with crossfire and its code long after we don't. I'm thinking about all the ideas that could get implemented much more easily on a cleaner base than on a patchwork of code. No, I don't suggest working towards a cleaner and more generic code just for the sake of a handful of theoretical developers. I'm suggesting it to make *our* own developments easier and faster, to have a workbasis that we can expand further than what can be achieved now. We have wonderful game mechanisms in most cases, that can rival or even outclass those of a lot of commercial (successful games). I think that adding a new spell or a new object type to Crossfire should be as simple as writing a new map, so that new gaming mechanisms can get quickly implemented and tested - I don't see this as the benefit of a few coders, but a benefit for all players, who wouldn't have to wait for ages to get bugs solved or new, interesting ideas implemented. Maybe you're satisfied with the rythm at which your proposals are tested and implemented. I am not, and I believe a good structure would speed the process up a bit. > We have media, we are beyond framework. Nonsense. Just because we have code doesn't mean that its structure is of good quality, or that staying forever with it is satisfying. Given that you never had to add stuff in the Crossfire code, I suggest that you first try to do so, and *then* speak about your experience, as I really don't think you have any knowledge of the difficulties involved with the current codebase. Finally, I'd suggest not to introduce notions you obviously don't understand. By "framework" in this case, I was speaking about "a structure supporting a style of game"; or, if you prefer that term, a "generic, structured core of functions". The Media/Framework model has *nothing* to do with that. I don't think there can be any sane debate if you don't even understand the terms used. From brenlally at gmail.com Fri Jan 27 19:30:10 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sat, 28 Jan 2006 01:30:10 +0000 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1138408780.c7ff7d5cyann.chachkoff@myrealbox.com> References: <1138408780.c7ff7d5cyann.chachkoff@myrealbox.com> Message-ID: <7903f03c0601271730r2bcbdc45v8e8afb4699676c65@mail.gmail.com> On 1/28/06, Yann Chachkoff wrote: > I'm not speaking about "theoretical developers" - I'm speaking about those who (hopefully) will still play with crossfire and its code long after we don't. I'm thinking about all the ideas that could get implemented much more easily on a cleaner base than on a patchwork of code. > I'd be inclined to say that the quickest way to do that would be to have a deliberate compatibility break, not completely, but at least back to what is actually used. Debian Stable is probably the single most obsolete GNU/Linux distro in widespread use, but even this ships crossfire 1.7.0 Given that crossfire 1.9 should be close to release (maybe?) the second digit would wrap round, and the next release after that would logically be 2.0. A major version number shift would be a reasonable time to deliberately break compatibility with all versions below 1.7 (and maybe include some metaserver filter to stop servers older than this being included too). If this were to occur there would be an awful lot on the server side that could be dispensed with the map command and map1 commands (map1a could be used exclusively) the item1 command (the C clients have long since used item2) spell conversion from the old spell system support for the old skill system. support for oldsocket mode (pippijn recently made a textmode parser using the modern packet structure, oldsocketmode is a hack that could be retired completely) doubtless there are more that I haven't thought of. Remove all that compatibility cruft first, and then, when the server is made leaner as a result, look at what, if anything needs simplifying. (note also, I would suggest taking the same approach with the C clients, which have a similar problem (though less acutely)) From brenlally at gmail.com Fri Jan 27 19:39:47 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sat, 28 Jan 2006 01:39:47 +0000 Subject: [crossfire] renaming binaries (was: Moving server towards a modularized system?) Message-ID: <7903f03c0601271739i66b741f2kae44cd4a73effa73@mail.gmail.com> On 1/28/06, Brendan Lally wrote: > I'd be inclined to say that the quickest way to do that would be to > have a deliberate compatibility break, oh, one other thing which is vaguely related to that, a 2.0 release would also seem to be a good time to rename some binaries. Currently the server binary is called crossfire, and the gtkclient is gcfclient, every few weeks someone appears on either #crossfire or the cfmb who can't find the name of the binary to run, the naming system isn't as straightforward as it might be I would suggest the following mappings (for both binaries and package names) crossedit -> crossedit crossfire -> crossfire-server gcfclient -> crossfire-client gcfclient2 -> crossfire-client2 (or crossfire-client-gtk2) cfclient -> crossfire-client-x CFJavaEditor -> jcrossedit The slight annoyance this might cause with script breakages can be justified by a major version number change. From yann.chachkoff at myrealbox.com Sat Jan 28 02:59:08 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sat, 28 Jan 2006 09:59:08 +0100 Subject: [crossfire] Moving server towards a modularized system? Message-ID: <1138438748.c7dfe25cyann.chachkoff@myrealbox.com> > I'd be inclined to say that the quickest way to do that would be to have a deliberate compatibility break, not completely, but at least back to what is actually used. > I do agree with that. I think that fixing all the current bugs should be the first priority, so that a solid 1.9 release can be achieved. Note that after 1.9 could come 1.10, though :) > (and maybe include some metaserver filter to stop servers older than this being included too). If protocol compatibility is to get broken, it is probably better to change the metaserver URL, so that versions 1.x and 2.x don't overlap. > If this were to occur there would be an awful lot on the server side that could be dispensed with > the map command and map1 commands (map1a could be used exclusively) Probably a good time to get the "map2" command idea back on track. > the item1 command (the C clients have long since used item2) > spell conversion from the old spell system > support for the old skill system. > support for oldsocket mode (pippijn recently made a textmode parser > using the modern packet structure, oldsocketmode is a hack that could be retired completely) > doubtless there are more that I haven't thought of. >Remove all that compatibility cruft first, and then, when the server is made leaner as a result, look at what, if anything needs simplifying. > Yes, I agree with that completely. Not having to deal with old piece of code would make the work a little easier for sure. > (note also, I would suggest taking the same approach with the C clients, which have a similar problem (though less acutely)) Probably, although I'd say that clients are lower-priority, as their code complexity is somewhat lower. From alex_sch at telus.net Sat Jan 28 13:10:42 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sat, 28 Jan 2006 12:10:42 -0700 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1138408780.c7ff7d5cyann.chachkoff@myrealbox.com> References: <1138408780.c7ff7d5cyann.chachkoff@myrealbox.com> Message-ID: <43DBC1B2.4090307@telus.net> Yann Chachkoff wrote: >>If someone want's to create a RPG engine crossfire, in my opinion, is not the place to do it. >> >> >It is the exact place where to discuss about what we want to do with Crossfire, being maintaining it in its current state, expanding it or making it more generic. See the description of the list: "This list is used for general discussion and questions, answers, and latest changes and updates." This is general discussion around the game, so that discussion is perfectly in sync with that definition. If you don't like it, don't answer to it - simple as that. > > I agree that the code structure could be improved, and some level of modularization/separation of parts would be good if done with care. However, personally I do not see any real value in expanding it to a generic game engine. That said, I don't see any harm in that either, so long as it is done carefully. IMHO, creating a generic game engine is not a good goal for the project, however isn't necessarily a harmful as a side affect of increased modularization. I feel that modularization should be done (gradually and with care), to improve maintainability, *not* to create a generic game engine, though that would not be harmful to come as a side affect. Alex Schultz From mwedel at sonic.net Sat Jan 28 22:35:01 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 28 Jan 2006 20:35:01 -0800 Subject: [crossfire] renaming binaries (was: Moving server towards a modularized system?) In-Reply-To: <7903f03c0601271739i66b741f2kae44cd4a73effa73@mail.gmail.com> References: <7903f03c0601271739i66b741f2kae44cd4a73effa73@mail.gmail.com> Message-ID: <43DC45F5.9030601@sonic.net> Brendan Lally wrote: > On 1/28/06, Brendan Lally wrote: >> I'd be inclined to say that the quickest way to do that would be to >> have a deliberate compatibility break, > > oh, one other thing which is vaguely related to that, a 2.0 release > would also seem to be a good time to rename some binaries. Currently > the server binary is called crossfire, and the gtkclient is gcfclient, > every few weeks someone appears on either #crossfire or the cfmb who > can't find the name of the binary to run, the naming system isn't as > straightforward as it might be > > I would suggest the following mappings (for both binaries and package names) > crossedit -> crossedit Arguably, crossedit should just disappear. This, however, may become more or less an issue depending on other changes (if a code restructuring means significant rewrites needed for crossedit, I could see more reason to get rid of it. OTOH, if that major rewrite makes it cleaner, then maybe more compelling reason to keep crossedit, or make a gtk replacement). Also, if we're going to go with this naming convention, it should probably be crossfire-edit(or) > crossfire -> crossfire-server Agree. > gcfclient -> crossfire-client > gcfclient2 -> crossfire-client2 (or crossfire-client-gtk2) > cfclient -> crossfire-client-x I don't know if there is any official standard on this, but if anything, it would seem the standard is that it be toolkitname-program name. Eg, gnome-terminal, xterm, etc. It is a little unclear to me where gtk ends and gnome begins - on my system, I see a lot of gnome-* programs, but not many gtk-* programs But given that, I'd suggest gtk-crossfire-client, gtkv2-..., x-crossfire-client, etc to keep that naming convention. Perhaps have a generic crossfire-client script that looks for the different programs and tries to run the 'best' one available. > CFJavaEditor -> jcrossedit See note above about naming. That said, I'd be a little less concerned about this one, as I doubt there is as much confusion in this (at least on the unix side, you don't run it directly anyways - you're going to use ant or have to do the java command by hand, so that is sort of hidden). I don't in fact know if this can be reasonably assembled into a package or installed. But once again, making a script called jcrossedit that runs the JVM with the needed flags (I recall the default memory sizes really aren't big enough) may be the way to really go here. From mwedel at sonic.net Sat Jan 28 22:42:04 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 28 Jan 2006 20:42:04 -0800 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <7903f03c0601271730r2bcbdc45v8e8afb4699676c65@mail.gmail.com> References: <1138408780.c7ff7d5cyann.chachkoff@myrealbox.com> <7903f03c0601271730r2bcbdc45v8e8afb4699676c65@mail.gmail.com> Message-ID: <43DC479C.8020309@sonic.net> Brendan Lally wrote: > the map command and map1 commands (map1a could be used exclusively) > the item1 command (the C clients have long since used item2) > spell conversion from the old spell system > support for the old skill system. > support for oldsocket mode (pippijn recently made a textmode parser > using the modern packet structure, oldsocketmode is a hack that could > be retired completely) > doubtless there are more that I haven't thought of. Note that removing the old protocol commands is probably a good thing. I don't necessarily know we need to wait for a major version number (2.0) to do it. It could be done sooner - the server would need some code to detect minimum version the client can have (based on the cs/sc version as well as setup commands), and if the client doesn't meet it, it could print a message to the client like: Your client is too old to play on this server. Download the latest client from .... if you want to play on this server I don't think that would be too terrible. That said, I don't think much of that code is causing too much confusion/cruft - I think in the most part, the functions are pretty well defined. The stuff I'm more concerned about is code you look at and scratch your head and say 'what the heck is that for'. Yet if you remove it, you then find out that some maps break or whatever. That is the stuff that should be cleaned up - the problem is that the process is basically: Remove the odd code Run on somewhat well used server and see what problems are reported (if you know what stuff it will break, you could fix it yourself) Update the maps/objects, repeat The issue here is that this means that for some time period, there is a server with likely issues, just not known exactly what those would be. From mwedel at sonic.net Sat Jan 28 22:46:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 28 Jan 2006 20:46:52 -0800 Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1138438748.c7dfe25cyann.chachkoff@myrealbox.com> References: <1138438748.c7dfe25cyann.chachkoff@myrealbox.com> Message-ID: <43DC48BC.80503@sonic.net> Yann Chachkoff wrote: >> (and maybe include some metaserver filter to stop servers older than this >> being included too). > > If protocol compatibility is to get broken, it is probably better to change > the metaserver URL, so that versions 1.x and 2.x don't overlap. When there was the metaserver downtime/issues, there was talk at that time about a new more distributed metaserver implementation. Now the problem with the metaserver got resolved, and that sort of lowered in priority. But we still have the case of a single metaserver. If we know the server/protocol is going to change, coming up/using a new metaserver protocol at the same time would make a lot of sense. Thus, only new servers would have the code to talk to this metaserver. Only new clients would have the code to talk to this metaserver. It sorts its self out quite nicely in that regard. From mwedel at sonic.net Sat Jan 28 22:56:42 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 28 Jan 2006 20:56:42 -0800 Subject: [crossfire] Crossfire 2.0+ features/priorities Message-ID: <43DC4B0A.8030808@sonic.net> With the current discussion regarding modularization, the topic of new features also came up. For 2.0, it was mentioned do a general code cleanup to removed old crufty code that is only there for compatibility reasons. Fair enough. but relatively to players and developers, what do people see as the top feature(s) that should be added (or things fixed) to make crossfire a better game. I'm somewhat curious to see what the thoughts are. I think this info may indirectly help drive the modularization discussion - it may be that some of these features require significant rewrites or cleanups of the code that make sense with modularization. It may also be that some are relatively easy to do and don't require such changes. From mikeeusaa at yahoo.com Fri Jan 27 19:12:27 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Fri, 27 Jan 2006 17:12:27 -0800 (PST) Subject: [crossfire] Negative Luck for In-Reply-To: <1138401749.2864.12.camel@cthulhu> Message-ID: <20060128011227.25082.qmail@web32709.mail.mud.yahoo.com> Hi, I've asked for just that configuration option before. I'll forward this mail to the mailing list so the other devs may see that this is a wanted feature. --- Logan Tygart wrote: > Hey Man, > > I enjoy the hell out of your server. I have a > couple of characters > there. (Funyuns and Cugel) but when ever you pk your > luck goes down. > Since the server has no rules, is there anyway to > turn off that > "feature"? > > The last couple of days, we have been having a pk > fest on a character > named killah. > > Logan > -- > Nam et ipsa scientia potestas est -- Sir Francis > Bacon > Registered Linux User: 277727 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaa at yahoo.com Fri Jan 27 19:15:57 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Fri, 27 Jan 2006 17:15:57 -0800 (PST) Subject: [crossfire] Moving server towards a modularized system? In-Reply-To: <1138408780.c7ff7d5cyann.chachkoff@myrealbox.com> Message-ID: <20060128011557.25925.qmail@web32709.mail.mud.yahoo.com> MWedel just talked about a complete redesign in his latest post. Things that are redesigned tend to be broken for 1 or 2 years. I could be dead in 1 or 2 years, so could any of us. I'd rather not wait around. --- Yann Chachkoff wrote: > > I don't think it would be wise to remove the > hacks, the hacks make things work as they should. > > Hacks are what the name imply: "dirty fixes". By > "removing hacks", it simply means "replacing them by > something cleaner that does the same job". Which > benefits from code clarity, ease of debugging, and > probably performances as well. We already removed > some in the past, so that's simply a restatement > that the efforts in that should continue. > > > If someone want's to create a RPG engine > crossfire, in my opinion, is not the place to do it. > > > It is the exact place where to discuss about what we > want to do with Crossfire, being maintaining it in > its current state, expanding it or making it more > generic. See the description of the list: "This list > is used for general discussion and questions, > answers, and latest changes and updates." This is > general discussion around the game, so that > discussion is perfectly in sync with that > definition. If you don't like it, don't answer to it > - simple as that. > > > Crossfire is a game in it's own right, > > I never said the contrary. > > > we should be concerned with our game, not some > theoretical developers who might want to make their > own game. > > I'm not speaking about "theoretical developers" - > I'm speaking about those who (hopefully) will still > play with crossfire and its code long after we > don't. I'm thinking about all the ideas that could > get implemented much more easily on a cleaner base > than on a patchwork of code. > > No, I don't suggest working towards a cleaner and > more generic code just for the sake of a handful of > theoretical developers. I'm suggesting it to make > *our* own developments easier and faster, to have a > workbasis that we can expand further than what can > be achieved now. We have wonderful game mechanisms > in most cases, that can rival or even outclass those > of a lot of commercial (successful games). I think > that adding a new spell or a new object type to > Crossfire should be as simple as writing a new map, > so that new gaming mechanisms can get quickly > implemented and tested - I don't see this as the > benefit of a few coders, but a benefit for all > players, who wouldn't have to wait for ages to get > bugs solved or new, interesting ideas implemented. > > Maybe you're satisfied with the rythm at which your > proposals are tested and implemented. I am not, and > I believe a good structure would speed the process > up a bit. > > > We have media, we are beyond framework. > > Nonsense. Just because we have code doesn't mean > that its structure is of good quality, or that > staying forever with it is satisfying. > > Given that you never had to add stuff in the > Crossfire code, I suggest that you first try to do > so, and *then* speak about your experience, as I > really don't think you have any knowledge of the > difficulties involved with the current codebase. > > Finally, I'd suggest not to introduce notions you > obviously don't understand. By "framework" in this > case, I was speaking about "a structure supporting a > style of game"; or, if you prefer that term, a > "generic, structured core of functions". The > Media/Framework model has *nothing* to do with that. > I don't think there can be any sane debate if you > don't even understand the terms used. > > > _______________________________________________ > crossfire mailing list > crossfire at 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 mikeeusaa at yahoo.com Sat Jan 28 23:25:34 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sat, 28 Jan 2006 21:25:34 -0800 (PST) Subject: [crossfire] renaming binaries (was: Moving server towards a modularized system?) In-Reply-To: <43DC45F5.9030601@sonic.net> Message-ID: <20060129052534.77583.qmail@web32715.mail.mud.yahoo.com> If crossedit dissappears then I dissapear. I guess that is what you all want though. Should CF fork? --- Mark Wedel wrote: > Arguably, crossedit should just disappear. This, > however, may become more or > less an issue depending on other changes (if a code > restructuring means > significant rewrites needed for crossedit, I could > see more reason to get rid of > it. OTOH, if that major rewrite makes it cleaner, > then maybe more compelling > reason to keep crossedit, or make a gtk > replacement). > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaa at yahoo.com Sat Jan 28 23:31:45 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sat, 28 Jan 2006 21:31:45 -0800 (PST) Subject: [crossfire] renaming binaries (was: Moving server towards a modularized system?) In-Reply-To: <43DC45F5.9030601@sonic.net> Message-ID: <20060129053146.90362.qmail@web32710.mail.mud.yahoo.com> I am not opposed to porting crossedit to gtk however. But if my favorite editor is removed outright... java is not an option. However crossedit works great (IMHO) now, so there really is no reason to change it. All this constant talk of removing things is displeasurable, thus my retirement for a time. If the things I like are not removed I'll come back, if the things I like are removed I won't come back. I am also waiting on some new features aswell. I trust all notice the drop in cvs commits? That is because I am uninspired as I watch the CF dev team discuss the most effective way of canning the whole project. How about not removing things from the game, a novel idea, no? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From yann.chachkoff at myrealbox.com Sun Jan 29 02:31:55 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun, 29 Jan 2006 09:31:55 +0100 Subject: [crossfire] Crossfire 2.0+ features/priorities Message-ID: <1138523515.c7eefbdcyann.chachkoff@myrealbox.com> > But relatively to players and developers, what do people see as the top feature(s) that should be added (or things fixed) to make crossfire a better game. Apart from the code cleanup idea, here's what I see as important: - Better visual appearance. On the coding side, it means adding things like support for "smooth moves" (continuous move of characters and monsters between squares, instead of the current "direct jump to the next square" visual effect), or support for action animations (when I attack a monster, I expect my character to swing its weapon. When I wear a shield, I expect the shield to appear on the character displayed). - Better scenaristic background. Currently, a lot of the maps are very "bash-n-slash" without little to no story behind. I think that more than software code additions, solid, interesting stories will keep people playing. Offering different starting points for each race, providing more interactions with NPCs, chaining quests, etc. would require no new code and would also help filling the Bigworld map. - Friendlier client. The currently available clients are intimidating for newcomers: the cfclient looks rather primitive while gcfclient is crowded with options bars, icons and menus and leaves only a small patch in the middle to display the game playfield itself. I think that a friendlier design here that leaves more space for the game would make the game somewhat more immersive and enjoyable to play. Those are the things that I see as top-priority. Apart from the first, I don't think they require massive code changes. I tend to think that - once cleaned - the current "game engine" of Crossfire is very good and includes a lot of interesting features, on par with many commercial RPG and that it mostly requires to offer better content to get much more attractive. From yann.chachkoff at myrealbox.com Sun Jan 29 03:02:00 2006 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun, 29 Jan 2006 10:02:00 +0100 Subject: [crossfire] renaming binaries (was: Moving server towards a modularized system?) Message-ID: <1138525320.c7eefbdcyann.chachkoff@myrealbox.com> > I am not opposed to porting crossedit to gtk however. > The current difficulty I see with crossedit is that it is rather heavily dependent on the server code. I think that the best would be at some point to get the editor - being GTK, Athena or whatever else - get its own codebase, alongside the client and the server. This, however, would require significant work. The question being: do we really need to maintain two editors ? When the Java Editor was introduced, my answer to that question was "yes", because a lot of machines were a little too tight to run the Java Editor comfortably. But nowadays, my answer would be "no" - most not-too-ancient computers can run it, and it offers more functionalities (I think) than the old Athena Editor. > But if my favorite editor is removed outright... java is not an option. Well, it would be interesting to understand why Java isn't an option for you - did you have issues with the Java Editor when trying it ? If so, report those on the ML, so work can be done on it to try to solve them. > However crossedit works great (IMHO) now, so there really is no reason to change it. But it definitely wouldn't work anymore if significant changes occur in the server code - in particular, getting rid of the Athena Editor would allow to remove the separation between the "common" and "server" subdirectories - something that makes the code structure more complex with no real benefit (other than allowing the Athena Editor to exist in the first place). > All this constant talk of removing things is displeasurable, thus my retirement for a time. Notice that it was never suggested to remove game functionalities, but obsolete protocol commands, pieces of code not used anymore, or tools that got outdated by (supposedly) better ones. It may mean that some low-end computers that were previously able to run cfclient/crossedit will not be able to run their replacements with the same level of comfort, yes. But are we targetting the game at computers manufactured ten years ago ? I agree that not limiting Crossfire to the most modern machines is very important - but I am not convinced that we should extend support *that* far in the past. > If the things I like are not removed I'll come back, if the things I like are removed I won't come back. I'm immune to that kind of childish ultimatum, and I hope other developers are as well. > I am also waiting on some new features aswell. Nobody prevents you to code them and submit a patch on the ML if you want them. If no coder wants (or has time) to code your suggestions, it is their choice and you have to deal with it. > I trust all notice the drop in cvs commits? That is because I am uninspired as I watch the CF dev team discuss the most effective way of canning the whole project. And now, we're responsible of your lack of inspiration... Given that inspiration is something often driven by an unknown and highly complex mental process that science still fails to properly understand, I suggest that the discussion about possible future changes continues, as we're absolutely unsure that stopping it would solve your imagination issue. Now, I could suggest you various things to get inspiration back, like reading books, have a walk outside, listen to music, or spend less time ranting (which definitely can have a negative impact on imagination). > How about not removing things from the game, a novel idea, no? How about proposing an alternative to "let's keep everything unchanged forever" - a novel idea for you, wouldn't it ? From alex_sch at telus.net Sun Jan 29 03:28:32 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 29 Jan 2006 02:28:32 -0700 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <43DC4B0A.8030808@sonic.net> References: <43DC4B0A.8030808@sonic.net> Message-ID: <43DC8AC0.1060806@telus.net> Mark Wedel wrote: > With the current discussion regarding modularization, the topic of new >features also came up. > > Discussions do that :P > For 2.0, it was mentioned do a general code cleanup to removed old crufty code >that is only there for compatibility reasons. Fair enough. > > Yes, I agree. We can't keep much of this old compatibility cruft around forever. Yes we don't need to do a major release for it, but IMHO doing it at a major release will confuse the players less and therefore would be of benefit. > but relatively to players and developers, what do people see as the top >feature(s) that should be added (or things fixed) to make crossfire a better game. > > Features added... well... here's some ones I think would be neat for a 2.0 release (though doing all isn't too realistic): -Land plots (I plan on working on those some time) -Colored lighting and more lighting levels -More layers -Revamp/fix sound A few ideas/proposals on those are at http://wiki.metalforge.net/doku.php/dev_todo (feel free to contribute to the todo list there) Also I would really like to see the weather fixed up. The issues with that are: 1) Some disappearing tiles and such ugly bugs (might be a bug in the overlay code instead of weather code). (Also, no this isn't just Mikee, I've seen this on my private test server too) 2) Too much granularity right now. For this I think strange elevation values might be to blame. Might also be some simulation parameters. Not really sure. But in any case, you shouldn't see things like so many wet and dry spots speckled right beside eachother, that makes it seem almost as if there is little rainclouds speckled all over the place looking like they could float individually over player's heads 3) Once the granularity is fixed, perhaps some new rain pictures would also help that look even better > I'm somewhat curious to see what the thoughts are. I think this info may >indirectly help drive the modularization discussion - it may be that some of >these features require significant rewrites or cleanups of the code that make >sense with modularization. It may also be that some are relatively easy to do >and don't require such changes. > Personally, I think modularization and better organization would be something good to do, however I do not think it is worth doing major rewrites to archive such. Perhaps rewrite some parts, but IMHO there is plenty of organization that can be done with the current code without major rewrites. Also, out of the modularization discussions, there has been some 'game engine' talk. Personally, I do not believe separating into a game engine would be a good goal within/for the project, though I do believe that it isn't harmful if such separation comes as a side affect of other goals such as making the code more maintainable (not saying engine separation would necessarily have that affect, that is for another discussion). Alex Schultz From brenlally at gmail.com Sun Jan 29 04:48:06 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sun, 29 Jan 2006 10:48:06 +0000 Subject: [crossfire] Negative Luck for In-Reply-To: <20060128011227.25082.qmail@web32709.mail.mud.yahoo.com> References: <1138401749.2864.12.camel@cthulhu> <20060128011227.25082.qmail@web32709.mail.mud.yahoo.com> Message-ID: <7903f03c0601290248o3dff8963r3bcca913bbf8fd78@mail.gmail.com> On 1/28/06, Miguel Ghobangieno wrote: > Hi, I've asked for just that configuration option > before. I'll forward this mail to the mailing list so > the other devs may see that this is a wanted feature. Correction: it /was/ a wanted feature, about a year ago, which is roughly when it was introduced. from the settings file: # This is the penalty to luck that is given to a player who kills another # player (PK's). The value here is deducted from their luck value, so set this # high to discourage PK-ing and zero (or negative) to encourage it. # Range is limited to -100 to 100, since this is the value range that the luck # stat can be within. pk_luck_penalty 1 In the case of cat2, you probably want to set it to zero. From brenlally at gmail.com Sun Jan 29 04:56:40 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sun, 29 Jan 2006 10:56:40 +0000 Subject: [crossfire] renaming binaries (was: Moving server towards a modularized system?) In-Reply-To: <1138525320.c7eefbdcyann.chachkoff@myrealbox.com> References: <1138525320.c7eefbdcyann.chachkoff@myrealbox.com> Message-ID: <7903f03c0601290256p72f84ef4sb935a45112cbab36@mail.gmail.com> On 1/29/06, Yann Chachkoff wrote: > But it definitely wouldn't work anymore if significant changes occur in the server code - in particular, getting rid of the Athena Editor would allow to remove the separation between the "common" and "server" subdirectories - something that makes the code structure more complex with no real benefit (other than allowing the Athena Editor to exist in the first place). > I believe that the random map generator also needs the same seperation of common and server, at least the way it is compiled at the moment. From brenlally at gmail.com Sun Jan 29 06:20:14 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sun, 29 Jan 2006 12:20:14 +0000 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <43DC4B0A.8030808@sonic.net> References: <43DC4B0A.8030808@sonic.net> Message-ID: <7903f03c0601290420x2a1eae8fpe3a7c919d2b2f5bb@mail.gmail.com> On 1/29/06, Mark Wedel wrote: > but relatively to players and developers, what do people see as the top > feature(s) that should be added (or things fixed) to make crossfire a better game. I'll split this into two parts, usability issues/improvements, and game issues/improvements (many of these things I have hinted at on IRC in the past, but I'll describe them more fully here) Usability: currently most useful features of the game are hidden behind obscure text commands, without any nice way for the clients to show them in a systematic way. . - the rest are really minor niggles. I would suggest then, in no particular order: * client side display of parties (so that they can present an interface more like gcfclient2 has for the metaserver, removing the need for using the rather complex party commands directly). * adding more stats, including a number that could be considered as settings, so that clients can have a configure menu for them (imagine having a 'server' tab next to the general, map, and keybindings tabs in gcfclient) In order to do that, I think you would need to send.... output-sync short (byte?) output-count byte bowmode byte mapped to associated requestinfo applymode byte mapped to associated requestinfo listen level byte petmode byte mapped to associated requestinfo usekeys byte mapped to associated requestinfo all of which would have better names displayed client side (eg, group up to [spinbox] identical messages before sending, recieve messages with priority [spinbox] or lower) * I'd also want to consider removing brace altogether, or at least making it a flag in the stats so that it can be displayed client side (hitting brace by accident and not being able to move can be confusing). * providing an [instruction] ext new draw info so that clients can print the instructions that apply to them in order to do things. (I would imagine that this would be something like "drawextinfo 0 8 0 to worship a new god, stand on their alter and $(use_skill praying)" then a client could look up their own 'instructions' array, or check their keybindings, and if use_skill praying is found, print that instead (otherwise, strip out the $() characters). - so for example, my gcfclient setup has use_skill praying mapped to 'p', so when I receive that message, it should check an 'instructions' array, find it empty, and then look in the keybindings, find one that matches, and say "to worship a new god, stand on their alter and press p" * a new login system, which would allow single packet character login, or creation. something like a login name\0password packet, and also a createchar name\0\password packet (with the double typing the responsibility of the client). then some way to request die rolls, and send back the final results, and a race choice For this there would be something like requestinfo races, returning replyinfo [list of races with their corresponding face numbers], then requestinfo race foo return replyinfo race foo "the foo are a mysterious race from the land of the metasyntactic variable...." - clients then would be able to present a list of races to choose from, and a nicer interface to handling swapping stats. * sending all the information given from describing items in the items command (I think this is only the message, chosen name & values, then having the description generated client side, and shown as a tooltip to each item - freeing the left mouse button to do something else to items (moving apply away from middle click, maybe?). * having a concept of actions applying to a square (an extension of what I mentioned the other day about having a goto system, have something like left-click to walk to a square/pull a lever/talk to an NPC/fight a monster on a square (probably whichever is appropriate to the topmost item on the square, decided server side) and right click to cast a spell/fire an arrow, etc to a square. (diablo-style controls) possibly as an extension to this, send an actionid to the client with the map command (2 bytes per square (maybe a byte if there isn't a convenient tayste within the rest of the (newly redesigned) map command), so that clients can tell the player what would happen by clicking on a given square (this would also need some special flags to decide whether to show things like secret walls - possibly they should be marked walkable once you are adjacent to them, but not from a distance - or maybe the detect traps skill should mark them detected, after which they show up....) - an extension to the extension above, send health status along with monsters (probably as a percentage to not give away total hp), they can then have clients draw health bars above their heads. * having a keywords system in NPC dialog, so that when NPCs speak, it formats their text specially, underlining (or similar) the words they say that you can ask more about - additionally then, store all recent (last day or so) keywords that were discovered in speech (probably using markers), and present an interface to the client to select keywords from what was last said, or anything said in the last day or so. * starting all initial equipment as locked, with a special warning for god-given items when they hit the drop button, that dropping this will get rid of it, and in any case they need to unlock it first. * send mapname (not path) in the stats command, so that player's can be shown it in the client. * Likewise send god (probably by id number, with a corresponding request-info to get the full list * send perm exp for each skill, also have a levelbreaks requestinfo, so that clients can display bars or similar to show how close a skill is to leveling. (seeing that you are about a half an inch from a level up is more intuitive than seeing your current exp is n, and the next level up is at x, and your last level up was at m, so you are about n-m/x-m of the way there). * default new players to listen mode 10, and usekeys keyring * send help in a special form (similar to the instruction drawext I mentioned above) so that clients can screen out the commands they handle internally, (north, south, cast, etc) Ingame: * states in conversation (so that going up to someone and saying 'yes' will have them say 'what are you talking about' whereas saying 'yes' after they ask a question will give a different response (this really would require the point about conversation keywords to be in as a pre-requisite)). * auction house for in-game items: cf-bay? * a town and god based reputation system, linked to the quests system, and other actions that are taken - eg you kill an NPC, your reputation in the region goes down, you kill a monster, your reputation with the god that monster worships goes down, and your reputation with the god who is the enemy of that monster goes up (but not by as much). reputation then would affect prices in shops, damage done by banishment (if a god likes you, he won't hurt you even if you are of a race he initially hates), rewards from gods (instead of praying for hours, each reward could 'cost' a certain amount of reputation, which is then deducted from the current total), ability to convert, and available quests (a check in the magicmouth/NPC for reputation > or < a certain value). also there should be interconnectedness between reputation values, as local regions hear rumours, so for instance if you go on a killing spree in scorn and kill enough NPCs to lose 1 million reputation points (I haven't quite figured out the scaling yet), then santo dominion and stoneville might lose 100000-odd points towards you as well. Note: a few of these are quite straightforward, and I may try doing them almost immediatly if there are no objections. From alex_sch at telus.net Sun Jan 29 10:15:49 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 29 Jan 2006 09:15:49 -0700 Subject: [crossfire] crossedit and the Java editor (was: renaming binaries (was: Moving server towards a modularized system?)) In-Reply-To: <1138525320.c7eefbdcyann.chachkoff@myrealbox.com> References: <1138525320.c7eefbdcyann.chachkoff@myrealbox.com> Message-ID: <43DCEA35.80209@telus.net> Yann Chachkoff wrote: >>I am not opposed to porting crossedit to gtk however. >> >> >The current difficulty I see with crossedit is that it is rather heavily dependent on the server code. I think that the best would be at some point to get the editor - being GTK, Athena or whatever else - get its own codebase, alongside the client and the server. > >This, however, would require significant work. The question being: do we really need to maintain two editors ? When the Java Editor was introduced, my answer to that question was "yes", because a lot of machines were a little too tight to run the Java Editor comfortably. But nowadays, my answer would be "no" - most not-too-ancient computers can run it, and it offers more functionalities (I think) than the old Athena Editor. > > From what I have saw, the java editor is very flawed (not impossible to fix, however IMHO not very maintainable), largely due to various fixable bugs, but more importantly the language being unfamiliar to most of our devs, and therefor "bad things happen" such as mistakes that cause it to be slow (As I understand, there are lots of slow java programs, not necessarily because of the language, but coding mistakes that are common in it for C coders and such). The old crossedit is also very flawed due to a combination of it's widget set, and rather messy code (so messy that it's even worse than the Java editor likely). IMHO, what would be BEST (by no means least effort, in fact likely most effort), would be a rewrite of crossedit (different toolkit, make sure the code is organized), and a big cleanup of the 'common'/'server' separation. I might be willing to do this myself even once I get a bit more time on my hands. >>But if my favorite editor is removed outright... java is not an option. >> >> >Well, it would be interesting to understand why Java isn't an option for you - did you have issues with the Java Editor when trying it ? If so, report those on the ML, so work can be done on it to try to solve them. > > As I understand, his reason is because Java is a non-foss dependency. IMHO this is not a worthless point, it doesn't prevent me from using the java editor, but it does leave a 'bad taste in my mouth'. >>However crossedit works great (IMHO) now, so there really is no reason to change it. >> >> >But it definitely wouldn't work anymore if significant changes occur in the server code - in particular, getting rid of the Athena Editor would allow to remove the separation between the "common" and "server" subdirectories - something that makes the code structure more complex with no real benefit (other than allowing the Athena Editor to exist in the first place). > I believe the way that it is dependent on the server code is actually a rather eloquent thing; why maintain two separate copies of the map saving and loading code? Of course, that said, the current state of the split between "common" and "server" IS very hackish and somewhat ugly. However, I see making the separation more distinct and cleaner, would be something that would help with modularization, not so much fo any advantage in making features easier, but for making the code more maintainable. So if anything, the boundary between "common" and "server" shouldn't be removed, but should be fixed/cleaned up and solidified. Alex Schultz From brenlally at gmail.com Sun Jan 29 11:21:12 2006 From: brenlally at gmail.com (Brendan Lally) Date: Sun, 29 Jan 2006 17:21:12 +0000 Subject: [crossfire] renaming binaries (was: Moving server towards a modularized system?) In-Reply-To: <43DC45F5.9030601@sonic.net> References: <7903f03c0601271739i66b741f2kae44cd4a73effa73@mail.gmail.com> <43DC45F5.9030601@sonic.net> Message-ID: <7903f03c0601290921o2e071ac9kf41a515e4ded3560@mail.gmail.com> On 1/29/06, Mark Wedel wrote: > > I would suggest the following mappings (for both binaries and package names) > > crossedit -> crossedit > > Arguably, crossedit should just disappear. This, however, may become more or > less an issue depending on other changes (if a code restructuring means > significant rewrites needed for crossedit, I could see more reason to get rid of > it. OTOH, if that major rewrite makes it cleaner, then maybe more compelling > reason to keep crossedit, or make a gtk replacement). The problem is that at the moment there is no real replacement for crossedit (CFJavaEditor doesn't work well enough, it doesn't even have undo support). I don't think that crossedit needs to be abandoned though, splitting it out into a separately distributed tarball/CVS module would suffice, if the functions that it uses from the server code are well documented/commented, then any changes to these functions in the server module should backport to crossedit as and when that is needed. Meanwhile, the server/ common/ distinction could go, and everything be rearranged more logically. (this would also have the advantage of allowing crossedit to be ported to a modern toolkit without breaking the server). > > gcfclient -> crossfire-client > > gcfclient2 -> crossfire-client2 (or crossfire-client-gtk2) > > cfclient -> crossfire-client-x > > I don't know if there is any official standard on this, but if anything, it > would seem the standard is that it be toolkitname-program name. > > Eg, gnome-terminal, xterm, etc. > > It is a little unclear to me where gtk ends and gnome begins - on my system, I > see a lot of gnome-* programs, but not many gtk-* programs > > But given that, I'd suggest gtk-crossfire-client, gtkv2-..., > x-crossfire-client, etc to keep that naming convention. The thing with this is that currently all distro packages are called crossfire-client or crossfire-client-gtk. If I am on a debian (or similar) system and install a program, I always try and run it using the name of the package, only if that fails do I bother to grep the filelist for bin/, sometimes if it is something I don't care about, then I ignore it and find something else to do the job instead. having the binary being tab-completable from the start of the package name is a good thing, especially when the .desktop files aren't installed properly. of course, should there ever be a KDE client, then the rules change somewhat, the name krossfire-klient would be obligatory. > > Perhaps have a generic crossfire-client script that looks for the different > programs and tries to run the 'best' one available. I'd be interested to know how 'best' would be determined there. > > CFJavaEditor -> jcrossedit > > See note above about naming. That said, I'd be a little less concerned about > this one, as I doubt there is as much confusion in this (at least on the unix > side, you don't run it directly anyways - you're going to use ant or have to do > the java command by hand, so that is sort of hidden). java -jar CFJavaEditor.jar > I don't in fact know if this can be reasonably assembled into a package or > installed. But once again, making a script called jcrossedit that runs the JVM > with the needed flags (I recall the default memory sizes really aren't big > enough) may be the way to really go here. The default memory size is ok if you only open a couple of maps, and is a lot better than it used to be since tchize fixed it a while back. From fuchs.andy at gmail.com Sun Jan 29 12:53:00 2006 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun, 29 Jan 2006 13:53:00 -0500 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <7903f03c0601290420x2a1eae8fpe3a7c919d2b2f5bb@mail.gmail.com> References: <43DC4B0A.8030808@sonic.net> <7903f03c0601290420x2a1eae8fpe3a7c919d2b2f5bb@mail.gmail.com> Message-ID: I have added a page to the wiki, where crossfire 2.0 features could be tracked. http://wiki.metalforge.net/doku.php/dev_todo/cf2.0 -- Andrew Fuchs From mikeeusaa at yahoo.com Sun Jan 29 09:09:57 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun, 29 Jan 2006 07:09:57 -0800 (PST) Subject: [crossfire] renaming binaries (was: Moving server towards a modularized system?) In-Reply-To: <1138525320.c7eefbdcyann.chachkoff@myrealbox.com> Message-ID: <20060129150957.79730.qmail@web32701.mail.mud.yahoo.com> Understand this Yann. IF crossedit is removed I remove myself. Do you want to lose your biggest current media contributor? If so then remove crossedit. I think you need to fork off crossfire and make your own project where you can do whatever you want. Perhapse crossfire-awsome.sf.net? --- Yann Chachkoff wrote: > > I am not opposed to porting crossedit to gtk > however. > > > The current difficulty I see with crossedit is that > it is rather heavily dependent on the server code. I > think that the best would be at some point to get > the editor - being GTK, Athena or whatever else - > get its own codebase, alongside the client and the > server. > > This, however, would require significant work. The > question being: do we really need to maintain two > editors ? When the Java Editor was introduced, my > answer to that question was "yes", because a lot of > machines were a little too tight to run the Java > Editor comfortably. But nowadays, my answer would be > "no" - most not-too-ancient computers can run it, > and it offers more functionalities (I think) than > the old Athena Editor. > > > But if my favorite editor is removed outright... > java is not an option. > > Well, it would be interesting to understand why Java > isn't an option for you - did you have issues with > the Java Editor when trying it ? If so, report those > on the ML, so work can be done on it to try to solve > them. > > > However crossedit works great (IMHO) now, so there > really is no reason to change it. > > But it definitely wouldn't work anymore if > significant changes occur in the server code - in > particular, getting rid of the Athena Editor would > allow to remove the separation between the "common" > and "server" subdirectories - something that makes > the code structure more complex with no real benefit > (other than allowing the Athena Editor to exist in > the first place). > > > All this constant talk of removing things is > displeasurable, thus my retirement for a time. > > Notice that it was never suggested to remove game > functionalities, but obsolete protocol commands, > pieces of code not used anymore, or tools that got > outdated by (supposedly) better ones. > > It may mean that some low-end computers that were > previously able to run cfclient/crossedit will not > be able to run their replacements with the same > level of comfort, yes. But are we targetting the > game at computers manufactured ten years ago ? I > agree that not limiting Crossfire to the most modern > machines is very important - but I am not convinced > that we should extend support *that* far in the > past. > > > If the things I like are not removed I'll come > back, if the things I like are removed I won't come > back. > > I'm immune to that kind of childish ultimatum, and I > hope other developers are as well. > > > I am also waiting on some new features aswell. > > Nobody prevents you to code them and submit a patch > on the ML if you want them. If no coder wants (or > has time) to code your suggestions, it is their > choice and you have to deal with it. > > > I trust all notice the drop in cvs commits? That > is because I am uninspired as I watch the CF dev > team discuss the most effective way of canning the > whole project. > > And now, we're responsible of your lack of > inspiration... Given that inspiration is something > often driven by an unknown and highly complex mental > process that science still fails to properly > understand, I suggest that the discussion about > possible future changes continues, as we're > absolutely unsure that stopping it would solve your > imagination issue. > > Now, I could suggest you various things to get > inspiration back, like reading books, have a walk > outside, listen to music, or spend less time ranting > (which definitely can have a negative impact on > imagination). > > > How about not removing things from the game, a > novel idea, no? > > How about proposing an alternative to "let's keep > everything unchanged forever" - a novel idea for > you, wouldn't it ? > > > _______________________________________________ > crossfire mailing list > crossfire at 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 temitchell at sympatico.ca Sun Jan 29 14:29:58 2006 From: temitchell at sympatico.ca (todd) Date: Sun, 29 Jan 2006 15:29:58 -0500 Subject: [crossfire] renaming binaries In-Reply-To: <20060129150957.79730.qmail@web32701.mail.mud.yahoo.com> References: <20060129150957.79730.qmail@web32701.mail.mud.yahoo.com> Message-ID: <43DD25C6.5030404@sympatico.ca> I suppose this would be a nice perk and a big incentive to remove crossedit, but you've quit so many times before that it just isn't a reliable enough promise to base a decision like this on ;) Miguel Ghobangieno wrote: >Understand this Yann. IF crossedit is removed I remove >myself. Do you want to lose your biggest current media >contributor? If so then remove crossedit. > >I think you need to fork off crossfire and make your >own project where you can do whatever you want. >Perhapse crossfire-awsome.sf.net? > >--- Yann Chachkoff >wrote: > > From mwedel at sonic.net Sun Jan 29 16:20:36 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 29 Jan 2006 14:20:36 -0800 Subject: [crossfire] renaming binaries In-Reply-To: <20060129150957.79730.qmail@web32701.mail.mud.yahoo.com> References: <20060129150957.79730.qmail@web32701.mail.mud.yahoo.com> Message-ID: <43DD3FB4.4030909@sonic.net> Miguel Ghobangieno wrote: > Understand this Yann. IF crossedit is removed I remove > myself. Do you want to lose your biggest current media > contributor? If so then remove crossedit. I seem to see this ultimatum almost once a week now (do this or I leave) This carries no weight for me. I'm not going to program and make changes based on what one person demands to be done. Maybe you are the one that needs to fork off crossfire for your own use so you can do whatever you want with it. From mwedel at sonic.net Sun Jan 29 16:21:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 29 Jan 2006 14:21:52 -0800 Subject: [crossfire] crossedit and the Java editor (was: renaming binaries (was: Moving server towards a modularized system?)) In-Reply-To: <43DCEA35.80209@telus.net> References: <1138525320.c7eefbdcyann.chachkoff@myrealbox.com> <43DCEA35.80209@telus.net> Message-ID: <43DD4000.1000004@sonic.net> Crossedit still works to some degree. However, when new things are added, it does break and fixes are needed. Anyone remember regions? Also, I haven't looked lately, but I'm not sure sure if crossedit actually supports all needed features - is there an interface to map tiling information, etc. If crossedit was to be redone, this would briefly be my suggestions: 1) Use glade to do layout, so additional layout features are easy to add in/layout. This would make whipping up the basic interface pretty quickly. 2) Make this a separate program from the server (new CVS tree). That said, large portions of code could be grabbed from the server (load/save) and the client (display). Sure, having the editor be a separate program would mean that that code may get out of date. OTOH, at least on the server side, there is a lot of code there that does things that the editor doesn't really need (and there are about half a dozen editor checks in the common directory to handle things we do or don't want to do if being used through the editor). 3) Do something like the java editor and have a file that does an object type/special fields type of documentation, instead of it being hardcoded into the program (eg, for exits, it is sp/hp which are the coordinates it leads to, but the editor should present that as dest_x and dest_y) That said, all of this is a non trivial process. If the java editor is not good enough, and can't be made 'good enough' then this is perhaps something that should be investigated. random map code: It only requires the 'common' directory for the stand alone random map generator. Since the random map code is linked into the server, it does not need/care about libcross.a. I don't know how often the standalone program is used, but if it was used enough, I'd suggest that the server could be modified to take some command line options (eg, crossfire -gen-random-map -random_map_options='....') From mwedel at sonic.net Sun Jan 29 16:31:29 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 29 Jan 2006 14:31:29 -0800 Subject: [crossfire] renaming binaries In-Reply-To: <7903f03c0601290921o2e071ac9kf41a515e4ded3560@mail.gmail.com> References: <7903f03c0601271739i66b741f2kae44cd4a73effa73@mail.gmail.com> <43DC45F5.9030601@sonic.net> <7903f03c0601290921o2e071ac9kf41a515e4ded3560@mail.gmail.com> Message-ID: <43DD4241.40907@sonic.net> Brendan Lally wrote: > On 1/29/06, Mark Wedel wrote: >>> I would suggest the following mappings (for both binaries and package names) >>> crossedit -> crossedit >> Arguably, crossedit should just disappear. This, however, may become more or >> less an issue depending on other changes (if a code restructuring means >> significant rewrites needed for crossedit, I could see more reason to get rid of >> it. OTOH, if that major rewrite makes it cleaner, then maybe more compelling >> reason to keep crossedit, or make a gtk replacement). > > The problem is that at the moment there is no real replacement for > crossedit (CFJavaEditor doesn't work well enough, it doesn't even have > undo support). This is perhaps a problem. But then I think we need to figure out what our editor story is. If it is that the java editor is the official editor, these bugs should be reported and fixed up. I do agree that the fact it is in java and not C probably doesn't help things a great deal in terms of java competency of some of the programmers (me included). > > > The thing with this is that currently all distro packages are called > crossfire-client or crossfire-client-gtk. If I am on a debian (or > similar) system and install a program, I always try and run it using > the name of the package, only if that fails do I bother to grep the > filelist for bin/, sometimes if it is something I don't care about, > then I ignore it and find something else to do the job instead. > > having the binary being tab-completable from the start of the package > name is a good thing, especially when the .desktop files aren't > installed properly. Have to admit, I've not looked at what other packages do in terms of program names vs package names. >> Perhaps have a generic crossfire-client script that looks for the different >> programs and tries to run the 'best' one available. > > I'd be interested to know how 'best' would be determined there. Probably basically in this order: gcfclient (still most complete) gtkv2-client (not complete, but still usable, and probably more complete/featureful than) cfclient - last resort really, and it doesn't provide much in the way of UI, and I think is still limited in terms of graphics and map size. From mwedel at sonic.net Sun Jan 29 16:38:55 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 29 Jan 2006 14:38:55 -0800 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <1138523515.c7eefbdcyann.chachkoff@myrealbox.com> References: <1138523515.c7eefbdcyann.chachkoff@myrealbox.com> Message-ID: <43DD43FF.908@sonic.net> Yann Chachkoff wrote: > - Friendlier client. The currently available clients are intimidating for > newcomers: the cfclient looks rather primitive while gcfclient is crowded > with options bars, icons and menus and leaves only a small patch in the > middle to display the game playfield itself. I think that a friendlier design > here that leaves more space for the game would make the game somewhat more > immersive and enjoyable to play. I hope the gtkv2 client goes a little in that direction (the map display is at least considerable. However, I know there are issues regarding the minimum window size it needs). One of the things that have been on my wishlist a long time is a better character creation method. the current method of 'press keys to swap stats', 'press spacebar to cycle through classes', 'move your now created character to choose a class', and then heading to the nexus are all a little hokey. And for new players, probably a little frustrating - not knowing how the race/class will affect your stats until you choose that previous piece, etc. Pretty much all games provide a screen for the player to choose this - arrange stats, pull down option for race (which effects stats), pulldown for class (which also effects stats), etc. For stats, I'd probably suggest 4 colums in fact - base stat, modifiers from race, modifiers from class, and final stat. One nice effect of this getting moved to the client is all that code currently in the server that handles this could just go away. As far of this, I'd also suggest going with just a straight point system for stats (you get 180 points for your stats to distribute, instead of rolling). New code would have to be added to the server to validate the final result (player didn't over spend points, etc) From mwedel at sonic.net Sun Jan 29 16:46:27 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 29 Jan 2006 14:46:27 -0800 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <7903f03c0601290420x2a1eae8fpe3a7c919d2b2f5bb@mail.gmail.com> References: <43DC4B0A.8030808@sonic.net> <7903f03c0601290420x2a1eae8fpe3a7c919d2b2f5bb@mail.gmail.com> Message-ID: <43DD45C3.1020500@sonic.net> Brendan Lally wrote: > I would suggest then, in no particular order: > > * client side display of parties (so that they can present an > interface more like gcfclient2 has for the metaserver, removing the > need for using the rather complex party commands directly). > Yes - that sounds like a good idea. > * adding more stats, including a number that could be considered as > settings, so that clients can have a configure menu for them (imagine > having a 'server' tab next to the general, map, and keybindings tabs > in gcfclient) > > In order to do that, I think you would need to send.... > > output-sync short (byte?) > output-count byte I'd suggest the output-* stuff on the server should go away. That was put in before the client/server split IIRC. I think any collapsing/discarding of messages should just be done on the client. Granted, doing it on the server does save some bandwidth, but I can't see that as much an issue on current connections. > bowmode byte mapped to associated requestinfo > applymode byte mapped to associated requestinfo > listen level byte is listen level really used much? I'd almost suggest this go away also, but right now, harder for the client to deal with it, since it isn't getting message levels. > petmode byte mapped to associated requestinfo > usekeys byte mapped to associated requestinfo Yes, all the rest makes sense, and wouldn't be hard to do at all. > * I'd also want to consider removing brace altogether, or at least > making it a flag in the stats so that it can be displayed client side > (hitting brace by accident and not being able to move can be > confusing). Brace could probably go away now. I believe there are other ways to get the same effect (ready melee weapon skill, and just fire in that direction) From mikeeusaa at yahoo.com Sun Jan 29 15:07:23 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun, 29 Jan 2006 13:07:23 -0800 (PST) Subject: [crossfire] renaming binaries In-Reply-To: <43DD25C6.5030404@sympatico.ca> Message-ID: <20060129210723.61864.qmail@web32709.mail.mud.yahoo.com> Lol. --- todd wrote: > I suppose this would be a nice perk and a big > incentive to remove > crossedit, but you've quit so many times before that > it just isn't a > reliable enough promise to base a decision like this > on ;) > > > Miguel Ghobangieno wrote: > > >Understand this Yann. IF crossedit is removed I > remove > >myself. Do you want to lose your biggest current > media > >contributor? If so then remove crossedit. > > > >I think you need to fork off crossfire and make > your > >own project where you can do whatever you want. > >Perhapse crossfire-awsome.sf.net? > > > >--- Yann Chachkoff > >wrote: > > > > > > _______________________________________________ > crossfire mailing list > crossfire at 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 mikeeusaa at yahoo.com Sun Jan 29 16:59:07 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun, 29 Jan 2006 14:59:07 -0800 (PST) Subject: [crossfire] renaming binaries In-Reply-To: <43DD3FB4.4030909@sonic.net> Message-ID: <20060129225907.98990.qmail@web32709.mail.mud.yahoo.com> Check the CVS logs. I have stopped committing about a week ago. If you remove crossedit I will not restart. --- Mark Wedel wrote: > Miguel Ghobangieno wrote: > > Understand this Yann. IF crossedit is removed I > remove > > myself. Do you want to lose your biggest current > media > > contributor? If so then remove crossedit. > > I seem to see this ultimatum almost once a week > now (do this or I leave) > > This carries no weight for me. I'm not going to > program and make changes > based on what one person demands to be done. Maybe > you are the one that needs > to fork off crossfire for your own use so you can do > whatever you want with it. > > _______________________________________________ > crossfire mailing list > crossfire at 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 mikeeusaa at yahoo.com Sun Jan 29 17:59:44 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun, 29 Jan 2006 15:59:44 -0800 (PST) Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <43DD45C3.1020500@sonic.net> Message-ID: <20060129235944.96427.qmail@web32712.mail.mud.yahoo.com> Brace is used, as Leaf said before, to make it easier to swich deities without being pushed off the alter... this was allready discussed! We shouldn't do things that increase bandwidth usage... /me watches the bandwith usage skyrocket just to spite him. --- Mark Wedel wrote: > Brendan Lally wrote: > > > I would suggest then, in no particular order: > > > > * client side display of parties (so that they can > present an > > interface more like gcfclient2 has for the > metaserver, removing the > > need for using the rather complex party commands > directly). > > > > Yes - that sounds like a good idea. > > > * adding more stats, including a number that could > be considered as > > settings, so that clients can have a configure > menu for them (imagine > > having a 'server' tab next to the general, map, > and keybindings tabs > > in gcfclient) > > > > In order to do that, I think you would need to > send.... > > > > output-sync short (byte?) > > output-count byte > > I'd suggest the output-* stuff on the server > should go away. That was put in > before the client/server split IIRC. I think any > collapsing/discarding of > messages should just be done on the client. > > Granted, doing it on the server does save some > bandwidth, but I can't see that > as much an issue on current connections. > > > > bowmode byte mapped to associated requestinfo > > applymode byte mapped to associated requestinfo > > listen level byte > > is listen level really used much? I'd almost > suggest this go away also, but > right now, harder for the client to deal with it, > since it isn't getting message > levels. > > > petmode byte mapped to associated requestinfo > > usekeys byte mapped to associated requestinfo > > Yes, all the rest makes sense, and wouldn't be > hard to do at all. > > > * I'd also want to consider removing brace > altogether, or at least > > making it a flag in the stats so that it can be > displayed client side > > (hitting brace by accident and not being able to > move can be > > confusing). > > Brace could probably go away now. I believe there > are other ways to get the > same effect (ready melee weapon skill, and just fire > in that direction) > > _______________________________________________ > crossfire mailing list > crossfire at 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 mikeeusaa at yahoo.com Sun Jan 29 18:24:34 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun, 29 Jan 2006 16:24:34 -0800 (PST) Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <43DD45C3.1020500@sonic.net> Message-ID: <20060130002434.96103.qmail@web32704.mail.mud.yahoo.com> One of the things we should do for 2.0 (note: we are not yet at 1.9) is try to decrease bandwith usage. For instance, some animations are cylical, and the server knows which ones these are currently IIRC. The server shouldn't have to send a update for every tile every time for cylical animations, the client should beable to work this feat IMHO. Also if we can make some commands that are 4 bytes long (north south etc) or other longish commands shorter that might be good too. (We should keep backwards compat here maybe thought, so if a client says it's not 2.0+ it gets to use the old, easier to parse, stuff). Plots should go in at 1.9 I guess. Crossedit could be gtkized for 2.0. or after. (I'm not against updating crossedit, I am against removing it). Maybe some new spells too? Circular spells ect (kinda like a circle of protection of fireballs spining around you etc). __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From brenlally at gmail.com Sun Jan 29 20:04:50 2006 From: brenlally at gmail.com (Brendan Lally) Date: Mon, 30 Jan 2006 02:04:50 +0000 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <20060129235944.96427.qmail@web32712.mail.mud.yahoo.com> References: <43DD45C3.1020500@sonic.net> <20060129235944.96427.qmail@web32712.mail.mud.yahoo.com> Message-ID: <7903f03c0601291804m61e3fdbfh3bd82ad2c67033a2@mail.gmail.com> On 1/29/06, Miguel Ghobangieno wrote: > Brace is used, as Leaf said before, to make it easier > to swich deities without being pushed off the alter... > this was allready discussed! But since being pushed off the square is an intended effect, being able to brace to avoid that is probably a bug rather than an intended feature. From mikeeusaa at yahoo.com Sun Jan 29 21:28:33 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun, 29 Jan 2006 19:28:33 -0800 (PST) Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <7903f03c0601291804m61e3fdbfh3bd82ad2c67033a2@mail.gmail.com> Message-ID: <20060130032833.79473.qmail@web32703.mail.mud.yahoo.com> Well Leaf said that it was so that if someone really wanted to recant their diety that they could, but they would have to mean it (not by accident, or by mere trifiling whim) and thus brace. A question I have is does brace have any ill effects. EX: if you are on a mover, and brace, does that stop you from being moved. If so then... well that's not supposed to happen and brace seems like it needs work, if not then nm. --- Brendan Lally wrote: > On 1/29/06, Miguel Ghobangieno > wrote: > > Brace is used, as Leaf said before, to make it > easier > > to swich deities without being pushed off the > alter... > > this was allready discussed! > > But since being pushed off the square is an intended > effect, being > able to brace to avoid that is probably a bug rather > than an intended > feature. > > _______________________________________________ > crossfire mailing list > crossfire at 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 Jan 29 23:32:19 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 29 Jan 2006 21:32:19 -0800 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <20060130032833.79473.qmail@web32703.mail.mud.yahoo.com> References: <20060130032833.79473.qmail@web32703.mail.mud.yahoo.com> Message-ID: <43DDA4E3.1090000@sonic.net> Miguel Ghobangieno wrote: > Well Leaf said that it was so that if someone really > wanted to recant their diety that they could, but they > would have to mean it (not by accident, or by mere > trifiling whim) and thus brace. A question I have is > does brace have any ill effects. EX: if you are on a > mover, and brace, does that stop you from being moved. > If so then... well that's not supposed to happen and > brace seems like it needs work, if not then nm. I'd make the case that this should just be handled better, like if you pray over an altar to another god, you get a message like: You currently worship ... Changing gods will result in a loss of experience in the praying skill. Are you sure you want to do this (y/n)? This is one of those cases where hacks are currently in place - IIRC, there is a 1% chance when praying over the altar of a new god you won't get pushed off. This still means that occassionaly someone could be over an altar, pray (not intending to change gods) but hits that 1% chance when it doesn't push him off and thus change gods. The current method is to just repeat until you are not hit by that 1%, but that still seems like a bit of a hack. This could be changed without breaking any compatibility in clients, since it is just messages. That said, the current query status is IMO one of those things that could be done in a better fashion - currently, there is a ST_.. case statement with function to call. It would be much more flexible to convert that into callbacks. Eg, the function that prints out that message would do something like: set_reply_callback(change_god_confirmation, ...) Instead of having to set ST_ states. I think one reason there isn't much in the way of actual questions from the server because it really is a pain to set them up. From mwedel at sonic.net Sun Jan 29 23:40:45 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 29 Jan 2006 21:40:45 -0800 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <20060130002434.96103.qmail@web32704.mail.mud.yahoo.com> References: <20060130002434.96103.qmail@web32704.mail.mud.yahoo.com> Message-ID: <43DDA6DD.8060700@sonic.net> Miguel Ghobangieno wrote: > One of the things we should do for 2.0 (note: we are > not yet at 1.9) is try to decrease bandwith usage. For > instance, some animations are cylical, and the server > knows which ones these are currently IIRC. The server > shouldn't have to send a update for every tile every > time for cylical animations, the client should beable > to work this feat IMHO. I'll probably throw out a 1.9 release in the next few weeks. I do plan to work on the map2 command in that not too distant future (really!). Part of that is to let the client do animations. That said, that isn't a huge bandwidth hog. > > Also if we can make some commands that are 4 bytes > long (north south etc) or other longish commands > shorter that might be good too. (We should keep > backwards compat here maybe thought, so if a client > says it's not 2.0+ it gets to use the old, easier to > parse, stuff). IMO, the client->server communications isn't an issue. Even at say 10 bytes/command, and doing 10 commands/second, that is 100 bytes per second. A 2400 baud modem can cover that. This issue is really the server->client direction, and that already is binary, so not a whole bunch of savings. I have a feeling the big hog is the map data - things like stats is never much. The item stuff, especially for huge piles, can add up. And I think someone suggested that the detailed item information (what you get from describe item) is also sent along - I think that may be a reasonable idea, but does increase the bandwidth on that (that is also tricky in that certain things could change the description of the item (it being identified will change its value for example) - I'm not 100% the UPD_ flags cover that, but probably do (but money will always be suspect - changing charisma can affect costs also). It _may_ be reasonable to compress the map data if that packet was big enough (there would need to be a new command, like: S->C: cdata And after the client gets the data, it then uncompresses it and then runs the commands from it. But to do that, requires some reworking - ideally, you would want to queue all the data that the server is about to send to the client during the activity tick, and then after that, go and compress the data and send it along. This actually wouldn't be that hard. However, it does make a tradeoff of CPU consumption (on the server to compress it) vs bandwidth. From mwedel at sonic.net Mon Jan 30 00:15:00 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 29 Jan 2006 22:15:00 -0800 Subject: [crossfire] move_allow attribute Message-ID: <43DDAEE4.40404@sonic.net> Thinking a little little about transportation objects (boats, horses, etc) and came to the realization that at some level, a move_allow field is needed. The basic idea is that move_allow would override any move_block. The case I'm thinking about here is boats - players normally can't move on the water. While the move_block of the water spaces for boats in harbor could be changed so you could get on the boat, this doesn't work so well if you anchor your boat at some island. The code to handle this would actually be fairly trivial - basically, in the update position, move_block &= ~move_allow This also allows for some other interesting things. For example, one could imagine creating a 'bridge' spell that goes over water - basically, it just acts like a wall spell, but has move_allow WALK on it. Passwall (letting you put holes in walls) would be another case. One question would be on how to handle slow_move attributes - should those get blanked out also. I'm sort of thinking yes - then you could also have a 'create road' spell to get through the jungle quickly. Thoughts? Questions? From alex_sch at telus.net Mon Jan 30 10:16:04 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 30 Jan 2006 09:16:04 -0700 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <43DDA6DD.8060700@sonic.net> References: <20060130002434.96103.qmail@web32704.mail.mud.yahoo.com> <43DDA6DD.8060700@sonic.net> Message-ID: <43DE3BC4.4020309@telus.net> Mark Wedel wrote: > This issue is really the server->client direction, and that already is binary, >so not a whole bunch of savings. > > I have a feeling the big hog is the map data - things like stats is never >much. The item stuff, especially for huge piles, can add up. And I think >someone suggested that the detailed item information (what you get from describe >item) is also sent along - I think that may be a reasonable idea, but does >increase the bandwidth on that (that is also tricky in that certain things could >change the description of the item (it being identified will change its value >for example) - I'm not 100% the UPD_ flags cover that, but probably do (but >money will always be suspect - changing charisma can affect costs also). > What would also save alot of bandwidth, would be including in the new server protocol a method of sending rectangular blocks of tiles that should all be added of deleted. This could potentially cut the map bandwidth in half or less in some locations (lots of floor and walls compared to everything else). Making the client interperate the data for that would be very easy, the most difficult part would be the server logic of where it should define rectangles but I am sure that is not too bad. I put up a couple ideas about the new map protocol here a while back: http://wiki.metalforge.net/doku.php/dev_todo/newmapprotocol (see also http://wiki.metalforge.net/doku.php/dev_todo and http://wiki.metalforge.net/doku.php/dev_todo/cf2.0 on the wiki) Alex Schultz From mikeeusaa at yahoo.com Mon Jan 30 01:15:42 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun, 29 Jan 2006 23:15:42 -0800 (PST) Subject: [crossfire] Crossfire 2.0+ features/priorities (compression) In-Reply-To: <43DDA6DD.8060700@sonic.net> Message-ID: <20060130071542.62674.qmail@web32713.mail.mud.yahoo.com> A server variable could be set that turns on/off compression. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaa at yahoo.com Mon Jan 30 01:19:34 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Sun, 29 Jan 2006 23:19:34 -0800 (PST) Subject: [crossfire] move_allow attribute In-Reply-To: <43DDAEE4.40404@sonic.net> Message-ID: <20060130071934.41012.qmail@web32702.mail.mud.yahoo.com> I like this idea very much (though I would caution against giving players themselves a pass wall spell), I creates a granular permissions system that is appealing. --- Mark Wedel wrote: > > Thinking a little little about transportation > objects (boats, horses, etc) and > came to the realization that at some level, a > move_allow field is needed. > > The basic idea is that move_allow would override > any move_block. The case I'm > thinking about here is boats - players normally > can't move on the water. While > the move_block of the water spaces for boats in > harbor could be changed so you > could get on the boat, this doesn't work so well if > you anchor your boat at some > island. > > The code to handle this would actually be fairly > trivial - basically, in the > update position, move_block &= ~move_allow > > This also allows for some other interesting > things. > > For example, one could imagine creating a 'bridge' > spell that goes over water > - basically, it just acts like a wall spell, but has > move_allow WALK on it. > > Passwall (letting you put holes in walls) would be > another case. > > One question would be on how to handle slow_move > attributes - should those get > blanked out also. I'm sort of thinking yes - then > you could also have a 'create > road' spell to get through the jungle quickly. > > Thoughts? Questions? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From antonoussik at gmail.com Mon Jan 30 14:07:43 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Mon, 30 Jan 2006 20:07:43 +0000 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <43DD43FF.908@sonic.net> References: <1138523515.c7eefbdcyann.chachkoff@myrealbox.com> <43DD43FF.908@sonic.net> Message-ID: On 29/01/06, Mark Wedel wrote: > One of the things that have been on my wishlist a long time is a better > character creation method. I'd say that a character creation window would work best - where you can select the name, roll and re-roll stats, chose your race, sex, and class, and see how it changes your character (as well as seeing how the character looks themselves). Race/Class descriptions can then go into textboxes under pulldown selection controls, and starting items/skills should be viewable. Another thing I can propose is to replace the listen level with channels, and be able to toggle/redirect individual channels between different tabs in the client. From brenlally at gmail.com Mon Jan 30 16:18:16 2006 From: brenlally at gmail.com (Brendan Lally) Date: Mon, 30 Jan 2006 22:18:16 +0000 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: References: <1138523515.c7eefbdcyann.chachkoff@myrealbox.com> <43DD43FF.908@sonic.net> Message-ID: <7903f03c0601301418m5e631f2cm8420f729ccbfb6eb@mail.gmail.com> On 1/30/06, Anton Oussik wrote: > Another thing I can propose is to replace the listen level with > channels, and be able to toggle/redirect individual channels between > different tabs in the client. I had a working channels implemention, but the problem was that it was too complex to be really usable, and seemed too similar to the party code. hijacking colours in the draw_info packet to send meaningful data about the type of draw_info would be more reasonable Maybe also it would be an interesting idea to have a 'triggered' draw_info which would send back the packet number that caused them to be printed (this would involve storing the last packet number in the player struct, and sending it in the packet) From alex_sch at telus.net Mon Jan 30 17:28:29 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 30 Jan 2006 16:28:29 -0700 Subject: [crossfire] Crossfire 2.0+ features/priorities (compression) In-Reply-To: <20060130071542.62674.qmail@web32713.mail.mud.yahoo.com> References: <20060130071542.62674.qmail@web32713.mail.mud.yahoo.com> Message-ID: <43DEA11D.5050603@telus.net> Miguel Ghobangieno wrote: >A server variable could be set that turns on/off >compression. > This is a good point, it would allow servers to balance bandwidth and processor usage on the server side better if the are short on one but not the other. Alex Schultz From alex_sch at telus.net Mon Jan 30 17:33:19 2006 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 30 Jan 2006 16:33:19 -0700 Subject: [crossfire] move_allow attribute In-Reply-To: <20060130071934.41012.qmail@web32702.mail.mud.yahoo.com> References: <20060130071934.41012.qmail@web32702.mail.mud.yahoo.com> Message-ID: <43DEA23F.2020502@telus.net> Miguel Ghobangieno wrote: >(though I would caution against giving players themselves a pass wall spell) > As I understand it, with what Mark is saying, walls would have to explicitly be set to allow passwall. Alex Schultz From leaf at real-time.com Mon Jan 30 18:20:48 2006 From: leaf at real-time.com (Rick Tanner) Date: Mon, 30 Jan 2006 18:20:48 -0600 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <20060130032833.79473.qmail@web32703.mail.mud.yahoo.com> References: <20060130032833.79473.qmail@web32703.mail.mud.yahoo.com> Message-ID: <43DEAD60.2080000@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Miguel Ghobangieno wrote: > Well Leaf said that it was so that if someone really > wanted to recant their diety that they could, but they > would have to mean it (not by accident, or by mere > trifiling whim) and thus brace. Actually, I pointed out how the brace command *can* be used when switching cults during a discussion[1] of removing the command because it offered little or no benefit for using it. [1] - http://forum.metalforge.net/viewtopic.php?p=9535#9535 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD3q1ghHyvgBp+vH4RAtE3AJ9TirT0cTwj3+5tSuZgtcmH9C2r0gCfcGQU kt9rlYbH/7UPLeUD+uyxei8= =8P5B -----END PGP SIGNATURE----- From leaf at real-time.com Mon Jan 30 18:29:57 2006 From: leaf at real-time.com (Rick Tanner) Date: Mon, 30 Jan 2006 18:29:57 -0600 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <20060130002434.96103.qmail@web32704.mail.mud.yahoo.com> References: <20060130002434.96103.qmail@web32704.mail.mud.yahoo.com> Message-ID: <43DEAF85.5070508@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Miguel Ghobangieno wrote: > > Maybe some new spells too? Circular spells ect (kinda > like a circle of protection of fireballs spining > around you etc). This "effect" is already possible (and probably unintentionally, too) by using the "stay fire" command. NOTE: I /think/ the stay fire sequence is used, but it's been years(!) since I bound this to my key settings. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD3q+FhHyvgBp+vH4RAigXAKC9X0u0chR8f9aEcDYk5modvYDB0gCePVVm tkB0XDttxy7QyYq7we4Q3qw= =MWhv -----END PGP SIGNATURE----- From mikeeusaa at yahoo.com Mon Jan 30 12:27:20 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon, 30 Jan 2006 10:27:20 -0800 (PST) Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <43DE3BC4.4020309@telus.net> Message-ID: <20060130182720.60164.qmail@web32701.mail.mud.yahoo.com> This is a good idea. If there is a 100x100 (or 100x50 etc) block of completely identical archtypes (and the player is in LOS range of these (they are not behind a wall), we don't want to send the whole map to him, then the server could send something like (100x100 of flagstone starting at bla bla). --- Alex Schultz wrote: > Mark Wedel wrote: > > > This issue is really the server->client > direction, and that already is binary, > >so not a whole bunch of savings. > > > > I have a feeling the big hog is the map data - > things like stats is never > >much. The item stuff, especially for huge piles, > can add up. And I think > >someone suggested that the detailed item > information (what you get from describe > >item) is also sent along - I think that may be a > reasonable idea, but does > >increase the bandwidth on that (that is also tricky > in that certain things could > >change the description of the item (it being > identified will change its value > >for example) - I'm not 100% the UPD_ flags cover > that, but probably do (but > >money will always be suspect - changing charisma > can affect costs also). > > > What would also save alot of bandwidth, would be > including in the new > server protocol a method of sending rectangular > blocks of tiles that > should all be added of deleted. This could > potentially cut the map > bandwidth in half or less in some locations (lots of > floor and walls > compared to everything else). Making the client > interperate the data for > that would be very easy, the most difficult part > would be the server > logic of where it should define rectangles but I am > sure that is not too > bad. > I put up a couple ideas about the new map protocol > here a while back: > http://wiki.metalforge.net/doku.php/dev_todo/newmapprotocol > (see also > http://wiki.metalforge.net/doku.php/dev_todo and > http://wiki.metalforge.net/doku.php/dev_todo/cf2.0 > on the wiki) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaa at yahoo.com Mon Jan 30 18:26:33 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon, 30 Jan 2006 16:26:33 -0800 (PST) Subject: [crossfire] move_allow attribute In-Reply-To: <43DEA23F.2020502@telus.net> Message-ID: <20060131002633.84884.qmail@web32715.mail.mud.yahoo.com> move_allow * would just add some more control over movement permissions so that one can more easily set what cannot and what can pass over the tile; more granularity. Theoretically, after this is added, spells can be created (such as build bridge, which could set move_allow walk on the affected water tiles and then spawn brige arches forward (if spells were allowed on said tiles ofcourse) that can use modify permissions. I would suggest, however, that (specifically) a passwall spell not be given to players (could be used in fire-walls for some things though etc). --- Alex Schultz wrote: > Miguel Ghobangieno wrote: > > >(though I would caution against giving players > themselves a pass wall spell) > > > As I understand it, with what Mark is saying, walls > would have to > explicitly be set to allow passwall. > > Alex Schultz > > _______________________________________________ > crossfire mailing list > crossfire at 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 brenlally at gmail.com Mon Jan 30 20:49:57 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue, 31 Jan 2006 02:49:57 +0000 Subject: [crossfire] cfclient colouring (was: gcfclient options deathlist) Message-ID: <7903f03c0601301849n395753er7cbc61623ff0df36@mail.gmail.com> On 1/17/06, Brendan Lally wrote: > (on) Colored Inventory Lists > (on) Colored Information Text - maybe to be replaced by some future feature > (off) Print Grid Overlay > (on) Cache Images > (on) splash window (gros' suggestion) it has been two weeks since this list was first posted, I have completed the first patch to take out the first two of these (coloured inventory lists, and coloured text) I'm posting about this explicitly here because to cleanly remove them has one side effect, and one potentially controversial bugfix which is related to it. The side-effect of this patch is to remove all special code in cfclient for dealing with black and white monitors, it should cause them to now try and display identically to a colour monitor, without several extra hacks in various places. The bugfix concerns the colours which cfclient uses to display itself. All the colours gcfclient uses are from the 16 that are also sent by the server as possible text colours (I haven't touched support for ega graphics displays, they should still work fine). However, the colour used by cfclient for its background - light green, is also used for some dm-activity related commands by the server. This causes cfclient to print these in the same colour as the background. In order to resolve this, I changed the background colour to 9 (grey), which is only used by one polymorph message, which can not be called anyway. I then adjusted the shade of grey to make the text stand out better. The result can be seen at http://cavetroll.uwcs.co.uk/cfclient-grey1.png if it is felt that this new colouring is a bad move, it would be quite possible to remap the colours assigned to various colour numbers - likewise if it is felt that an alternative colour would be a better choice. In any case since this is a very obvious change in the look and feel of cfclient I felt a message such as this to be necessary, From mwedel at sonic.net Tue Jan 31 00:18:22 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 30 Jan 2006 22:18:22 -0800 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <7903f03c0601301418m5e631f2cm8420f729ccbfb6eb@mail.gmail.com> References: <1138523515.c7eefbdcyann.chachkoff@myrealbox.com> <43DD43FF.908@sonic.net> <7903f03c0601301418m5e631f2cm8420f729ccbfb6eb@mail.gmail.com> Message-ID: <43DF012E.70609@sonic.net> Brendan Lally wrote: > On 1/30/06, Anton Oussik wrote: >> Another thing I can propose is to replace the listen level with >> channels, and be able to toggle/redirect individual channels between >> different tabs in the client. > > I had a working channels implemention, but the problem was that it was > too complex to be really usable, and seemed too similar to the party > code. > > hijacking colours in the draw_info packet to send meaningful data > about the type of draw_info would be more reasonable > > Maybe also it would be an interesting idea to have a 'triggered' > draw_info which would send back the packet number that caused them to > be printed (this would involve storing the last packet number in the > player struct, and sending it in the packet) Long on my wish list also was to change handling of messages (draw_info) to change from color to tags that denote what the message pertains to. Eg, combat messages, listings (shop, who, etc), shout, talk, etc. I think there would probably be about a dozen different content types. The client could then have a pretty easy interface to say what to do with the message (discard, print in window 1, window 2). Also, let the player choose the color/font for these. This adds some amount of complication to the client. But a first pass is to just update all the draw_info to use new flags. A first pass on the client would be something simple like 'shout - ok, these are red, and put in window 2' - basically be hardcoded to how it works now, with the interface to follow, since that is probably the harder part. From mwedel at sonic.net Tue Jan 31 00:32:04 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 30 Jan 2006 22:32:04 -0800 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <43DE3BC4.4020309@telus.net> References: <20060130002434.96103.qmail@web32704.mail.mud.yahoo.com> <43DDA6DD.8060700@sonic.net> <43DE3BC4.4020309@telus.net> Message-ID: <43DF0464.7070909@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: > >> This issue is really the server->client direction, and that already is binary, >> so not a whole bunch of savings. >> >> I have a feeling the big hog is the map data - things like stats is never >> much. The item stuff, especially for huge piles, can add up. And I think >> someone suggested that the detailed item information (what you get from describe >> item) is also sent along - I think that may be a reasonable idea, but does >> increase the bandwidth on that (that is also tricky in that certain things could >> change the description of the item (it being identified will change its value >> for example) - I'm not 100% the UPD_ flags cover that, but probably do (but >> money will always be suspect - changing charisma can affect costs also). >> > What would also save alot of bandwidth, would be including in the new > server protocol a method of sending rectangular blocks of tiles that > should all be added of deleted. This could potentially cut the map > bandwidth in half or less in some locations (lots of floor and walls > compared to everything else). Making the client interperate the data for > that would be very easy, the most difficult part would be the server > logic of where it should define rectangles but I am sure that is not too > bad. It could be done now, but could prove to be a costly (CPU wise) operation - the map code would have to look to see if there are such regions. There may be fast ways to do that. But you also get the cases that you need to check to see if it is faster to send that block. a 2 square rectangle is not going to be any faster than just sending it as two spaces. a 3 space block may be the break even point. But it also gets tricky - having a 10x10 area of floor with nothing on it, it would be a clear win. But if that floor is littered with monsters, objects, etc, it becomes less clear, because we're going to need to send data on those spaces, so we are not saving the cost of sending the coordinates, just the cost of sending the face itself. I'm more inclined to just go with the compression method - if the same face is repeated 200 times, the compress code should do a good job of reducing that to very little space. And I think this may actually be less cpu costly than trying to find rectangles. It also helps for those cases where we are sending data that does not encompass the entire range of data size. For example, we use 16 bits to send the face data. Yet right now, we only have 5000 faces, which can fit in 13 bits. So going through compression would still save space even on maps without good rectangles. > I put up a couple ideas about the new map protocol here a while back: > http://wiki.metalforge.net/doku.php/dev_todo/newmapprotocol > (see also http://wiki.metalforge.net/doku.php/dev_todo and > http://wiki.metalforge.net/doku.php/dev_todo/cf2.0 on the wiki) > > Alex Schultz > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Tue Jan 31 00:41:18 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 30 Jan 2006 22:41:18 -0800 Subject: [crossfire] move_allow attribute In-Reply-To: <20060131002633.84884.qmail@web32715.mail.mud.yahoo.com> References: <20060131002633.84884.qmail@web32715.mail.mud.yahoo.com> Message-ID: <43DF068E.9020309@sonic.net> Miguel Ghobangieno wrote: > move_allow * would just add some more control over > movement permissions so that one can more easily set > what cannot and what can pass over the tile; more > granularity. > > Theoretically, after this is added, spells can be > created (such as build bridge, which could set > move_allow walk on the affected water tiles and then > spawn brige arches forward (if spells were allowed on > said tiles ofcourse) that can use modify permissions. > I would suggest, however, that (specifically) a > passwall spell not be given to players (could be used > in fire-walls for some things though etc). Yes - that is basically correct. For things like water, this could be more easily done in existing code - water would allow swimming and/or boat movement. So if the spell in question had the move_type of swimming, it could move over the water and create the bridge. But right now, walls block everything. So by default, as the code is now, the spell can't move onto the wall to create the hole. So if someone was to write it, they would have to change pieces of code to currently ignore the current move block logic. This could change if we add a movement type of ETHEREAL or the like (giving it to ghosts would be interesting) - the spell could be given the ethereal movement type to let is go through the walls to create the tunnels. That said, any such change would have to be carefully considered, as it could ruin many maps (or the default behavior be that walls continue to block everything by default) From mwedel at sonic.net Tue Jan 31 00:47:31 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 30 Jan 2006 22:47:31 -0800 Subject: [crossfire] cfclient colouring (was: gcfclient options deathlist) In-Reply-To: <7903f03c0601301849n395753er7cbc61623ff0df36@mail.gmail.com> References: <7903f03c0601301849n395753er7cbc61623ff0df36@mail.gmail.com> Message-ID: <43DF0803.4060203@sonic.net> I'd personally say that requiring a 256 color display isn't asking too much now days. Yes, in the old days, black and white monitors and workstations were somewhat common, and given crossfire was a unix game, made sense to accomodate them But 8 bit color has been around for a long time - I don't know the last system manufactured that only had black and white output. I actually think the grey background looks nicer than the old dark green background. From mwedel at sonic.net Tue Jan 31 02:18:03 2006 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 31 Jan 2006 00:18:03 -0800 Subject: [crossfire] Transports Message-ID: <43DF1D3B.2000302@sonic.net> Below is my propose implementation for tranports (boats, horses, wagons, etc). Look it over and let me know any questions/improvements, etc. Tranports are objects that help the player move. These should not be confused with EXITS, which instaneously transport a player from one map to another. Instead, tranports may let the player move faster, give them move types they don't have, etc. A simple example of this would a horse. It doesn't let the player move anyplace he normally couldn't go, but lets him get there faster. Ships would be another case - the player normally can't move accross water, but with a ship, he can. Meaning of various object attributes (KV means the value is stored in the key/value list, and thus the get_ob_key_value() and set_ob_key_value() routines need to be used. move_type The move type this object has. move_allow Normal meanings - useful for things like boats so people can actually get on the boat. speed How fast the object moves weight_limit How much this object can carry. weight_speed_ratio (KV) This value is taken as a percentage which is multiplied against against the weight this object is carrying (the player) - this is then divided by weight_limit to determine the effective loading to determine effective object speed, eg: speed = base_speed - (base_speed * pl->weight * weight_speed_ratio) / (weight_limit * 100) Thus, if weight_factor is 0, this object will move the same speed no matter how loaded it is. If it is 100, then if the transport is fully loaded, it moves at a crawl. In a sense, this somewhat mimics the player movement speed. Large transports, like boats, should likely be largely unaffected by weight (maybe have this value at 10), where something like a horse would have a relatively high value. base_speed(KV) This is only needed if weight_speed_ratio is set - it is used to know what the base speed to use in the calculation (since speed is getting clobbered). If this is not set and weight_speed_ratio is set, the archetypes speed will be used. passenger_limit(KV) How many players this transport can hold. Thus, boats can transport a party (this being set to 6) while horses could only transport a single person. If this is not set, a default of 1 will be used. face_full It may be desirable to have different faces to denote what the tranport looks like if someone is on it vs not (mounted horse vs just a horse). This is used to denote what it will look like when loaded. If the tranport becomes empty, it will fall back to the archetype face. anim_full Like face_full above, but for animated objects. Usage/implementation details: To activate a transport, the player will stop onto it and 'board' it. When this is done, the transports op->contr will point to the player, and a pl->transport pointer will be set up. An 'unboard' command will be needed to leave the transport (thoughts on a better way to deal with this?) I don't think apply will work because that will be needed to get stuff in/out of it like a container. For transports that hold multiple people, the first person to apply the transport becomes the captain. It is this person that decides where the transport goes. Transports to some extent will appear as containers - thus you could load stuff onto(into) the transport without having to be able to carry it all - imagine wagons that carry 10,000. When aboard a transport, the player will be in the inventory of the transport. Thus, the players movement/speed doesn't play any role. In this implementation, transports don't attack or defend, and thus don't take damage. If something damages items on the space (say spikes), it will damage the player(s) and not the transport. Thus, transports can't be used to avoid traps and the like. Thoughts/questions? From lalo.martins at gmail.com Tue Jan 31 02:42:57 2006 From: lalo.martins at gmail.com (Lalo Martins) Date: Tue, 31 Jan 2006 16:42:57 +0800 Subject: [crossfire] On moving the Lone Town apartment [bigworldized pupland] In-Reply-To: <200601201047.00674.eracclists@bellsouth.net> References: <20060118000514.68199.qmail@web32707.mail.mud.yahoo.com> <200601201047.00674.eracclists@bellsouth.net> Message-ID: And so says ERACC on 21/01/06 00:46... > Lalo? Are you there? I would like to know how this is progressing and > when you think you will have it done. I'm sorry, I was off-net when this discussion happened. Continental Pupland is about halfway there, if you want to help, poke me on IRC. The islands will wait till after mainland is merged. Personally, I don't have a problem with the Lone Town apartments. The war hasn't been going on for long - and if there was a property this size in the town, they would probably find a way to sell/rent it to a rich foreigner to raise money for the cause. You could rename it, if you wish. "Private villa" or something. But I don't see a reason to move it. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ From antonoussik at gmail.com Tue Jan 31 05:19:22 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Tue, 31 Jan 2006 11:19:22 +0000 Subject: [crossfire] Transports In-Reply-To: <43DF1D3B.2000302@sonic.net> References: <43DF1D3B.2000302@sonic.net> Message-ID: On 31/01/06, Mark Wedel wrote: > When aboard a transport, the player will be in the inventory of the transport. I would say that transport should also point to a map containing the inside of the transport. Therefore two actions are requared as regards to a transport: "enter" it, and "drive" it. Only the owner should be able to drive the transport, but anyone in the same party should be able to enter it. This way a transport ship or a cart will be able to transport people and goods. This would not make much sense for a horse or a dragon though, which would not be able to carry goods, but be only used to transport the owner. From alex_sch at telus.net Tue Jan 31 07:49:26 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 31 Jan 2006 06:49:26 -0700 Subject: [crossfire] Transports In-Reply-To: <43DF1D3B.2000302@sonic.net> References: <43DF1D3B.2000302@sonic.net> Message-ID: <43DF6AE6.1020002@telus.net> Mark Wedel wrote: > Below is my propose implementation for tranports (boats, horses, wagons, etc). > Look it over and let me know any questions/improvements, etc. > > > > Thoughts/questions? > Well, for it to be more useful, it would be good if it could go through exits (scorn gatehouse). However this leads to questions like: What should the transports do on non-bigworld maps? (wagons could easily appear too small) And what should be done to prevent you from running around shops in a wagon? Such things incline me to want to disallow them from going through exits, though that in my opinion makes them more limited in usefulness too. Alex Schultz From brenlally at gmail.com Tue Jan 31 08:32:52 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue, 31 Jan 2006 14:32:52 +0000 Subject: [crossfire] Transports In-Reply-To: <43DF6AE6.1020002@telus.net> References: <43DF1D3B.2000302@sonic.net> <43DF6AE6.1020002@telus.net> Message-ID: <7903f03c0601310632k6caeb898yf545f315523ecd@mail.gmail.com> On 1/31/06, Alex Schultz wrote: > Such things incline me to want to disallow them from going through > exits, though that in my opinion makes them more limited in usefulness too. Can exits use the move allow/block idea too? if so, you could look at them to decide whether a transport can go through an exit or not. From brenlally at gmail.com Tue Jan 31 08:37:29 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue, 31 Jan 2006 14:37:29 +0000 Subject: [crossfire] Transports In-Reply-To: <43DF1D3B.2000302@sonic.net> References: <43DF1D3B.2000302@sonic.net> Message-ID: <7903f03c0601310637n7960ed2s8a8da6cbb63cf1c6@mail.gmail.com> On 1/31/06, Mark Wedel wrote: > Usage/implementation details: > To activate a transport, the player will stop onto it and 'board' it. When this > is done, the transports op->contr will point to the player, and a > pl->transport pointer will be set up. An 'unboard' command will be needed > to leave the transport (thoughts on a better way to deal with this?) > I don't think apply will work because that will be needed to get stuff in/out > of it like a container. what's wrong with pickup? If I follow the description properly, this transport will stop most of the items on the ground being useful once you are inside it anyway, so you could send as the ground view a single item such as 'get off horse' 'dismount ship' (this requires a new K-V (onboard name). Picking up this item should then dismount from the transport. From brenlally at gmail.com Tue Jan 31 08:31:08 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue, 31 Jan 2006 14:31:08 +0000 Subject: [crossfire] cfclient colouring (was: gcfclient options deathlist) In-Reply-To: <43DF0803.4060203@sonic.net> References: <7903f03c0601301849n395753er7cbc61623ff0df36@mail.gmail.com> <43DF0803.4060203@sonic.net> Message-ID: <7903f03c0601310631n31fcaf8bl5f61678ae181283f@mail.gmail.com> On 1/31/06, Mark Wedel wrote: > > I'd personally say that requiring a 256 color display isn't asking too much > now days. I'm inclined to agree, I just don't know xlibs well enough to break support for 16 colour displays in a non-hacky way. (there is still some 'private colourmap' stuff, which I think is somehow related to that) > I actually think the grey background looks nicer than the old dark green > background. excellent, I've commited the patch. From brenlally at gmail.com Tue Jan 31 09:51:50 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue, 31 Jan 2006 15:51:50 +0000 Subject: [crossfire] crossfire traffic Message-ID: <7903f03c0601310751w66491ebtd011ac1f45a3112a@mail.gmail.com> One of the recurring things with crossfire is that it is often a long time before new features are noticed or utilised properly, if at all. I consider that this might be because there is no real form of public communication from this project to the outside world. In order to rectify this, I have attempted to create something I am provisionally calling 'crossfire traffic', it's aim is roughly the same as that of KDE's 'this month in svn' or 'kernel traffic'. - to summarise activity in a way that is understandable to someone who hasn't followed this project previously. I have created a prototype version for january, which found below: if it is felt that this is a good approach to presenting this information, then I'll create a wiki page to hold the data for febuary, and combine it at the end of that month into a similar form. I'd like to think that this could become effectively a sort of press release, a monthly showcase for the activity that has been ongoing within the crossfire development community (as well as a regular source of news for crossfire.real-time.com). Future versions then could include the wider player community, I'd like to see details about server updates and settings changes there too, (at the moment this information is not really available in any reliable way, I know that bratwurst updated last night, but only because the server admin mentioned it on IRC). NB: I know this list is probably incomplete, future versions, should this idea be approved, would have data dumped in the wiki, I have almost certainly missed some things doing this on my own. However I hope that it will serve as a proof of concept. ======= This is crossfire traffic for January 2006 Crossfire Traffic is a new attempt to create a means to communicate the activity surrounding crossfire in an accessible and non-technical way, it is targeted at those who are curious about what is happening with the project, but find the existing mailing lists, CVS list. forum, wiki and IRC channels overly complicated, scary, or time consuming to read. As such it does not contain any background details, but instead focuses only on things that are or would be visible to those playing. On the mailing lists this month (these are ongoing topics of discussion, issues that were resolved/implemented are in the Changes section below): This month has seen more traffic on the crossfire-devel list than there has been for almost 3 years. The main topics of discussion: * Modularising the server to allow internal plug-in like behaviour for objects and other parts of the code. * A new banner proposed for use throughout the crossfire project, it can currently be seen at http://crossfire.real-time.com/demo/ * Reducing lag, and possible designs to deal with that. * Move allow, as a way to counter move_block, and designs for transports (horses, boats, etc) * A general call for feature requests for crossfire 2.0, which is now being tracked by the wiki: http://wiki.metalforge.net/doku.php/dev_todo/cf2.0 * Renaming the binaries that crossfire uses, and whether to have a deliberate compatibility break for 2.0 * Efforts to move pupland into the world map, concerns over the effect this would have on the weather system. * Possible changes to the banking and currancy system, including debit cards and higher denomination coinage. * A question about how to have objects do damage to a player when held. Changes that occurred this month: Gameplay: * marking an item will now make the throwing skill throw that in preference to any other object. * summoned pets won't teleport about so much on tiled maps anymore. * servers can now disable stealing from other players * spells work better in large areas. * all orcknuckle messages now appear in the same place * forked lightning will fork properly again. * magic walls should work again. * servers can now send lists of spells to clients that can choose how to display them. * A server will now drop your connection if you fail to enter the correct password too many times in a row. You will be able reconnect again, this is just to prevent any scripted brute force password attempts. In Bigworld: * zorn's castle has increased in size. * darcap has a new style of architecture * shops in brest have some new doors * navar has a prison of its own * The dragon hanger network now extends to Nurnberg * The easternmost dragon at pupland terminal will take players to Nurnberg * The Forgotten town access pass in darcap works again. * Lone town is now being served by the Imperial Post Office. * There are now animating chandaliers * New Floor types, red marble, white and red inlaid marble and white and pink inlaid marble new monster: * garden gnome new items: - look out for these as you play. * pink roses * black roses * zinc * uranium * uranium bar * uranium hexafloride * uranium oxide * graphite * steel bars * hooksword * nine ring sword * butterfly sword * sickle sword * cudgel * hanging firepot Clients: - You will need to update your client to see the effect of these. jxclient: * works better with java 1.5 * fixed a panel display bug * fixed opening containers * reduce flickering in map display * initial support for client-side scripts * spell description panel added cfclient: * will now work for anyone running on a 64-bit processor * no longer has a special mode for anyone running with a black & white monitor. * is now a grey colour rather than its previous green. gcfclient: * close button is greyed out when it won't do anything * skills display in a scroll pane * a list of known spells can be shown on servers that support it by selecting 'Spells' from the client menu * The options window has been simplified and no longer has coloured inventory and coloured text as options gcfclient2: * fix some OpenGL issues. From mikeeusaa at yahoo.com Mon Jan 30 19:55:15 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Mon, 30 Jan 2006 17:55:15 -0800 (PST) Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <43DEAF85.5070508@real-time.com> Message-ID: <20060131015515.30122.qmail@web32711.mail.mud.yahoo.com> That wouldn't cause the fireballs to spin around you (nor in a true circle, rather the stay fire effect causes a box of (spell) to eminate in all directions instead (wall spells don't work at all)). --- Rick Tanner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Miguel Ghobangieno wrote: > > > > Maybe some new spells too? Circular spells ect > (kinda > > like a circle of protection of fireballs spining > > around you etc). > > This "effect" is already possible (and probably > unintentionally, too) by > using the "stay fire" command. > > > NOTE: I /think/ the stay fire sequence is used, but > it's been years(!) > since I bound this to my key settings. > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - > http://enigmail.mozdev.org > > iD8DBQFD3q+FhHyvgBp+vH4RAigXAKC9X0u0chR8f9aEcDYk5modvYDB0gCePVVm > tkB0XDttxy7QyYq7we4Q3qw= > =MWhv > -----END PGP SIGNATURE----- > > _______________________________________________ > crossfire mailing list > crossfire at 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 mikeeusaa at yahoo.com Tue Jan 31 05:05:44 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue, 31 Jan 2006 03:05:44 -0800 (PST) Subject: [crossfire] Transports In-Reply-To: <43DF1D3B.2000302@sonic.net> Message-ID: <20060131110544.66056.qmail@web32703.mail.mud.yahoo.com> Perhaps both the player and the transport should be damaged? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From antonoussik at gmail.com Tue Jan 31 16:23:30 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Tue, 31 Jan 2006 22:23:30 +0000 Subject: [crossfire] crossfire traffic In-Reply-To: <7903f03c0601310751w66491ebtd011ac1f45a3112a@mail.gmail.com> References: <7903f03c0601310751w66491ebtd011ac1f45a3112a@mail.gmail.com> Message-ID: Great idea! Now make the URL to that widely known, and easily findable, so the user base will easily find it. From brenlally at gmail.com Tue Jan 31 16:35:40 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue, 31 Jan 2006 22:35:40 +0000 Subject: [crossfire] crossfire traffic In-Reply-To: References: <7903f03c0601310751w66491ebtd011ac1f45a3112a@mail.gmail.com> Message-ID: <7903f03c0601311435n39983eueaa9698a01e72603@mail.gmail.com> On 1/31/06, Anton Oussik wrote: > Great idea! Now make the URL to that widely known, and easily > findable, so the user base will easily find it. well, I think that if any future versions of these were to be posted onto the crossfire.real-time.com website (ideally on seperate pages with an archive, and a permenent link in the news/updates box on the front page), and onto the cfmb, with the topic on #crossfire also linking to the most recent cf-rt.com copy, then it should be easy enough to find. Possibly they could also be posted to the announcements mailing list, and as news items on the sourceforge project page? - It would then become quite hard to miss them. From antonoussik at gmail.com Tue Jan 31 16:44:13 2006 From: antonoussik at gmail.com (Anton Oussik) Date: Tue, 31 Jan 2006 22:44:13 +0000 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: <7903f03c0601290420x2a1eae8fpe3a7c919d2b2f5bb@mail.gmail.com> References: <43DC4B0A.8030808@sonic.net> <7903f03c0601290420x2a1eae8fpe3a7c919d2b2f5bb@mail.gmail.com> Message-ID: On 29/01/06, Brendan Lally wrote: > - an extension to the extension above, send health status along with > monsters (probably as a percentage to not give away total hp), they > can then have clients draw health bars above their heads. As extension to your extension to the extension above, or even on its own, some re-balancing of the game could be performed. Last month I set my girlfriend lose on CF, and her biggest negative feedback was that exploring was very difficult. You either go into a new map and can kill everything without taking any damage, or you die by the end the map finishes loading. Either outcome is not very exciting. Therefore a re-balancing to increase the margin between "that does not even tickle" and "what was that which just killed me?" is needed. In order to achieve that I propose starting with 3 changes: * DRASTICALLY reduce the hp regeneration (something like 10-fold) * Significantly increase hp of players and monsters (3-10 fold) * Significantly lower resistances given by items (so a player can get up to 25% resistance or so with several items) That way there will be less reliance on item resistances, and it will be easier to match a map difficulty to a specific level. Also a player that enters a difficult area will not be killed before they have a good chance to run away. As a side effect healing potions and healing spells will then become useful. Monster combat will also take longer, so running through a pack of enemies much weaker than you to gain lots of experience will not be as useful. Perhaps a balancing test server should be set up to allow finding the right balance. As an extension to the aboce extension a new family or party spells can be introduced. These will aid parties in combat by providing spells like party heal, and party word of recall. Possibly party strength, party wisdom, and so on can be introduced. They would be high level spells that would act on all of the party, and will belong to different magic schools. From elshar at cheekan.org Tue Jan 31 16:51:40 2006 From: elshar at cheekan.org (Michael) Date: Tue, 31 Jan 2006 14:51:40 -0800 Subject: [crossfire] Transports In-Reply-To: <43DF6AE6.1020002@telus.net> References: <43DF1D3B.2000302@sonic.net> <43DF6AE6.1020002@telus.net> Message-ID: <43DFE9FC.6050807@cheekan.org> Alex Schultz wrote: > And what should be done to prevent you from running around shops in a wagon? > > Such things incline me to want to disallow them from going through > exits, though that in my opinion makes them more limited in usefulness too. > Well, I think the typical shop exit check would be easy to implement for the vehicle. And anyways, even if they did figure out how to get the 'stolen' items out of a shop, they can't use them as they're still flagged. I suppose they could clean out a shop of neat items people have sold to it, but that's about it. From alex_sch at telus.net Tue Jan 31 17:28:53 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 31 Jan 2006 16:28:53 -0700 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: References: <43DC4B0A.8030808@sonic.net> <7903f03c0601290420x2a1eae8fpe3a7c919d2b2f5bb@mail.gmail.com> Message-ID: <43DFF2B5.6060406@telus.net> Anton Oussik wrote: >party spells can be introduced. These will aid parties in combat by providing >spells like party heal, and party word of recall. Possibly party >strength, party wisdom, and so on can be introduced. They would be >high level spells that would act on all of the party, and will belong >to different magic schools. > In case you don't already know, the server code for party spells is in there, but not very well tested, and no spells have been implemented with the code yet. Hence, this should be a relatively easy task. Alex Schultz From alex_sch at telus.net Tue Jan 31 17:31:52 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 31 Jan 2006 16:31:52 -0700 Subject: [crossfire] Transports In-Reply-To: <7903f03c0601310632k6caeb898yf545f315523ecd@mail.gmail.com> References: <43DF1D3B.2000302@sonic.net> <43DF6AE6.1020002@telus.net> <7903f03c0601310632k6caeb898yf545f315523ecd@mail.gmail.com> Message-ID: <43DFF368.7000507@telus.net> Brendan Lally wrote: >On 1/31/06, Alex Schultz wrote: > > >>Such things incline me to want to disallow them from going through >>exits, though that in my opinion makes them more limited in usefulness too. >> >> > >Can exits use the move allow/block idea too? if so, you could look at >them to decide whether a transport can go through an exit or not. > Ahh, good idea. That should work in theory from what I know. Alex Schultz From brenlally at gmail.com Tue Jan 31 17:33:32 2006 From: brenlally at gmail.com (Brendan Lally) Date: Tue, 31 Jan 2006 23:33:32 +0000 Subject: [crossfire] Crossfire 2.0+ features/priorities In-Reply-To: References: <43DC4B0A.8030808@sonic.net> <7903f03c0601290420x2a1eae8fpe3a7c919d2b2f5bb@mail.gmail.com> Message-ID: <7903f03c0601311533v1d9c54ebn5448d0ea0aba7025@mail.gmail.com> On 1/31/06, Anton Oussik wrote: > In order to achieve that I propose starting with 3 changes: > * DRASTICALLY reduce the hp regeneration (something like 10-fold) > * Significantly increase hp of players and monsters (3-10 fold) > * Significantly lower resistances given by items (so a player can > get up to 25% resistance or so with several items) One thing that might work well there, would be to also have a reduction in weapon speed (reduce it by a factor of 2 or so). Currently when you attack monsters the attack messages are numerous and spam-y, if they were slowed down a lot (to at least the point where you could read all of them out loud as they come in). There would be fewer attacks to calculate, the rate of damage would be less, and there would also be fewer draw_info messages to transmit, which seems like a win all round. It would also make it possible to bring back the point from long ago of attack sounds, since attacks and parries would be slow enough that you could actually have sounds mapped to them. > As an extension to the aboce extension a new family or party spells > can be introduced. These will aid parties in combat by providing > spells like party heal, and party word of recall. Possibly party > strength, party wisdom, and so on can be introduced. They would be > high level spells that would act on all of the party, and will belong > to different magic schools. IIRC party spells are already supported in principle, but nothing is currently using them. From leaf at real-time.com Tue Jan 31 20:46:14 2006 From: leaf at real-time.com (Rick Tanner) Date: Tue, 31 Jan 2006 20:46:14 -0600 Subject: [crossfire] renaming binaries In-Reply-To: <43DD4241.40907@sonic.net> References: <7903f03c0601271739i66b741f2kae44cd4a73effa73@mail.gmail.com> <43DC45F5.9030601@sonic.net> <7903f03c0601290921o2e071ac9kf41a515e4ded3560@mail.gmail.com> <43DD4241.40907@sonic.net> Message-ID: <43E020F6.1000309@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Wedel wrote: > Brendan Lally wrote: >> >>The problem is that at the moment there is no real replacement for >>crossedit (CFJavaEditor doesn't work well enough, it doesn't even have >>undo support). > > This is perhaps a problem. But then I think we need to figure out what our > editor story is. > > If it is that the java editor is the official editor, these bugs should be > reported and fixed up. I do agree that the fact it is in java and not C > probably doesn't help things a great deal in terms of java competency of some of > the programmers (me included). Last week (or maybe longer..) on IRC one of the developers who worked on and updated the map editor for Daimonin asked about a collaboration on a Java based editor that had a central or common core with specific side packages(?) for Crossfire and one for Daimonin. For those who can *and* are willing to contribute Java development interested in persuing this? Or discussing it further? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD4CD2hHyvgBp+vH4RAnibAKCUf2ewB2GK1IDIfYxkbdJ+GJ7QjgCfegUs PvkAtKCEfcYhGePr6g0uSjk= =y+MG -----END PGP SIGNATURE----- From mikeeusaa at yahoo.com Tue Jan 31 20:55:35 2006 From: mikeeusaa at yahoo.com (Miguel Ghobangieno) Date: Tue, 31 Jan 2006 18:55:35 -0800 (PST) Subject: [crossfire] Transports In-Reply-To: <43DFF368.7000507@telus.net> Message-ID: <20060201025535.14200.qmail@web32702.mail.mud.yahoo.com> One can't put unpaied stuff in a box and steal them, same would go for transports I'd assume. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From brenlally at gmail.com Tue Jan 31 21:20:26 2006 From: brenlally at gmail.com (Brendan Lally) Date: Wed, 1 Feb 2006 03:20:26 +0000 Subject: [crossfire] Transports In-Reply-To: <20060201025535.14200.qmail@web32702.mail.mud.yahoo.com> References: <43DFF368.7000507@telus.net> <20060201025535.14200.qmail@web32702.mail.mud.yahoo.com> Message-ID: <7903f03c0601311920r62318f7by3a6c4781721490e4@mail.gmail.com> On 2/1/06, Miguel Ghobangieno wrote: > One can't put unpaied stuff in a box and steal them, > same would go for transports I'd assume. I think the point is rather that horses shouldn't go into shops in the first place, through gates maybe, and certainly into cities, but not shops or other buildings with human-sized doors. From alex_sch at telus.net Tue Jan 31 21:50:41 2006 From: alex_sch at telus.net (Alex Schultz) Date: Tue, 31 Jan 2006 20:50:41 -0700 Subject: [crossfire] Transports In-Reply-To: <7903f03c0601311920r62318f7by3a6c4781721490e4@mail.gmail.com> References: <43DFF368.7000507@telus.net> <20060201025535.14200.qmail@web32702.mail.mud.yahoo.com> <7903f03c0601311920r62318f7by3a6c4781721490e4@mail.gmail.com> Message-ID: <43E03011.7000202@telus.net> Brendan Lally wrote: >On 2/1/06, Miguel Ghobangieno wrote: > > >>One can't put unpaied stuff in a box and steal them, >>same would go for transports I'd assume. >> >> >I think the point is rather that horses shouldn't go into shops in the >first place, through gates maybe, and certainly into cities, but not >shops or other buildings with human-sized doors. > Yes, that is the point I am trying to make. Though it would probably be good to have a sanity check that covers what mikee is saying. Alex Schultz