From tanner at real-time.com Wed May 16 13:30:19 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:53:02 2005 Subject: [cf-admin] Testing Message-ID: <20010516133019.R4770@real-time.com> Testing. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From highway at cstone.net Fri May 18 12:56:01 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 17:53:02 2005 Subject: [cf-admin] upgrading servers Message-ID: <3B056231.C26B8D7F@cstone.net> I'm about to upgrade our server from .98 to 1.0. Are there any specific issues I should be aware of, in particular as to keeping the characters intact? Thanks, SeanMike From mwedel at scruznet.com Fri May 18 15:33:44 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 17:53:03 2005 Subject: [cf-admin] upgrading servers In-Reply-To: <3B056231.C26B8D7F@cstone.net> Message-ID: On Fri, 18 May 2001, Sean Michael Whipkey wrote: > I'm about to upgrade our server from .98 to 1.0. Are there any specific > issues I should be aware of, in particular as to keeping the characters > intact? Nope. Just run configure with the same -prefix option as you did for 0.98 and you should be fine. I've made attempts such that make install does not clobber/change stuff that does not need to be changed. From olle at viksten.com Thu May 24 23:12:52 2001 From: olle at viksten.com (Olle Viksten) Date: Thu Jan 13 17:53:03 2005 Subject: [cf-admin] How stable is 1.0? Message-ID: <01052506125201.04088@pingu> I'm contemplating setting up a crossfire server at my server. What I need to know is how stable is the latest release? I can't take any chance that the crossfire will take down the whole server. And can anyone make an educated guess on how much traffic a crossfire server will generate? Olle Viksten From mwedel at scruz.net Thu May 24 23:23:07 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 17:53:03 2005 Subject: [cf-admin] How stable is 1.0? References: <01052506125201.04088@pingu> Message-ID: <3B0DDE2B.B997D422@scruz.net> Olle Viksten wrote: > > I'm contemplating setting up a crossfire server at my server. What I need to > know is how stable is the latest release? I can't take any chance that the > crossfire will take down the whole server. And can anyone make an educated > guess on how much traffic a crossfire server will generate? I have yet to here time the crossfire server has crashed the entire server machine. I'm presuming you are running on unix - if running under windows, then a lot depends on how good that OS is. the server process does periodically crash, but doesn't take anything else down with it. As for bandwidth - a lot depends on number of players. More players obvioiusly equals more bandwidth. I don't think we have any really good numbers right now, but hopefully with the improved reporting capabilities to the metaserver that I just added to CVS, some better numbers can be determined. From tanner at real-time.com Fri May 25 01:49:50 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:53:03 2005 Subject: [cf-admin] How stable is 1.0? In-Reply-To: <3B0DDE2B.B997D422@scruz.net>; from mwedel@scruz.net on Thu, May 24, 2001 at 09:23:07PM -0700 References: <01052506125201.04088@pingu> <3B0DDE2B.B997D422@scruz.net> Message-ID: <20010525014950.M25025@real-time.com> Quoting Mark Wedel (mwedel@scruz.net): > Olle Viksten wrote: > > > > I'm contemplating setting up a crossfire server at my server. What I need to > > know is how stable is the latest release? I can't take any chance that the > > crossfire will take down the whole server. And can anyone make an educated > > guess on how much traffic a crossfire server will generate? As far as bandwidth, I can tell you this. Using MRTG and sampling metalforge port switch every 5 minutes. I get this: Max in: 5774.0 B/s Max out: 1840.0 B/s Average In: 591.0 B/s Average Out: 307.0 B/s Metalforge is not all that popular, but the network utilization is trivial. For comparision, continuum (a netrek server) Max In: 36.1 kB/s Max Out: 12.5 kB/s Average In: 16.6 kB/s Average Out: 5876.0 B/s Again, significantly more, but also trivial. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From olle at viksten.com Sat May 26 09:58:08 2001 From: olle at viksten.com (Olle Viksten) Date: Thu Jan 13 17:53:03 2005 Subject: [cf-admin] How stable is 1.0? In-Reply-To: <3B0DDE2B.B997D422@scruz.net> References: <01052506125201.04088@pingu> <3B0DDE2B.B997D422@scruz.net> Message-ID: <01052616580800.13254@pingu> fredagen den 25 maj 2001 06:23 wrote Mark Wedel: > I have yet to here time the crossfire server has crashed the entire server > machine. I'm presuming you are running on unix - if running under windows, > then a lot depends on how good that OS is. > > the server process does periodically crash, but doesn't take anything else > down with it. > > As for bandwidth - a lot depends on number of players. More players > obvioiusly equals more bandwidth. I don't think we have any really good > numbers right now, but hopefully with the improved reporting capabilities > to the metaserver that I just added to CVS, some better numbers can be > determined. It's up and running. It took me a litle less than one hour. No major problems just some stupidity on my part. It's on folkvang.freja.net the usual port and it showed up in the gtk client even when I had loged off the server. BTW. Folkvang is the name of the place where the Nordic godess Freja lives, hence the name. Olle Viksten From mwedel at scruz.net Tue May 1 00:10:53 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:44 2005 Subject: [Re: [[CF-Devel] CPU and memory?]] References: <20010430104156.23031.qmail@nwcst286.netaddress.usa.net> Message-ID: <3AEE455D.27E2D144@scruz.net> DAVID DELBECQ wrote: > Ok, you say it requires a lot of changes because it is a problem of lots of > spells. If this is the case, this means you changed a lot of stuff from 0.97 > version cause this version didn't lag and i don't think you made so heavily > changes. I looked, and don't see any changes between then and now which would immediately change this behavioiur. Note the lots of spell causing lag/high cpu consumption is infinitely old (or at least as old as crossfire). But generally, it starts to require a fair number of spells before you hit the threshold (although, to be honest, I don't know where the exact threshold is). > > Moreover, you speak about lots of spell on the same square. I have checked, > there are no more than 5 objects on a square (6 if i include my self, 7 with > the floor). The map, as i said, contain only 10 spellcaster, disposed so that > 8 of them are hurting the player the same time, reducing number of spellcaster > is simply stupid. I would guess that the number of spells per square would need to be at least 20-30 before serious performance problems would get observed. > > 3rd point, even if map could be smaller, with lesser spellcaster, don't forget > that level 80 players can cast more than 10 spells nearly at the same time, > linked on the same key in the client (e.g. cast 5 icestorm, 5 burnig hands, 5 > holy word, 1 counterwall in the same key to do lots damages in a short time in > the arena.....). This cannot be prevented. Correct, and in fact that can cause performance issues. comet/large fireball are actually the worst examples, as they create a lot more objects for the one cast. But yes, the problem happens no matter who is casting the spells. However, generally players are more restained than most monsters are, who cast things as fast as possible. Players are probably more likely to try and limit the number of spells to not be more than it really takes - otherrwise you burn up mana and also increase the likelihood of incinerating the treasure you may want. > > At the end, i'll say this is not a problem for crossfire to be cpu consuming. > The problem is that it becomes also VERY laggy (can hang-up up to 5 seconds > when spellcasters become to cast). Its one in the same. ITs laggy because the server is spending all its time processing the spell objects. It is probably worst when the spell casters first come up because they have full mana and will unlease it as fast they can. One quick fix may be to increase the recovery time for high speed monsters casting spells so they can't cast them quite as quickly (even delaying them a few ticks may be enough, as its really the stacking of the spell objects on the space that chew it up). > > You say you are fixing bugs in crossfire for version 1.0 THIS clearly is a > bug, i recommend you to check closely at the cast cone code, it contains a lot > of useless assignements in a loop. (System does not seem laggy when casting > things other than cone!!). If you make some checks, you could also see the the > time consuming is done when spell casting, not when the spell spreads. I've done checking, and the time is when the spell is spreading. IT happens with fireballs and other ball spells. Believe me, I have investigated this. The cost of creating the spell effect is small compared to inserting a spell object on a space where there are 60 other objects, and we need to check all of those to see if this spell may effect one of those or vice versa. So inserting the 61'st object requires 60 other object checks (each of them non trivial), and to actually get up to that 60'th object has already required 1800+ such checks. Is this a bad bug? Sure. Should it be fixed for 1.0? Would be nice, but doing so would mean delaying 1.0 a long time - as said, the change to improve that processing is non trivial, and is fairly integral - it really needs to be pretty thoroughly tested. I will note that there are several public servers where this does noot generally seem to be a problem. And I have no illusions - there will be some bugs in 1.0. But a little while ago, it was decided that getting 1.0 out as quick as reasonably possible was what was important, and not fixing everything on the TODO list. From peterm at tonks.EECS.Berkeley.EDU Tue May 1 00:35:56 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] The answer to ON/OFF attacktype protection! In-Reply-To: Your message of "Mon, 30 Apr 2001 21:21:02 PDT." <3AEE39AE.37CA370C@scruz.net> Message-ID: <200105010535.f415Zvh31581@tonks.EECS.Berkeley.EDU> I have *the* answer to on/off attactype protection. I was considering how the Spell of Peace and the Face of Death are overpowered. The problem is that these guys get MANY chances at the same monster. The fix? You get ONE chance to hit the monster with YOUR Face of Death spell and ONE chance to Peace him. After a fail, you put an object into the 'victim' which prevents that spell cast by you ever working on him again. (Unless you advance a level and try again.) We can do this for paralyzation too. Regards, PeterM > Andreas Vogl wrote: > > > > Note that draining resistance actually reduces effect. 90% resistance > > > means you lose only 10% the amount of experience you would if you had > > > no protection. > > > > This will be true when draining is adjusted to be fairly harmless > > with 90% resistance. As things are now, it definitly is not. > > I think a lot of the problem here is the same as with death - the experience > totals needed for levels becomes fairly linear at some point, so losing 10% > amounts for a lot more than it does at low levels. > > If you had 90% resistance, it would mean each hit you take with a drain atta >ck > would take 1% of your exp total. At low levels, this isn't that big a deal - > even at half a million exp, that means a hit takes 5000 exp - thats just a fe >w > monsters to kill. I could see at higher levels where even 1% is 10 really to >ugh > monsters - monsters that just can't easily be found. > > > > > > Just brainstorming here, but it seems to me that if draining is so nasty > > > that any experienced character wants drain resistance 100, then draining > > > seems to be a too powerful attacktype. It also means that drain attacks > > > on monsters pretty much become meaningless (if all the characters its > > > going to attack are immune to drain, then that attacktype has no effect. > > > And this may be what leads to more monsters having drain developer/ > > > tester sees it as not big deal because the player will be immune). > > > > > > But I think some of this is also good map design [...] > > I think I mistated what I really wanted to say. > > > > > *Good* map design? > > What you described above is what I call: > > "the revenge of the mapmakers". =) > > agree here. > > > > > Sometimes developers create things that are real ugly/horrific in the > > players' eyes. Like the irreversible acid corrosion or the > > "worse-than-dying" draining attack. > > Since players don't like these but also don't like to war with us > > developers, people start to create artifacts with immunities to that > > stuff. Then *every* player gets these artifacts - And soon mapmakers > > design maps in the assurance that players are always immune. > > What is the outcome in the end? - Pretty much like the original hazard > > (acid/draining) would have been removed in the first place. > > agree. > > > > > I'm not trying to judge on anything here. But maybe we should listen > > more to the players' preferences in such cases. > > Either we remove the whole thing, we do nothing and stick with the > > immunities, or we tone down the hazard till players can accept it. > > Note that some players preferance might be something like 'virtually impossi >ble > to be killed'. So we have to take some consesus and common sense. > > I personally think the third choice is the way to go - tune things down so t >hey > are acceptable. > > Depending on the attacktype may determine how easy/hard this is to do. For > drain, it would not be really hard to reduce the amount that a drain hit take >s > (instead of 10% by default, maybe 3% or the like) as well a put some upper li >mit > (100,000 or something) for high level characters. > > For acid, the first thing should be that the number of acid using monsters b >e > severely limited. Rust monster, green slime, and black pudding are good. I > think if acid had only remained with those monsters, acid immunity probably > would not have been added - those monsters are infrequent enough and typicall >y > most uses have good warning (or they move slow enough) that youu can get away >. > Plus, you could kill them somewhat easily with range spells/missiles. But th >en > some really tough monsters started getting acid attacks, and that really open >ed > things up of needing real protection because fighters at least could not kill > them via bow, but need to go hand in hand. > > The other factor is that most all artifacts are immune to acid. I've been > playing a character recently and thinking 'hmm. wonder if acid attack is bro >ken > - it keeps hitting my helm'. Then I realized that was the only item I had wh >ich > was made of metal. mithril chain, dragon shield, leather gloves and jackboot >s > are all immune to the effects. So at some point, you don't even need to worr >y > about acid protection for your equipment, as all the good stuff is already > protected. > > It has been sugested that items should have quality ratings and thus get > repaired. Being able to repair acid damage could be reasonable addition (not > sure how to do this so that is balanced, however - if its too easy, then once > again, then the acid attack only becomes slightly annoying). I don't know if > I > like the idea of general weapon quality, having it break, getting it repaired >, > etc as a standard feature - that seems more annoying than useful (in fact, th >e > might & magic games have items get damaged, and the only effect is that it is > annoying, as typically at least one character in the party can repair it, so >it > just becomes a matter of noticing the item is damaged, moving it to the repai >r > character, moving it back, equipping it, etc. Worst part is that this takes >no > game time, so you can do it in the middle of combat with no bad effect). > > > > re confusion, slow, ... > > No, it is correct. Unless either the offending monster gets killed > > or the player hides, the player will be "infected" again and again. > > Duration has no effect. As I said, if the player *can* be infected > > he will be -> the effect is ON. If the player is immune, he goes > > unharmed -> the effect is OFF. Partial resistance is an illusion here. > > It is still useful. A lot depends on the spell casting frequency of the > monster. If you just have a couple of the spell casting monsters, this reduc >ed > duration may be useful enough that you can get out of danger and do something > reasonable (like drink the potion that gives you full resistance). > > Paralyzation is really tough, as that is really an on/off effect. And if yo >ur > paralyzed, chances are you'll get pegged by an incoming damage spell. > > One problem may just be the spellcasting of monsters - they can cast much > faster than the player can recover, so you are correct - if you get hit once, > your probably in trouble. Another problem is how fast damage can kill a > player. a lightning bolt cast by most monsters can take out a 90 hp player i >n > about a second, so if a bolt comes out, you need really fast reaction time to > get out of the way or your toast. > > But what I'm really arguing against here is the items that give permanent > immunity. As youu say above, once those are given out, the attacktype become >s > meaningless. And that is the case for confusion, paralyze, and slow I believ >e - > you get the amulet/ring of free actiion (or the speed +1, immune to > paralyze/slow/confusion), and never worry about those attacks again. And tho >se > attacks are so deadly, that you really need a relatively high degree of > protection. > > idea for fixing at least some of these: > confusion: If you have a resistance, then perhaps give some chance based on > resistance for the player to move the direction they want. Thus, if you are >50% > resistant, you will still wonder around somewhat, but basically move in the > direction youu want to, and hopefully get away from the creature. > slow: amount of slowdown could be affected by resistance. So if you are 50% > resistant, you are only slowed by 50% of what youu would have been otherwise. > > Once again, this should let you get out of danger. > paralyze: No good solution. This is really either an on/off effect. Perhaps > just do away with paralyzation as a monster attack, and leave it for players? > > Currently, players beyond a certain level are immune anyways because they get > an > immunity item for it. > > Note that my argument isn't that 100% immunity is bad. My argument is that > items that give 100% immunity permanently are bad, and these should instead b >e > replaced by potions (or blessings from god) that do so. So given that basis, > the idea that if a player is mostly protected (say free action gives 90% inst >ead > of 100), the player, once seeing big nasty monster, still has a chance to get > away and drink relevant potion. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From gros at magellan.fpms.ac.be Tue May 1 07:39:57 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS: crossfire/lib artifacts,1.26,1.27 In-Reply-To: <000001c0d1c6$b4788160$4ca7fea9@kyle> References: <000001c0d1c6$b4788160$4ca7fea9@kyle> Message-ID: <01050108395700.01709@Terminus.magellan.fpms.ac.be> > Resistance to godpower must not exist! > If we don't want to plunge the whole attacktype-concept > into anarchy, there's certain rules we must keep. > > Mapmakers have to rely on certain attacktypes being > dangerous. Godpower is the last resort against crazy > equipment. Don't ruin it. > > Please take it out. > > Andreas V. > > > Update of /cvsroot/crossfire/crossfire/lib > > In directory usw-pr-cvs1:/tmp/cvs-serv23480 > > > > Modified Files: > > artifacts > > Log Message: > > New priest-oriented rings. > > > > [...] > > + # > > + # Ring of Benevolence > > + # Two small things I want to underline: - Andreas V. is right. Allowing such protection against Godpower will ruin fun since it means that you could become nearly immune to nearly any attack type. What could then those poor monsters do ? And I just can't see how you could justify a protection against the pure force of the gods in a RPG. So please, throw it away ! - I thought that Crossfire-0.98.0 was the last step before 1.0 release and that the only additions that would be integrated were bugfixes. Strangely, the Ring of Benevolence doesn't seem to be a bugfix at all... Does it mean that the Crossfire development team changed their projects and finally decided to accept new additions, or is it just the manifestation that only some people are allowed to make such additions ? If so, please send an official 'Authorized Developers List' so other coders will not loose time on Crossfire. Commander Gros Of the Western Dwarven Kingdom From dnh at hawthorn.csse.monash.edu.au Tue May 1 02:19:23 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] Prison for player killers? In-Reply-To: <200105010111.f411B7w31078@tonks.EECS.Berkeley.EDU> Message-ID: LoL! I would love to see someone in jail =). Go for it. dnh On Mon, 30 Apr 2001, Peter Mardahl wrote: > > Hello, > > On IRC we kicked around this idea: > > 1) If someone kills another player, they get sent to prison IF: > a) The "victim" was on a map of reasonable difficulty compared > to his level (high leveller hunted down and killed a low-leveller > in the low-leveller's natural habitat, easy maps.) > Otherwise if, the victim is on a hard map (the high leveller's natural > habitat) we deem the death 'accidental'. > > 2) If the victim shouts "forgive ", he's free. > Otherwise, he's stuck for 3 days. > > 3) Other people have put forth the idea of only enforcing this upon > repeat offenders, and having no penalty if people are on the same team. > > PeterM > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Tue May 1 02:38:29 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:44 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS: crossfire/lib artifacts,1.26,1.27 References: <000001c0d1c6$b4788160$4ca7fea9@kyle> <01050108395700.01709@Terminus.magellan.fpms.ac.be> Message-ID: <3AEE67F5.9C6AC937@scruz.net> gros wrote: > - I thought that Crossfire-0.98.0 was the last step before 1.0 release and > that the only additions that would be integrated were bugfixes. Strangely, > the Ring of Benevolence doesn't seem to be a bugfix at all... Does it mean > that the Crossfire development team changed their projects and finally > decided to accept new additions, or is it just the manifestation that only > some people are allowed to make such additions ? If so, please send an > official 'Authorized Developers List' so other coders will not loose time on > Crossfire. This is probably my fault. There is certainly a 'code' freeze. However, I didn't worry about most of the map, image and arch changes (and in fact, did not really pay attention to them very much) - changes to those would not affect reliability of the server, which was my chief concern. And in that sense, this is still true - the server is unlikely to be any less reliable with these new artifact changes. However, as suggested, there are balance changes. Even that probably isn't a big deal, but then again, the changes to arch should probably not be wide open. Actually, my bigger worry is frequency of the objects - the treasurelists and artifact generation lists are have a little voodoo involved for generation of objects, and often it takes a little while to get the tweeking just right. I was seriously considering revoking all CVS access to prevent unauthorized changes, but even with that, I really only wanted to restrict the server area (which is not really possible with sourceforge), and it never seemed like that big a deal. And to be honest, it still isn't that big a deal. Other option would have been to do a branch for 1.0 stability (as I will still need to do one for post 1.0 patches/releases) Actually, I'm very happy people are looking over the cvs commits and finding these problems. I'll probably be releasing 1.0 within the next week, and then it will be opened up for everyone again. Oh well. You live and learn. Hopefully, 2.0 will end up being a much smoother process after learning from these mistakes. From gros at magellan.fpms.ac.be Tue May 1 08:46:50 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:45 2005 Subject: [Re: [[CF-Devel] CPU and memory?]] In-Reply-To: <3AEE455D.27E2D144@scruz.net> References: <20010430104156.23031.qmail@nwcst286.netaddress.usa.net> <3AEE455D.27E2D144@scruz.net> Message-ID: <01050109465001.01709@Terminus.magellan.fpms.ac.be> Le Mardi 1 Mai 2001 01:10, vous avez ?crit : > DAVID DELBECQ wrote: > > Ok, you say it requires a lot of changes because it is a problem of lots > > of spells. If this is the case, this means you changed a lot of stuff > > from 0.97 version cause this version didn't lag and i don't think you > > made so heavily changes. > > I looked, and don't see any changes between then and now which would > immediately change this behavioiur. Note the lots of spell causing > lag/high cpu consumption is infinitely old (or at least as old as > crossfire). But generally, it starts to require a fair number of spells > before you hit the threshold (although, to be honest, I don't know where > the exact threshold is). You may have looked at the wrong place. It is definitely true that my Crossfire-0.97.0 consumed about 40% CPU power when loading the map of David. Crossfire-0.98.0 consumed nearly 80% CPU power for the same map. This is not an impression, it is a fact. It is also a fact that I was unable to play the map locally on a K62/450 with only one player - Will Crossfire 1.0 require a PIII/Athlon to run fine ? > > > Moreover, you speak about lots of spell on the same square. I have > > checked, there are no more than 5 objects on a square (6 if i include my > > self, 7 with the floor). The map, as i said, contain only 10 spellcaster, > > disposed so that 8 of them are hurting the player the same time, reducing > > number of spellcaster is simply stupid. > > I would guess that the number of spells per square would need to be at > least 20-30 before serious performance problems would get observed. Again, it depends on the machine where you are running Crossfire on. > > > 3rd point, even if map could be smaller, with lesser spellcaster, don't > > forget that level 80 players can cast more than 10 spells nearly at the > > same time, linked on the same key in the client (e.g. cast 5 icestorm, 5 > > burnig hands, 5 holy word, 1 counterwall in the same key to do lots > > damages in a short time in the arena.....). This cannot be prevented. > > Correct, and in fact that can cause performance issues. comet/large > fireball are actually the worst examples, as they create a lot more objects > for the one cast. But yes, the problem happens no matter who is casting > the spells. > > However, generally players are more restained than most monsters are, who > cast things as fast as possible. Players are probably more likely to try > and limit the number of spells to not be more than it really takes - > otherrwise you burn up mana and also increase the likelihood of > incinerating the treasure you may want. You forget that Crossfire is designed to be a 'Multiplayer Adventure Game'. This means that there could be many players on a server at the same time. And if two or three level 110 players in a team join their forces to finish a map, it means lots of spells at the same time - theirs and those of the opposing monsters... And high-level players can cast spells _very_ fast... > > You say you are fixing bugs in crossfire for version 1.0 THIS clearly is > > a bug, i recommend you to check closely at the cast cone code, it > > contains a lot of useless assignements in a loop. (System does not seem > > laggy when casting things other than cone!!). If you make some checks, > > you could also see the the time consuming is done when spell casting, not > > when the spell spreads. *snip* > Is this a bad bug? Sure. Should it be fixed for 1.0? Would be nice, but > doing so would mean delaying 1.0 a long time - as said, the change to > improve that processing is non trivial, and is fairly integral - it really > needs to be pretty thoroughly tested. > > I will note that there are several public servers where this does noot > generally seem to be a problem. And I have no illusions - there will be > some bugs in 1.0. But a little while ago, it was decided that getting 1.0 > out as quick as reasonably possible was what was important, and not fixing > everything on the TODO list. What is said here above looks quite strange and makes me somewhat anxious about the way things are going. This means that: - Bugs difficult to correct will not be resolved because it is too time-consuming; - Getting a '1.0' version number is more important than having a 'clean' program (note that in the TODO file, 1.0 is 'First true public release - fully stable, and very well balanced.' I see 'fully stable', not 'to be released as quick as reasonably possible'). - Getting a '1.0' version number is more important than wishes of players and mapmakers (If Mr. Delbecq encountered the bug, it is certainly a problem for him and potentially for others, even if 'this is generally not a problem for public servers'). I think the only feature needed by Crossfire before 1.0 release is a complete rethinking on how the code is managed, how players/mapmakers can make their wishes known, how the work must be distributed between contributors, how bugs are fixed, etc. I know it is not programming - it is managment. And I also know saying such things will not be on the taste of many people, but is is sad too see that an OpenSource project goes more and more 'closed' because of bad managment and communication techniques. Again, I know that many people will not like what I say, but it is how I (and others too) see things. Commander Gros From dnh at hawthorn.csse.monash.edu.au Tue May 1 02:48:45 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] Adding stuff right now.. In-Reply-To: <01050108395700.01709@Terminus.magellan.fpms.ac.be> Message-ID: No, only archetypes are being added (including the graphics for them). Peterm has not made any significant code changes, nor has anyone in quite awhile. Nor have any maps changes been made, if you want to fiddle with the archetypes feel free.. but I suggest we avoid controversial ones just for now. Peterm, I think god power resistance is a fair enough addition, but now is not the time to add it. Perhaps just leave it out for now, add an extra grace regen or something, but so close to a release I don't think we want any unbalancing items. On the other hand, every ring you have added excepting the god power is very clever and I would say people aren't giving you the credit you deserve in that respect. It is quite hard to think up such items (as I learnt with the cloaks). Another flip of the coin, I have quite abit if trouble believing you can even get the WDSM without cheating in some way. Level 125 monsters with meteor swarm? Monsters immune to everything excepting one thing? Monsters hidden underground that kill you in one hit, in a no magic zone? I don't know, I feel those maps are way to hard anyway but that is my own opinion and tends to be of little worth. dnh From dnh at hawthorn.csse.monash.edu.au Tue May 1 03:01:13 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] This is the item.. In-Reply-To: <3AEE4159.43099965@scruz.net> Message-ID: On Mon, 30 Apr 2001, Mark Wedel wrote: > > anyone else seeing this crash? I haven't seen it myself, so I wonder if it may > have something to do with the peculiarities of powerpc linux (the fact it is 64 > bit, or the endianess, or the like). > No I don't think this is anything to do witht he processor at all... it happens rarely (very rarely) and only in very large chests. I can't pin point it.. because i don't have the time nor software. You need to do the titan castle higher levels a few times that is really all i can say. dnh > > dnh wrote: > > > > Another cause of seg faults that has been around ALONG time is this one, > > > > Got update_item command for item we don't have (8198364) > > Segmentation fault > > > > That is what the client spews out. It has been around for along time I > > tends to turn up in the chests in the titan castle random maps by peterm. > > Should defn be fixed before V1, I am running on the LATEST cvs of the post > > 1.0 client, on csua which is about half a day old I think. > > > > dnh > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From peterm at tonks.EECS.Berkeley.EDU Tue May 1 04:02:01 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS: crossfire/lib artifacts,1.26,1.27 In-Reply-To: Your message of "Tue, 01 May 2001 08:39:57 EDT." <01050108395700.01709@Terminus.magellan.fpms.ac.be> Message-ID: <200105010902.f41921X31884@tonks.EECS.Berkeley.EDU> > Two small things I want to underline: > - Andreas V. is right. Allowing such protection against Godpower will ruin > fun since it means that you could become nearly immune to nearly any attack Oh hardly. 51% max protection vs. godpower isn't perfect invulnerability by any means. "nearly immune", hogwash. And you pay 2 ring slots for this 51% protection, that's 2 ring slots which could be worth several hundred points of protection. > type. What could then those poor monsters do ? And I just can't see how you > could justify a protection against the pure force of the gods in a RPG. So > please, throw it away ! One god protecting vs. another? Why is that so unimaginable? So far, 2 con and 1 pro the prot. godpower. If this keeps up I'll have to take it out. > - I thought that Crossfire-0.98.0 was the last step before 1.0 release and > that the only additions that would be integrated were bugfixes. Strangely, As Mark remarked, this primarily applied to server and client code bases. Those *can* and *have* been largely frozen except for bugfixes and minor tweaks. We've been mostly worried about removing all the bugs which cause crashes. However, we've been modifying the image set completely freely, and many map updates/fixes have been done as well. > the Ring of Benevolence doesn't seem to be a bugfix at all... Does it mean No, it's not a bugfix. However, balancing is part of the current phase of development. There're precious few artifacts around for helping priests, so I added the priest series of ring artifacts, MOST of which AV approved of, and no one else has seen fit to comment on. His only objection was to the 30% godpower resistance on one of these rings for priests, the Ring of Benevolence, which will get taken out if this 2-1 trend against continues. My main problem with AV's strategy of using Godpower as "the irresitible attacktype which is given to monsters to make them hard" is that Godpower can be rightly and logically defended against with the power of another God, and Godpower rightfully should be used only for divine attacks, effects, and rarely, divine creatures. Weaponmagic seems to me a much better attacktype for something to which "no protection may be granted", and I'd rather see protection on that banned than Godpower. I've even offered to retrofit the maps. Despite this, I fundamentally disagree with using weaponmagic or godpower vs. players. Players OUGHT and SHOULD be able to prepare vs. and defend against what the mapmaker throws against them. I think maps should be soluble instead of gambling with deathtraps that cannot be avoided, protected against, or prepared for. Players that play correctly and use the proper precautions should WIN. In NO map I've made have I used weaponmagic or godpower vs. players. (knowingly: someone might have added these attacktypes to some monster) Even with these new rings defense against those attacktypes is very thin. Mapsets don't have to kill players a lot to be fun. Maps are cool mostly because of their puzzles, structure, and story, not because of their impossible monsters. PeterM > that the Crossfire development team changed their projects and finally > decided to accept new additions, or is it just the manifestation that only > some people are allowed to make such additions ? If so, please send an > official 'Authorized Developers List' so other coders will not loose time on > Crossfire. > > Commander Gros Of the Western Dwarven Kingdom > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From andi.vogl at gmx.net Tue May 1 04:13:38 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] luxory manor In-Reply-To: <3AEE34D3.9FFC9DB8@cstone.net> Message-ID: <000001c0d21f$03909500$ab1efea9@kyle> > We got a key to the manor in Stoneville on our .98 server. > > However, the three beds on the right hand side of the manor show up as > "damned". > > Can beds to reality be damned? If so, how, and what does that do? Is > it something we did, perhaps? We do a good bit of alchemical and > polymorphing in there... It is not the polymorphing code. In fact, every savebed has the "damned" and "no_magic" flag set. You surely have noticed that players get beamed on their last-applied savebed after dying these days. Now imagine you are a wizard and cast fireballs in a dungeon. Suddenly you die, but still your finger is on the fire key. *Wooof* - Your whole apartment goes up in smoke. Even worse: Sometimes players died in autofire mode and managed to get themselves killed with their own spells about ten times in their apartment afterwards. This is the reason why savebeds have been set both damned (no prayers) and no_magic (no spells). Andreas V. From andi.vogl at gmx.net Tue May 1 05:57:00 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] poisoning & demonologic tower In-Reply-To: <3AEE39AE.37CA370C@scruz.net> Message-ID: <000101c0d22d$73e62dc0$ab1efea9@kyle> Mark W. wrote: > [...] > > I'm not trying to judge on anything here. But maybe we should listen > > more to the players' preferences in such cases. > > Either we remove the whole thing, we do nothing and stick with the > > immunities, or we tone down the hazard till players can accept it. > > Note that some players preferance might be something like > 'virtually impossible to be killed'. So we have to take some > consesus and common sense. That's true. > I personally think the third choice is the way to go - tune things > down so they are acceptable. > > Depending on the attacktype may determine how easy/hard this is to do. > For drain, it would not be really hard to reduce the amount that a > drain hit takes (instead of 10% by default, maybe 3% or the like) as > well as put some upper limit (100,000 or something) for high level > characters. Yes, good idea. Maybe the upper limit could be dependant on level- difference between attacker<->defender? Say, a grimreaper couldn't drain much from a level 100+ player. Anyways, the upper limit for draining shouldn't be high. One should barely ever loose a level from it. > For acid, [...] It has been sugested that items should have quality > ratings and thus get repaired. I agree this is a pain in most RPGs and we should consider this with care. > re confusion, slow, ... > But what I'm really arguing against here is the items that > give permanent immunity. As youu say above, once those are given > out, the attacktype becomes meaningless. [...] > > idea for fixing at least some of these: > confusion: If you have a resistance, then perhaps give some chance > based on resistance for the player to move the direction they want. > Thus, if you are 50% resistant, you will still wonder around somewhat, > but basically move in the direction youu want to, and hopefully get > away from the creature. > slow: amount of slowdown could be affected by resistance. So if you > are 50% resistant, you are only slowed by 50% of what youu would > have been otherwise. Once again, this should let you get out of danger. > paralyze: No good solution. This is really either an on/off effect. > Perhaps just do away with paralyzation as a monster attack, and leave it > for players? Currently, players beyond a certain level are immune > anyways because they get an immunity item for it. Great suggestions for confuse and slow. It's true that 90% resistance to these attacktypes is much nicer when it really helps. I would leave paralyze like it is, till we have some idea what to do with it. Andreas V. From peterm at tonks.EECS.Berkeley.EDU Tue May 1 06:14:38 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:45 2005 Subject: [Re: [[CF-Devel] CPU and memory?]] In-Reply-To: Your message of "Tue, 01 May 2001 09:46:50 EDT." <01050109465001.01709@Terminus.magellan.fpms.ac.be> Message-ID: <200105011114.f41BEcY32115@tonks.EECS.Berkeley.EDU> > > You may have looked at the wrong place. It is definitely true that my > Crossfire-0.97.0 consumed about 40% CPU power when loading the map of David. What "map of david"? What map is this? > - Bugs difficult to correct will not be resolved because it is too > time-consuming; Ever heard of milestones? We defer the major fixes we foresee to get something servicable and stable out soon. We'll leave the hard project which involves ripping out the innards and restructuring for 2.0. The hope is that with a reasonable 1.0 out, we'll generate more developer and player interest in contribution to crossfire. This was a consensus decision by the developers: the current code freeze--which Mark has the unpleasant task of enforcing--is directly serving that purpose. We do not have enough people NOR time to fix everything, and getting a 1.0 out is, we hope, a way to get MORE people AND programmer/designer/artist time to help with this game. We should NOT wait until 1.0 is completely perfect before releasing it. > - Getting a '1.0' version number is more important than having a 'clean' > program (note that in the TODO file, 1.0 is 'First true public release - > fully stable, and very well balanced.' I see 'fully stable', not 'to be > released as quick as reasonably possible'). Have you missed all the bugfixes that have gone in recently? This crash fixed, that crash fixed, another crash fixed, this weird thing removed, that bug killed.... and on and on and on. Where have you BEEN? Mean time to server crash has tripled in the last several weeks, mostly due to Mark's efforts, with some help from the rest of us. TREMENDOUS progress has been made. > - Getting a '1.0' version number is more important than wishes of players and > mapmakers (If Mr. Delbecq encountered the bug, it is certainly a problem for > him and potentially for others, even if 'this is generally not a problem for > public servers'). Yeah, we all wish for a totally fast and totally bugfree server. Who, however, is going to do the work? If Mark strangles the developers from doing creative new stuff (the main attraction of working with crossfire) for too long, they'll leave. *that* is an excellent reason to push 1.0 out and lift the code freeze as soon as possible, while also serving the need for stability and game balance. It'd be REALLY nice if we could also eliminate the performance problem, but Mark (and I, and others) think the problem is due to poor algorithms in certain sections of the code, which would be a MAJOR rip-and-rework job, best undertaken past the current milestone goal, which is release of a version called 1.0, which has stability and balance as its primary goals. We'd all be thrilled if you could demonstrate otherwise and provide a simple patch, one we could be sure wouldn't hurt the PRIMARY goal of stability for the 1.0 release. > I think the only feature needed by Crossfire before 1.0 release is a complete > > rethinking on how the code is managed, how players/mapmakers can make their > wishes known, how the work must be distributed between contributors, how bugs What's wrong with people sending email to crossfire devel, discussing things there, which is how we've done it for a very long time? Or getting on the IRC channel and chatting with the developers and players who happen to be around? And as to distributing work, everyone works on what they want to work on, and have time for, same as ANY open source project. And as to the 'command and control' structure for crossfire development, there aren't that many of us. Mark's doing the bulk of the work, *and* has shouldered the job of lead maintainer, a job NO ONE else wanted. It's only fair that he have a good bit of control over development. And your charge of this being a 'closed' open source project are completely off-base. Most people who've really wanted access have GOT it: I know of no one who hasn't. In fact, we've pushed access onto people who were reluctant to have it so that they'd quit bugging us to incorporate their patches! PeterM From peterm at tonks.EECS.Berkeley.EDU Tue May 1 06:40:59 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] I will withdraw the 30 godpower. In-Reply-To: Your message of "Tue, 01 May 2001 17:48:45 +1000." Message-ID: <200105011141.f41BexI32165@tonks.EECS.Berkeley.EDU> > the archetypes feel free.. but I suggest we avoid controversial ones just Well, the consensus seems against me, 3 to 1. I don't see the trend changing and I see the sense in deferring controversial changes 'till post 1.0. I honestly didn't think godpower 30 on a rare ring was going to be THIS controversial. I'm not going to give up on this issue, but I'm willing to defer it 'till later. Thanks for the opinions and arguments thus far. PeterM From dnh at hawthorn.csse.monash.edu.au Tue May 1 07:11:52 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] I will withdraw the 30 godpower. In-Reply-To: <200105011141.f41BexI32165@tonks.EECS.Berkeley.EDU> Message-ID: I agree this is the correct action peter. I tend to take your side of the arguement in terms of which attack type is for what, but at this late stage we are best to sit it out =). I am just wondering if very soon we should really consider not adding ANYTHING more until Mark is all clear. It obviously isn't fair to some people that we are changing things and they can't, we are by no means special and we should all sit back for abit. I suggest we pour our energy into finding every last bug we can! For example, my client crashes.. what is the deal? can everyone go and do the peterm random titan quest (the one for scorn). Open every treasure chest, and if possible run debugger on client and server. My Debugger is quite broken (don't ask) so I beg people to throw a hand out. I believe this bug is around, but only very rarely until i can get some solid ground to stand on it may be allowed into our glorious V1! ;) Enough of this argueing so close to a MAJOR release. We are a team, and now is most definately a time is serious beta testing. Peterm has set the example, let us follow the lead. dnh On Tue, 1 May 2001, Peter Mardahl wrote: > > the archetypes feel free.. but I suggest we avoid controversial ones just > > Well, the consensus seems against me, 3 to 1. I don't see the trend > changing and I see the sense in deferring controversial changes > 'till post 1.0. > > I honestly didn't think godpower 30 on a rare ring was going to > be THIS controversial. > > I'm not going to give up on this issue, but I'm willing to > defer it 'till later. > > Thanks for the opinions and arguments thus far. > > PeterM > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From andi.vogl at gmx.net Tue May 1 07:52:40 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] Resist godpower +30 In-Reply-To: <200105010150.f411oCF31142@tonks.EECS.Berkeley.EDU> Message-ID: <000201c0d23d$9d2ec560$ab1efea9@kyle> Thank you for removing the godpower ring for now peter. I don't want to appear stubborn, but since this issue will be continued after 1.0, I want to make some additional comments. (So we can maybe find a consens and don't have to roll this discussion all up again.) If you feel like this is stealing your time, just read this post after 1.0 is out. ;) peterm wrote: > It's good that you've overhauled pupland and fixed up the problems > in it, but I think it's unfortunate that you've made monsters depend on > godpower in order to make them hard. > > godpower belongs to gods and it makes sense to me to have > relics of benevolent gods defend you from hostile godpower. > > Godpower attack belongs on afflictions from gods: disease, > effects from gods: holy word, cause wounds, divine shock, > and possibly god avatars (but I would prefer not in this case), > not on monsters for the sole purpose of making them hard. > > I suggest that if you want to make monsters hard you use > combinations of other attacktypes, so that a person will > need lots of high resistances to defend vs. them: not practically > possible. I have designed many high level maps in pupland, and I do have some experience there. If you want to create a melee monster that can threaten a high level character, there's only two possible ways: 1) You hand "harmless" attacktypes to the monster, but many of them (fire/cold/physical etc). Since players can drink potions and wear protections you must set the monster to extremely high level (>100) and insane strenght. If you don't, players would soon smite your "highlevel monster" like an ant. What is the outcome? A monster that kills players instantly unless they know exactly about all attacktypes of that monster. Now tell me: Isn't that the exact opposite of what you want peter? 2) Second, you hand godpower (or weaponmagic) to the monster. Since there is no protection from these, the monster can be of sane strenght. A player who is not well-prepared has a good chance to survive here. Instead of cowardly hiding in equipment, the player needs to work with healing spells/potions against this type of monster. A tactic that seems quite interesting in addition. > Alternately, use weaponmagic, and remove > "prot weaponmagic" from the carrillium apron and from that > hammer someone just told me about. Okay, be it weaponmagic or godpower doesn't really make much difference. Personally I favour godpower. Not only that it sounds like being the "ultimate thing" - Important spells like cause wounds, retributive strike and diseases rise and fall with this attacktype. (E.g. Serious protection from disease can easily make it abusive again). Besides, I would miss these spells in my (map-making) repertoire if they became harmless due to protective items. However, if the majority favours weaponmagic to rule over godpower, guess I can live with that. I would only like to have at least one attacktype without any means of protection (for players). And that should then be kept as a strict "rule" in future, so people can rely on it for mapmaking. Andreas V. From crow at bear.cs.dartmouth.edu Tue May 1 11:16:56 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] destroying barrels Message-ID: <200105011616.f41GGu324497@bear.cs.dartmouth.edu> In the recent discussion concerning destroying boulders and barrels, I was surprised to learn that you are supposed to be able to destroy barrels. Is this right? I can't seem to do it. I've tried using several different weapons with different attack types, and it always tells me that I miss. I've tried fireballs. What works? In particular, it seems that you must destroy a barrel for a critical step in getting the white dragon shield. (I'm avoiding details to avoid spoilers.) So one of the following must be true: * You can destroy barrels, and I'm just not doing it right. * You should be able to destroy barrels, but the code is broken. * There is another way to get to that square that I've missed. * The map is broken. Can someone tell me which one it is? --PC From crow at bear.cs.dartmouth.edu Tue May 1 14:38:41 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] resetting race Message-ID: <200105011938.f41Jcfk24806@bear.cs.dartmouth.edu> When I start crossfire, it tells me: Reading races from /usr/local/share/crossfire/races... Resetting race to undead from Wraith for archetype Wraith Resetting race to faerie from elf for archetype elf Resetting race to dragon from Quetzalcoatl for archetype quetzalcoatl Resetting race to fire_elemental from fireborn for archetype fireborn Resetting race to human from barbarian for archetype barbarian Resetting race to human from cleric for archetype cleric Resetting race to human from mage for archetype mage Resetting race to human from ninja for archetype ninja Resetting race to human from priest for archetype priest Resetting race to human from swashbuckler for archetype swashbuckler Resetting race to human from thief for archetype thief Resetting race to human from viking for archetype viking Resetting race to human from warrior for archetype warrior Resetting race to human from wizard for archetype wizarddone. I assume that this is correcting for the race/class split. Shouldn't the changes be made to the data files so that that doesn't need to be done anymore? It seems like a bit of historical ugliness that doesn't belong in 1.0. --PC From andi.vogl at gmx.net Tue May 1 15:24:58 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] destroying barrels In-Reply-To: <200105011616.f41GGu324497@bear.cs.dartmouth.edu> Message-ID: <000001c0d27c$cc7262c0$77e6fea9@kyle> > In the recent discussion concerning destroying boulders and barrels, > I was surprised to learn that you are supposed to be able to destroy > barrels. Is this right? I can't seem to do it. I've tried using > several different weapons with different attack types, and it always > tells me that I miss. I've tried fireballs. What works? > > In particular, it seems that you must destroy a barrel for a critical > step in getting the white dragon shield. (I'm avoiding details to > avoid spoilers.) > > So one of the following must be true: > > * You can destroy barrels, and I'm just not doing it right. > * You should be able to destroy barrels, but the code is broken. > * There is another way to get to that square that I've missed. > * The map is broken. > > Can someone tell me which one it is? Barrels and boulders used to be destroyable with all kinds of bullet spells. A few months ago large parts of the attack code have been rewritten/cleaned up. During this process the ability to destroy barrels got removed. I have no idea if that was done intentional or not. There's only few maps that really needed this feature, reception water tower (-> white dragon shield - wds) is one of them. As workaround for this problem I removed the no_spell area under the critical barrels in the reception water tower, a while ago. So you can jump over them with dimdoor. Yet, the water tower quest is still in pretty bad shape altogether, but that is another story... Solving this barrel-problem is not very urgent. We could either make barrels destroyable again, or we fix up the few maps to work without that feature. Andreas V. From peterm at tonks.EECS.Berkeley.EDU Tue May 1 16:50:19 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] Resist godpower +30 In-Reply-To: Your message of "Tue, 01 May 2001 14:52:40 +0200." <000201c0d23d$9d2ec560$ab1efea9@kyle> Message-ID: <200105012150.f41LoKe00670@tonks.EECS.Berkeley.EDU> > Thank you for removing the godpower ring for now peter. > I don't want to appear stubborn, but since this issue will Well, I don't mind appearing stubborn :) I think we both have valid arguments and no doubt we'll keep hammering at this until everyone is satisfied, or at least, tired. > I have designed many high level maps in pupland, and I do > have some experience there. If you want to create a melee monster > that can threaten a high level character, there's only two > possible ways: > > 1) You hand "harmless" attacktypes to the monster, but many > of them (fire/cold/physical etc). Since players can drink potions > and wear protections you must set the monster to extremely > high level (>100) and insane strenght. If you don't, players > would soon smite your "highlevel monster" like an ant. > > What is the outcome? A monster that kills players instantly > unless they know exactly about all attacktypes of that monster. > Now tell me: Isn't that the exact opposite of what you want peter? You raise a good point here. My reasoning is that demanding that the player take potions in order to survive imposes enough cost to balance this. Once he's got enough potions in him, I think he SHOULD be able to whack these monsters. I agree, though, that you shouldn't make the monsters so powerful they destroy an unprepared character before he has any possibility of fleeing. This in effect means that a player with 95 resist would have little to moderate trouble. I, however, think this is fine. It's the whole reason we allowed the 90 and 95 potions in the first place: to let players survive in the face of overwhelming firepower--ESPECIALLY when they're playing through lag. > 2) Second, you hand godpower (or weaponmagic) to the monster. Are we talking melee attack with godpower/weaponmagic or via spells? There IS protection from melee attack: a very high AC, which is *permanent* and which a player can attain relatively easily. And there IS protection from cause wounds and comet, the two spells bearing godpower and weaponmagic: reflect spells. However, reflect spells is unreliable in face of what high-level monsters that spew out cause wounds and comet/swarm in high volume. A bit of lag, a few hits, and before you know it you're dead--and your only fault was being unlucky with the Internet. > Since there is no protection from these, the monster can be > of sane strenght. A player who is not well-prepared has > a good chance to survive here. > Instead of cowardly hiding in equipment, the player needs to > work with healing spells/potions against this type of > monster. A tactic that seems quite interesting in addition. cowardly hiding in equipment or potions is the only recourse for a player who is suffering from lag. He cannot count on being able to click that healing potion or press that key and have the keypress arrive in time to save his ass. > > Alternately, use weaponmagic, and remove > > "prot weaponmagic" from the carrillium apron and from that > > hammer someone just told me about. > > Okay, be it weaponmagic or godpower doesn't really make much > difference. Personally I favour godpower. Not only that it sounds And I favor weaponmagic, for this reason: in this game, we have many gods in opposition. I think it makes sense for one to counteract another's power. > like being the "ultimate thing" - Important spells like > cause wounds, retributive strike and diseases rise and fall with > this attacktype. (E.g. Serious protection from disease can easily > make it abusive again). I'll respond to each of these separately: 1) Cause wounds: why not have a god of Good protect you from harm from cause wounds? counterspell and sanctuary and counterwall and reflect spell and directors all offer protection. What's so horrible about 51%? 2) Retributive strike: this spell is so overpowered that 51% is going to be overwhelmed. I also can't see this spell as important. When is it used on players? 3) Disease: players, by and large, easily avoid the effects of their own diseases anyway. The key to balance of them is to require enough grace cost/kill to make them OK: this has been done for all the diseases to my knowledge. Players can simply loose their disease and run away before it gets them, leaving the pestilence to do their work. Furthermore, nothing is sacred about using Godpower as the attacktype for a disease. Weaponmagic could be used instead. However, I have no problem with one good god aiding your survival vs. an affliction due to another god. As for using diseases ON players, you can easily make them fatal unless cured no matter WHAT protection is used, even 99% godpower, and STILL give the player reasonable time to save his own ass, even a lagged player. On aside: you keep making the argument that once we allow ANY defense vs. godpower, we allow UNLIMTED defense against godpower. This is not true. We can forbid protection above 51%, (or 75%, or 80%, whatever level we decide is OK for lagged players.) Weaponmagic defense has been limited to less than 51% for years now without any inflation. > Besides, I would miss these spells in my (map-making) repertoire > if they became harmless due to protective items. Please don't argue against the straw man of 90%+ resistance to godpower anymore, which no one has advocated. 51% is by no means total immunity, 51% fire protection, for example, is of no use vs. dragons. > However, if the majority favours weaponmagic to rule over > godpower, guess I can live with that. > > I would only like to have at least one attacktype without any > means of protection (for players). And that should then be > kept as a strict "rule" in future, so people can rely on it for > mapmaking. I also can accept weaponmagic as being resistance banned for players. I would prefer not, since I think players should be able to defend themselves vs. what is thrown at them. But you say you need an unavoidable attacktype for Pupland. I'm not qualified to comment on pupland, I just hope you haven't made it too hard. Barely possible for the pinnacle of crossfire players playing with low lag might be a bit too much to expect. But the pupland set is the best of the mapsets in the game, and so I think we must give weight to your demand for an unavoidable attack. PeterM From mwedel at scruznet.com Tue May 1 20:20:10 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:45 2005 Subject: [CF-Devel] Resist godpower +30 In-Reply-To: <200105012150.f41LoKe00670@tonks.EECS.Berkeley.EDU> Message-ID: Just some various notes on this discussion: Why AC may be a reasonable defense against physical attacks, realistically it probably is not a very good one. AC/to hit is based on a d20 roll. At low levels, you can balance this pretty good. But if you have a level 100 monster, it basically means you need a -100 AC to be immune, and if your ac is -80 or worse, it will hit you all the time. To be honest, I don't know what the best AC players at high level get. I'm guessing in the -20 to -30 range? You could try adjusting the monster to not always hit, but the problem is that if at -30 the monster hits 50% at of the time, at -20 it will hit 100% of the time. I could see this as very difficult to balance (at it could basically fall into the same protection scheme - player maxes out there AC and is now safe). I agree to AV to the extent that once you start adding items with godpower protection, you may as well assume that players will be able to get 90% protection in that (or anything else). Map makers will see godpower protection items already out there and figure it is OK to add more in, same with new arch's and the like, and pretty quickly you could see where this goes. Its much easier to have a strict policy (no godpower/weaponmagic/whatever protection items) than to try to say something like 'try not to put too many of these in'. As far as survivability and lag: This is a concern, but something tough to deal with. If it is made such taht a player with lag can survive otherwise deadly situations, then that means someone without lag has that much an easier time at it. Now I do think many of the attacks are too deadly too quickly. bolt spells don't last very long but do a lot of damage in that quick time frame. Even most had to hand combats against monsters go pretty quickly. The end result is that the same thing happens against the player. Don't notice that bolt spell under you quick enough? Your toast, with or without lag. While there are lots of puzzles and what not, crossfire really is a fast action game, and I don't know how much we should try to compensate for laggy connections. If someone has severe lag, they are really playing at their own risk. Hopefully, crossfire will get more out there so that more players will have local servers with low lag time, and this won't be much a problem. One reason i play on csua is the <15 ms round trip ping times (compared to about 80 ms for real-time). no fault of real-time of course - it just the csua server is located in a much closer proximity. But when the connection is even really laggy to csua, I park the character or do something safe (visit shops for example) - I'm not going to go and do something dangerous and get killed by lag. From mwedel at scruznet.com Tue May 1 20:35:11 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] resetting race In-Reply-To: <200105011938.f41Jcfk24806@bear.cs.dartmouth.edu> Message-ID: Actual, this ugliness is from far before the race/class split. What was basically done was the addition of a lib/races file which overrides the race value in the archetypes file. I'm not positive of all the motivation that was behind it. One thing it did do was make it easier to set the races properly (as you only had to modify the races file, and not all the individual arch files). One other thing I do notice is that the race listings in the races file is used for various monster summoning spells. I beleive the listing in the races file is ordered by difficulty (ie, the first entry in the human race is the easiest, followed by next tougher, etc). Generate these race lists from the archetypes could be done, but ordering would be harder (although, I would think the exp value would be a fair indicator). the messsages below are basically harmless, but at the same time, pointless. Appropriate race entries should be aded for those files - getting rid of the races file may be something to look at for later releases. On Tue, 1 May 2001, Preston Crow wrote: > When I start crossfire, it tells me: > > Reading races from /usr/local/share/crossfire/races... > Resetting race to undead from Wraith for archetype Wraith > Resetting race to faerie from elf for archetype elf > Resetting race to dragon from Quetzalcoatl for archetype quetzalcoatl > Resetting race to fire_elemental from fireborn for archetype fireborn > Resetting race to human from barbarian for archetype barbarian > Resetting race to human from cleric for archetype cleric > Resetting race to human from mage for archetype mage > Resetting race to human from ninja for archetype ninja > Resetting race to human from priest for archetype priest > Resetting race to human from swashbuckler for archetype swashbuckler > Resetting race to human from thief for archetype thief > Resetting race to human from viking for archetype viking > Resetting race to human from warrior for archetype warrior > Resetting race to human from wizard for archetype wizarddone. > > I assume that this is correcting for the race/class split. > > Shouldn't the changes be made to the data files so that that doesn't need > to be done anymore? It seems like a bit of historical ugliness that > doesn't belong in 1.0. > > --PC > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Tue May 1 22:24:39 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] destroying barrels References: <000001c0d27c$cc7262c0$77e6fea9@kyle> Message-ID: <3AEF7DF7.70A6864B@scruz.net> I only did a quick look at the code, and haven't tested this. But it appears that all barrels need to be destroyable is some hp value that is non zero. boulders would also need some material type I believe, but physical attacks would still otherwise be able to destroy them. someone should probably verify this will work, and then perhaps update the maps that really need this feature to work. From mwedel at scruz.net Tue May 1 22:35:55 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] poisoning & demonologic tower References: <000101c0d22d$73e62dc0$ab1efea9@kyle> Message-ID: <3AEF809B.B18BDD23@scruz.net> Andreas Vogl wrote: > > Depending on the attacktype may determine how easy/hard this is to do. > > For drain, it would not be really hard to reduce the amount that a > > drain hit takes (instead of 10% by default, maybe 3% or the like) as > > well as put some upper limit (100,000 or something) for high level > > characters. > > Yes, good idea. Maybe the upper limit could be dependant on level- > difference between attacker<->defender? Say, a grimreaper couldn't > drain much from a level 100+ player. > Anyways, the upper limit for draining shouldn't be high. One should > barely ever loose a level from it. Not positive if level diff is really needed. It strikes me that might put more reason for map makers to make the drain monsters they put in really high level so they do more of a wammy. But the amount to be drained could be determined by the level diff. For example, to go from level 9 (250,000 exp) to 10 (250,000) would mean the baseline drain value if you are level 10 is 250,000. However, at level 100, this baseline would be 1600000 even though your exp total is 118100000 (or thereabouts). In this way, the amount you would get drained would basically be around 1 level if you had no protection and presuming we did not change the algorythim currently used (grimreapers survive for 10 hits) > > > For acid, [...] It has been sugested that items should have quality > > ratings and thus get repaired. > > I agree this is a pain in most RPGs and we should consider > this with care. One possibility is just acid (or other specialized attacks) damage equipment. However, the point remains that if you can pick up your -4 helm of gorokh and just go to town and get it fixed, acid at best it just an annoying attack (not it still does damage of course, but if repairing items becomes fairly trivial, might as well just remove the damage item feature). The only way that might make this challenging is to have repair item scrolls or the like, but if they are too rare, people will hoard them like crazy (and once again, have them when needed), and if they are too common, it once again has no effect. The only reasonable solution I have would be along the one peter suggested - a monster gets one item damage attack against the player, and all attacks after that are just for damaging. In this case, your items might slowly get dinged up, but not noticing that one rust monster fast enough doesn't mean everything you have ends up at -4. > > idea for fixing at least some of these: > > confusion: If you have a resistance, then perhaps give some chance > > based on resistance for the player to move the direction they want. > > Thus, if you are 50% resistant, you will still wonder around somewhat, > > but basically move in the direction youu want to, and hopefully get > > away from the creature. > > slow: amount of slowdown could be affected by resistance. So if you > > are 50% resistant, you are only slowed by 50% of what youu would > > have been otherwise. Once again, this should let you get out of danger. > > paralyze: No good solution. This is really either an on/off effect. > > Perhaps just do away with paralyzation as a monster attack, and leave it > > for players? Currently, players beyond a certain level are immune > > anyways because they get an immunity item for it. > > Great suggestions for confuse and slow. It's true that 90% resistance > to these attacktypes is much nicer when it really helps. > > I would leave paralyze like it is, till we have some idea what to > do with it. I have different ideas with paralyze, but if players are able to get high paralyze resistant values, they don't work out (my idea was basically to just make the player really slowed based - you may get to move 1/10'th the rate youu did before). From mwedel at scruz.net Tue May 1 22:43:12 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] The answer to ON/OFF attacktype protection! References: <200105010535.f415Zvh31581@tonks.EECS.Berkeley.EDU> Message-ID: <3AEF8250.A29DC629@scruz.net> Peter Mardahl wrote: > > I have *the* answer to on/off attactype protection. > > I was considering how the Spell of Peace and the Face of Death > are overpowered. > > The problem is that these guys get MANY chances at the same monster. > > The fix? > > You get ONE chance to hit the monster with YOUR Face of Death spell > and ONE chance to Peace him. > > After a fail, you put an object into the 'victim' which prevents that > spell cast by you ever working on him again. (Unless you advance > a level and try again.) > > We can do this for paralyzation too. Reasonable ideas. Perhaps somehow mark those objects so that at least when the player goes to get saved, it won't save all those marking objects. Or alternatively, give them some speed and have them expire automatically. This means for example if you are fighting a skull and he casts paralyze on you, and you do not succumb, this object is put in your inventory and gives you say a hundred ticks before it expires - all paralyze the skull casts until that expiration you are automatically immune to, but if you don't kill that skull within that hundred ticks, he could hit you again. This works better for monsters casting on players than vice versa. 100 ticks is typically enough times for a player to kill a monster, but if a player wants to try that spell on a monster, 100 ticks is not a very long waiting time (roughly 12 seconds - not 100 ticks is not an absolute value - it could be 250, or 1000 for that matter, but in all cases, player would almost certainly be able to kill the monster, but not so long that the player couldn't wait it out if the monster is getting that immunity.) I could also see some odd abuses - players wondering into area of paralyze but not on a direct diagonal to get this immunity, and such that even if they fail, they won't get clobbered by bolt spells. The other problem is that paralyze can be just very deadly - if you don't make that first saving throw, youu are likely to be toast if youu are in direct line of fire. From peterm at tonks.EECS.Berkeley.EDU Tue May 1 23:03:27 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] The answer to ON/OFF attacktype protection! In-Reply-To: Your message of "Tue, 01 May 2001 20:43:12 PDT." <3AEF8250.A29DC629@scruz.net> Message-ID: <200105020403.f4243R006854@tonks.EECS.Berkeley.EDU> > Reasonable ideas. Perhaps somehow mark those objects so that at least when > player goes to get saved, it won't save all those marking objects. Or > alternatively, give them some speed and have them expire automatically. Yes, an expiring force was what I had in mind. How long the force lasts can depend on the strength of the resistance. > expiration you are automatically immune to, but if you don't kill that skull > within that hundred ticks, he could hit you again. Yes, exactly. For paralyze it can be 100 ticks. For Face of Death or Peace it can be 1000, or more. > I could also see some odd abuses - players wondering into area of paralyze b > not on a direct diagonal to get this immunity, and such that even if they fai > they won't get clobbered by bolt spells. > that first saving throw, youu are likely to be toast if youu are in direct li > of fire. Yes, players could certainly learn to work this system to some degree but it offers the possibility of significant improvement. The duration of the temporary protection could depend on the player's resistance. PeterM From hsteoh at quickfur.yi.org Tue May 1 23:06:22 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] Invisible object bug Message-ID: <20010502000622.A3739@crystal> If you click on a square that has an invisible object on top, it will report that you see nothing; but when there's no invisible object on top, then it will list out what you see. T -- MS Windows: 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand 1-bit of competition. From the_real_tomble at hotmail.com Tue May 1 23:11:36 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] destroying barrels Message-ID: Mark Wedel wrote: >I only did a quick look at the code, and haven't tested this. >But it appears that all barrels need to be destroyable is >some hp value that is non zero. Does all this also apply to freezing them? That has certainly worked in the past (such that you can pick up the heavy icecubes, and thaw them out later), but I forget whether I've tried since installing this release. Tomble (Tom Barnes-LawrencE) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From the_real_tomble at hotmail.com Tue May 1 23:43:49 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] poisoning & demonologic tower Message-ID: Mark Wedel wrote: >>>For acid, [...] It has been sugested that items should have >>>quality >>>ratings and thus get repaired. >>I agree this is a pain in most RPGs and we should consider >>this with care. >One possibility is just acid (or other specialized attacks) >damage equipment. > >However, the point remains that if you can pick up your -4 helm of >gorokh and >just go to town and get it fixed, acid at best it just an annoying >attack (note it still does damage of course, but if repairing items >becomes fairly trivial, might as well just remove the damage item >feature). > >The only way that might make this challenging is to have repair >item scrolls or the like, but if they are too rare, people will >hoard them like crazy (and once >again, have them when needed), and if they are too common, it once >again has no effect. How about build some limiting factor into the repair- say the acid decreases the magic rating, but also adds "wear" to the item. The repair restores the magic rating to its original, but only removes *most* of the wear (and then note that that wear that was left is permanent wear). When the amount of wear that is on the item reaches some level, say 10, it falls to pieces. (lets suppose if this is implemented, we add archs "wear_perm" and "wear_temp", which are placed in item's inventory, and a proportion of wear_temp is turned to wear_perm when repaired. Or something) That, or when the item is repaired, it is only restored completely to its "qualitly rating" if it has just suffered one point of damage. If it has lost more than that, it's quality rating is *also* reduced (probably just by 1). So if your +4 item gets badly damaged, it can only ever be repaired to +3 after that, and so on. Also, if repair is implemented as a skill, it should take A LONG TIME! Tomble (Tom Barnes-LawrencE) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From mwedel at scruz.net Tue May 1 23:50:17 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] destroying barrels References: Message-ID: <3AEF9209.24204FCE@scruz.net> Tom Barnes-Lawrence wrote: > > Mark Wedel wrote: > >I only did a quick look at the code, and haven't tested this. > >But it appears that all barrels need to be destroyable is > >some hp value that is non zero. > Does all this also apply to freezing them? That has certainly > worked in the past (such that you can pick up the heavy icecubes, > and thaw them out later), but I forget whether I've tried since > installing this release. It should apply to basically all attack forms on the barrel. So giving it a hp value should make them freezable as well. From mwedel at scruz.net Wed May 2 02:28:28 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] Invisible object bug References: <20010502000622.A3739@crystal> Message-ID: <3AEFB71C.9FDAA725@scruz.net> "H. S. Teoh" wrote: > > If you click on a square that has an invisible object on top, it will > report that you see nothing; but when there's no invisible object on top, > then it will list out what you see. Fixed in cvs. From crow at bear.cs.dartmouth.edu Wed May 2 10:45:45 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] destroying barrels Message-ID: <200105021545.f42FjjY26527@bear.cs.dartmouth.edu> Ahh. I see that I can, indeed, dimension door to where I need to get, but only if I do it at the right time. So I can complete all four towers. Good deal. --PC From crow at bear.cs.dartmouth.edu Wed May 2 10:49:09 2001 From: crow at bear.cs.dartmouth.edu (Preston Crow) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] poisoning & demonologic tower Message-ID: <200105021549.f42Fn9726577@bear.cs.dartmouth.edu> Why should repairing be a pain? In my experience, once you can get an item once, you can get a bunch of them, so if repairing is a pain, you just horde a collection of them. The only exception was when I got the Katana of Matsume in the raffle. --PC From mwedel at scruznet.com Wed May 2 14:12:59 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] poisoning & demonologic tower In-Reply-To: <200105021549.f42Fn9726577@bear.cs.dartmouth.edu> Message-ID: On Wed, 2 May 2001, Preston Crow wrote: > Why should repairing be a pain? Because if it isn't, there really isn't any point to damage it in the first place? > > In my experience, once you can get an item once, you can get a bunch of > them, so if repairing is a pain, you just horde a collection of them. > > The only exception was when I got the Katana of Matsume in the raffle. I think this depends. At high levels, probably most all your items are specific artifacts that you can get from someplace (or are in fact immune to acid attacks, so you don't need to worry about them anyays.) But at low levels, it may be the random items that are very rare. For exapmle, the character I'm currently playing on csua found a helm of sorig (might have even been +1 when I found it). I don't think I've seen another since that time. So when the one I had got corroded down to -4, I gave it up and just went for the full helm +2 (until I find something better). So at least in that case, I would have gone to some lengths to get it repaired. If it was trivially easy (ie, just go to the shop and pay some amount of money), then the corrosion wouldn't have bothered me at all. That said, easy repairability could be allowed, in which case for acid monsters, what becomes fearsome is the damage they might do, and not the corrosion. Which may be perfectly fine. It just diminishes that danger of acid monsters quite a bit, and since there are not a lot of acid monsters, reduces the need for protection from them abit. From echter at informatik.uni-rostock.de Wed May 2 17:01:30 2001 From: echter at informatik.uni-rostock.de (Jan Echternach) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS: crossfire/server gods.c,1.17,1.18 In-Reply-To: ; from crossfire-cvs-admin@lists.sourceforge.net on Fri, Apr 27, 2001 at 11:19:56PM -0700 References: Message-ID: <20010503000130.A15521@hokkaido.informatik.uni-rostock.de> On Fri, Apr 27, 2001 at 11:19:56PM -0700, crossfire-cvs-admin@lists.sourceforge.net wrote: > RCS file: /cvsroot/crossfire/crossfire/server/gods.c,v > + move_player(pl,(pl->facing + 4)%8); /* back him off the way he came. */ This looks wrong. I think it should be move_player (pl, absdir (pl->facing + 4)); /* back him off the way he came. */ -- Jan From echter at informatik.uni-rostock.de Wed May 2 17:26:44 2001 From: echter at informatik.uni-rostock.de (Jan Echternach) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] On the uselessness of lifesaving In-Reply-To: <200104300752.f3U7qeG27697@tonks.EECS.Berkeley.EDU>; from peterm@tonks.EECS.Berkeley.EDU on Mon, Apr 30, 2001 at 12:52:40AM -0700 References: <200104300752.f3U7qeG27697@tonks.EECS.Berkeley.EDU> Message-ID: <20010503002644.B15521@hokkaido.informatik.uni-rostock.de> On Mon, Apr 30, 2001 at 12:52:40AM -0700, Peter Mardahl wrote: > You know those amulets of lifesaving which no one ever wears > beccause the second you die, whatever killed you gets another > chance and probably does it again right away? It is not useful when you wouldn't normally survive a situation. But it's genuinely useful to protect you from small lag or a small mistake because it lets you survive twice as long. I'm using it whenever I can, provided that I don't need a different amulet for its protections or special properties. IMHO it's already worthwhile wearing it if it is saving your valuable expirience points every other time. Note that from this point of view, 50% protection is also a lot, because it also lets you survive twice as long. But you're more tempted to plan using up this extra time because you wouldn't lose a rare amulet of lifesaving. > How about we make lifesaving bring you back.... Alive.... > to your savebed? I'd rather see it heal poison and disease. -- Jan From peterm at tonks.EECS.Berkeley.EDU Thu May 3 04:06:40 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS: crossfire/server gods.c,1.17,1.18 In-Reply-To: Your message of "Thu, 03 May 2001 00:01:30 +0200." <20010503000130.A15521@hokkaido.informatik.uni-rostock.de> Message-ID: <200105030906.f4396en08567@tonks.EECS.Berkeley.EDU> Right you are. Will fix in CVS. PeterM > On Fri, Apr 27, 2001 at 11:19:56PM -0700, crossfire-cvs-admin@lists.sourcefor >ge.net wrote: > > RCS file: /cvsroot/crossfire/crossfire/server/gods.c,v > > > + move_player(pl,(pl->facing + 4)%8); /* back him off the way he >came. */ > > This looks wrong. I think it should be > > move_player (pl, absdir (pl->facing + 4)); /* back him off the way he came. > */ > > -- > Jan > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From michael.toennies at nord-com.net Thu May 3 16:54:32 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] dx client version 1.20 Message-ID: New dx client version 1.20 - some small bug fixes - cmd line history (use cursor keys) download: http://mids.student.utwente.nl/~michtoen/crossfire From the_real_tomble at hotmail.com Thu May 3 23:40:52 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] Unclear crash Message-ID: Whilst trying to catch up on some of the mail I hadn't read yet, and generally sort out my inbox, I noticed Mark talking about maybe releasing V1 next week (or maybe post was from last week), so I thought I should point out a crash I had 2 or 3 days ago- (v0.98) I hadn't mentioned it before as I hadn't got any logfile or any sort of messages, so it seemed of very little use, but it was a *server* crash, not a dropped client or other bug, and I hadn't noticed any references to such crashes recently. Basically, I'd connected to my server to check one of my maps was doing what I'd expected, then got my character back to a nearby inn to logout again, and altered the map I'd checked. I waited 15 minutes (I'd set v.low reset), then logged back in. Character appeared back in the inn, as expected. I resized the client window, and then noticed that it was asking me to choose a server again, and the game window was blank. Tried to reconnect, and realised the server was dead (I hadn't been using crossloop). .. Obviously without a logfile you can't really tell anything, but the inn map I was logging into would also have been going to reset something like the same time as I logged in. It had nothing fancy, just floors, walls, savebeds and an exit. As I say, my character managed to log in just before the server crashed. Sorry there was no more useful info than that, Tomble PS-I do realise that whatever it was may have been fixed in CVS, but then again, it might not, so I figure maybe it's better to say. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From mwedel at scruz.net Fri May 4 21:42:28 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] Unclear crash References: Message-ID: <3AF36894.801BBABB@scruz.net> There was a bug in 0.98.0 (and probably many releases earlier) that would cause the server to crash if a character saved, but left themself connected to the server. The description described seems a little similar to that, and a little different. But it is very hard to try and figure this out just from a description. Even log file output tends not be be very useful - typically, a crash dump with stacktrace is the minimum starting point to figure out the problem. Often, that isn't even enough - further investigation is needed (values of variables and so forth), but some times a stack trace is sufficient to figure the function, and just inspection of the function can sometimes figure it out. From dnh at hawthorn.csse.monash.edu.au Sun May 6 01:30:26 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:46 2005 Subject: [CF-Devel] devoureres Message-ID: I request we seriously revise drain, currently it is COMPLETELY useless to players, and COMPLETELY deadly against players. A while ago I suggested we add life stealing, I think we should revisit that thought. I was just mucking around with a devourers character and this is what I found, * Can't gain spell levels with any ease because of den fire * Can't use physical because of drain (you only get half the exp for each kill) * Not only is disease to far away to get (avatar is crap) but any useful spell is also way to hard to get. * red death isn't much use without small pox (originally you could slow everything with smallpox, then zap them with red death). * general fighting is really screwed, protection spells and restoration are repelled, fire -30, hp -1!. When I first created the 'new pantheon' I hoped devourers would get some serious meat in some respect (I really wanted to change drain to give grace points + exp). I think it is time we considered that possibility, currently I can see 2/10 reasons to play devourers and 8/10 not to =). Fair enough that some will be more powerful than others, but considering undead is such a major area of crossfire I think the god of undead could give alittle more =). dnh From Philipp.Currlin at t-online.de Mon May 7 02:24:05 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] bugs in gcfclient Message-ID: <3AF64D95.1010706@epost.de> Hi Two bugs that are around for some time now: 1. With the current version of gcfclient you can't scroll the list of servers if you updated them before you started playing. 2. If you say something that is longer than 250 bytes the client crashes. (This applies to both, client and post-1-0 client) Phil From Philipp.Currlin at t-online.de Mon May 7 06:45:13 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] devourers Message-ID: <3AF68AC9.6080203@epost.de> Hello When you start worshipping devourers you become undead. However when you change gods again you stay undead and you will be very vulnerable to holy word. PhilC From dnh at hawthorn.csse.monash.edu.au Mon May 7 06:56:54 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] devourers In-Reply-To: <3AF68AC9.6080203@epost.de> Message-ID: I am happy to try to solve this, but I will need some help =). Sounds like a great way to improve my C skills, I have a fair idea what to do. We need to check if the player is a wraith (or even better if op->race makes it undead) and if it isn't restore FLAG_UNDEAD. I had alook through the code but I can't seem to find how to check if that flag is called by the race (or even class.. necromancer anyone?). Thanks, dnh On Mon, 7 May 2001, Philipp Currlin wrote: > Hello > > When you start worshipping devourers you become undead. However when you > change gods again you stay undead and you will be very vulnerable to > holy word. > > > PhilC > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From gros at magellan.fpms.ac.be Mon May 7 14:37:41 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] devourers In-Reply-To: References: Message-ID: <01050715374100.02536@Terminus.magellan.fpms.ac.be> Le Lundi 7 Mai 2001 07:56, vous avez ?crit : > I am happy to try to solve this, but I will need some help =). Sounds like > a great way to improve my C skills, I have a fair idea what to do. > We need to check if the player is a wraith (or even better if op->race > makes it undead) and if it isn't restore FLAG_UNDEAD. I had alook through > the code but I can't seem to find how to check if that flag is called by > the race (or even class.. necromancer anyone?). > > Thanks, dnh > > On Mon, 7 May 2001, Philipp Currlin wrote: > > Hello > > > > When you start worshipping devourers you become undead. However when you > > change gods again you stay undead and you will be very vulnerable to > > holy word. > > > > > > PhilC > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel Here is a bugfix for that. Change the update_priest_flag to: void update_priest_flag (object *god, object *exp_ob, uint32 flag) { if(QUERY_FLAG(god,flag)&&!QUERY_FLAG(exp_ob,flag)) SET_FLAG(exp_ob,flag); else if(QUERY_FLAG(exp_ob,flag)&&!QUERY_FLAG(god,flag)) { if (!(QUERY_FLAG(arch_to_object(exp_ob->arch),flag))) { printf("Change\n"); CLEAR_FLAG(exp_ob,flag); } else { printf("Don't Change\n"); }; }; } From dnh at hawthorn.csse.monash.edu.au Mon May 7 09:04:02 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] devourers In-Reply-To: <01050715374100.02536@Terminus.magellan.fpms.ac.be> Message-ID: Ahh excellent... someone else can cvs commit im busy working on this angel then im sleeping.. dnh On Mon, 7 May 2001, gros wrote: > Le Lundi 7 Mai 2001 07:56, vous avez écrit : > > I am happy to try to solve this, but I will need some help =). Sounds like > > a great way to improve my C skills, I have a fair idea what to do. > > We need to check if the player is a wraith (or even better if op->race > > makes it undead) and if it isn't restore FLAG_UNDEAD. I had alook through > > the code but I can't seem to find how to check if that flag is called by > > the race (or even class.. necromancer anyone?). > > > > Thanks, dnh > > > > On Mon, 7 May 2001, Philipp Currlin wrote: > > > Hello > > > > > > When you start worshipping devourers you become undead. However when you > > > change gods again you stay undead and you will be very vulnerable to > > > holy word. > > > > > > > > > PhilC > > > > > > _______________________________________________ > > > crossfire-devel mailing list > > > crossfire-devel@lists.real-time.com > > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > Here is a bugfix for that. Change the update_priest_flag to: > > void update_priest_flag (object *god, object *exp_ob, uint32 flag) { > > if(QUERY_FLAG(god,flag)&&!QUERY_FLAG(exp_ob,flag)) > SET_FLAG(exp_ob,flag); > else if(QUERY_FLAG(exp_ob,flag)&&!QUERY_FLAG(god,flag)) > { > if (!(QUERY_FLAG(arch_to_object(exp_ob->arch),flag))) > { > printf("Change\n"); > CLEAR_FLAG(exp_ob,flag); > } else { > printf("Don't Change\n"); > }; > }; > } > From the_real_tomble at hotmail.com Mon May 7 20:30:43 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] Unclear crash Message-ID: I've pretty much cornered it now, but I'm not sure what to make of it- my bad or CF's? Further experimentation had yet another server crash, but approx 20 minutes after logging in.So I figured it was almost certainly to do with map resets. As I'd put in a unique-item tile with machinery just before the 1st crash, I figured that may be involved. ... And then I realised that there *had* been a logfile after all, but it'd been dumped in my root directory. (Mebbe you should change compile-time defaults for that?) Looking through to the appropriate times, I found in each occasion: resetting map tomble/prototypes/keep_prot-pt6 Internal error in update button(pedestal) Internal error in update button(pedestal) Internal error in update button(button) Internal error in update button(plate) Internal error in update button(plate) Fatal, too many errors (Sorry I'm paraphrasing here, logs are on other machine which is switched off.If you want an exact quote I'll look tomorrow) SO you get the point, there's no actual crash-bug as such, it's just bailing out because of the errors, fair enough. But I don't get what exactly is wrong with my maps: At other points in the log, it had also produced these errors, but in smaller numbers- It looks as though the map I was working on maybe wasn't horrifically screwed up, it merely gave CF *that bit* more trouble. Apart from earlier versions of the Castle Lament map, one of the market stalls (tomble/squishi/market/stall_2, IIRC) also caused errors. But for the most part, both seem to work OK. > There was a bug in 0.98.0 (and probably many releases earlier) >that >would cause the server to crash if a character saved, >but left themself connected to the server. Well, at least we can now say its not that. > But it is very hard to try and figure this out just from >a description. Any use now? I've not released the version of the map that caused the crash, but the version that has been released, plus the 2nd stall of the market do give that error (but less times), so you or someone else should be able to verify crossfire's complaints, and perhaps figure out what *exactly* it's upset about? (according to Dnh, my initial release is already in the unlinked directory of the map archive). If necessary, I can upload the specific map to ftp, or get a proper quote of the errors in the logfile. Bye for now, Tomble _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From mwedel at scruz.net Tue May 8 00:09:16 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] Unclear crash References: Message-ID: <3AF77F7C.AACCA6B7@scruz.net> As said, the program is exiting because it gets too many errors. update_button is called whenever the button is pressed/activated. If you are using a button/plate, then all this takes is for some object (of appropriate weight) be be on the space. Now what the error really means is that one of the objects that had the same connected value has 'disappeared'. disappeared could be any of various causes -a monster that was killed, or some other destroyable objects. As currently implemented, connected objects must be permanent. My guess is you have some objects with connected values that are not permanent (note it doesn't make a difference code wise that these destroyed connected objects may not do anything - just anything with a connected value is put on the connected object list at load time). Tom Barnes-Lawrence wrote: > > I've pretty much cornered it now, but I'm not sure what to make > of it- my bad or CF's? > Further experimentation had yet another server crash, but approx > 20 minutes after logging in.So I figured it was almost certainly > to do with map resets. As I'd put in a unique-item tile with > machinery just before the 1st crash, I figured that may be involved. > ... > And then I realised that there *had* been a logfile after all, but > it'd been dumped in my root directory. (Mebbe you should change > compile-time defaults for that?) > Looking through to the appropriate times, I found in each occasion: > resetting map tomble/prototypes/keep_prot-pt6 > Internal error in update button(pedestal) > Internal error in update button(pedestal) > Internal error in update button(button) > Internal error in update button(plate) > Internal error in update button(plate) > > Fatal, too many errors > (Sorry I'm paraphrasing here, logs are on other machine which is > switched off.If you want an exact quote I'll look tomorrow) > SO you get the point, there's no actual crash-bug as such, it's > just bailing out because of the errors, fair enough. From Philipp.Currlin at t-online.de Tue May 8 07:26:21 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] yet another bug in gcfclient Message-ID: <3AF7E5ED.9030000@epost.de> Hi When I try to change servers with the current version of the post-1-0 client it crashes and I get these messages: Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter) serial 114538 error_code 9 request_code 62 minor_code 0 Gdk-ERROR **: BadPixmap (invalid Pixmap parameter) serial 114694 error_code 4 request_code 56 minor_code 0 PhilC From highway at cstone.net Tue May 8 15:54:35 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] devourers References: <01050715374100.02536@Terminus.magellan.fpms.ac.be> Message-ID: <3AF85D0B.A20DEB94@cstone.net> gros wrote: > Here is a bugfix for that. Change the update_priest_flag to: Just out of curiousity, if a wraith joins the Devourers, then changes away, will this bug fix make the wraith non-undead? :) Thanks, SeanMike From meeg at mamia.prninfo.com Tue May 8 15:50:59 2001 From: meeg at mamia.prninfo.com (Meegwun South) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] Demonology tower Message-ID: <200105082050.QAA26283@mamia.prninfo.com> THe Demonology tower's air masters should have the spell windstorm...it is a bit to easy so also make the fire masters have dragon breath...and the water make the wizards have large ice. Thank you. From the_real_tomble at hotmail.com Tue May 8 21:08:37 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] Unclear crash Message-ID: (NOTE- whatever I try to do to circumvent it, Hotmail always seems able to screw up my posts in one way or another. I just want to get that off my chest before it does it again.) Mark Wedel wrote: >update_button is called whenever the button is pressed/activated. >If you are using a button/plate, then all this takes is for some >object (of appropriate weight) to be on the space. That sounds like a reasonable thing for it to do. >Now what the error really means is that one of the objects that >had the same connected value has 'disappeared'. disappeared >could be any of various causes -a monster that was killed, or >some other destroyable objects. OK, now that's a bit freaky. You are saying the actual button objects, etc. are being destroyed? > As currently implemented, connected objects must be permanent. > >My guess is you have some objects with connected values that >are not permanent (note it doesn't make a different code wise >that these destroyed connected objects may not do anything - >just anything with a connected value is put on the connected >object list at load time). Some of my maps have slightly extreme bits of machinery- but I'm fairly sure I've not put buttons that get used up or anything like that. There've been some creators which get used up, but I don't think the ones in the stall_2 map did, and that got a few errors too.None of the errors have mentioned creators, prolly because they're not buttons :P ... Putting everything together now, I'm *supposing* that what's happening, is that when the affected maps are reset, at which point the objects on it must be removed from memory (or have I got that wrong?), the bit that calls update_button doesn't realise they've gone (or maybe it even thinks the buttons are on a different map, I dunno the CF internals). .. For some bizarre reason, I had *previously* been thinking along the lines of the maps resetting and CF trying to reinitialise everything on them, and deciding that the combination of buttons couldn't be resolved- but in retrospect, that would make no sense :P . Looking now, it makes much more sense as the maps are basically usable, and only produce the errors on reset. Perhaps it's related to the things DNH had been saying about the "update item for item we don't have" error (I've no idea), like maybe one global data structure could be messing up and causing all this. As my maps seem to be causing the errors fairly repeatably, perhaps this could shed some more light on it. [BTW- I prolly should have mentioned earlier, yes I'm sure I've seen the "update_item for item we don't have" error in cfclient, but I don't remember them crashing it at all. And not anywhere near titans, either :P] Tomble _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From the_real_tomble at hotmail.com Tue May 8 22:36:29 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] Cosmetic improvements Message-ID: It's often seemed to me that before making an official stable release, Crossfire could prolly do with a handful of small "Cosmetic Improvements", to give it a bit of polish. Obviously many such improvements would be inappropriate in a feature-freeze, or difficult in such short time. For instance, overhauling the PNG tileset would take ages. However, if the tilesets are to *eventually* change, IMHO it would be a good idea to mention this on the start map (so people know that some of the faces are likely to be changed in future, and don't get too attatched to them, etc) .. Further, a sub-miniature patch that has no known issues: The syntax of many of the messages CF gives the player is screwy, and whilst some would be nontrivial to change, the one regarding no_pick objects is not: If you try picking up an object "foo" that has "no_pick" set, the message is "You cannot pick up a foo". In most instances, that looks wrong, whereas in *all* instances I can think of, "You cannot pick up THE foo" is perfect, as it refers to the one you are trying to pick up. The current form looks OK for trees, houses, etc, but wrong for: floor, earth, grass, etc., plus anything like a book, sword, etc that you would normally be able to pick up except that the mapmaker has decided you shouldn't be able to. Using "the" is spot on for *all* of those. There is only one form where I'm not sure about it: If you have a pile of objects you can't pick up. If you try to pick up the whole pile, it would have to say "You can't pick up the arrows", or "You can't pick up the 27 arrows", rather than "You can't pick up the arrow". .. I've only just looked for the function, so I'm a bit confused as to why it appears in c_object.c to be covered by both pick_up_object and command_take (which does what?). I'd also assumed "a" was printed by some function that returned "a foo" or "3 bars" for an object or pile of objects, but it's just part of the message, so you can change it straight to "You can't pick up the %s". .. If you want to cover the possibility of a pile of unpickable objects, it'd need to use something like sprintf(buf,"You can't pick up the %s", (tmp->nrof=1)? tmp->name : tmp->nrof+" "+tmp->name+"s"); [As the function currently assumes *single* no_pick objects, I expect that's all there ever is. Unpickable heaps sounds odd, but not necessarily wrong though.] Not the biggest issue in CF, but it's been annoying me. Tomble _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From gros at magellan.fpms.ac.be Wed May 9 07:34:37 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] devourers In-Reply-To: <3AF85D0B.A20DEB94@cstone.net> References: <01050715374100.02536@Terminus.magellan.fpms.ac.be> <3AF85D0B.A20DEB94@cstone.net> Message-ID: <01050908343700.02029@Terminus.magellan.fpms.ac.be> Le Mardi 8 Mai 2001 16:54, vous avez ?crit : > gros wrote: > > Here is a bugfix for that. Change the update_priest_flag to: > > Just out of curiousity, if a wraith joins the Devourers, then changes > away, will this bug fix make the wraith non-undead? > > :) > > Thanks, > > SeanMike No, the Wraith will stay an undead. NB: You can safely remove the "printf" lines included in the bugfix, they were there only for quick-and-dirty debugging purpose; that gives the following code (the bugfix only adds one line to the original code): void update_priest_flag (object *god, object *exp_ob, uint32 flag) { ? ? if(QUERY_FLAG(god,flag)&&!QUERY_FLAG(exp_ob,flag)) ? ? ? ? SET_FLAG(exp_ob,flag); ? ? else if(QUERY_FLAG(exp_ob,flag)&&!QUERY_FLAG(god,flag)) ? ? { ? ? ? ? if (!(QUERY_FLAG(arch_to_object(exp_ob->arch),flag))) ? ? ? ? ? ? ? ? CLEAR_FLAG(exp_ob,flag); ? ? }; } From mwedel at scruz.net Wed May 9 02:01:54 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] devourers References: <01050715374100.02536@Terminus.magellan.fpms.ac.be> <3AF85D0B.A20DEB94@cstone.net> <01050908343700.02029@Terminus.magellan.fpms.ac.be> Message-ID: <3AF8EB62.2FB727@scruz.net> > > void update_priest_flag (object *god, object *exp_ob, uint32 flag) { > > if(QUERY_FLAG(god,flag)&&!QUERY_FLAG(exp_ob,flag)) > SET_FLAG(exp_ob,flag); > else if(QUERY_FLAG(exp_ob,flag)&&!QUERY_FLAG(god,flag)) > { > if (!(QUERY_FLAG(arch_to_object(exp_ob->arch),flag))) > CLEAR_FLAG(exp_ob,flag); > }; > } Err, arch_to_object should not be used, as that ends up creating a nice memory leak (one for each functiion call). What you really want to be doing is something like: if (!(QUERY_FLAG(exp_ob->arch->clone,flag))) or the like (not sure if it should be .clone there). Theres already enough memory leaks out there - we don't want to be adding more. From mwedel at scruz.net Wed May 9 02:08:41 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] Unclear crash References: Message-ID: <3AF8ECF9.189F38E@scruz.net> > >Now what the error really means is that one of the objects that > >had the same connected value has 'disappeared'. disappeared > >could be any of various causes -a monster that was killed, or > >some other destroyable objects. > OK, now that's a bit freaky. You are saying the actual > button objects, etc. are being destroyed? That is what causes those error messages to be printed (ie, the object it added in to the buttonlist when the map was loaded does not match the object now there, or the object now there is a defunct object) > Putting everything together now, I'm *supposing* that what's > happening, is that when the affected maps are reset, at which > point the objects on it must be removed from memory (or have I > got that wrong?), the bit that calls update_button doesn't > realise they've gone (or maybe it even thinks the buttons are on > a different map, I dunno the CF internals). Are you running CVS or 0.98.0? There was a bug in 0.98.0 that resulted in something similar to what youu desribe - when maps with in memory were reset, the freeing of the data resulted in the above situation. That is fixed in CVS. > [BTW- I prolly should have mentioned earlier, yes I'm sure I've > seen the "update_item for item we don't have" error in cfclient, > but I don't remember them crashing it at all. And not anywhere near > titans, either :P] the update_item is a sort of harmless error message. Sort of harmless in the sense the client will just ignore it. Not completely harmless in that it does take up some bandwidth to send data we will discard. The fix for the bug (levers/other object player is standing on not getting the face updated) is not completely satisfactory. It does work, with the cost that we send some false updates to the clients. From gros at magellan.fpms.ac.be Wed May 9 08:25:56 2001 From: gros at magellan.fpms.ac.be (gros) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] devourers In-Reply-To: <3AF8EB62.2FB727@scruz.net> References: <01050908343700.02029@Terminus.magellan.fpms.ac.be> <3AF8EB62.2FB727@scruz.net> Message-ID: <01050909255600.03225@Terminus.magellan.fpms.ac.be> Le Mercredi 9 Mai 2001 03:01, vous avez ?crit : > > void update_priest_flag (object *god, object *exp_ob, uint32 flag) { > > > > if(QUERY_FLAG(god,flag)&&!QUERY_FLAG(exp_ob,flag)) > > SET_FLAG(exp_ob,flag); > > else if(QUERY_FLAG(exp_ob,flag)&&!QUERY_FLAG(god,flag)) > > { > > if (!(QUERY_FLAG(arch_to_object(exp_ob->arch),flag))) > > CLEAR_FLAG(exp_ob,flag); > > }; > > } > > Err, arch_to_object should not be used, as that ends up creating a nice > memory leak (one for each functiion call). > > What you really want to be doing is something like: > > if (!(QUERY_FLAG(exp_ob->arch->clone,flag))) > The correct patch is then: void update_priest_flag (object *god, object *exp_ob, uint32 flag) { if(QUERY_FLAG(god,flag)&&!QUERY_FLAG(exp_ob,flag)) SET_FLAG(exp_ob,flag); else if(QUERY_FLAG(exp_ob,flag)&&!QUERY_FLAG(god,flag)) { if (!(QUERY_FLAG(&(exp_ob->arch->clone),flag))) { CLEAR_FLAG(exp_ob,flag); }; }; } > > Theres already enough memory leaks out there - we don't want to be adding > more. True. Sorry for forgetting I was in C and not in Java. Commander Gros Ad Dwarvam Aeternam ! From dnh at hawthorn.csse.monash.edu.au Wed May 9 03:26:53 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:47 2005 Subject: [CF-Devel] Cosmetic improvements In-Reply-To: Message-ID: Fixed in cvs, good idea I must say =) dnh On Wed, 9 May 2001, Tom Barnes-Lawrence wrote: > It's often seemed to me that before making an official > stable release, Crossfire could prolly do with a handful > of small "Cosmetic Improvements", to give it a bit of polish. > Obviously many such improvements would be inappropriate in > a feature-freeze, or difficult in such short time. > For instance, overhauling the PNG tileset would take ages. > However, if the tilesets are to *eventually* change, IMHO > it would be a good idea to mention this on the start map > (so people know that some of the faces are likely to be changed > in future, and don't get too attatched to them, etc) > .. > Further, a sub-miniature patch that has no known issues: > The syntax of many of the messages CF gives the player is > screwy, and whilst some would be nontrivial to change, the > one regarding no_pick objects is not: > If you try picking up an object "foo" that has "no_pick" set, > the message is "You cannot pick up a foo". In most instances, that > looks wrong, whereas in *all* instances I can think of, > "You cannot pick up THE foo" is perfect, as it refers to the one > you are trying to pick up. > The current form looks OK for trees, houses, etc, but wrong for: > floor, earth, grass, etc., plus anything like a book, sword, etc > that you would normally be able to pick up except that the > mapmaker has decided you shouldn't be able to. > Using "the" is spot on for *all* of those. > There is only one form where I'm not sure about it: If you > have a pile of objects you can't pick up. If you try to pick > up the whole pile, it would have to say "You can't pick up the > arrows", or "You can't pick up the 27 arrows", rather than > "You can't pick up the arrow". > .. > I've only just looked for the function, so I'm a bit confused > as to why it appears in c_object.c to be covered by both > pick_up_object and command_take (which does what?). > I'd also assumed "a" was printed by some function that returned > "a foo" or "3 bars" for an object or pile of objects, but it's > just part of the message, so you can change it straight to > "You can't pick up the %s". > .. > If you want to cover the possibility of a pile of unpickable > objects, it'd need to use something like > > sprintf(buf,"You can't pick up the %s", > (tmp->nrof=1)? tmp->name : tmp->nrof+" "+tmp->name+"s"); > > [As the function currently assumes *single* no_pick objects, I > expect that's all there ever is. Unpickable heaps sounds odd, but > not necessarily wrong though.] > Not the biggest issue in CF, but it's been annoying me. > Tomble > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From peterm at tonks.EECS.Berkeley.EDU Wed May 9 13:07:56 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] Reducing exp penalty on death Message-ID: <200105091807.f49I7uW01543@tonks.EECS.Berkeley.EDU> This has been discussed several times, but I'll float it here: do we have a consensus in favor of reducing the experience penalty on death? Some on IRC have said we should change it BEFORE v. 1.0. 1) Yes, reduce it. a) Reduce it to 25% or 3 experience levels in each category, whichever is LESS. (my favored method) b) Reduce it to 10% (or X--you fill in X). c) Use this forumla: loss = F(current_exp) (you fill in F) 2) No, death is already too painless. Leave it. PeterM From jbontje at suespammers.org Wed May 9 15:53:26 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] Reducing exp penalty on death In-Reply-To: <200105091807.f49I7uW01543@tonks.EECS.Berkeley.EDU>; from peterm@tonks.EECS.Berkeley.EDU on Wed, May 09, 2001 at 11:07:56AM -0700 References: <200105091807.f49I7uW01543@tonks.EECS.Berkeley.EDU> Message-ID: <20010509225326.A15214@mids.student.utwente.nl> On Rick Tanner's request I have added these options about death penalty to the Polls part of my site http://mids.student.utwente.nl/ Vote for yourself at: http://mids.student.utwente.nl/~crossfire/polls/vote.php3?pollID=5 Joris Bontje / MiDS From dnh at hawthorn.csse.monash.edu.au Thu May 10 05:43:55 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] Troll Message-ID: Unless there are any major complaints I am uping the trolls cold resistance to 30. Currently it really sucks as a race, and as we are about to make a release.. it would be nice to have the races alittle more closely balanced, of course after V1, when AV adds his patch I will take off the change. To justify the change, trolls by nature are rugged creatures and can thrive in in inhospitable mountain lands where no human would dare to tread. dnh From Philipp.Currlin at t-online.de Thu May 10 07:20:09 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] merging of horns Message-ID: <01051014200900.00360@truth> Hi Horns (Horn of fire, plenty, etc.) still don't merge on the floor or in your inventory. On IRC we've also been talking about merging containers. Is there a way to check if they are empty and if they are, merge them? Phil From peterm at CSUA.Berkeley.EDU Thu May 10 03:22:01 2001 From: peterm at CSUA.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] Wrapping AC Message-ID: <200105100822.f4A8M1B56568@soda.csua.berkeley.edu> Hello, I've noticed that when I'm wearing all my armour I pray over an altar, my ac can "wrap" i.e., become so negative it's positive. PeterM From peterm at CSUA.Berkeley.EDU Thu May 10 03:24:36 2001 From: peterm at CSUA.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] Wrapping AC is real. Message-ID: <200105100824.f4A8Oa756716@soda.csua.berkeley.edu> The net effect of the wrapping AC is to make my very highly armoured character completely vulnerable. PM From Philipp.Currlin at t-online.de Thu May 10 12:55:42 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] marking runes Message-ID: <01051019554202.00360@truth> Marking runes still cause trouble on damn.informatik.uni-bremen.de Someone casted marking rune in Scorn and left afterwards. A few minutes later the map was completely screwed again (see my mail from last month with the output of the "marking rune") I had to reset the map to keep the server from crashing. Phil From Philipp.Currlin at t-online.de Thu May 10 13:00:17 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] polymorph Message-ID: <01051020001703.00360@truth> Could we do something about polymorph please? Here's a list of monsters we had in newbie maps after a player was fooling around with a heavy rod of polymorph (level 22): Dave Lord Eureca Evil Master (two different ones, the human one and the skull-like one) Ologh-hi I do now want these monsters in low-level maps killing newbies because of some idiot.... Phil From highway at cstone.net Thu May 10 15:32:43 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] polymorph References: <01051020001703.00360@truth> Message-ID: <3AFAFAEB.2708C71E@cstone.net> Philipp Currlin wrote: > I do now want these monsters in low-level maps killing newbies because of > some idiot.... We noticed that too on our server. We actually used it to practice against tough monsters, but you seemed extremely likely to make something obscenely powerful out of the kobolds in the Beginner's Area... SeanMike From Philipp.Currlin at t-online.de Thu May 10 17:02:08 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] cpu-usage of gcfclient Message-ID: <01051100020801.12561@truth> When I just checked my system with top I noticed that gcfclient (todays cvs) hadn't shut down completely and that it used up 96.8 % of my cpu. And I thought it was the fault of the server that it was so slow... I can't recall how long I played without shutting down the client... maybe 2-3 hours. Phil From Philipp.Currlin at t-online.de Thu May 10 17:14:53 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] broken animation Message-ID: <01051100145302.12561@truth> In the alternate set (todays cvs) the animation of the balrog doesn't work correctly. It uses the wrong image in the top left corner. Even a small bug is a bug.... Phil From mwedel at scruz.net Fri May 11 00:44:42 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] bugs in gcfclient References: <3AF64D95.1010706@epost.de> Message-ID: <3AFB7C4A.3387238F@scruz.net> Philipp Currlin wrote: > > Hi > > Two bugs that are around for some time now: > > 1. With the current version of gcfclient you can't scroll the list of > servers if you updated them before you started playing. Can you be more precise? I can scroll the text window at the metaserver selection prompt, so I'm not sure if your talking about this or something else. > > 2. If you say something that is longer than 250 bytes the client > crashes. (This applies to both, client and post-1-0 client) This is now fixed. From crossfire at suckfuell.net Fri May 11 01:12:19 2001 From: crossfire at suckfuell.net (Jochen Suckfuell) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] Wrapping AC is real. In-Reply-To: <200105100824.f4A8Oa756716@soda.csua.berkeley.edu> Message-ID: On 10-May-2001 Peter Mardahl wrote: > The net effect of the wrapping AC is to make my very highly armoured > character completely vulnerable. I get this effect all the time when I use many holy possessions. It also affects wc. At some point it showed my usual wc and ac (i.e. what I have without holy possession), but I still hit high level monsters. So I'm not sure that this wrapping effect makes you vulnerable. If it was a real overflow, further holy possessions would lower the wc/ac further, but they don't. So I guess the server handles it correctly, but maybe the client has only 8 bits for it? Bye Jochen -- E-Mail: Jochen Suckfuell From mwedel at scruz.net Fri May 11 01:18:30 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] marking runes References: <01051019554202.00360@truth> Message-ID: <3AFB8436.E06E9EC1@scruz.net> Fixed in CVS. Philipp Currlin wrote: > > Marking runes still cause trouble on damn.informatik.uni-bremen.de > > Someone casted marking rune in Scorn and left afterwards. A few minutes later > the map was completely screwed again (see my mail from last month with the > output of the "marking rune") > > I had to reset the map to keep the server from crashing. > > Phil > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Fri May 11 01:26:02 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] cpu-usage of gcfclient References: <01051100020801.12561@truth> Message-ID: <3AFB85FA.8B1912D7@scruz.net> Philipp Currlin wrote: > > When I just checked my system with top I noticed that gcfclient (todays cvs) > hadn't shut down completely and that it used up 96.8 % of my cpu. And I > thought it was the fault of the server that it was so slow... > I can't recall how long I played without shutting down the client... maybe > 2-3 hours. I have seen that periodically - the fix I just checked in may fix that. Otherwise, I'm not 100% sure of the solution/cause of this. From mwedel at scruz.net Fri May 11 01:29:35 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] polymorph References: <01051020001703.00360@truth> <3AFAFAEB.2708C71E@cstone.net> Message-ID: <3AFB86CF.63A2A7A@scruz.net> Sean Michael Whipkey wrote: > > Philipp Currlin wrote: > > I do now want these monsters in low-level maps killing newbies because of > > some idiot.... > > We noticed that too on our server. We actually used it to practice > against tough monsters, but you seemed extremely likely to make > something obscenely powerful out of the kobolds in the Beginner's > Area... It has been suggested that polymorph gets removed all together - I don't really like that. It seems that if a high level player wants to make things difficult, they can probably always do that (I can think of at least a few other things that may cause player difficulty). Perhaps one thing to do, which may make it fairer, is to make sure the transformed monster is within some number of levels of the original (ie, ?5 levels for example?) This would also reduce the usefulness some of polymorph tough monsters to get some quest item or the like. From peterm at tonks.EECS.Berkeley.EDU Fri May 11 02:42:57 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] AC and WC use signed chars. Wrapping can happen EASILY. In-Reply-To: Your message of "Fri, 11 May 2001 08:12:19 +0200." Message-ID: <200105110742.f4B7gw205514@tonks.EECS.Berkeley.EDU> > If it was a real overflow, further holy possessions would lower the wc/ac > further, but they don't. So I guess the server handles it correctly, but mayb > the client has only 8 bits for it? A 3 minute examination of the code shows this: typedef struct liv { /* Mostly used by "alive" objects */ sint8 Str,Dex,Con,Wis,Cha,Int,Pow; sint8 wc,ac; /* Weapon Class and Armour Class */ sint16 hp; /* Hit Points. */ sint16 maxhp; sint16 sp; /* Spell points. Used to cast mage spells. */ wc and ac are 8 bit signed ints. Wrapping can and does occur. Your guesses are borne out neither by the code nor by my observation "in the field". PeterM > Bye > Jochen > > -- > E-Mail: Jochen Suckfuell > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From Philipp.Currlin at t-online.de Thu May 10 14:26:45 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] acid and repairing of weapons Message-ID: <01051021264505.00360@truth> Here's my opinion on this topic: Make repairing available for money but then acid should always corrode your stuff, except with something like > 95% acid res. What should be changed for that is the chance of an item getting corroded. Phil From peterm at tonks.EECS.Berkeley.EDU Thu May 10 15:57:34 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] polymorph In-Reply-To: Your message of "Thu, 10 May 2001 20:00:17 +0200." <01051020001703.00360@truth> Message-ID: <200105102057.f4AKvYu04716@tonks.EECS.Berkeley.EDU> I'm in favor of disabling polymorph entirely for 1.0. We can repair it after v. 1.0. PeterM > Could we do something about polymorph please? > > Here's a list of monsters we had in newbie maps after a player was fooling > around with a heavy rod of polymorph (level 22): > Dave > Lord Eureca > Evil Master (two different ones, the human one and the skull-like one) > Ologh-hi > > I do now want these monsters in low-level maps killing newbies because of > some idiot.... > > > Phil > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From dnh at hawthorn.csse.monash.edu.au Fri May 11 04:05:08 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] polymorph In-Reply-To: <200105102057.f4AKvYu04716@tonks.EECS.Berkeley.EDU> Message-ID: I agree with this choice of action, peterm.. look in irc ;) dnh On Thu, 10 May 2001, Peter Mardahl wrote: > > I'm in favor of disabling polymorph entirely for 1.0. > > We can repair it after v. 1.0. > > PeterM > > > Could we do something about polymorph please? > > > > Here's a list of monsters we had in newbie maps after a player was fooling > > around with a heavy rod of polymorph (level 22): > > Dave > > Lord Eureca > > Evil Master (two different ones, the human one and the skull-like one) > > Ologh-hi > > > > I do now want these monsters in low-level maps killing newbies because of > > some idiot.... > > > > > > Phil > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From hsteoh at quickfur.yi.org Thu May 10 16:23:31 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] marking runes In-Reply-To: <01051019554202.00360@truth>; from Philipp.Currlin@t-online.de on Thu, May 10, 2001 at 07:55:42PM +0200 References: <01051019554202.00360@truth> Message-ID: <20010510172331.A25279@crystal> On Thu, May 10, 2001 at 07:55:42PM +0200, Philipp Currlin wrote: > Marking runes still cause trouble on damn.informatik.uni-bremen.de > > Someone casted marking rune in Scorn and left afterwards. A few minutes later > the map was completely screwed again (see my mail from last month with the > output of the "marking rune") > > I had to reset the map to keep the server from crashing. [snip] It happened last night on metalforge too. T -- Airplanes stall. Computers just hang in the air... From hsteoh at quickfur.yi.org Fri May 11 06:48:42 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:48 2005 Subject: [CF-Devel] acid and repairing of weapons In-Reply-To: <01051021264505.00360@truth>; from Philipp.Currlin@t-online.de on Thu, May 10, 2001 at 09:26:45PM +0200 References: <01051021264505.00360@truth> Message-ID: <20010511074842.A27408@crystal> On Thu, May 10, 2001 at 09:26:45PM +0200, Philipp Currlin wrote: > Here's my opinion on this topic: > > Make repairing available for money but then acid should always corrode your > stuff, except with something like > 95% acid res. > What should be changed for that is the chance of an item getting corroded. I like this idea. Although in that case, artifacts like ring of Acid might need to be changed; right now it gives about 30% acid protection which is almost useless against both acid damage and equipment corrosion. Repairing should also be *expensive* IMHO, so that you still would want to really try avoiding acid corrosion if you can help it. T -- "How are you doing?" "Doing what?" From Philipp.Currlin at t-online.de Fri May 11 08:03:14 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] acid and repairing of weapons In-Reply-To: <20010511074842.A27408@crystal> References: <01051021264505.00360@truth> <20010511074842.A27408@crystal> Message-ID: <01051115031401.01055@truth> On Friday 11 May 2001 13:48, you wrote: > I like this idea. Although in that case, artifacts like ring of Acid might > need to be changed; right now it gives about 30% acid protection which is > almost useless against both acid damage and equipment corrosion. > > Repairing should also be *expensive* IMHO, so that you still would want to > really try avoiding acid corrosion if you can help it. I agree that it should be expensive. Your resistance to acid should affect the chance of an item getting corroded and the damage you take. So if you kill an acid blob with one hit and you have 50% acid res, you take half the damage of the acid attack and there is also a chance of 50% that your equipment still has the same stats as before... Phil From peterm at tonks.EECS.Berkeley.EDU Fri May 11 14:01:46 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] acid and repairing of weapons In-Reply-To: Your message of "Thu, 10 May 2001 21:26:45 +0200." <01051021264505.00360@truth> Message-ID: <200105111901.f4BJ1kJ06268@tonks.EECS.Berkeley.EDU> I think acid sucks enough as it is. Also, I spend enough time messing about with my inventory already. I'd rather not have to bother repairing my equipment all the time, too. Furthermore, this will disproportionally hassle newer players, who have a tough enough time already. Old players have many items made of adamant or material 0, both of which are totally acid-immune. PeterM > Here's my opinion on this topic: > > Make repairing available for money but then acid should always corrode your > stuff, except with something like > 95% acid res. > What should be changed for that is the chance of an item getting corroded. > > > Phil > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From Philipp.Currlin at t-online.de Fri May 11 16:57:33 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] acid and repairing of weapons In-Reply-To: <200105111901.f4BJ1kJ06268@tonks.EECS.Berkeley.EDU> References: <200105111901.f4BJ1kJ06268@tonks.EECS.Berkeley.EDU> Message-ID: <01051123573302.01055@truth> The way it is now your stuff doesn't get corroded when you have 50% acid res. But where is the difference for a newbie? At low levels you don't have acid res. Once you are strong enough to get acid res you are also strong enough to get lots of money. And then you will also be able to repair your items. Phil On Friday 11 May 2001 21:01, you wrote: > I think acid sucks enough as it is. > > Also, I spend enough time messing about with my inventory already. > I'd rather not have to bother repairing my equipment all the time, > too. > > Furthermore, this will disproportionally hassle newer players, who > have a tough enough time already. Old players have many items made > of adamant or material 0, both of which are totally acid-immune. > > PeterM From crossfire at suckfuell.net Fri May 11 01:07:06 2001 From: crossfire at suckfuell.net (Jochen Suckfuell) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] polymorph In-Reply-To: <3AFAFAEB.2708C71E@cstone.net> Message-ID: On 10-May-2001 Sean Michael Whipkey wrote: > Philipp Currlin wrote: >> I do now want these monsters in low-level maps killing newbies because of >> some idiot.... > We noticed that too on our server. We actually used it to practice > against tough monsters, but you seemed extremely likely to make > something obscenely powerful out of the kobolds in the Beginner's > Area... I think polymorph should only produce monsters of the same level, or max 5 lvl higher. Is it depending on the player level right now? Bye Jochen -- E-Mail: Jochen Suckfuell From the_real_tomble at hotmail.com Fri May 11 19:51:13 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] acid and repairing of weapons Message-ID: If the subject of acid+repair is up again, I'd like to repeat my opinion that item repair should be available, but limited as I suggested a week or so ago -ie, the item can only be partially repaired (unless perhaps it's only slightly damaged, where it could be completely repaired). The partial repairing could either slowly bring down the "quality rating", or keep the "quality" as it always was but wear the item out such that it is *eventually* destroyed (that earlier post explained that better). ... That way, item repair wouldn't need to be very expensive (perhaps repair cost could be proportional to amount to repair; maybe you could even pay for partial repair?) as the limitations of repair would balance it. Corrosion-immunity could stay at 50%ish, as it would make a long-term difference (or it prolly should be adjustment of probability that item will corrode). ... So: newbie is likely to not suffer too much from a one-off incident with rust monster, but it can still make things difficult for players who fight *lots* of acid monsters. Tomble >The way it is now your stuff doesn't get corroded when you >have 50% acid res. But where is the difference for a newbie? >At low levels you don't have acid res. Once you are strong >enough to get acid res you are also strong enough to get >lots of money. And then you will also be able to repair >your items. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From the_real_tomble at hotmail.com Fri May 11 21:31:35 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] About CVS 11th/May Message-ID: After what Mark said, I got the latest CVS last night to see if the errors I'd seen before were fixed by it, and it looks now like they were, hurrah! Some other stuff I noticed tho: .. 1)-Configure script broken: It thinks libXpm and libpng aren't installed. I noticed this in 0.98, but I forget how I got round it then; this time I resorted to passing --with-ldflags=-L/usr/X11R6/lib to configure. .. I dunno if everyone else gets this, if not you must all have that directory in the linker's search path, but AFAIK that isn't a usual thing. When configure searches for libX11, it specifies -L/usr/X11R6/lib in the test it runs; when it then tries to compile against Xpm and png libs, it links in libX11 as well, but without specifying the search path for that, so it fails to find it. Anyhoo, if it's tough to change the configure script (I wouldn't know how to), maybe it should be explained in the INSTALL file before it confuses anyone else. .. 2) Changes to message text: Dnh said the other day that he'd altered the text for where you can't pick stuff up, like I'd suggested. Thanks for that, but I notice that it's only been changed in pick_up(), and not in command_take()- The latter seems to apply to using the "," key to pick stuff up, so that stills wrongly says "a thing". .. OTOH, the cost description in examine() seems to be changed to say "The It/They would cost" or "You would get (money) for the it/them", which are both pretty bad- IMHO those were OK before, without "the" in them :) .. 3)Not a bug, just an idea: Glancing over the config file, I noticed the random encounters thing, and got thinking. The comment there suggests the main problem with it was when they turned up in the wrong places, which had been my experience also. As a variation on maps specifying that encounters can occur, how about a config option to allow encounters, but only on maps in the /world directory? IMHO that's where most of them would be *meant* to happen, so servers could use them without them being too obtrusive, and then maybe some of those bugs mentioned with them could be found. Would this be reasonably simple to implement? Could it slow the server down much? Would it be better to pretend the encounter maps never existed right now? .. Tomble _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From mwedel at scruz.net Fri May 11 22:26:45 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] About CVS 11th/May References: Message-ID: <3AFCAD75.E8B048AD@scruz.net> Tom Barnes-Lawrence wrote: > 1)-Configure script broken: > It thinks libXpm and libpng aren't installed. I noticed > this in 0.98, but I forget how I got round it then; > this time I resorted to passing > --with-ldflags=-L/usr/X11R6/lib to configure. I just looked at the script/configure.in Best I can tell, when it tries to link in for the testing of the png and Xpm libraries, it should be using the same compiler flags as it will when it does the actual program compile. If the link doesn't work at that point, better to bail out there than find out when we try to do the actual compile. Fixing this up to work better may not be really hard, but verifying it actually works properly for everyone gets fairly difficult (ie, that it doesn't break anything for people with the libraries in /usr/lib, or /usr/openwin/lib, ...) > 2) Changes to message text: > Dnh said the other day that he'd altered the text for > where you can't pick stuff up, like I'd suggested. > Thanks for that, but I notice that it's only been > changed in pick_up(), and not in command_take()- > The latter seems to apply to using the "," key > to pick stuff up, so that stills wrongly says "a thing". > .. > OTOH, the cost description in examine() seems to be > changed to say "The It/They would cost" or "You would > get (money) for the it/them", which are both pretty > bad- IMHO those were OK before, without "the" in them :) DB: youu want to fix this? > .. > 3)Not a bug, just an idea: > Glancing over the config file, I noticed the random > encounters thing, and got thinking. The comment there > suggests the main problem with it was when they turned > up in the wrong places, which had been my experience also. > As a variation on maps specifying that encounters can > occur, how about a config option to allow encounters, but > only on maps in the /world directory? IMHO that's where > most of them would be *meant* to happen, so servers could > use them without them being too obtrusive, and then maybe > some of those bugs mentioned with them could be found. > Would this be reasonably simple to implement? Could it > slow the server down much? Would it be better to pretend > the encounter maps never existed right now? Probably yeah. IMO, that should be removed all together with the addition of the random map code peter added. Even if it is limited to world maps, you get into this situation: You are wondering through the forest to say the dragon cave. It generates one of these encounter maps, and drops you basically in the center. This map is full of monsters, but these monsters are relatively easy (your going to the dragon cave after all!), so it just just becomes a nuisance to head to one of the edges so you can get out of this. So you beat things up in the dragon cave, and head home. Unfortunately, this encounter map is still there, and there is no way to tell exactly where it is (other than memory), so you can into it on your way home, and once again, head towards the edge. So aside from the fact these are really nuisances, even if you want the exp to kill whatever monsters, these maps are relatively boring - has some number of monsters, has a little varied terrain, etc. If we really want random encounters out there, much more preferable would be to create a new object type that does this for us. This would be an invisible map object. it would contain some speed value (denoting how often monsters get generated), perhaps some random fudge factor so it isn't 100% predictable (ie, it could be 10 minutes one time, and 5 minutes the next), using a treasure list to know what monsters to generate (and in this way you could actually generate a group, like a group of orcs, and not just one at a time), and use some value to denote where these monsters would appear (the invisible object location would be the upper left corner of the rectangle, and perhaps sp/hp would denote the amount of possible offset, giving a rectangle of where this stuff may appear) There would be nothing preventing more than one of these per maps, or even having the areas overlap. Realistically, with the current outdoor maps, I'm not sure how important an idea this really is. This could be interesting if we went for a unified scale map scale, which may have some apeal, but I think is unlikely to happen. I think more likely would be a dual scale (basically keep city scale and building scale, but get rid of the outdoor scale, the city would just be a large area on the outdoor map). This IMO is more likely as only the world maps would need to get redone then, and they are not that extensive that this would be a really hard job, But even that I would consider somewhat unlikely and a low priority. On the bonus, this would put some real scale between cities (currently, the walk accross the continent is not that much than a couple walks accross the city - if this scale change, the walk accross the continent would be a serious walk). This would also help mesh with other possible enhancements (boats, flying, etc. Ie, you could fly over the city wall to get in/out instead of going through gatehouse) But that is another discussion. > .. > Tomble > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Fri May 11 23:19:19 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] acid and repairing of weapons References: Message-ID: <3AFCB9C7.24D2A412@scruz.net> The thing with acid is tricky. At low levels, it beats up a bunch of your items, but for the most part, the items it might destroy are pretty common (not to hard to find a replacement helm +2 for example). At mid levels, you have better stuff that may be harder to replace. At high levels, are your stuff is basically immune because of the type of object (ie, artifact), with adamantite/no material. So at low levels, having it cost a lot isn't very useful, as the player won't be able to afford it anyways. But I have various thoughts: Acid is most nasty for new players (and not characters). That new player doesn't know what that rust monster/black pudding/green slime look like or what it does. So they are merrily going through the dungeons killing everything in sight. They then run into that monster, and before they know it there set of nice +2 stuff is now all -3. Experience players know what those monsters look like, so if they see one, they know to choose alternate tactics. And if they have played the map before, they may even know what door it is behind, etc, and adjust accordingly. So to me, that is the problem with rust monsters and grim reapers - you get toasted the first time. Some of this could perhaps be improved along the same suggestion of paraylze - monster gets one chance to hit you with it, then your immune for some amount of time. If this was done for acid/drain - ie, youu get hit, something may get corroded, but then your immune for X amount of time, this would give newbies at least a chance to learn and change tactics. The monster could still attack and do damage. But in terms of repair: An alternate idea would be to have an 'enchanting' service. This service would only enchant up to the value that you might normally find (or maybe just straight +2 for everything) at some price. For example, enchanting from -4 to -3 might be fairly cheap, and -3 to -2 likewise fairly cheap, but that +1 to +2 could be pretty costly. This basically takes the place of repair, and also means that some of the 'mundane' but somewhat rare items can be made if the player has the money (maybe you've been unlucky and haven't been able to find that +2 jack boots for whatever reason, but have a pile of cash - have them custom made for you). From tanner at real-time.com Sat May 12 00:22:32 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] MetalForge moving to a dedicated machine Message-ID: <20010512002232.I32683@real-time.com> I'll be moving MetalForge to a dedicated Crossfire Server tonight (May 12) at 12:30am CST. The new machine will be dedicated to running MetalForge. It's a G3 Mac running YellowDog PPC linux, it's got 128Mb of RAM (we will upgrade the RAM to 384Mb later this month). The machine will be accessible via metalforge.real-time.com as soon as DNS updates. Mark will make change the Metaserver stuff in a couple of minutes. This should keep both the Netrek players and the Crossfire players happy, since they both have their own machines now. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From andi.vogl at gmx.net Sat May 12 06:44:31 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] acid and repairing of weapons In-Reply-To: <3AFCB9C7.24D2A412@scruz.net> Message-ID: <000001c0dad8$e95ab180$ac1efea9@kyle> I'd like to throw in some new aspect to weapon repairing that seemingly hasn't been mentioned yet: In many RPGs weapons get "damaged" by using them and need to be repaired after a while. A good example for this scheme is Diablo II. But there's more to it than just forcing players to keep in touch with their local blacksmith: The cost for weapon repairing kinda balances weapon level vs. player level. E.g. if a newbie finds a super-powerful sword (or maybe gets one as present) he cannot afford the repair costs, hence cannot use it efficiently. So he will mostly leave it in his backbag until he has reached a level where he can afford to use it. Now we all know that in CF we have this problem of newbies getting "presents" from high level players all the time. Maybe we could use this weapon repair scheme to our advantage in this case: We could make all weapons (and maybe armour too) contain a "durability" value. While this piece of equipment is in use, the durability would very slowly decrease. When it reaches zero, the item can no longer be worn unless repaired. Being hit by acid would just greatly speed up the process of decay (This has already been proposed once). And the repair cost would be a certain percentage of the base value of the item. Say: cheap for ordinary stuff, expensive for artifacts. After implementing this, we should certainly specify materials for all artifacts. That way a newbie will have some difficulties using that demonslayer and power dragonmail it got from the level 100 guy. Besides, high level players would finally have something to spend their huge amounts of money on (At least part of it). Anyways, it's just a thought. Andreas V. From andi.vogl at gmx.net Sat May 12 07:00:11 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] Reducing exp penalty on death In-Reply-To: <200105091807.f49I7uW01543@tonks.EECS.Berkeley.EDU> Message-ID: <000101c0dadb$1a95ece0$ac1efea9@kyle> PeterM wrote: > This has been discussed several times, but I'll float it here: > do we have a consensus in favor of reducing the experience penalty > on death? Some on IRC have said we should change it BEFORE v. 1.0. > > 1) Yes, reduce it. > > a) Reduce it to 25% or 3 experience levels in each category, > whicheveris LESS. (my favored method) > b) Reduce it to 10% (or X--you fill in X). > c) Use this forumla: loss = F(current_exp) (you fill in F) > > 2) No, death is already too painless. Leave it. I think we pretty much have a consesus that exp loss at high levels hurts too bad. I'd rather not do it before 1.0 though, since I'd prefer to have it seriously thought out and tested a bit. While having a formula (c) of flattening exp loss at high levels seems best, the 3-levels limit (a) might work quite okay as well. However, when there is less exp-loss on death, collecting exp to high numbers will of course be much easier. While this is more or less what we intended, I think we should consider to increase the gaps between level gains at the high end. The step from level 109 to 110 should be much wider than from level 50 to 51. Right now this is not the case, as far as I know. Andreas V. From mwedel at scruz.net Sat May 12 12:59:05 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] acid and repairing of weapons References: <000001c0dad8$e95ab180$ac1efea9@kyle> Message-ID: <3AFD79E9.26F123BD@scruz.net> How big a problem is presents for experienced people? It seems that it will always be difficult to prevent that abuse. Even with a you need to have the item repaired periodically, I could see the experienced people still giving out say the dragon armor, and maybe some cash now and again. My bigger worry about wear and tear on items is balancing it so it happens fast enough, but not too fast and not too slow. If its too fast such that you need to visit the armourer a few times when clearing out a dungeon because your weapons are getting damaged, this just makes it annoying. However, at the same time, if youu can go through several dungeons before the object getting damaged, this may not be frequent enough to have much real effect. If presents from high level characters are really the problem, a better way to deal with this is probably to add min_level values to most all the objects. This would act in a similar fashion as how player improved swords act - if your not high enough level, you can't use it. Except for map makers putting in really good items with no min level, I can't really think of any way this could be abused. The tricky part is of course figuring out what reasonable min levels for all the varioius pieces of equipment may be. But that is probably no harder than trying to balance repair costs and how much they decay for normal objects. This doesn't address the problem with acid however. And AV's idea of decay, even if only used for acid, may help out - now it just becomes a matter of spending money to get your item back the way it was before. And some items could of course have a very high decay rate, so take lots of hits. From andi.vogl at gmx.net Sat May 12 14:16:35 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] acid and repairing of weapons In-Reply-To: <3AFD79E9.26F123BD@scruz.net> Message-ID: <000001c0db18$117bd4c0$7730fea9@kyle> Mark W. wrote: > How big a problem is presents for experienced people? To my experience it happens very often on all online servers. Of course this has to do with the fact that low level players generally have a harder time than high level players in CF. So instead of doing all the struggle to work ones way up, many players accept a "present" at a certain point to get a boost. Of course it can be argued wether forcing players to go all the way is actually good. Personally I think it is. > It seems that it will always be difficult to prevent that abuse. > Even with a you need to have the item repaired periodically, I > could see the experienced people still giving out say the dragon > armor, and maybe some cash now and again. Yes, I see this too. That's why diablo II uses BOTH level requirements AND repair costs to keep newbies away from the heavy stuff. Still, asking other players for money all the time doesn't make one feel like a hero. And if high level players are in better need for their own money (to repair stuff), they might not give it away so easily. > My bigger worry about wear and tear on items is balancing it so it > happens fast enough, but not too fast and not too slow. [...] That's a good point. I would make it last rather long though. So that one can clear a fair number of dungeons before seeing the blacksmith again. > If presents from high level characters are really the problem, a better > way to deal with this is probably to add min_level values to most all > the objects. [...] > This doesn't address the problem with acid however. [...] Min levels are indeed a good alternative, except for the acid corrosion. As stated before, some RPGs use it both. Of course, it would require a bit of work to implement and apply either of these ideas. Andreas V. From mwedel at scruz.net Sat May 12 14:19:38 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] AC and WC use signed chars. Wrapping can happen EASILY. References: <200105110742.f4B7gw205514@tonks.EECS.Berkeley.EDU> Message-ID: <3AFD8CCA.5534584F@scruz.net> Fixed in CVS: common/living.c: Fix AC wrapping problem - now limit ac to +/- 120. MSW 2001-05-12 Just as a note - I would think the definition of easily may be a bit overstated. I'm guessing to get this bug you need to be very high level - once your there, it may be easy, but getting to that point may not be easy. From mwedel at scruz.net Sat May 12 15:36:22 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] CVS access/commiters note Message-ID: <3AFD9EC6.8601E86A@scruz.net> With the upcoming release of 1.0, and the fact that currently the following rules are not always being followed, I decided to write a more formal description for doing CVS checkins. If you have additions or other notes, feel free to followup. 1) Log messages should include the following: a) what changed b) why it changed c) name of person doing the checkin, and date done. It is not necessary to go into a long exposition, and pasting the actual changes is not generally useful. But this log message should be useful for someone looking over the logs at a future point to see what did change. Havinga log like 'various skill stuff' isn't very useful. A log message like 'prevent abuse with the literacy skill, and increase chance of singing' is much more useful, and not a lot more words. One of the main uses of the log entries is when bugs are reported where behaviour changed between version X and Y to be able to look at the log entries and get an idea of what specific revision may have caused that change. If doing a commit of several different files at each time, and the commits are different in nature, do try to at least mention what is changing in each file. Do not refer to other files or other log messages. Saying 'see changes file' is not useful, nor is a message like 'continuing with last set of commits'. Such messages are not useful when trying to look back through the logs at a future point. There is no excuse for not having a good log entry. Worst case, cut and past from the CHANGES file or those prior commits. My typical method of doing commits is filling out the CHANGES file, and then copying/pasting from that when I do the commit. 2) All checkins should go through at least minimum testing: For source code, this means it compiles and at least a basic test has been done (for example, if it is a new spell, have you tried casting the spell?) This basic testing implies the code at least compiles also. I realize it is very difficult to do 100% testing of code, but at least a basic test should be done. All source code should also be ANSI & POSIX compliant. Don't use // for comments. Be careful of new library calls that are not being used elsewhere in the source - there may be a reason they are not being used. "it compiles on my system" is not justification for writing code that does not work elsewhere. It is understandable that you may not know that the code written is non portable, but once this is learned, it should be corrected. For archetypes, this testing should involve rebuilding the arch file and running with the new file. There should be no errors in the loading of the archetype files. For maps, this means that the map should load, and the exits should lead back and forth. Note that maps in the unlinked directory are more work in progress so can be checked in a more experimental state. 3) Style & Balance: Your changes may work, but do they fit in with the rest of the game. This basically means following the files guides that already existing, eg doc/programming_guide, doc/mapguide There really is no arch guide, but take common sense. Does the object fit in with the game (ie, a blaster rifle would not), is this arch very unbalancing, etc. 4) Before starting a big project, send a note to the mailing list asking for opinions. While it is not possible to prevent someone working on whatever they may want, if the general consensus is that it is a bad idea, you may want to find that out before spending a lot of work on it only to find out that your idea will not get added to the game. Mark Wedel May 12, 2001 From dnh at hawthorn.csse.monash.edu.au Sat May 12 20:21:58 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] Reducing exp penalty on death In-Reply-To: <000101c0dadb$1a95ece0$ac1efea9@kyle> Message-ID: I agree with AV, you feel alot more proud of a high level char because it took so much work to do, if we lower that difficulty.. OBVIOUSLY.. you will be less proud of getting a high exp char. I would actually be more happy to see the amount of exp required per level a log(x) - 2 curve or such... dnh On Sat, 12 May 2001, Andreas Vogl wrote: > PeterM wrote: > > > This has been discussed several times, but I'll float it here: > > do we have a consensus in favor of reducing the experience penalty > > on death? Some on IRC have said we should change it BEFORE v. 1.0. > > > > 1) Yes, reduce it. > > > > a) Reduce it to 25% or 3 experience levels in each category, > > whicheveris LESS. (my favored method) > > b) Reduce it to 10% (or X--you fill in X). > > c) Use this forumla: loss = F(current_exp) (you fill in F) > > > > 2) No, death is already too painless. Leave it. > > I think we pretty much have a consesus that exp loss at high levels > hurts too bad. I'd rather not do it before 1.0 though, since I'd > prefer to have it seriously thought out and tested a bit. > > While having a formula (c) of flattening exp loss at high levels > seems best, the 3-levels limit (a) might work quite okay as well. > > However, when there is less exp-loss on death, collecting exp to > high numbers will of course be much easier. While this is more or > less what we intended, I think we should consider to increase the > gaps between level gains at the high end. > The step from level 109 to 110 should be much wider than from > level 50 to 51. Right now this is not the case, as far as I know. > > Andreas V. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Sat May 12 20:48:49 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:49 2005 Subject: [CF-Devel] acid and repairing of weapons In-Reply-To: <000001c0db18$117bd4c0$7730fea9@kyle> Message-ID: A small thing... interesting how we admit it is harder for low levels, and in particular newbies. Why pray tell is this? perhaps we should do abit of exp tweaking? I would be happy to see skeletons worth more, and small trolls... perhaps we should really think deap about this. Most people on this list are experienced players and thus are alittle prone to making things harder not easier.. dnh On Sat, 12 May 2001, Andreas Vogl wrote: > Mark W. wrote: > > > How big a problem is presents for experienced people? > > To my experience it happens very often on all online servers. > Of course this has to do with the fact that low level players > generally have a harder time than high level players in CF. > So instead of doing all the struggle to work ones way up, > many players accept a "present" at a certain point to get > a boost. Of course it can be argued wether forcing players > to go all the way is actually good. Personally I think it is. > > > It seems that it will always be difficult to prevent that abuse. > > Even with a you need to have the item repaired periodically, I > > could see the experienced people still giving out say the dragon > > armor, and maybe some cash now and again. > > Yes, I see this too. That's why diablo II uses BOTH level requirements > AND repair costs to keep newbies away from the heavy stuff. > Still, asking other players for money all the time doesn't make > one feel like a hero. And if high level players are in better need > for their own money (to repair stuff), they might not give it away > so easily. > > > My bigger worry about wear and tear on items is balancing it so it > > happens fast enough, but not too fast and not too slow. [...] > > That's a good point. I would make it last rather long though. > So that one can clear a fair number of dungeons before seeing the > blacksmith again. > > > If presents from high level characters are really the problem, a better > > way to deal with this is probably to add min_level values to most all > > the objects. [...] > > This doesn't address the problem with acid however. [...] > > Min levels are indeed a good alternative, except for the acid corrosion. > As stated before, some RPGs use it both. Of course, it would require > a bit of work to implement and apply either of these ideas. > > Andreas V. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From peterm at tonks.EECS.Berkeley.EDU Sat May 12 21:10:33 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:50 2005 Subject: Overgenerosity.. Re: [CF-Devel] acid and repairing of weapons In-Reply-To: Your message of "Sat, 12 May 2001 10:59:05 PDT." <3AFD79E9.26F123BD@scruz.net> Message-ID: <200105130210.f4D2AY708203@tonks.EECS.Berkeley.EDU> > > How big a problem is presents for experienced people? It's fairly common. When I see it happen I try to persuade the 'overgenerous' player that it's better to make the new player pay for or trade for the items he wants. Trading and selling to other players is social and doesn't spoil the fun for the new player, who, after all, had to work for what he got. I like Mark's idea of setting a minimum level on many artifacts, but better yet, we can try to persuade everyone not to be overgenerous. After all, what is more fun, finding something cool in the dungeon for the first time, or getting told, "here, I don't need this, you can have it." I think most people would agree with this point of view when it is properly explained. We just have to form the proper culture and be a bit persuasive. This "cultural" fix has the added benefits of allowing the players discretion, and the ability to pass things between their own chars without restriction. Maybe for your first char it's very exciting to find that Darkblade, but for your second char, it's not such a big deal. All in all, I think we should be very glad we have THIS problem and not the problem of people slaughtering each other. PeterM From hsteoh at quickfur.yi.org Sat May 12 21:12:24 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] acid and repairing of weapons In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Sun, May 13, 2001 at 11:48:49AM +1000 References: <000001c0db18$117bd4c0$7730fea9@kyle> Message-ID: <20010512221224.A2113@crystal> On Sun, May 13, 2001 at 11:48:49AM +1000, dnh wrote: > A small thing... interesting how we admit it is harder for low levels, and > in particular newbies. Why pray tell is this? perhaps we should do abit of > exp tweaking? I would be happy to see skeletons worth more, and small > trolls... perhaps we should really think deap about this. Most people on > this list are experienced players and thus are alittle prone to making > things harder not easier.. [snip] Actually, IMHO, the problem is with the lack of good low-level maps. Every time I start a new character, I find that after a while, i have to keep repeating the same few quests because the rest are too high-level and there aren't any other low-level maps left. Plus, most of the low-level maps suck (to be quite frank). IMHO, if there are enough interesting, worthwhile low-level quests around, new players would tend to prefer gaining levels themselves, instead of going for gifts from higher-level players to get a "boost". (And part of "worthwhile" is rewarding -- too many low-level quests have little or nothing whatsoever to offer in return for the newbie's efforts, so there is not much motivation to do them in the first place.) This is why I've stopped working on high-level maps, and am now working on making *good* low-level maps. T -- PNP = Plug 'N' Pray From dnh at hawthorn.csse.monash.edu.au Sat May 12 21:16:47 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] CVS access/commiters note In-Reply-To: <3AFD9EC6.8601E86A@scruz.net> Message-ID: Cmpletely agree and accept this email, dnh On Sat, 12 May 2001, Mark Wedel wrote: > > With the upcoming release of 1.0, and the fact that currently the > following rules are not always being followed, I decided to write a more > formal description for doing CVS checkins. > > If you have additions or other notes, feel free to followup. > > 1) Log messages should include the following: > a) what changed > b) why it changed > c) name of person doing the checkin, and date done. > > It is not necessary to go into a long exposition, and pasting the actual > changes is not generally useful. But this log message should be useful for > someone looking over the logs at a future point to see what did change. > Havinga log like 'various skill stuff' isn't very useful. A log message like > 'prevent abuse with the literacy skill, and increase chance of singing' is > much more useful, and not a lot more words. > > One of the main uses of the log entries is when bugs are reported where > behaviour changed between version X and Y to be able to look at the log > entries and get an idea of what specific revision may have caused that > change. > > If doing a commit of several different files at each time, and the commits > are different in nature, do try to at least mention what is changing in > each file. > > Do not refer to other files or other log messages. Saying 'see changes > file' is not useful, nor is a message like 'continuing with last set > of commits'. Such messages are not useful when trying to look back through > the logs at a future point. > > There is no excuse for not having a good log entry. Worst case, cut and > past from the CHANGES file or those prior commits. My typical method > of doing commits is filling out the CHANGES file, and then > copying/pasting from that when I do the commit. > > 2) All checkins should go through at least minimum testing: > For source code, this means it compiles and at least a basic test has > been done (for example, if it is a new spell, have you tried casting > the spell?) This basic testing implies the code at least compiles > also. I realize it is very difficult to do 100% testing of code, but > at least a basic test should be done. > > All source code should also be ANSI & POSIX compliant. Don't use // for > comments. Be careful of new library calls that are not being used > elsewhere in the source - there may be a reason they are not being used. > "it compiles on my system" is not justification for writing code that does > not work elsewhere. It is understandable that you may not know that the > code written is non portable, but once this is learned, it should be > corrected. > > For archetypes, this testing should involve rebuilding the arch file and > running with the new file. There should be no errors in the loading > of the archetype files. > > For maps, this means that the map should load, and the exits should lead > back and forth. Note that maps in the unlinked directory are more > work in progress so can be checked in a more experimental state. > > 3) Style & Balance: Your changes may work, but do they fit in with the > rest of the game. This basically means following the files guides > that already existing, eg doc/programming_guide, doc/mapguide > > There really is no arch guide, but take common sense. Does the > object fit in with the game (ie, a blaster rifle would not), is this > arch very unbalancing, etc. > > 4) Before starting a big project, send a note to the mailing list asking > for opinions. While it is not possible to prevent someone working on > whatever they may want, if the general consensus is that it is a bad idea, > you may want to find that out before spending a lot of work on it only > to find out that your idea will not get added to the game. > > Mark Wedel > May 12, 2001 > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From peterm at tonks.EECS.Berkeley.EDU Sat May 12 21:55:22 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] acid and repairing of weapons In-Reply-To: Your message of "Sat, 12 May 2001 10:59:05 PDT." <3AFD79E9.26F123BD@scruz.net> Message-ID: <200105130255.f4D2tMZ08231@tonks.EECS.Berkeley.EDU> Regarding repairs of equipment, I truly think it's just another hassle, and won't be particularly fun. However, I can live with it if the hassle is kept to a minimum. But what happens if you DON'T repair your items? Do they fail on you in the field, probably causing your death? Not good. I don't think it can be realistically made to address the problem of overgenerosity. Requiring too much money for repairs won't be *any* fun, because players will have to do low-level no-risk maps for money collection. Requiring too little (even 1% too little) will give players more than enough spare resources to donate to lower-level players, after a while. PeterM From peterm at tonks.EECS.Berkeley.EDU Sat May 12 22:01:14 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] Reducing exp penalty on death In-Reply-To: Your message of "Sun, 13 May 2001 11:21:58 +1000." Message-ID: <200105130301.f4D31Ed08299@tonks.EECS.Berkeley.EDU> > I agree with AV, you feel alot more proud of a high level char because it > took so much work to do, if we lower that difficulty.. OBVIOUSLY.. you Well, it took me, arguably a highly experienced and expert player, something like 3-4 months to bring my char to his present mostly-maxed state on Metalforge. Seems hard enough to me! I don't think it needs fixing. PeterM > will be less proud of getting a high exp char. I would actually be more > happy to see the amount of exp required per level a log(x) - 2 curve or > such... > > dnh > > On Sat, 12 May 2001, Andreas Vogl wrote: > > > PeterM wrote: > > > > > This has been discussed several times, but I'll float it here: > > > do we have a consensus in favor of reducing the experience penalty > > > on death? Some on IRC have said we should change it BEFORE v. 1.0. > > > > > > 1) Yes, reduce it. > > > > > > a) Reduce it to 25% or 3 experience levels in each category, > > > whicheveris LESS. (my favored method) > > > b) Reduce it to 10% (or X--you fill in X). > > > c) Use this forumla: loss = F(current_exp) (you fill in F) > > > > > > 2) No, death is already too painless. Leave it. > > > > I think we pretty much have a consesus that exp loss at high levels > > hurts too bad. I'd rather not do it before 1.0 though, since I'd > > prefer to have it seriously thought out and tested a bit. > > > > While having a formula (c) of flattening exp loss at high levels > > seems best, the 3-levels limit (a) might work quite okay as well. > > > > However, when there is less exp-loss on death, collecting exp to > > high numbers will of course be much easier. While this is more or > > less what we intended, I think we should consider to increase the > > gaps between level gains at the high end. > > The step from level 109 to 110 should be much wider than from > > level 50 to 51. Right now this is not the case, as far as I know. > > > > Andreas V. > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From peterm at tonks.EECS.Berkeley.EDU Sat May 12 22:04:04 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] acid and repairing of weapons In-Reply-To: Your message of "Sun, 13 May 2001 11:48:49 +1000." Message-ID: <200105130304.f4D344v08312@tonks.EECS.Berkeley.EDU> > A small thing... interesting how we admit it is harder for low levels, and > in particular newbies. Why pray tell is this? perhaps we should do abit of Er, it's harder because they don't know the tricks, being newbies. Also, low level chars they can't find anything weaker to beat on. THEY are on a par with the weakest things. So it's inherently hard. Now, as to tweaking the experience value of stuff. THIS IS SORELY NEEDED. Monster worth is almost *totally* irrational right now. We should put this on the post 1.0 TODO. PeterM > exp tweaking? I would be happy to see skeletons worth more, and small > trolls... perhaps we should really think deap about this. Most people on > this list are experienced players and thus are alittle prone to making > things harder not easier.. > > dnh > > On Sat, 12 May 2001, Andreas Vogl wrote: > > > Mark W. wrote: > > > > > How big a problem is presents for experienced people? > > > > To my experience it happens very often on all online servers. > > Of course this has to do with the fact that low level players > > generally have a harder time than high level players in CF. > > So instead of doing all the struggle to work ones way up, > > many players accept a "present" at a certain point to get > > a boost. Of course it can be argued wether forcing players > > to go all the way is actually good. Personally I think it is. > > > > > It seems that it will always be difficult to prevent that abuse. > > > Even with a you need to have the item repaired periodically, I > > > could see the experienced people still giving out say the dragon > > > armor, and maybe some cash now and again. > > > > Yes, I see this too. That's why diablo II uses BOTH level requirements > > AND repair costs to keep newbies away from the heavy stuff. > > Still, asking other players for money all the time doesn't make > > one feel like a hero. And if high level players are in better need > > for their own money (to repair stuff), they might not give it away > > so easily. > > > > > My bigger worry about wear and tear on items is balancing it so it > > > happens fast enough, but not too fast and not too slow. [...] > > > > That's a good point. I would make it last rather long though. > > So that one can clear a fair number of dungeons before seeing the > > blacksmith again. > > > > > If presents from high level characters are really the problem, a better > > > way to deal with this is probably to add min_level values to most all > > > the objects. [...] > > > This doesn't address the problem with acid however. [...] > > > > Min levels are indeed a good alternative, except for the acid corrosion. > > As stated before, some RPGs use it both. Of course, it would require > > a bit of work to implement and apply either of these ideas. > > > > Andreas V. > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From highway at cstone.net Sun May 13 01:28:34 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] acid and repairing of weapons References: <200105130304.f4D344v08312@tonks.EECS.Berkeley.EDU> Message-ID: <3AFE2992.2B9058DC@cstone.net> Peter Mardahl wrote: > Monster worth is almost *totally* irrational right now. That's completely true. I have one player on my server who refuses to fight certain creatures because they aren't worth his time, in his words - he'll only fight certain maps, over and over, to get the XP. Of course, I noticed I get more for goblins than gnolls, and I'm not certain that's right...then again, I'm at my highest level yet (level 21), so I'm still figgerin' stuff out. :) SeanMike From peterm at tonks.EECS.Berkeley.EDU Sun May 13 02:49:42 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] Enchant Armour MUST be moderated In-Reply-To: Your message of "Sun, 13 May 2001 02:28:34 EDT." <3AFE2992.2B9058DC@cstone.net> Message-ID: <200105130749.f4D7ngl08762@tonks.EECS.Berkeley.EDU> Hello, With enchant armour scrolls, it's not very hard to obtain armour values like 95 or 97. Permanently, and with items of your choice. We can do this immediately post 1.0. To get similar values for other resistances, you have to make REAL tradeoffs. How about this? Armour caps for every type of armour: Type Max armour Current max boots 10 90 helmet 20 90 armour 60 90 shield 20 90 gloves 10 90 gauntlets 10 90 cloak 20 90 bracers 10 90 I don't propose to cap the amout of ac given beyond what is already done. PeterM From peterm at tonks.EECS.Berkeley.EDU Sun May 13 02:51:21 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] Another to-do for post 1.0: monster experience worth Message-ID: <200105130751.f4D7pLT08778@tonks.EECS.Berkeley.EDU> It'd be nice if someone came up with a rational system of awarding experience for monsters. Right now experience award is quite haphazard. PeterM From peterm at tonks.EECS.Berkeley.EDU Sun May 13 02:56:43 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] URGENT: compile problem in crossfire? Current CVS. Message-ID: <200105130756.f4D7uhn08799@tonks.EECS.Berkeley.EDU> Hello, I get this compile problem for crossedit: /bin/rm -f crossedit gcc -o crossedit crossedit.o Attr.o CrFace.o CrEdit.o CrList.o CrUtil.o Edit.o App.o Bitmaps.o Str.o xutil.o ../common/libcross.a Cnv/libCnv.a -ldes -lcrypt -lm -L/usr/X11R6/lib -L/usr/X11R6/lib -lXaw -lX11 -lICE -lSM -lXext -lXt -lXmu -lXpm /usr/X11R6/lib/libXaw.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() ../common/libcross.a(map.o): In function `free_all_maps': /home/crosfire/crossfire/common/map.c(.text+0x2f31): undefined reference to `styles' /home/crosfire/crossfire/common/map.c(.text+0x2f39): undefined reference to `styles' /home/crosfire/crossfire/common/map.c(.text+0x2f4a): undefined reference to `styles' *** Error code 1 This is seemingly a current CVS snapshot. Those with access to crossfire.csua can give it a shot. PeterM From mwedel at scruz.net Sun May 13 03:23:13 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] URGENT: compile problem in crossfire? Current CVS. References: <200105130756.f4D7uhn08799@tonks.EECS.Berkeley.EDU> Message-ID: <3AFE4471.6229E368@scruz.net> Sorry - my bad. I had actually noticed this and fixed it, but had forgot to check it in. It now is checked in. Peter Mardahl wrote: > > Hello, > > I get this compile problem for crossedit: > /bin/rm -f crossedit > gcc -o crossedit crossedit.o Attr.o CrFace.o CrEdit.o CrList.o CrUtil.o Edit.o App.o Bitmaps.o Str.o xutil.o ../common/libcross.a Cnv/libCnv.a -ldes -lcrypt -lm -L/usr/X11R6/lib -L/usr/X11R6/lib -lXaw -lX11 -lICE -lSM -lXext -lXt -lXmu -lXpm > /usr/X11R6/lib/libXaw.so: warning: tmpnam() possibly used unsafely; consider using mkstemp() > ../common/libcross.a(map.o): In function `free_all_maps': > /home/crosfire/crossfire/common/map.c(.text+0x2f31): undefined reference to `styles' > /home/crosfire/crossfire/common/map.c(.text+0x2f39): undefined reference to `styles' > /home/crosfire/crossfire/common/map.c(.text+0x2f4a): undefined reference to `styles' > *** Error code 1 > > This is seemingly a current CVS snapshot. > Those with access to crossfire.csua can give it a shot. > > PeterM > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From andi.vogl at gmx.net Sun May 13 03:48:41 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] Reducing exp penalty on death In-Reply-To: <200105130301.f4D31Ed08299@tonks.EECS.Berkeley.EDU> Message-ID: <000001c0db89$84ab5f80$c154fea9@kyle> Peterm wrote: > > I agree with AV, you feel alot more proud of a high level char > > because it took so much work to do, if we lower that difficulty.. > > OBVIOUSLY.. you will be less proud of getting a high exp char. > > I would actually be more happy to see the amount of exp required > > per level a log(x) - 2 curve or such... > > Well, it took me, arguably a highly experienced and expert player, > something like 3-4 months to bring my char to his present mostly-maxed > state on Metalforge. > > Seems hard enough to me! > > I don't think it needs fixing. Well, we're talking about reducing exp loss on death. Now imagine every time you died it took you only 3 levels down, would you still need 3 months to hit level 110? I bet no. Anyways, my concern is that once we have this 3 levels limit, there is no difference between being level 50 and level 110, except that the player grows stronger. You need the same amount of exp to gain a level, and you loose the same amount when you die. In other words: If you are able to reach level 50, growing to level 110 requires no additional effort. In fact, it will be much easier at the high end because the player is a lot stronger by that time. I think this would be very odd. That's why I plead for using widening gaps for level gains, like all RPGs do. That wouldn't make the game very much harder, it would mainly lenghten the process to hit the uppermost level. So that the average time to beat the game is kept about the same, while the difficulty to keep your levels is reduced. Make players grow slower but grow more steadily. Andreas V. From andi.vogl at gmx.net Sun May 13 04:27:29 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] Enchant Armour MUST be moderated In-Reply-To: <200105130749.f4D7ngl08762@tonks.EECS.Berkeley.EDU> Message-ID: <000101c0db8e$efc0c1c0$c154fea9@kyle> Peterm wrote: > With enchant armour scrolls, it's not very hard to obtain > armour values like 95 or 97. Permanently, and with items of > your choice. > > We can do this immediately post 1.0. > > To get similar values for other resistances, you have to > make REAL tradeoffs. > > How about this? Armour caps for every type of armour: > > Type Max armour Current max > boots 10 90 > helmet 20 90 > armour 60 90 > shield 20 90 > gloves 10 90 > gauntlets 10 90 > cloak 20 90 > bracers 10 90 max total: 86% 99% > I don't propose to cap the amout of ac given beyond what > is already done. It's a real good idea, but I think the maxes you proposed are too low. Almost every monster has physical attack, at higher levels these do crazy amounts of damage. A warrior needs real tight physical protection or he is totally screwed. 86% is not enough. What about this?: Type Max armour boots 20 helmet 30 armour 65 shield 40 gauntlets 30 /gloves 10 cloak 20 bracers 10 max total: 94% Note that the max total can be surpassed by finding equipment with more than max armour. Wearing rings/amulets(/girdles?) with physical protection is also possible but usually this will not be rewarding. Andreas V. From Philipp.Currlin at t-online.de Sun May 13 06:43:04 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] URGENT: compile problem in crossfire? Current CVS. In-Reply-To: <3AFE4471.6229E368@scruz.net> References: <200105130756.f4D7uhn08799@tonks.EECS.Berkeley.EDU> <3AFE4471.6229E368@scruz.net> Message-ID: <01051313430400.10721@truth> On Sunday 13 May 2001 10:23, you wrote: > Sorry - my bad. I had actually noticed this and fixed it, but had forgot > to check it in. > > It now is checked in. It still doesn't work, I get the same error. Phil From hsteoh at quickfur.yi.org Sun May 13 08:01:31 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] broken animation In-Reply-To: <01051100145302.12561@truth>; from Philipp.Currlin@t-online.de on Fri, May 11, 2001 at 12:14:53AM +0200 References: <01051100145302.12561@truth> Message-ID: <20010513090131.A8399@crystal> On Fri, May 11, 2001 at 12:14:53AM +0200, Philipp Currlin wrote: > In the alternate set (todays cvs) the animation of the balrog doesn't work > correctly. It uses the wrong image in the top left corner. > > Even a small bug is a bug.... [snip] I've noticed this on metalforge as well. I suspect it's NOT the animation itself that's broken, but something in the server that causes multi-part monsters to have out-of-sync squares. I've also seen DK's show the same problem (forget where, could be on metalforge, or could be my local server). T -- Why is a river rich? 'cos it has two banks. From dnh at hawthorn.csse.monash.edu.au Sun May 13 08:47:59 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] Enchant Armour MUST be moderated In-Reply-To: <200105130749.f4D7ngl08762@tonks.EECS.Berkeley.EDU> Message-ID: This sounds like a good idea, I am totally sick of the fact that you can't add monsters with purely physical damage, they do absolutely nothing to most players, dnh On Sun, 13 May 2001, Peter Mardahl wrote: > > Hello, > > With enchant armour scrolls, it's not very hard to obtain > armour values like 95 or 97. Permanently, and with items of > your choice. > > We can do this immediately post 1.0. > > To get similar values for other resistances, you have to > make REAL tradeoffs. > > How about this? Armour caps for every type of armour: > > Type Max armour Current max > boots 10 90 > helmet 20 90 > armour 60 90 > shield 20 90 > gloves 10 90 > gauntlets 10 90 > cloak 20 90 > bracers 10 90 > > > I don't propose to cap the amout of ac given beyond what > is already done. > > PeterM > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From peterm at tonks.EECS.Berkeley.EDU Sun May 13 15:27:18 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:50 2005 Subject: [CF-Devel] Enchant Armour MUST be moderated In-Reply-To: Your message of "Sun, 13 May 2001 11:27:29 +0200." <000101c0db8e$efc0c1c0$c154fea9@kyle> Message-ID: <200105132027.f4DKRId15893@tonks.EECS.Berkeley.EDU> > Peterm wrote: AV, your modified scheme seems fine to me, by and large, but your calculations don't include protection spells (protection from attack) armour spell (armour) (ironwood skin) potions (invulnerability, aetherality). Does consideration of these other ways to boost physical protection change your calculations? 3 of the 5 are readily available to fighters. After all, fighters must also often face fire and cold and other attacks, and these are much more dangerous, because they cannot be avoided by simply stepping back a square. So I think we can safely tolerate less protection to physical attacks than for the others. How about you pick values for 90, instead of 94? PeterM > > With enchant armour scrolls, it's not very hard to obtain > > armour values like 95 or 97. Permanently, and with items of > > your choice. > > > > We can do this immediately post 1.0. > > > > To get similar values for other resistances, you have to > > make REAL tradeoffs. > > > > How about this? Armour caps for every type of armour: > > > > Type Max armour Current max > > boots 10 90 > > helmet 20 90 > > armour 60 90 > > shield 20 90 > > gloves 10 90 > > gauntlets 10 90 > > cloak 20 90 > > bracers 10 90 > > max total: 86% 99% > > > I don't propose to cap the amout of ac given beyond what > > is already done. > > It's a real good idea, but I think the maxes you proposed > are too low. Almost every monster has physical attack, at > higher levels these do crazy amounts of damage. A warrior > needs real tight physical protection or he is totally screwed. > 86% is not enough. > > What about this?: > > Type Max armour > boots 20 > helmet 30 > armour 65 > shield 40 > gauntlets 30 /gloves 10 > cloak 20 > bracers 10 > > max total: 94% > > Note that the max total can be surpassed by finding equipment with > more than max armour. Wearing rings/amulets(/girdles?) with > physical protection is also possible but usually this will not > be rewarding. > > > Andreas V. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From yann.chachkoff at mailandnews.com Sun May 13 22:22:40 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] Bug report - The Divine Flower Bug Message-ID: <01051323224000.03672@Terminus.magellan.fpms.ac.be> Version: Current CVS version (0.98.0) Problem: Suppose player A is a follower of Mostrai, and B a follower of Sorig. B fails a priest casting and creates flowers all around. A takes some of these flowers and magically behaves like a follower of Sorig (can pray on Sorig altar but not on Mostrai's, gets Sorig's special stuff, etc) until dropping flowers or exiting the game (The divine flowers will never be saved). Source: in gods.c, function determine_god: for players, the inventory is browsed until a 'divine' object is encountered. That object is the praying skill 90% of the time, but it may also be 'divine' flowers. Proposed solution: Adding a skill check in the loop; the code: /* If we are player, lets search a bit harder for the god. This * is a fix for perceive self (before, we just looked at the active * skill.) */ if(op->type==PLAYER) { object *tmp; for (tmp=op->inv; tmp!=NULL; tmp=tmp->below) { if (tmp->exp_obj && tmp->exp_obj->title) return tmp->exp_obj->title; } } will become: /* If we are player, lets search a bit harder for the god. This * is a fix for perceive self (before, we just looked at the active * skill.) */ if(op->type==PLAYER) { object *tmp; for (tmp=op->inv; tmp!=NULL; tmp=tmp->below) { if (tmp->type == SKILL) { if (tmp->exp_obj && tmp->exp_obj->title) return tmp->exp_obj->title; } } } Note that the extra test should not slow the whole thing a lot, since for all non-skill objects, we only do one test. Commander Gros Ad Dwarvam Aeternam ! From mwedel at scruz.net Sun May 13 16:47:55 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] acid and repairing of weapons References: <200105130304.f4D344v08312@tonks.EECS.Berkeley.EDU> <3AFE2992.2B9058DC@cstone.net> Message-ID: <3AFF010B.5022FC5F@scruz.net> Sean Michael Whipkey wrote: > That's completely true. I have one player on my server who refuses to > fight certain creatures because they aren't worth his time, in his words > - he'll only fight certain maps, over and over, to get the XP. > > Of course, I noticed I get more for goblins than gnolls, and I'm not > certain that's right...then again, I'm at my highest level yet (level > 21), so I'm still figgerin' stuff out. :) > The problem is that this is very tricky to do right. I have two different characters, roughly the same level. One is a troll barbarian, the other a human paladin. Even though the have roughly the same items, the religion they have is different. The troll barbarian would have a very tough time going through the wyvern quest, for example, as even the dragon armor/shield, he has fire res of 30%. For the human, that quest is no problem, as his resistance to fire due to items and gods is in the 80+% range. Given that case, how can you ever really make things fair? The exp value for wyverns for one character may actually be too high for the ease he has of killing them, but for the other, they are very difficult monsters. That not to say that there are not problems out there. ITs just hard to say what is really a fair exp value, as perceived difficulty can vary greatly from character to character. From peterm at tonks.EECS.Berkeley.EDU Sun May 13 17:02:44 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] Bug report - The Divine Flower Bug In-Reply-To: Your message of "Sun, 13 May 2001 23:22:40 EDT." <01051323224000.03672@Terminus.magellan.fpms.ac.be> Message-ID: <200105132202.f4DM2iV16092@tonks.EECS.Berkeley.EDU> Ouch. This is an important abuse. Rather than apply your fix, how about disabling the stupid flowers? Many have complained about them. PeterM > Version: Current CVS version (0.98.0) > > Problem: > Suppose player A is a follower of Mostrai, and B a follower of Sorig. B > fails a priest casting and creates flowers all around. A takes some of these > flowers and magically behaves like a follower of Sorig (can pray on Sorig > altar but not on Mostrai's, gets Sorig's special stuff, etc) until dropping > flowers or exiting the game (The divine flowers will never be saved). > > Source: > in gods.c, function determine_god: for players, the inventory is browsed > until a 'divine' object is encountered. That object is the praying skill 90% > of the time, but it may also be 'divine' flowers. > > Proposed solution: > Adding a skill check in the loop; the code: > > /* If we are player, lets search a bit harder for the god. This > * is a fix for perceive self (before, we just looked at the active > * skill.) > */ > if(op->type==PLAYER) { > object *tmp; > > for (tmp=op->inv; tmp!=NULL; tmp=tmp->below) { > if (tmp->exp_obj && tmp->exp_obj->title) > return tmp->exp_obj->title; > } > } > > will become: > > /* If we are player, lets search a bit harder for the god. This > * is a fix for perceive self (before, we just looked at the active > * skill.) > */ > if(op->type==PLAYER) { > object *tmp; > > for (tmp=op->inv; tmp!=NULL; tmp=tmp->below) { > if (tmp->type == SKILL) > { > if (tmp->exp_obj && tmp->exp_obj->title) > return tmp->exp_obj->title; > } > } > } > > Note that the extra test should not slow the whole thing a lot, since for > all non-skill objects, we only do one test. > > Commander Gros > Ad Dwarvam Aeternam ! > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From peterm at tonks.EECS.Berkeley.EDU Sun May 13 17:12:48 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] Data to enlighten the armour maximum argument In-Reply-To: Your message of "Sun, 13 May 2001 11:27:29 +0200." <000101c0db8e$efc0c1c0$c154fea9@kyle> Message-ID: <200105132212.f4DMCmF16119@tonks.EECS.Berkeley.EDU> Hello, This strange set of data may enlighten, a little, where we should set the max armour value. My idea is if we know the survival time of a fighter vs. certain benchmark monsters, we'll know how high to set the max armour. I measured this stuff by: 1) Starting with a character with ac of 2 and no armour 2) Quaffing a potion of invuln for 90 armour 3) Standing next to the monster and seeing how long it took to kill me. Test dummy had 400 hp. All modified to have only AT_PHYSICAL. Monster wc ac speed dam armour survival in seconds Great Worm of Chaos -15 2 1.0 63 90 25 Arch Angel -40 2 .3 60 90 50+ Golem of Necromancer -20 2 .4 50 90 50+ Modified behomoth -100 2 .5 16 90 50+ Hanuk -20 2 .5 30 90 50+ Great Worm of Chaos -100 2 1.0 63 90 25 Ancient Red Dragon -25 2 0.5 40 90 18 These reults are fairly inexplicable. WHY is the ancient red dragon, with seemingly inferior stats, so deadly? I think this points to something bizarre in the code. AV is performing similar tests with other monsters, but I think 18 seconds of life at armour 90 is good enough, unless something evil is done, like placing him in the middle of 3 ancient red dragons. Resistance 95 would give the player ~2x the survival time shown 97 would give the player 3.3x the survival time shown. PeterM From mwedel at scruz.net Sun May 13 17:15:16 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] devourers References: <01050908343700.02029@Terminus.magellan.fpms.ac.be> <3AF8EB62.2FB727@scruz.net> <01050909255600.03225@Terminus.magellan.fpms.ac.be> Message-ID: <3AFF0774.C84A3A6B@scruz.net> I got to thinking about this (the fact if you worship the devourers, you become undead). And from a stylistic/realistic point of view, I got to thinking about this. First, I would think that if you became undead, you should lose most of your normal racial abilities. After all, your not really that race anymore are you (unless your playing a wraith). And from a storytelling point of view, exactly how does that transformation take place? Is it some ritual you do when you become a follower of the devourers? And if so, is it really a reversible process? You don't suddenly become a dwarf once you follow Mostrai. This is not really a big deal however we do it. But I was just thinking about it, and perhaps becoming a follower of the devourers should be a permanent commitment, at least as far as being undead is concerned. From mwedel at scruz.net Sun May 13 17:28:39 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] Data to enlighten the armour maximum argument References: <200105132212.f4DMCmF16119@tonks.EECS.Berkeley.EDU> Message-ID: <3AFF0A97.1383EC65@scruz.net> How are youu deriving the damage and wc values? Are you just taking what is listed in the .arch file? Remember that things like Dex and Str may adjust those values some. From peterm at tonks.EECS.Berkeley.EDU Sun May 13 17:35:57 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] Data to enlighten the armour maximum argument In-Reply-To: Your message of "Sun, 13 May 2001 15:28:39 PDT." <3AFF0A97.1383EC65@scruz.net> Message-ID: <200105132235.f4DMZvX16188@tonks.EECS.Berkeley.EDU> I wasn't aware that Str adjusted the wc of monsters. As for ac, I took it from the client, which said the target dummy player had an ac of 2. PeterM > How are youu deriving the damage and wc values? > > Are you just taking what is listed in the .arch file? > > Remember that things like Dex and Str may adjust those values some. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From peterm at tonks.EECS.Berkeley.EDU Sun May 13 17:38:05 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] devourers In-Reply-To: Your message of "Sun, 13 May 2001 15:15:16 PDT." <3AFF0774.C84A3A6B@scruz.net> Message-ID: <200105132238.f4DMc5u16201@tonks.EECS.Berkeley.EDU> The real benefit of being undead for devourers is that you NEVER have to worry about disease, and you ALWAYS have to worry about holy word. I've got no real problem with not forcing a devourer follower to become undead, and banning them from changing religions thereafter. PeterM > I got to thinking about this (the fact if you worship the devourers, you bec >ome > undead). And from a stylistic/realistic point of view, I got to thinking abo >ut > this. > > First, I would think that if you became undead, you should lose most of your > normal racial abilities. After all, your not really that race anymore are yo >u > (unless your playing a wraith). > > And from a storytelling point of view, exactly how does that transformation > take place? Is it some ritual you do when you become a follower of the > devourers? And if so, is it really a reversible process? > > You don't suddenly become a dwarf once you follow Mostrai. > > This is not really a big deal however we do it. But I was just thinking abo >ut > it, and perhaps becoming a follower of the devourers should be a permanent > commitment, at least as far as being undead is concerned. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From andi.vogl at gmx.net Sun May 13 18:41:50 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] Enchant Armour MUST be moderated In-Reply-To: <200105132027.f4DKRId15893@tonks.EECS.Berkeley.EDU> Message-ID: <000001c0dc06$4b3edf60$1733fea9@kyle> PeterM wrote: > After all, fighters must also often face fire and cold > and other attacks, and these are much more dangerous, because > they cannot be avoided by simply stepping back a square. > > So I think we can safely tolerate less protection to physical > attacks than for the others. [...] There's some truth in this. From my and PeterM's tests we have seen that physical, being a melee attack is a bit less dangerous than others. Of course, reducing physical resistance *will* make the game harder for warriors, but not in a way that it is byond sanity. So we agreed to a total max of 90% armour: boots 10 helmet 30 armour 60 shield 40 gauntlets 15 / gloves 10 cloak 20 bracers 10 total max: 90% This is the theory. Has yet to be coded into the game of course. Andreas V. From andi.vogl at gmx.net Sun May 13 18:53:20 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] Data to enlighten the armour maximum argument In-Reply-To: <200105132235.f4DMZvX16188@tonks.EECS.Berkeley.EDU> Message-ID: <000101c0dc07$e5642040$1733fea9@kyle> > I wasn't aware that Str adjusted the wc of monsters. > As for ac, I took it from the client, which said the > target dummy player had an ac of 2. That's a good point. I suspect STR for monsters does nothing. Likewise WIS, CON and POW do completely different things than all mapmakers assumed. Stats do *not* work for monsters like they do for players. According to "crossfire.doc": "Pow ": If the creature can cast spells, this is how many spell points are regenerated each move. "Con ": Monsters regenerate this many hit points each move. This is each time the monster has a move (same for Pow). So two monsters with the same Con can regenerate at different rates if their speeds are different. "Wis ": Determines how close a player needs to be before the creature wakes up. Is this really intended actually? Why are all monsters designed under the assumption that stats work for monsters just like for players. This is weird. Andreas V. From mwedel at scruz.net Sun May 13 22:34:44 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] Bug report - The Divine Flower Bug References: <200105132202.f4DM2iV16092@tonks.EECS.Berkeley.EDU> Message-ID: <3AFF5254.53E0FC3A@scruz.net> Peter Mardahl wrote: > > Ouch. This is an important abuse. > > Rather than apply your fix, how about disabling the stupid > flowers? > > Many have complained about them. The flowers in general are just a nuisance (even for things like wonder spell or fumbles). It may be cute, but makes it very difficult to find things that should not be that hard. But in this bug, I'm more curioius as th why the flowers have an experience object. My guess is that this is for things like wall of thorns, so the owner gets proper credit, but since the flowers don't kill anything, this doesn't make any sense. And I imagine this bug will happen for any other spell that creates objects that does damage that can be picked up (to be honest, I don't know if there is anything else out there like that, but who knows). So the better thing may be to make it such that if the object being created can be picked up, the experience object point should get cleared. From mwedel at scruz.net Sun May 13 22:54:05 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] Data to enlighten the armour maximum argument References: <000101c0dc07$e5642040$1733fea9@kyle> Message-ID: <3AFF56DD.9694065D@scruz.net> Andreas Vogl wrote: > > > I wasn't aware that Str adjusted the wc of monsters. > > As for ac, I took it from the client, which said the > > target dummy player had an ac of 2. > > That's a good point. I suspect STR for monsters does > nothing. Likewise WIS, CON and POW do completely > different things than all mapmakers assumed. > Stats do *not* work for monsters like they do for > players. According to "crossfire.doc": This is of course easily tested. My guess would be that Str works the same for monsters as it does for players - ie, carrying capacity as well as damage (and to hit) bonus. > > "Pow ": If the creature can cast spells, this is how many spell > points are regenerated each move. > > "Con ": Monsters regenerate this many hit points each move. > This is each time the monster has a move (same for Pow). So two monsters > with the same Con can regenerate at different rates if their speeds > are different. > > "Wis ": Determines how close a player needs to be before the > creature wakes up. > > Is this really intended actually? Why are all monsters designed under > the assumption that stats work for monsters just like for players. > This is weird. I don't know if that is the case for sure or not. Monsters are fairly different compared to players (for example, they just have a set hp/sp/grace total, and not a level array that gets summed up). And this is no worse than meanings for other objects not meaning what the variable name suggests. I think the above largely happens because monsters need some abilities that the players don't directly have, and so these values were recycled for that purpose. From mwedel at scruz.net Mon May 14 02:11:42 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] Enchant Armour MUST be moderated Message-ID: <3AFF852E.CCFBAC22@scruz.net> Andreas Vogl wrote: > boots 10 > helmet 30 > armour 60 > shield 40 > gauntlets 15 / gloves 10 > cloak 20 > bracers 10 Just a note - the only difference between gloves & gauntlets is name. So its probably easier to have both those be the same - then you can just key off the type, and not have to look at the name and try and figure out the right thing. From tanner at real-time.com Mon May 14 02:34:43 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] client.gnome Message-ID: <20010514023443.A13766@real-time.com> Please add client.gnome to the default client tarball. I'm having to patch it in via rpm right now. Thanks. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From tanner at real-time.com Mon May 14 02:35:58 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] shield.png Message-ID: <20010514023558.B13766@real-time.com> Also, the shield.png. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From peterm at tonks.EECS.Berkeley.EDU Mon May 14 13:14:58 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] Re: [CF List] Reliable saving of players/unique-items In-Reply-To: Your message of "Mon, 14 May 2001 19:02:35 +0200." <20010514190235.A17057@nic.nigdzie> Message-ID: <200105141815.f4EIEwt17781@tonks.EECS.Berkeley.EDU> This is an excellent suggesstion. I have referred it to the crossfire development list. PeterM > Hi, > > I have just lost my apartments again, because of full filesystem (BTW it > was filled by crashed crossfire). I have never lost the player the same > way, but if player files are created the same way as unique-items file > it can always happen. > > Maybe those files should be created more reliably. Eg. by writting > file.new first, and only if it succeeds the file would be renamed to > proper name. It can "save some lives". > > Greets, > Jacek > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From mwedel at scruznet.com Mon May 14 16:26:24 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] client.gnome In-Reply-To: <20010514023443.A13766@real-time.com> Message-ID: On Mon, 14 May 2001, Bob Tanner wrote: To do this only requires updating the Makefile.in. There is nothing tricky about it. From Philipp.Currlin at t-online.de Mon May 14 17:29:48 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] coins Message-ID: <01051500294800.06227@truth> That is two platinum coins It is made of: iron ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ They weigh 0.020 kg. You would get 2 platinum coins for the them. Are these iron coins or platinum coins? I think we should decide what material coins are made of. The easiest way would be to change everything from iron to metal... Phil From mwedel at scruznet.com Mon May 14 17:40:21 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:51 2005 Subject: [CF-Devel] Re: [CF List] Reliable saving of players/unique-items In-Reply-To: <200105141815.f4EIEwt17781@tonks.EECS.Berkeley.EDU> Message-ID: On Mon, 14 May 2001, Peter Mardahl wrote: Why checking for success on write is not to hard to do (note an alternate method which may actually be better is to rename the original to a backup, and if the save files, rename back again. If it succeeds, you could either delete the backup, or keep it around in case somethign else trashes the player file). But a bigger question is what to do when the write does fail. Because at that point, there really isn't much crossfire can do. Presumably, it should probably just exit, or at minimum, warn all the people playing that writes are failing, and they are likely to lose anything they are doing. Granted, if the admin of the machine notices, they can fix the space issue, but the likelihood/ability for that to happen is certainly not guaranteed. The unique player maps are probably a little more dangerous in that regard than the player files, as once the server tries to write them out, they are lost from memory. At least the player data persists in server memory, so if the problem is later corrected, nothing is really lost. Note that if a player has a way to cause write failures, I can think of several exploits right away. This is probably not a likely situation - such a situation would presume that the server is a public machine (ie, work or university server for example), and chances are the admins would not likely kindly on people filling up disks to cheat at a game. > > This is an excellent suggesstion. > I have referred it to the crossfire development list. > > PeterM > > > Hi, > > > > I have just lost my apartments again, because of full filesystem (BTW it > > was filled by crashed crossfire). I have never lost the player the same > > way, but if player files are created the same way as unique-items file > > it can always happen. > > > > Maybe those files should be created more reliably. Eg. by writting > > file.new first, and only if it succeeds the file would be renamed to > > proper name. It can "save some lives". > > > > Greets, > > Jacek > > _______________________________________________ > > crossfire-list mailing list > > crossfire-list@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-list > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Mon May 14 23:40:11 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:52 2005 Subject: [CF-Devel] Crossfire 1.0.0 released Message-ID: <3B00B32B.BCE4E397@scruz.net> Crossfire 1.0.0 has been released. This is the first public release/release for wide spread distribution. Extenstive testing has gone out, and the server appears quite stable. NOTE TO MIRROR SITES: The primary site (ftp.scruz.net) has limited download bandwidth per day. You can also get this release off of sourceforge.net. Files released for this version: sums (bsd) filename 64947 1567 crossfire-1.0.0-arch.tar.bz2 29912 1858 crossfire-1.0.0-arch.tar.gz 44121 2995 crossfire-1.0.0-maps.tar.bz2 11006 4327 crossfire-1.0.0-maps.tar.gz 21265 2703 crossfire-1.0.0.tar.bz2 24930 239 crossfire-client-1.0.0.tar.gz Sums (md5) 18c3cff268c55a7561c785f6202ba715 crossfire-1.0.0-arch.tar.bz2 25990ae2ecdabcb4a2195dce92cc335a crossfire-1.0.0-arch.tar.gz 00b045172663768997a7b4f7e5dcf64c crossfire-1.0.0-maps.tar.bz2 d30eb96538627a899edd22b5cf2f2323 crossfire-1.0.0-maps.tar.gz bece4993c7ce9e3b15347c723f2a0d93 crossfire-1.0.0.tar.bz2 0bb73a6ea4268ecd4a5720128ecdf9c5 crossfire-1.0.0.tar.gz c79bf87ddc71bbee4ab46f64f3c908c7 crossfire-client-1.0.0.tar.gz crossfire-client-1.0.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. crossfire-1.0.0.tar.{gz/bz2} contains the server code with prebuilt archetype and image files. crossfire-1.0.0.arch.tar.{gz/bz2} contains the unpacked archetype changes. This is not needed if you only want to compile the server and play the game. crossfire-1.0.0-maps.tar.{gz/bz2} contains the maps. This is needed with the server distribution. FOR FIRST TIME USERS: You will only need the appropriate server, map and client file. You do not need the arch file. If you are a first time user, you may want the doc file unless you are using a web based player referance. If you just want to play the game at some remote server, you need the client and perhaps some version of the doc file. Crossfire is avaible on the following ftp sites Primary: ftp://ftp.scruz.net:/users/mwedel/public (165.227.192.254) ftp://ftp.sourceforge.net:/pub/sourceforge/crossfire (64.28.67.101) ftp://ftp.ifi.uio.no:/pub/crossfire (129.240.64.44) Secondary: ftp://ftp.real-time.com/pub/games/crossfire ftp://ftp.cs.city.ac.uk:/pub/games/crossfire/ ftp://ftp.sunet.se:/pub/unix/games/crossfire (130.238.127.3) ftp://ftp.cs.titech.ac.jp:/pub/games/crossfire ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ ftp://crossfire.futt.org//pub/crossfire I uploaded this version to just ftp.scruz.net and sourceforge- it should be on the other ftp sites in a short time Mark Wedel mwedel@scruz.net ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Changes: Client: Changes for 1.0.0: player.c: Fix for client crashes if player enters really long commands (like say .....). MSW 2001-05-08 gx11.c,command.c: Remove some debug statements which really should not be there for 1.0, and which are not really useful anyways. items_types, item_types.h: Varioius minor updates. MSW 2001-05-04 gx11.c: Fix bug that causes gtk client not to update weapon speed. metaserver.c: Have the listing get sorted by hostname to make it easier to find the host the user may want. MSW 2001-05-02 ------------------------------------------------------------------------------ Server: Changes for 1.0.0: common/living.c: Fix AC wrapping problem - now limit ac to +/- 120. MSW 2001-05-12 include/config.h: Add NO_POLYMORPH feature selection include/spellist.h: If NO_POLYMORPH is set, make it so that polymorph will not show up in wands/rods server/spell_util.c: Handling for NO_POLYMORPH selection MSW 2001-05-11 server/rune.c: Make sure rune message is newline terminated. Fix map corruption problem. MSW 2001-05-10 Various improvements to make finding memory leaks easier. common/anim.c: Add free_all_anim function common/arch.c: Modify free_all_arch to free more data common/init.c: If running under MEMORY_DEBUG, don't pre-allocate objects. common/map.c: Add free_all_maps functiion. common/object.c: Modify object allocations if using MEMORY_DEBUG to only malloc one object at a time, and not pre-allocate objects. common/readable.c: Fix memory leak. common/shstr.c: Include autoconf.h so it can pull in dmalloc.h file. include/config.h: Remove notes of what was removed a long time ago. Add MEMORY_DEBUG option. include/libproto.h, include/sockproto.h, include/sproto.h: automatic rebuild server/c_misc.c: Fix 'malloc info command so it reports right memory total for maps. Add command_style_map_info which sums up memory used by style maps. server/commands.c: Add style_info wiz command which dumps memory usage for style maps. server/init.c: Have sighup handler call cleanup function. server/main.c: Fix clean_tmp_files which could result in crash if one of the maps in memory has 0 reset time. Modify cleanup function to free more data. server/player.c: op_on_battleground: Fix compile warning about unuused variable. socket/init.c: Change name of free_all_ericserver to free_all_newserver, have it free all face data. MSW 2001-05-08 socket/item.c: Modify look_at to not stop when it finds the first invisible object. server/monster.c: Modify monster_check_pickup to check to see if the next object got destroyed. I'm not sure the exact way this happens, but I've seen one crash where this did happen - I'm guess some function further down in the monster_check_apply look may call this or destroy the item. MSW 2001-05-01 common/object.c: Add clear_owner function. include/libproto.h: rebuild. server/player.c: Modify op_on_battleground to look for battleground anyplace on space. Temp for for wall of thorns on space - as long as maps don't try to abuse the use of battlegrounds, should be OK. server/time.c: Add clear_owner call to stop_arrow. Fixes problem of thrown objects not getting saved. MSW 2001-04-28 common/object.c: Have update_object map the look window for redraw if the object is not something the client normally animates (like a lever). MSW 2001-04-27 server/apply.c: Modify apply_id_altar check for player - had a && instead of a ||. socket/item.c: Modify ApplyCmd so a removed player can not apply objects. Fix crashes caused by players applying savebeds after they have used the bed. MSW 2001-04-26 server/spell_util.c: have put_a_monster generate random monster abilities. TODO, doc/mapguide: Various minor updates. MSW 2001-04-25 server/c_object.c: Pass right object to query_cost_string so that if you pick up an unpaid object into a container, it generates the correct price. MSW 2001-04-22 server/c_wiz.c: fix shutdown and reset_map wizard commands/function so they no longer crash the server. MSW 2001-04-22 server/monster.c: add check to was_destroyed when monster fires an arrow. Call was certainly missing, and appears to be responsible for crash. MSW 2001-04-20 server/player.c: Clear op->chosen_skill when we get to the play_again prompt. Otherwise, the server may try to use this later on, and it no longer points to a valid object, so it results in a crash. MSW 2001-04-19 server/skill_util.c: Add missing call to out_of_map in skill_attack which could result in crashes if player is at edge of maps and decides to attack in direction off map. MSW 2001-04-18 server/attack.c: Remove error message about golem without owners, also add better checking before clering the op->contr->golem field. common/map.c: set status flag on maps to MAP_SAVING so remove_ob does not do extra work when we are deleting a map (ie, immediate reset) from emory. server/skills.c: If someone is stolen from a player, send an esrv_delete_item to the client so the clients inventory remains correct. MSW 2001-04-16 common/re-cmp.c: Modify re_cmp functiion so that it properly matches strings not at the start 'ie, dude chain will now match against the chain value'. server/monster.c: Properly alter direction monster moves if they are feared or confused. It was properly altering direction when monsters were using range attacks, but not if they were just wanting to move. MSW 2001-04-12 common/living.c: Don't use the last_heal object in experience objects as sp regen penalty. This should fix the problem of inconsistent sp regen rates - last_heal is used in experience objects if the permanent experience option is turned on. MSW 2001-04-11 PeterM: server/spell_util.c: fix peace so it gives experience common/button.c: change the "error" to a "debug" message to reduce server crashing. From mwedel at scruz.net Mon May 14 23:53:29 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:52 2005 Subject: [CF-Devel] Crossfire 1.0.0 released. Message-ID: <3B00B649.51CB47E5@scruz.net> Crossfire 1.0.0 has been released. This is the first public release/release for wide spread distribution. Extenstive testing has gone out, and the server appears quite stable. NOTE TO MIRROR SITES: The primary site (ftp.scruz.net) has limited download bandwidth per day. You can also get this release off of sourceforge.net. Files released for this version: sums (bsd) filename 64947 1567 crossfire-1.0.0-arch.tar.bz2 29912 1858 crossfire-1.0.0-arch.tar.gz 44121 2995 crossfire-1.0.0-maps.tar.bz2 11006 4327 crossfire-1.0.0-maps.tar.gz 21265 2703 crossfire-1.0.0.tar.bz2 24930 239 crossfire-client-1.0.0.tar.gz Sums (md5) 18c3cff268c55a7561c785f6202ba715 crossfire-1.0.0-arch.tar.bz2 25990ae2ecdabcb4a2195dce92cc335a crossfire-1.0.0-arch.tar.gz 00b045172663768997a7b4f7e5dcf64c crossfire-1.0.0-maps.tar.bz2 d30eb96538627a899edd22b5cf2f2323 crossfire-1.0.0-maps.tar.gz bece4993c7ce9e3b15347c723f2a0d93 crossfire-1.0.0.tar.bz2 0bb73a6ea4268ecd4a5720128ecdf9c5 crossfire-1.0.0.tar.gz c79bf87ddc71bbee4ab46f64f3c908c7 crossfire-client-1.0.0.tar.gz crossfire-client-1.0.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. crossfire-1.0.0.tar.{gz/bz2} contains the server code with prebuilt archetype and image files. crossfire-1.0.0.arch.tar.{gz/bz2} contains the unpacked archetype changes. This is not needed if you only want to compile the server and play the game. crossfire-1.0.0-maps.tar.{gz/bz2} contains the maps. This is needed with the server distribution. FOR FIRST TIME USERS: You will only need the appropriate server, map and client file. You do not need the arch file. If you are a first time user, you may want the doc file unless you are using a web based player referance. If you just want to play the game at some remote server, you need the client and perhaps some version of the doc file. Crossfire is avaible on the following ftp sites Primary: ftp://ftp.scruz.net:/users/mwedel/public (165.227.192.254) ftp://ftp.sourceforge.net:/pub/sourceforge/crossfire (64.28.67.101) ftp://ftp.ifi.uio.no:/pub/crossfire (129.240.64.44) Secondary: ftp://ftp.real-time.com/pub/games/crossfire ftp://ftp.cs.city.ac.uk:/pub/games/crossfire/ ftp://ftp.sunet.se:/pub/unix/games/crossfire (130.238.127.3) ftp://ftp.cs.titech.ac.jp:/pub/games/crossfire ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ ftp://crossfire.futt.org//pub/crossfire I uploaded this version to just ftp.scruz.net and sourceforge- it should be on the other ftp sites in a short time Mark Wedel mwedel@scruz.net ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Changes: Client: Changes for 1.0.0: player.c: Fix for client crashes if player enters really long commands (like say .....). MSW 2001-05-08 gx11.c,command.c: Remove some debug statements which really should not be there for 1.0, and which are not really useful anyways. items_types, item_types.h: Varioius minor updates. MSW 2001-05-04 gx11.c: Fix bug that causes gtk client not to update weapon speed. metaserver.c: Have the listing get sorted by hostname to make it easier to find the host the user may want. MSW 2001-05-02 ------------------------------------------------------------------------------ Server: Changes for 1.0.0: common/living.c: Fix AC wrapping problem - now limit ac to +/- 120. MSW 2001-05-12 include/config.h: Add NO_POLYMORPH feature selection include/spellist.h: If NO_POLYMORPH is set, make it so that polymorph will not show up in wands/rods server/spell_util.c: Handling for NO_POLYMORPH selection MSW 2001-05-11 server/rune.c: Make sure rune message is newline terminated. Fix map corruption problem. MSW 2001-05-10 Various improvements to make finding memory leaks easier. common/anim.c: Add free_all_anim function common/arch.c: Modify free_all_arch to free more data common/init.c: If running under MEMORY_DEBUG, don't pre-allocate objects. common/map.c: Add free_all_maps functiion. common/object.c: Modify object allocations if using MEMORY_DEBUG to only malloc one object at a time, and not pre-allocate objects. common/readable.c: Fix memory leak. common/shstr.c: Include autoconf.h so it can pull in dmalloc.h file. include/config.h: Remove notes of what was removed a long time ago. Add MEMORY_DEBUG option. include/libproto.h, include/sockproto.h, include/sproto.h: automatic rebuild server/c_misc.c: Fix 'malloc info command so it reports right memory total for maps. Add command_style_map_info which sums up memory used by style maps. server/commands.c: Add style_info wiz command which dumps memory usage for style maps. server/init.c: Have sighup handler call cleanup function. server/main.c: Fix clean_tmp_files which could result in crash if one of the maps in memory has 0 reset time. Modify cleanup function to free more data. server/player.c: op_on_battleground: Fix compile warning about unuused variable. socket/init.c: Change name of free_all_ericserver to free_all_newserver, have it free all face data. MSW 2001-05-08 socket/item.c: Modify look_at to not stop when it finds the first invisible object. server/monster.c: Modify monster_check_pickup to check to see if the next object got destroyed. I'm not sure the exact way this happens, but I've seen one crash where this did happen - I'm guess some function further down in the monster_check_apply look may call this or destroy the item. MSW 2001-05-01 common/object.c: Add clear_owner function. include/libproto.h: rebuild. server/player.c: Modify op_on_battleground to look for battleground anyplace on space. Temp for for wall of thorns on space - as long as maps don't try to abuse the use of battlegrounds, should be OK. server/time.c: Add clear_owner call to stop_arrow. Fixes problem of thrown objects not getting saved. MSW 2001-04-28 common/object.c: Have update_object map the look window for redraw if the object is not something the client normally animates (like a lever). MSW 2001-04-27 server/apply.c: Modify apply_id_altar check for player - had a && instead of a ||. socket/item.c: Modify ApplyCmd so a removed player can not apply objects. Fix crashes caused by players applying savebeds after they have used the bed. MSW 2001-04-26 server/spell_util.c: have put_a_monster generate random monster abilities. TODO, doc/mapguide: Various minor updates. MSW 2001-04-25 server/c_object.c: Pass right object to query_cost_string so that if you pick up an unpaid object into a container, it generates the correct price. MSW 2001-04-22 server/c_wiz.c: fix shutdown and reset_map wizard commands/function so they no longer crash the server. MSW 2001-04-22 server/monster.c: add check to was_destroyed when monster fires an arrow. Call was certainly missing, and appears to be responsible for crash. MSW 2001-04-20 server/player.c: Clear op->chosen_skill when we get to the play_again prompt. Otherwise, the server may try to use this later on, and it no longer points to a valid object, so it results in a crash. MSW 2001-04-19 server/skill_util.c: Add missing call to out_of_map in skill_attack which could result in crashes if player is at edge of maps and decides to attack in direction off map. MSW 2001-04-18 server/attack.c: Remove error message about golem without owners, also add better checking before clering the op->contr->golem field. common/map.c: set status flag on maps to MAP_SAVING so remove_ob does not do extra work when we are deleting a map (ie, immediate reset) from emory. server/skills.c: If someone is stolen from a player, send an esrv_delete_item to the client so the clients inventory remains correct. MSW 2001-04-16 common/re-cmp.c: Modify re_cmp functiion so that it properly matches strings not at the start 'ie, dude chain will now match against the chain value'. server/monster.c: Properly alter direction monster moves if they are feared or confused. It was properly altering direction when monsters were using range attacks, but not if they were just wanting to move. MSW 2001-04-12 common/living.c: Don't use the last_heal object in experience objects as sp regen penalty. This should fix the problem of inconsistent sp regen rates - last_heal is used in experience objects if the permanent experience option is turned on. MSW 2001-04-11 PeterM: server/spell_util.c: fix peace so it gives experience common/button.c: change the "error" to a "debug" message to reduce server crashing. From david.delbecq at usa.net Tue May 15 01:57:18 2001 From: david.delbecq at usa.net (DAVID DELBECQ) Date: Thu Jan 13 18:00:52 2005 Subject: [Re: [CF-Devel] Re: [CF List] Reliable saving of players/unique-items] Message-ID: <20010515065718.25483.qmail@nwcst290.netaddress.usa.net> A good solution to resolve this problem is to allow the server to create a emergency save space. Let's say we create at installation time an empty file of about 2 or 3 Mb. This could be enough to emergency save players and their modified unique maps. (I think 1Mb is already enough since file only weight several Kbs) We don't need to save a lot of maps since each change in a unique map is immediately reported on the disk (this first map/player to fail enable an emergency save...). When the server detects an out of space problem, it open the emergency space (which already is 3 Mb length so there is enough space) and opens the file so to not delete or reset it (e.g. doing a rw). Inside the file it saves the various actual players, the unique maps and stop the server after sending an emergency message to all players. The server will then refuse to restart until enough space as been freed on media. Next time the server starts, it detects some things were saved in the emergency file, it restore the maps and the player (moving them to their bed before). Now the out of disk space problem has been resolved transparently and doesn't need any os specific function. For player, it was just a bug like another (except the server didn't restart immediatly after hang-up). And for the host, it doesn't need so much space. Mark Wedel wrote: On Mon, 14 May 2001, Peter Mardahl wrote: Why checking for success on write is not to hard to do (note an alternate method which may actually be better is to rename the original to a backup, and if the save files, rename back again. If it succeeds, you could either delete the backup, or keep it around in case somethign else trashes the player file). But a bigger question is what to do when the write does fail. Because at that point, there really isn't much crossfire can do. Presumably, it should probably just exit, or at minimum, warn all the people playing that writes are failing, and they are likely to lose anything they are doing. Granted, if the admin of the machine notices, they can fix the space issue, but the likelihood/ability for that to happen is certainly not guaranteed. The unique player maps are probably a little more dangerous in that regard than the player files, as once the server tries to write them out, they are lost from memory. At least the player data persists in server memory, so if the problem is later corrected, nothing is really lost. Note that if a player has a way to cause write failures, I can think of several exploits right away. This is probably not a likely situation - such a situation would presume that the server is a public machine (ie, work or university server for example), and chances are the admins would not likely kindly on people filling up disks to cheat at a game. > > This is an excellent suggesstion. > I have referred it to the crossfire development list. > > PeterM > > > Hi, > > > > I have just lost my apartments again, because of full filesystem (BTW it > > was filled by crashed crossfire). I have never lost the player the same > > way, but if player files are created the same way as unique-items file > > it can always happen. > > > > Maybe those files should be created more reliably. Eg. by writting > > file.new first, and only if it succeeds the file would be renamed to > > proper name. It can "save some lives". > > > > Greets, > > Jacek > > _______________________________________________ > > crossfire-list mailing list > > crossfire-list@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-list > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel David Delbecq David.delbecq@usa.net ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From yann.chachkoff at mailandnews.com Tue May 15 09:59:43 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:00:52 2005 Subject: [CF-Devel] Crossfire Scripting extensions patch, version 1.0.0b6 Message-ID: <01051510594300.01560@Terminus.magellan.fpms.ac.be> This is a patch that adds support for scripting language into crossfire 1.0.0. The scripting language used is Guile, a GNU-GPL implementation of Scheme. Requirements: - Crossfire-1.0.0 source distribution; - Guile version 1.4 or higher; It is yet not known if the scripting extensions may be compiled under Windows. If you try it and find bugs or other problems, please let me know. Sample maps are also provided. Please consult the README_SCRIPT file for more details on how to write your own scripts. If you like it, tell me. If you hate it, tell me also. Chachkoff Y. -------------- next part -------------- A non-text attachment was scrubbed... Name: scriptfire-1.0.0b6-maps.tar.bz2 Type: application/x-bzip2 Size: 15290 bytes Desc: Demo maps Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010515/7d06fdea/scriptfire-1.0.0b6-maps.tar.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-1.0.0.bz2 Type: application/x-bzip2 Size: 47908 bytes Desc: Scripting Support Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010515/7d06fdea/patch-1.0.0.bin From michael.toennies at nord-com.net Tue May 15 13:51:07 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:52 2005 Subject: [CF-Devel] New free tiles set!! Message-ID: I found a new free tile set from a guy called DeBray Bailey. Get it here: http://mids.student.utwente.nl/~michtoen/db-pcx1.zip Its a slighty other format, but some of the monster files are nice and he has included some animations!! bob, peter, try it out. Michael From yann.chachkoff at mailandnews.com Wed May 16 06:38:49 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:00:52 2005 Subject: [CF-Devel] Bug - Xpm and Png libraries detection Message-ID: <01051607384900.01585@Terminus.magellan.fpms.ac.be> Description: --------- The detection of the XPM and PNG libraries on some Linux Systems (This bug was discovered on Mandrake 8.0) by configure fails, resulting in a crossedit running with the old graphics only. Source of the problem: ---------------- The configure script tests the existence of various X11 libraries by trying to compile small test programs against them. For nearly all X11 libraries, the test compilation line is like this one: configure:2836: gcc -o conftest -g -O2 -lSM -lICE -L/usr/X11R6/lib conftest.c -lX11 -lnsl 1>&5 but for the Xpm and Png libraries, it is (at least on Mandrake): configure:3203: gcc -o conftest -g -O2 conftest.c -lpng -lX11 -lm -lnsl 1>&5 Having checked the configure.in used to initially generate configure, I found the difference: Correct checking: AC_CHECK_LIB(Xaw, main, AC_DEFINE(HAVE_LIBXAW) X11LIBS="-lXaw $X11LIBS", , $X11LIBS) Incorrect one: AC_CHECK_LIB(Xpm, main, AC_DEFINE(HAVE_LIBXPM) X11LIBS="$X11LIBS -lXpm", , -lX11 ) It appears that on some systems, -lX11 is not sufficient to compile the test program. Solution: ------- Correcting the two lines in configure.in to: AC_CHECK_LIB(Xpm, main, AC_DEFINE(HAVE_LIBXPM) X11LIBS="$X11LIBS -lXpm", , $X11LIBS ) AC_CHECK_LIB(png, main, AC_DEFINE(HAVE_LIBPNG) X11LIBS="$X11LIBS -lpng", , $X11LIBS ) and regenerating the configure script does solve the problem. Chachkoff Y. From yann.chachkoff at mailandnews.com Wed May 16 06:59:11 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:00:52 2005 Subject: [CF-Devel] Searching old cmb5 patch Message-ID: <01051607591101.01585@Terminus.magellan.fpms.ac.be> I am searching for an old patch made for crossfire-0.93.5 called cmb5. Does anyone still have it and can send it to me ? Chachkoff Y. From mwedel at scruz.net Wed May 16 01:55:21 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:52 2005 Subject: [CF-Devel] Future crossfire changes/projects Message-ID: <3B022459.8BF15CA1@scruz.net> Now that 1.0 is out, I'd like to get a little discussion/input on future changes for crossfire (say 2.0). I'm trying to keep these a bit more general in nature and not go into details of exactly how feasible different options are (as other changes may make some things easier or harder to do). This is also to make it aware to others possible projects they may want to take on. I'm also trying to limit to big and/or controversial projects. Doing something like adding a new spell isn't going to make this list. If you followup, it is probably worth while to start a thread for each of the proposed changes, so that conversation on each one is easier. Using the brief description in the Change line for subject is probably a good idea. General template I'm using: Proposed Change: Brief description of change Details: More detail on the change and other notes Pros & Cons: possible benefits So on to my list: Change: Increase viewable area of map Details: Currently, the viewable area of the map window is 11x11. this change suggests making this area 17x17 or some other number (best solution would be to have this a config option). Pros: Larger viewable area gives more glitz to the client. Most games have a much larger viewable area. Beyond the glitz factor, I think this may improve play/strategy. On a 11x11 map, the farthest a monster can be and still in site is basically 4 spaces (monster being on the 5th). If the size is 17x17, this now increases to 7 spaces, giving more oppurtunity to notice spells and other effects. Cons: Larger maps means more bandwidth to get updates. This may break/weaken some maps (ie, a map where you pull a lever and cannot currently see the result. OTOH, if youu have 2 players cooperating, they see that anyways). Things like the world maps wouldn't have enough padding spaces beyond the exits. Some maps may hide big treasures/monsters currently out of sight, but I'm not really sure the problem if that becomes visible. This change would require clients to get updated. Change: Improved client/server communication Details: This is intentionally broad - looking for input for things that should get improved. One thing that definately should get changed is text messages should have a content type instead of sending color type - this change would let the client choose the color and potentially other informatiion (font, what window to draw it to, etc.) Another case would be to improve ground object handling (for example, if on a very large pile, sending more objects each tick, so if you stand there, the entire stack might get sent). Pros: Should make the game more playable Cons: obsoletes old clients, don't want to do features that are a lot of work to do but give little gain. Change: Performance improvements Details: Currently, crossfire has some pretty severe performance issues when dealing with lots of spell objects. Very large maps can 'freeze' the server while loading. Likely to be other areas where performance is not very good. These should get fixed up. Pros: Improved performance is always a good thing. Cons: Some changes may be difficult to make or involve lots of code changes (and hence lots of potential bugs). Areas of improvement should really get identified so areas that don't have any real problem don't get worked on. Change: Improve NPC communication/scripting Details: Currently, it can be very difficult to hold a conversation with an npc because the communication is stateless and it isn't always to figure out the keywords. More advanced scripting would also allow for more complicated npc's (or remove the need of linking a bunch of objects to mimic some communication) Pros: improved communication is desirable Cons: May requiring redoing a lot of npcs. If an external scripting language is used, has the potential problem of reliability issues (external script could hang server by never returning) Change: New map editor Details: Currently, crossedit is basically unmaintained, and buggy. Ideally a replacement would be less buggy and more maintainable (if it was written in GTK, for example, at least its using the same toolkit as the client). However, something more portable so that windows and mac could use it would allow more people to design maps. Pros: More reliable editor Cons: May be a lot of work for not a great leap in reliability. If written in GTK, may lack portability to windows/mac (dunno if there is gtk port to those systems). If not written in gtk, it then lacks commonality with client, so its yet another toolkit that people need to learn (IMO, on reason currently client is largely unmaintained is no one really wants to learn Xt at this point in time) Change: Clean up object structure Details: Currently, values in the object structure has different meanings depending on the type of object - for example, sp has nothing to do with spellpoints when used with exits. This inconsistent use leads to problems (ie, sp regen speed bug when using permanent experience). Idea could be taken to several different levels: 1) Basic - just add enough unique elements to object struct so nothing gets re-used with these conflicting values. Str always means strength. This would result in higher memory usage 2) Go to object type/subtype setup. So equipment would be a major type, with its own substructure type, creatues another major type, exits/transporters another, etc - roughly a dozen major object types with subtypes. Within each major type, all the values mean the same thing. This is a lot of work, and I'm not sure the work is worth the gain. Related: Remove integer values from archetypes/maps and use string names. Instead of attacktype 5, it would be attacktype physical|electricity. This would likely reduce bugs in archetypes, and make them much easier to read. downside of this is a bit worse performance loading these things up. Pros: In the long run, may make things more stable as values don't get tromped over for other uses. If option #2 is taken, may make things more modular, and more extensible (adding a new equipment subtype easier - since most functions would deal with the main equipment type in the same fashion, supporting a new subtype may not require any more changes than just for the equip logic) Cons: Likely to introduce new bugs. Potential for more memory consumption & a lot of work (depending on which of these options is taken) Change: Have tiling of maps done automatically by server Details: Currently, tiling (ie, the world maps) is done by duplicating spaces from neighboring map and lining the map with invisible exits. This more or less works, but has some problems (things don't always line up quite right). One example I can think of is the wyvern question - if you come into that square from the south, your are on a different map and don't hit it. The idea here would be that there would be logic that says 'use map xyz for east, abc for north, and qwe for south'. As the player approaches the east edge of a map, the server would see that xyz is to the east, load it up, and display the spaces on that map as the player gets closer to the edge, and automatically handle when the player moves over. This also has an advantage in that you can synthesize layers. Imagine for example a tower with the balcony on the south side on say floors 2 and 3. With tiling, for levels 2 and 3, you could specify that south map is 'towerentry'. So as you stand on the balcony of either level 2 and 3, you would see this map. If someone walked up to the tower, both players on level 2 and 3 would see this player. but towerentry itself would say map north is tower1, so they would disappear into the first floor. If one of the players jumped off the balcony, they would once again be on this entry map, and as they went north, be on the first level again. Pros: Would make map designing of large maps easier. Could have some cool advantages Cons: Could be a bit of work for the benefits gained. Change: Increase outdoor map scale Details: Main issue is that the continent itself is quite small relative to other maps - in apparant scale, the continent is only 2-3 times larger than the city. There are 3 main points on how to do this (I'm going to include pros/cons with each one) 1) just take the world maps, and blow them up by 2,3,4 (or more) times. Do some cleanup so they aren't so blocky (as well as exits). Pro: Easy to do. Con: there is still a disparate scale 2) unified outdoor scale. In this mode, things like the city would actually be on the world maps (so you have the same scale inside and outside the city gates). Pros: Unifies 'outdoor' scale. Puts cities actually in the world map, so various spells or other abilities could let you bypass gates and so forth, giving the game more potential character. Cons: A bit more effort to do. May open things up to abuses. 3) Totally unified scale. This basically takes #2 above and extends it to everything. So shops are just 20x20 blocks actually located within the city, which is located with the world as a large. This would make everything much bigger (cities would have to be several hundred spaces across just to hold all the dungeons, shops, etc). Going accross country really would be a major journey. Pros: Basically takes what maps we have now and creates an apparantly huge world. May let players find maps they otherwise wouldn't (I know for a fact I don't try every house in the city, since 90% are closed, but if your taking a shortcut accross some area, you may notice some monsters in some house). Cons: A lot more work - this could probably be done more piecemeal. May make the scale too big (very hard to find some dungeons for example). Definately would want automatic tiling if this is done. Change: Allow transportation objects Details: Basically allow things like horses, dragons, boats, etc which speed up travel time or let you travel over types of terrain you normally could not go over. Pros: Adds some neat abilities Cons: Ability to travel over some types of spaces may open up abuses (ie, easy to get some quests, etc). Demand for this may not be really high? Change: Spell objects Details: remove spellist.h and spells.h file - instead have all that information contained in archetypes. Rely on archetype data for more information for spells (ie, size of explosion for the variosu fireballs would be by value in arch). A players known spells would be these spell archetypes in the players inventory. These archetypes would also be mutable, so someone could easily make a 'mega fireball' by taking a large fireball spell object, increase sp and size, and putting it in a spellbooks (spellbooks would basically be a book with a spell object within it - if player successfully learns it, this object goes from book to player object) Pros: Make spells much more extensible, and may actually reduce amount of code (as more data would come from archetypes and not values in the code itself) Cons: Likely to be some performance hit. Mapmakers could put out abusive spells (but no worse than right now with abusive objects I would guess) Phew. Longer than I thought it would be. From yann.chachkoff at mailandnews.com Wed May 16 08:57:03 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:00:52 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B022459.8BF15CA1@scruz.net> References: <3B022459.8BF15CA1@scruz.net> Message-ID: <01051609570303.01585@Terminus.magellan.fpms.ac.be> Le Mercredi 16 Mai 2001 02:55, vous avez ?crit : > Now that 1.0 is out, I'd like to get a little discussion/input on future > changes for crossfire (say 2.0). I'm trying to keep these a bit more > general in nature and not go into details of exactly how feasible different > options are (as other changes may make some things easier or harder to do). > This is also to make it aware to others possible projects they may want to > take on. I'm also trying to limit to big and/or controversial projects. > Doing something like adding a new spell isn't going to make this list. > > If you followup, it is probably worth while to start a thread for each of > the proposed changes, so that conversation on each one is easier. Using > the brief description in the Change line for subject is probably a good > idea. > > General template I'm using: > Proposed Change: Brief description of change > Details: More detail on the change and other notes > Pros & Cons: possible benefits > Some others ideas: Change: Isometric graphics ('Diablo-like' point of view). -Details: The current Crossfire graphics may be nice, there are still many players that simply find them 'outdated'. Isometric graphics may help Crossfire to be up-to-date with today's game standards. -Pros: May improve interest in the game, no longer seen as 'outdated'. No major changes in the server are needed. -Cons: The entire tileset would have to be redrawn. New client graphics handling needed to support isometric view. Change: Improved animations -Details: Currently, you don't _see_ anything when you hit a monster with your weapon or with karate/punching/etc. The idea is to create animations showing your character using his weapon. This system may also be implemented for some 'critical' monsters. -Pros: The game will definitely look better. It will be easier for other players to see if your own character is actually fighting or just waiting before a monster. Do not involve any changes on the Crossfire protocol/client. -Cons: May require extra CPU time to handle all those new animations. Change: New Map Features - Details: It is not always easy to create a map. If you want to add your own monsters or treasures for example, you may not always find a suitable picture in standard archetypes. The idea here is to allow new monsters/objects/etc. to be created and saved completely (including XPM/PNG) inside a map or even another object. Another map extension: the ability to take current time into account (for example to cast nightfall when time>22:00 and daylight when time>7:00). Why not even support for a weather system ? And a music support (a music tag containing the song to play) ? - Pros: New monsters/objects submissions would be much more easier since the only thing you need to get is the map. Standard atmosphere would be improved a lot with 'real' nightfall. - Cons: This may also mean a general increase of map sizes if lots of custom objects are created. May require extra CPU work to handle weather/night. Change: Improved Alchemy System - Details: The Alchemy is not often used in Crossfire. This may be because it is seen as somewhat too difficult for too limited effects. Why not extending its possibilities ? I think of a system allowing you to create objects that have the added abilities of ingredients used to make them (ex: Sword + Potion of Dex + Potion of Cha = Sword (Dex+1)(Cha+1)). - Pros: This may make Alchemy more interesting and fun to play. New fields of investigation for mages would be opened. - Cons: May disturb playbalance a lot. Change: Improved Combat System - Details: The current combat system is very simple: you run into a monster to hit. It may be interesting to improve this a bit by allowing special combat techniques and critical hits. Monsters could be immune/protected/vulnerable against some special combat techniques. In short, the idea is to create an equivalent of spells but in the field of fighting. - Pros: Make the warriors much more fun to play with. May allow more tactical play. - Cons: May become too complicated for many players to use. Chachkoff Y. From michael.toennies at nord-com.net Wed May 16 06:04:11 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:00:53 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B022459.8BF15CA1@scruz.net> Message-ID: You should know that there is one great chance for changing to isometric gfx. David Gervais, a prof. artist which has drawn for some full price games and which has served CF in the last month with some tiles of his free monsters/tiles set, has started a true isometric tile set. Look at this: http://dgrealm.50megs.com/iso-samples.html Well, if we can do it in this way, we can also talk about ONE skin design for linux and/or windows client. Of course, in style and tiles, there must be some small changes to fit it in CF, but the engine then should be useable for all newer items. The problems is, that DG is at the moment focused at on tile. Btw: for this style, monsters will look very VERY improved, when they can turn in 8 directions. This will give a great realistic look. Because only monsters must have this directions (map itself will not turn, forget the compass), it will be not so much work. The great thing is, that there is a great chance to inlcude DG in Crossfire! This thing is his baby, so i don't think he will skip the chance to include this gfx system in a great engine like CF. I had think about this isometric changing in the past, so i can tell you that is will be easy to change client/server to this. 90% work are the gfx, the whole gameplay/server will be the same. > Now that 1.0 is out, I'd like to get a little discussion/input on future > changes for crossfire (say 2.0). I'm trying to keep these a bit > more general in > nature and not go into details of exactly how feasible different > options are (as > other changes may make some things easier or harder to do). This > is also to > make it aware to others possible projects they may want to take > on. I'm also > trying to limit to big and/or controversial projects. Doing > something like > adding a new spell isn't going to make this list. > > If you followup, it is probably worth while to start a thread > for each of the > proposed changes, so that conversation on each one is easier. > Using the brief > description in the Change line for subject is probably a good idea. > > General template I'm using: > Proposed Change: Brief description of change > Details: More detail on the change and other notes > Pros & Cons: possible benefits > > So on to my list: > > Change: Increase viewable area of map > Details: Currently, the viewable area of the map window is 11x11. > this change > suggests making this area 17x17 or some other number (best > solution would be to > have this a config option). > Pros: Larger viewable area gives more glitz to the client. Most > games have a > much larger viewable area. Beyond the glitz factor, I think this > may improve > play/strategy. On a 11x11 map, the farthest a monster can be and > still in site > is basically 4 spaces (monster being on the 5th). If the size is > 17x17, this > now increases to 7 spaces, giving more oppurtunity to notice > spells and other > effects. > Cons: Larger maps means more bandwidth to get updates. This may > break/weaken > some maps (ie, a map where you pull a lever and cannot currently see the > result. OTOH, if youu have 2 players cooperating, they see that > anyways). > Things like the world maps wouldn't have enough padding spaces beyond the > exits. Some maps may hide big treasures/monsters currently out > of sight, but > I'm not really sure the problem if that becomes visible. This > change would > require clients to get updated. > > > Change: Improved client/server communication > Details: This is intentionally broad - looking for input for > things that should > get improved. One thing that definately should get changed is > text messages > should have a content type instead of sending color type - this > change would let > the client choose the color and potentially other informatiion (font, what > window to draw it to, etc.) > Another case would be to improve ground object handling (for > example, if on a > very large pile, sending more objects each tick, so if you stand > there, the > entire stack might get sent). > Pros: Should make the game more playable > Cons: obsoletes old clients, don't want to do features that are a > lot of work to > do but give little gain. > > Change: Performance improvements > Details: Currently, crossfire has some pretty severe performance > issues when > dealing with lots of spell objects. Very large maps can 'freeze' > the server > while loading. Likely to be other areas where performance is not > very good. > These should get fixed up. > Pros: Improved performance is always a good thing. > Cons: Some changes may be difficult to make or involve lots of > code changes (and > hence lots of potential bugs). Areas of improvement should really get > identified so areas that don't have any real problem don't get worked on. > > Change: Improve NPC communication/scripting > Details: Currently, it can be very difficult to hold a > conversation with an npc > because the communication is stateless and it isn't always to > figure out the > keywords. More advanced scripting would also allow for more > complicated npc's > (or remove the need of linking a bunch of objects to mimic some > communication) > Pros: improved communication is desirable > Cons: May requiring redoing a lot of npcs. If an external > scripting language is > used, has the potential problem of reliability issues (external > script could > hang server by never returning) > > Change: New map editor > Details: Currently, crossedit is basically unmaintained, and > buggy. Ideally a > replacement would be less buggy and more maintainable (if it was > written in GTK, > for example, at least its using the same toolkit as the client). However, > something more portable so that windows and mac could use it > would allow more > people to design maps. > Pros: More reliable editor > Cons: May be a lot of work for not a great leap in reliability. > If written in > GTK, may lack portability to windows/mac (dunno if there is gtk > port to those > systems). If not written in gtk, it then lacks commonality with > client, so its > yet another toolkit that people need to learn (IMO, on reason > currently client > is largely unmaintained is no one really wants to learn Xt at > this point in > time) > > Change: Clean up object structure > Details: Currently, values in the object structure has different meanings > depending on the type of object - for example, sp has nothing to do with > spellpoints when used with exits. This inconsistent use leads to > problems (ie, > sp regen speed bug when using permanent experience). Idea could > be taken to > several different levels: > 1) Basic - just add enough unique elements to object struct so > nothing gets > re-used with these conflicting values. Str always means > strength. This would > result in higher memory usage > 2) Go to object type/subtype setup. So equipment would be a > major type, with > its own substructure type, creatues another major type, exits/transporters > another, etc - roughly a dozen major object types with subtypes. > Within each > major type, all the values mean the same thing. This is a lot of > work, and I'm > not sure the work is worth the gain. > Related: Remove integer values from archetypes/maps and use string names. > Instead of attacktype 5, it would be attacktype > physical|electricity. This > would likely reduce bugs in archetypes, and make them much easier > to read. > downside of this is a bit worse performance loading these things up. > Pros: In the long run, may make things more stable as values > don't get tromped > over for other uses. If option #2 is taken, may make things more > modular, and > more extensible (adding a new equipment subtype easier - since > most functions > would deal with the main equipment type in the same fashion, > supporting a new > subtype may not require any more changes than just for the equip logic) > Cons: Likely to introduce new bugs. Potential for more memory > consumption & a > lot of work (depending on which of these options is taken) > > Change: Have tiling of maps done automatically by server > Details: Currently, tiling (ie, the world maps) is done by > duplicating spaces > from neighboring map and lining the map with invisible exits. > This more or less > works, but has some problems (things don't always line up quite > right). One > example I can think of is the wyvern question - if you come into > that square > from the south, your are on a different map and don't hit it. > The idea here > would be that there would be logic that says 'use map xyz for > east, abc for > north, and qwe for south'. As the player approaches the east > edge of a map, the > server would see that xyz is to the east, load it up, and display > the spaces on > that map as the player gets closer to the edge, and automatically > handle when > the player moves over. > This also has an advantage in that you can synthesize layers. > Imagine for > example a tower with the balcony on the south side on say floors > 2 and 3. With > tiling, for levels 2 and 3, you could specify that south map is > 'towerentry'. > So as you stand on the balcony of either level 2 and 3, you would > see this map. > If someone walked up to the tower, both players on level 2 and 3 > would see this > player. but towerentry itself would say map north is tower1, so > they would > disappear into the first floor. If one of the players jumped off > the balcony, > they would once again be on this entry map, and as they went > north, be on the > first level again. > Pros: Would make map designing of large maps easier. Could have some cool > advantages > Cons: Could be a bit of work for the benefits gained. > > Change: Increase outdoor map scale > Details: > Main issue is that the continent itself is quite small relative > to other maps - > in apparant scale, the continent is only 2-3 times larger than the city. > There are 3 main points on how to do this (I'm going to include > pros/cons with > each one) > 1) just take the world maps, and blow them up by 2,3,4 (or more) > times. Do some > cleanup so they aren't > so blocky (as well as exits). Pro: Easy to do. Con: there is > still a disparate > scale > 2) unified outdoor scale. In this mode, things like the city > would actually be > on the world maps (so you have the same scale inside and outside the city > gates). Pros: Unifies 'outdoor' scale. Puts cities actually in > the world map, > so various spells or other abilities could let you bypass gates > and so forth, > giving the game more potential character. Cons: A bit more > effort to do. May > open things up to abuses. > 3) Totally unified scale. This basically takes #2 above and extends it to > everything. So shops are just 20x20 blocks actually located > within the city, > which is located with the world as a large. This would make > everything much > bigger (cities would have to be several hundred spaces across > just to hold all > the dungeons, shops, etc). Going accross country really would be a major > journey. Pros: Basically takes what maps we have now and creates > an apparantly > huge world. May let players find maps they otherwise wouldn't (I > know for a > fact I don't try every house in the city, since 90% are closed, > but if your > taking a shortcut accross some area, you may notice some monsters in some > house). Cons: A lot more work - this could probably be done > more piecemeal. > May make the scale too big (very hard to find some dungeons for example). > Definately would want automatic tiling if this is done. > > Change: Allow transportation objects > Details: Basically allow things like horses, dragons, boats, etc > which speed up > travel time or let you travel over types of terrain you normally > could not go > over. > Pros: Adds some neat abilities > Cons: Ability to travel over some types of spaces may open up > abuses (ie, easy > to get some quests, etc). Demand for this may not be really high? > > Change: Spell objects > Details: remove spellist.h and spells.h file - instead have all > that information > contained in archetypes. Rely on archetype data for more > information for spells > (ie, size of explosion for the variosu fireballs would be by > value in arch). A > players known spells would be these spell archetypes in the > players inventory. > These archetypes would also be mutable, so someone could easily > make a 'mega > fireball' by taking a large fireball spell object, increase sp > and size, and > putting it in a spellbooks (spellbooks would basically be a book > with a spell > object within it - if player successfully learns it, this object > goes from book > to player object) > Pros: Make spells much more extensible, and may actually reduce > amount of code > (as more data would come from archetypes and not values in the > code itself) > Cons: Likely to be some performance hit. Mapmakers could put out > abusive spells > (but no worse than right now with abusive objects I would guess) > > Phew. Longer than I thought it would be. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From reeve at ductape.net Wed May 16 09:22:51 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:00:53 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B022459.8BF15CA1@scruz.net> References: <3B022459.8BF15CA1@scruz.net> Message-ID: <990022971.445.3.camel@terra> On 15 May 2001 23:55:21 -0700, Mark Wedel wrote: > > Now that 1.0 is out, I'd like to get a little discussion/input on future > changes for crossfire (say 2.0). I'm trying to keep these a bit more general in > nature and not go into details of exactly how feasible different options are (as > other changes may make some things easier or harder to do). This is also to > make it aware to others possible projects they may want to take on. I'm also > trying to limit to big and/or controversial projects. Doing something like > adding a new spell isn't going to make this list. > > If you followup, it is probably worth while to start a thread for each of the > proposed changes, so that conversation on each one is easier. Using the brief > description in the Change line for subject is probably a good idea. > > General template I'm using: > Proposed Change: Brief description of change > Details: More detail on the change and other notes > Pros & Cons: possible benefits I was just thinking about this yesterday. So here's my ideas: Proposed Change: Competition Maps Details: Add the ability to make NPCs remember things after map resets, so that maps like a "race to the finish" map or "battle to the death" map could be feasible. Also, just a novelty idea here, a map could be done that would be sortof a sumo wrestling tournament, players pay some coins to enter the tournment, try to push each other out of a circle, and the winner (the one that never got pushed out) gets all the coins the players paid. Just a thought :) Pros: Just think of the possiblities :) Cons: Might be difficult to do, players that are sore losers might get bitter and kill the winners ;) Proposed Change: "Smart" NPC's Details: Sortof the same thing. Make NPC's able to "remember" things about the players. Pros: It would make it possible for whole new plots to evolve around the players (ie, a player that steals and attacks townspeople, the townspeople would "remember" and could tell other players that they're bad, players could even become "villians" and "heros" of sorts :)) Cons: Would most likely be EXTREMELY difficult to implement. -- -- Reeve the cat ----BEGIN FORTUNE---- Allen's Axiom: When all else fails, read the instructions. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From reeve at ductape.net Wed May 16 09:22:20 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:00:53 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B022459.8BF15CA1@scruz.net> References: <3B022459.8BF15CA1@scruz.net> Message-ID: <990022940.453.2.camel@terra> On 15 May 2001 23:55:21 -0700, Mark Wedel wrote: > > Now that 1.0 is out, I'd like to get a little discussion/input on future > changes for crossfire (say 2.0). I'm trying to keep these a bit more general in > nature and not go into details of exactly how feasible different options are (as > other changes may make some things easier or harder to do). This is also to > make it aware to others possible projects they may want to take on. I'm also > trying to limit to big and/or controversial projects. Doing something like > adding a new spell isn't going to make this list. > > If you followup, it is probably worth while to start a thread for each of the > proposed changes, so that conversation on each one is easier. Using the brief > description in the Change line for subject is probably a good idea. > > General template I'm using: > Proposed Change: Brief description of change > Details: More detail on the change and other notes > Pros & Cons: possible benefits I was just thinking about this yesterday. So here's my ideas: Proposed Change: Competition Maps Details: Add the ability to make NPCs remember things after map resets, so that maps like a "race to the finish" map or "battle to the death" map could be feasible. Also, just a novelty idea here, a map could be done that would be sortof a sumo wrestling tournament, players pay some coins to enter the tournment, try to push each other out of a circle, and the winner (the one that never got pushed out) gets all the coins the players paid. Just a thought :) Pros: Just think of the possiblities :) Cons: Might be difficult to do, players that are sore losers might get bitter and kill the winners ;) Proposed Change: "Smart" NPC's Details: Sortof the same thing. Make NPC's able to "remember" things about the players. Pros: It would make it possible for whole new plots to evolve around the players (ie, a player that steals and attacks townspeople, the townspeople would "remember" and could tell other players that they're bad, players could even become "villians" and "heros" of sorts :)) Cons: Would most likely be EXTREMELY difficult to implement. -- -- Reeve the cat ----BEGIN FORTUNE---- Allen's Axiom: When all else fails, read the instructions. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From reeve at ductape.net Wed May 16 09:23:37 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:00:53 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B022459.8BF15CA1@scruz.net> References: <3B022459.8BF15CA1@scruz.net> Message-ID: <990023017.453.4.camel@terra> On 15 May 2001 23:55:21 -0700, Mark Wedel wrote: > > Now that 1.0 is out, I'd like to get a little discussion/input on future > changes for crossfire (say 2.0). I'm trying to keep these a bit more general in > nature and not go into details of exactly how feasible different options are (as > other changes may make some things easier or harder to do). This is also to > make it aware to others possible projects they may want to take on. I'm also > trying to limit to big and/or controversial projects. Doing something like > adding a new spell isn't going to make this list. > > If you followup, it is probably worth while to start a thread for each of the > proposed changes, so that conversation on each one is easier. Using the brief > description in the Change line for subject is probably a good idea. > > General template I'm using: > Proposed Change: Brief description of change > Details: More detail on the change and other notes > Pros & Cons: possible benefits I was just thinking about this yesterday. So here's my ideas: Proposed Change: Competition Maps Details: Add the ability to make NPCs remember things after map resets, so that maps like a "race to the finish" map or "battle to the death" map could be feasible. Also, just a novelty idea here, a map could be done that would be sortof a sumo wrestling tournament, players pay some coins to enter the tournment, try to push each other out of a circle, and the winner (the one that never got pushed out) gets all the coins the players paid. Just a thought :) Pros: Just think of the possiblities :) Cons: Might be difficult to do, players that are sore losers might get bitter and kill the winners ;) Proposed Change: "Smart" NPC's Details: Sortof the same thing. Make NPC's able to "remember" things about the players. Pros: It would make it possible for whole new plots to evolve around the players (ie, a player that steals and attacks townspeople, the townspeople would "remember" and could tell other players that they're bad, players could even become "villians" and "heros" of sorts :)) Cons: Would most likely be EXTREMELY difficult to implement. -- -- Reeve the cat ----BEGIN FORTUNE---- Allen's Axiom: When all else fails, read the instructions. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From reeve at ductape.net Wed May 16 09:23:43 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:00:53 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B022459.8BF15CA1@scruz.net> References: <3B022459.8BF15CA1@scruz.net> Message-ID: <990023024.445.5.camel@terra> On 15 May 2001 23:55:21 -0700, Mark Wedel wrote: > > Now that 1.0 is out, I'd like to get a little discussion/input on future > changes for crossfire (say 2.0). I'm trying to keep these a bit more general in > nature and not go into details of exactly how feasible different options are (as > other changes may make some things easier or harder to do). This is also to > make it aware to others possible projects they may want to take on. I'm also > trying to limit to big and/or controversial projects. Doing something like > adding a new spell isn't going to make this list. > > If you followup, it is probably worth while to start a thread for each of the > proposed changes, so that conversation on each one is easier. Using the brief > description in the Change line for subject is probably a good idea. > > General template I'm using: > Proposed Change: Brief description of change > Details: More detail on the change and other notes > Pros & Cons: possible benefits I was just thinking about this yesterday. So here's my ideas: Proposed Change: Competition Maps Details: Add the ability to make NPCs remember things after map resets, so that maps like a "race to the finish" map or "battle to the death" map could be feasible. Also, just a novelty idea here, a map could be done that would be sortof a sumo wrestling tournament, players pay some coins to enter the tournment, try to push each other out of a circle, and the winner (the one that never got pushed out) gets all the coins the players paid. Just a thought :) Pros: Just think of the possiblities :) Cons: Might be difficult to do, players that are sore losers might get bitter and kill the winners ;) Proposed Change: "Smart" NPC's Details: Sortof the same thing. Make NPC's able to "remember" things about the players. Pros: It would make it possible for whole new plots to evolve around the players (ie, a player that steals and attacks townspeople, the townspeople would "remember" and could tell other players that they're bad, players could even become "villians" and "heros" of sorts :)) Cons: Would most likely be EXTREMELY difficult to implement. -- -- Reeve the cat ----BEGIN FORTUNE---- Allen's Axiom: When all else fails, read the instructions. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From reeve at ductape.net Wed May 16 09:24:11 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:00:53 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B022459.8BF15CA1@scruz.net> References: <3B022459.8BF15CA1@scruz.net> Message-ID: <990023051.454.6.camel@terra> On 15 May 2001 23:55:21 -0700, Mark Wedel wrote: > > Now that 1.0 is out, I'd like to get a little discussion/input on future > changes for crossfire (say 2.0). I'm trying to keep these a bit more general in > nature and not go into details of exactly how feasible different options are (as > other changes may make some things easier or harder to do). This is also to > make it aware to others possible projects they may want to take on. I'm also > trying to limit to big and/or controversial projects. Doing something like > adding a new spell isn't going to make this list. > > If you followup, it is probably worth while to start a thread for each of the > proposed changes, so that conversation on each one is easier. Using the brief > description in the Change line for subject is probably a good idea. > > General template I'm using: > Proposed Change: Brief description of change > Details: More detail on the change and other notes > Pros & Cons: possible benefits I was just thinking about this yesterday. So here's my ideas: Proposed Change: Competition Maps Details: Add the ability to make NPCs remember things after map resets, so that maps like a "race to the finish" map or "battle to the death" map could be feasible. Also, just a novelty idea here, a map could be done that would be sortof a sumo wrestling tournament, players pay some coins to enter the tournment, try to push each other out of a circle, and the winner (the one that never got pushed out) gets all the coins the players paid. Just a thought :) Pros: Just think of the possiblities :) Cons: Might be difficult to do, players that are sore losers might get bitter and kill the winners ;) Proposed Change: "Smart" NPC's Details: Sortof the same thing. Make NPC's able to "remember" things about the players. Pros: It would make it possible for whole new plots to evolve around the players (ie, a player that steals and attacks townspeople, the townspeople would "remember" and could tell other players that they're bad, players could even become "villians" and "heros" of sorts :)) Cons: Would most likely be EXTREMELY difficult to implement. -- -- Reeve the cat ----BEGIN FORTUNE---- Allen's Axiom: When all else fails, read the instructions. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From reeve at ductape.net Wed May 16 09:24:24 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:00:53 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B022459.8BF15CA1@scruz.net> References: <3B022459.8BF15CA1@scruz.net> Message-ID: <990023065.453.7.camel@terra> On 15 May 2001 23:55:21 -0700, Mark Wedel wrote: > > Now that 1.0 is out, I'd like to get a little discussion/input on future > changes for crossfire (say 2.0). I'm trying to keep these a bit more general in > nature and not go into details of exactly how feasible different options are (as > other changes may make some things easier or harder to do). This is also to > make it aware to others possible projects they may want to take on. I'm also > trying to limit to big and/or controversial projects. Doing something like > adding a new spell isn't going to make this list. > > If you followup, it is probably worth while to start a thread for each of the > proposed changes, so that conversation on each one is easier. Using the brief > description in the Change line for subject is probably a good idea. > > General template I'm using: > Proposed Change: Brief description of change > Details: More detail on the change and other notes > Pros & Cons: possible benefits I was just thinking about this yesterday. So here's my ideas: Proposed Change: Competition Maps Details: Add the ability to make NPCs remember things after map resets, so that maps like a "race to the finish" map or "battle to the death" map could be feasible. Also, just a novelty idea here, a map could be done that would be sortof a sumo wrestling tournament, players pay some coins to enter the tournment, try to push each other out of a circle, and the winner (the one that never got pushed out) gets all the coins the players paid. Just a thought :) Pros: Just think of the possiblities :) Cons: Might be difficult to do, players that are sore losers might get bitter and kill the winners ;) Proposed Change: "Smart" NPC's Details: Sortof the same thing. Make NPC's able to "remember" things about the players. Pros: It would make it possible for whole new plots to evolve around the players (ie, a player that steals and attacks townspeople, the townspeople would "remember" and could tell other players that they're bad, players could even become "villians" and "heros" of sorts :)) Cons: Would most likely be EXTREMELY difficult to implement. -- -- Reeve the cat ----BEGIN FORTUNE---- Allen's Axiom: When all else fails, read the instructions. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From reeve at ductape.net Wed May 16 09:26:42 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:00:53 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <990023024.445.5.camel@terra> References: <3B022459.8BF15CA1@scruz.net> <990023024.445.5.camel@terra> Message-ID: <990023202.445.9.camel@terra> Ack, sorry about that, my mailer screwed up and sent it a bunch of times :( -- -- Reeve the cat ----BEGIN FORTUNE---- Batteries not included. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From hsteoh at quickfur.yi.org Wed May 16 11:22:37 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:53 2005 Subject: Transportation objects (Was: Re: [CF-Devel] Future crossfire changes/projects) In-Reply-To: <3B022459.8BF15CA1@scruz.net>; from mwedel@scruz.net on Tue, May 15, 2001 at 11:55:21PM -0700 References: <3B022459.8BF15CA1@scruz.net> Message-ID: <20010516122237.A5297@crystal> On Tue, May 15, 2001 at 11:55:21PM -0700, Mark Wedel wrote: [snip] > Change: Allow transportation objects > Details: Basically allow things like horses, dragons, boats, etc which speed up > travel time or let you travel over types of terrain you normally could not go > over. I, for one, would LOVE to see transportation objects in the game. Horses, caravans, etc., would all add a lot of flavor to the game. > Pros: Adds some neat abilities > Cons: Ability to travel over some types of spaces may open up abuses (ie, easy > to get some quests, etc). Demand for this may not be really high? [snip] I don't see *that* much a problem with abuses. For example, if we allowed boats to cross water, the player might be able to reach places impossible to reach before; however, if we wanted to *prevent* that, we can simply add rough waters or deep waters that the player cannot cross safely (or cannot cross at all). Ditto with flying objects, such as riding dragons, we can have very high mountains with strong winds that prevent the player from crossing them. Or we can simply prohibit players from carrying transportation objects, so only lakes that already have boats can be crossed; the player can't just drag a boat from elsewhere and cross where he's not intended to. T -- Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen From Philipp.Currlin at t-online.de Wed May 16 12:24:31 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:53 2005 Subject: Transportation objects (Was: Re: [CF-Devel] Future crossfire changes/projects) In-Reply-To: <20010516122237.A5297@crystal> References: <3B022459.8BF15CA1@scruz.net> <20010516122237.A5297@crystal> Message-ID: <01051619243102.00457@truth> > I don't see *that* much a problem with abuses. For example, if we allowed > boats to cross water, the player might be able to reach places impossible > to reach before; however, if we wanted to *prevent* that, we can simply > add rough waters or deep waters that the player cannot cross safely (or > cannot cross at all). Ditto with flying objects, such as riding dragons, > we can have very high mountains with strong winds that prevent the player > from crossing them. I could think of adding either a completely new floor-tile here, or modifying the existing ones to something like: allow_horses 1 allow_dragons 1 or similar on water: allow_boat 1 Then it would be up to the mapmaker if transports were allowed. And we wouldn't have to modify the maps. Then players could "carry" their transports around but wouldn't be able to use them unless that was allowed on the particular map/tile. Especially on a new world map with much larger dimensions I think transports would be really nice. Phil From tanner at real-time.com Wed May 16 13:07:25 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:53 2005 Subject: [CF-Devel] New Mailing List Message-ID: <20010516130725.H4770@real-time.com> With the release of 1.0, I expect public CF servers to start to pop-up "all" over the place. Talking on irc philc said a list where all the admins of the public CF servers would be subscribed would be helpful in disseminating info amongst the admins and the user base. I agree and the below mailing list is the result. https://mailman.real-time.com/mailman/listinfo/crossfire-admin If you are an admin (wannabe admin :-) please subscribe to the above list. I see this list as being a place where admins can discuss issues on RUNNING a crossfire server. I still think crossfire-list would be where general discussion happens, where user comments/dicussion happens, etc.. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From helfesrieder at netscape.net Wed May 16 13:50:48 2001 From: helfesrieder at netscape.net (helfesrieder@netscape.net) Date: Thu Jan 13 18:00:53 2005 Subject: [CF-Devel] Future crossfire changes/projects Message-ID: <6B4DB922.198BC964.79055386@netscape.net> Hi, I am Bjoern, aka Zack42. I am the creator of Yarid's house in Scorn, which some of you might know. The following are my thoughts on the future directions of CF after V1.0. My thoughts are of rather general nature and need to be broken down to specific changes. However, I think the highlight the directions and the areas of work well. Here we go.... To decide about the future directions of CF, there needs to be a consensus about the overall goal. To my understanding, the overall goal is to significantly enlarge the player base of CF. In other words, to attract, to pull, many more new players on the CF platform. Second, to attract many new players, one needs to know what most, if not almost all, players want. Well, new players don't come because technology is nice. They don't come because the source code is open. They dont come because a new level 80 spell xyz has been implemented etc...you know what I mean... All players play to have fun and a good and exciting gaming experience. If you meet this demand, they will come. Otherwise they will not come. So, what is needed to meet these demands and expectations ? In my opinion, CF needs improvement in 3 top-level areas: * Improve Presentation ** generally : support richer media types ** better sounds ** better graphics ** ambient sounds ** soundtracks (** video clips / cut scenes / stills? -> who would be able to produce them ?) * Improve Content ** CF background setting / story ** Consistent World design (world map) ** high quality Stories, Quests, "Epic Quests" (compare Everquest) ** New Player experience * Improve Game Mechanics / Logic ** Monster & NPC AI That is what I think needs to be adressed to significantly grow the player base of CF... What do you think ? Regards, Bjoern (aka Zack) __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From sniper at citilink.com Wed May 16 14:24:35 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:53 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B022459.8BF15CA1@scruz.net> Message-ID: I think the two biggest areas of needed development right now are: 1) performance issues, and 2) making the world a LOT bigger When I think of many massively multiplayer RPG's (ultima online, everquest etc.) they have these HUGE areas you can travel through. Take everquest for example. It would take you probably five or more hours of straight walking just to get from one side of a continent to another (and eq has multiple continents too). As well, it'd be impossible for a weaker character to travel by him/herself, because of the monsters that would be encountered on the way As it is right now in crossfire, it takes about one minute to travel the main continent from border to border, and there are no risks involved, as there are no monsters on the world map. The only real purpose to improving performance in crossfire is so that we'll be able to have more than 4-5 people on a server at once without getting serious lag. In everquest, there are between 1500 and 2000 people on a server at once. I think our goal at first should be to get 100 people on a single crossfire server with lag that doesn't make the game unplayable However, improving the performance is absolutely pointless without improving the size of the world. The dungeons in crossfire are not that large, the world is small, and the number of "popular" (good dungeons to level up in) are very few. So, let's say we improve performance and a server can handle 100 people without crippling lag. That doesn't mean anything if the world can't handle that many people without taking all the fun away from the game So, my vote is to make the entire game on a 1:1 scale, including shops, dungeons, towns, and the world map. This task should be worked on in parallel with performance improvements to the client/server architecture to allow more players on a server. This way it would be much more like everquest, where the world is vast and can't be traveled in mere seconds. Then, all of the performance gains in the client/server architecture won't be without purpose. -Sniper sniper@citilink.com From sniper at citilink.com Wed May 16 15:04:02 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: Message-ID: just for some input: wow! I really like this, and could see it fitting into crossfire perfectly. not only is the quality good, but the art captures the "fantasy" feeling perfect- they may not be 3d, but any RPG fan looking at them would be like, "hmmm, nice graphics" -Sniper sniper@citilink.com On Wed, 16 May 2001, Michael Toennies wrote: > You should know that there is one great chance for > changing to isometric gfx. > > David Gervais, a prof. artist which has drawn for some full price games > and which has served CF in the last month with some tiles of his free > monsters/tiles > set, has started a true isometric tile set. > > Look at this: http://dgrealm.50megs.com/iso-samples.html > > Well, if we can do it in this way, we can also talk about ONE skin design > for linux and/or windows client. > > Of course, in style and tiles, there must be some small changes to fit it in > CF, > but the engine then should be useable for all newer items. > > The problems is, that DG is at the moment focused at on tile. > > Btw: for this style, monsters will look very VERY improved, when they can > turn in 8 directions. > This will give a great realistic look. Because only monsters must have this > directions (map > itself will not turn, forget the compass), it will be not so much work. > > The great thing is, that there is a great chance to inlcude DG in Crossfire! > This thing is his baby, so i don't think he will skip the chance to include > this > gfx system in a great engine like CF. > > I had think about this isometric changing in the past, so i can tell you > that is will be easy > to change client/server to this. 90% work are the gfx, the whole > gameplay/server will be the same. > > > > Now that 1.0 is out, I'd like to get a little discussion/input on future > > changes for crossfire (say 2.0). I'm trying to keep these a bit > > more general in > > nature and not go into details of exactly how feasible different > > options are (as > > other changes may make some things easier or harder to do). This > > is also to > > make it aware to others possible projects they may want to take > > on. I'm also > > trying to limit to big and/or controversial projects. Doing > > something like > > adding a new spell isn't going to make this list. > > > > If you followup, it is probably worth while to start a thread > > for each of the > > proposed changes, so that conversation on each one is easier. > > Using the brief > > description in the Change line for subject is probably a good idea. > > > > General template I'm using: > > Proposed Change: Brief description of change > > Details: More detail on the change and other notes > > Pros & Cons: possible benefits > > > > So on to my list: > > > > Change: Increase viewable area of map > > Details: Currently, the viewable area of the map window is 11x11. > > this change > > suggests making this area 17x17 or some other number (best > > solution would be to > > have this a config option). > > Pros: Larger viewable area gives more glitz to the client. Most > > games have a > > much larger viewable area. Beyond the glitz factor, I think this > > may improve > > play/strategy. On a 11x11 map, the farthest a monster can be and > > still in site > > is basically 4 spaces (monster being on the 5th). If the size is > > 17x17, this > > now increases to 7 spaces, giving more oppurtunity to notice > > spells and other > > effects. > > Cons: Larger maps means more bandwidth to get updates. This may > > break/weaken > > some maps (ie, a map where you pull a lever and cannot currently see the > > result. OTOH, if youu have 2 players cooperating, they see that > > anyways). > > Things like the world maps wouldn't have enough padding spaces beyond the > > exits. Some maps may hide big treasures/monsters currently out > > of sight, but > > I'm not really sure the problem if that becomes visible. This > > change would > > require clients to get updated. > > > > > > Change: Improved client/server communication > > Details: This is intentionally broad - looking for input for > > things that should > > get improved. One thing that definately should get changed is > > text messages > > should have a content type instead of sending color type - this > > change would let > > the client choose the color and potentially other informatiion (font, what > > window to draw it to, etc.) > > Another case would be to improve ground object handling (for > > example, if on a > > very large pile, sending more objects each tick, so if you stand > > there, the > > entire stack might get sent). > > Pros: Should make the game more playable > > Cons: obsoletes old clients, don't want to do features that are a > > lot of work to > > do but give little gain. > > > > Change: Performance improvements > > Details: Currently, crossfire has some pretty severe performance > > issues when > > dealing with lots of spell objects. Very large maps can 'freeze' > > the server > > while loading. Likely to be other areas where performance is not > > very good. > > These should get fixed up. > > Pros: Improved performance is always a good thing. > > Cons: Some changes may be difficult to make or involve lots of > > code changes (and > > hence lots of potential bugs). Areas of improvement should really get > > identified so areas that don't have any real problem don't get worked on. > > > > Change: Improve NPC communication/scripting > > Details: Currently, it can be very difficult to hold a > > conversation with an npc > > because the communication is stateless and it isn't always to > > figure out the > > keywords. More advanced scripting would also allow for more > > complicated npc's > > (or remove the need of linking a bunch of objects to mimic some > > communication) > > Pros: improved communication is desirable > > Cons: May requiring redoing a lot of npcs. If an external > > scripting language is > > used, has the potential problem of reliability issues (external > > script could > > hang server by never returning) > > > > Change: New map editor > > Details: Currently, crossedit is basically unmaintained, and > > buggy. Ideally a > > replacement would be less buggy and more maintainable (if it was > > written in GTK, > > for example, at least its using the same toolkit as the client). However, > > something more portable so that windows and mac could use it > > would allow more > > people to design maps. > > Pros: More reliable editor > > Cons: May be a lot of work for not a great leap in reliability. > > If written in > > GTK, may lack portability to windows/mac (dunno if there is gtk > > port to those > > systems). If not written in gtk, it then lacks commonality with > > client, so its > > yet another toolkit that people need to learn (IMO, on reason > > currently client > > is largely unmaintained is no one really wants to learn Xt at > > this point in > > time) > > > > Change: Clean up object structure > > Details: Currently, values in the object structure has different meanings > > depending on the type of object - for example, sp has nothing to do with > > spellpoints when used with exits. This inconsistent use leads to > > problems (ie, > > sp regen speed bug when using permanent experience). Idea could > > be taken to > > several different levels: > > 1) Basic - just add enough unique elements to object struct so > > nothing gets > > re-used with these conflicting values. Str always means > > strength. This would > > result in higher memory usage > > 2) Go to object type/subtype setup. So equipment would be a > > major type, with > > its own substructure type, creatues another major type, exits/transporters > > another, etc - roughly a dozen major object types with subtypes. > > Within each > > major type, all the values mean the same thing. This is a lot of > > work, and I'm > > not sure the work is worth the gain. > > Related: Remove integer values from archetypes/maps and use string names. > > Instead of attacktype 5, it would be attacktype > > physical|electricity. This > > would likely reduce bugs in archetypes, and make them much easier > > to read. > > downside of this is a bit worse performance loading these things up. > > Pros: In the long run, may make things more stable as values > > don't get tromped > > over for other uses. If option #2 is taken, may make things more > > modular, and > > more extensible (adding a new equipment subtype easier - since > > most functions > > would deal with the main equipment type in the same fashion, > > supporting a new > > subtype may not require any more changes than just for the equip logic) > > Cons: Likely to introduce new bugs. Potential for more memory > > consumption & a > > lot of work (depending on which of these options is taken) > > > > Change: Have tiling of maps done automatically by server > > Details: Currently, tiling (ie, the world maps) is done by > > duplicating spaces > > from neighboring map and lining the map with invisible exits. > > This more or less > > works, but has some problems (things don't always line up quite > > right). One > > example I can think of is the wyvern question - if you come into > > that square > > from the south, your are on a different map and don't hit it. > > The idea here > > would be that there would be logic that says 'use map xyz for > > east, abc for > > north, and qwe for south'. As the player approaches the east > > edge of a map, the > > server would see that xyz is to the east, load it up, and display > > the spaces on > > that map as the player gets closer to the edge, and automatically > > handle when > > the player moves over. > > This also has an advantage in that you can synthesize layers. > > Imagine for > > example a tower with the balcony on the south side on say floors > > 2 and 3. With > > tiling, for levels 2 and 3, you could specify that south map is > > 'towerentry'. > > So as you stand on the balcony of either level 2 and 3, you would > > see this map. > > If someone walked up to the tower, both players on level 2 and 3 > > would see this > > player. but towerentry itself would say map north is tower1, so > > they would > > disappear into the first floor. If one of the players jumped off > > the balcony, > > they would once again be on this entry map, and as they went > > north, be on the > > first level again. > > Pros: Would make map designing of large maps easier. Could have some cool > > advantages > > Cons: Could be a bit of work for the benefits gained. > > > > Change: Increase outdoor map scale > > Details: > > Main issue is that the continent itself is quite small relative > > to other maps - > > in apparant scale, the continent is only 2-3 times larger than the city. > > There are 3 main points on how to do this (I'm going to include > > pros/cons with > > each one) > > 1) just take the world maps, and blow them up by 2,3,4 (or more) > > times. Do some > > cleanup so they aren't > > so blocky (as well as exits). Pro: Easy to do. Con: there is > > still a disparate > > scale > > 2) unified outdoor scale. In this mode, things like the city > > would actually be > > on the world maps (so you have the same scale inside and outside the city > > gates). Pros: Unifies 'outdoor' scale. Puts cities actually in > > the world map, > > so various spells or other abilities could let you bypass gates > > and so forth, > > giving the game more potential character. Cons: A bit more > > effort to do. May > > open things up to abuses. > > 3) Totally unified scale. This basically takes #2 above and extends it to > > everything. So shops are just 20x20 blocks actually located > > within the city, > > which is located with the world as a large. This would make > > everything much > > bigger (cities would have to be several hundred spaces across > > just to hold all > > the dungeons, shops, etc). Going accross country really would be a major > > journey. Pros: Basically takes what maps we have now and creates > > an apparantly > > huge world. May let players find maps they otherwise wouldn't (I > > know for a > > fact I don't try every house in the city, since 90% are closed, > > but if your > > taking a shortcut accross some area, you may notice some monsters in some > > house). Cons: A lot more work - this could probably be done > > more piecemeal. > > May make the scale too big (very hard to find some dungeons for example). > > Definately would want automatic tiling if this is done. > > > > Change: Allow transportation objects > > Details: Basically allow things like horses, dragons, boats, etc > > which speed up > > travel time or let you travel over types of terrain you normally > > could not go > > over. > > Pros: Adds some neat abilities > > Cons: Ability to travel over some types of spaces may open up > > abuses (ie, easy > > to get some quests, etc). Demand for this may not be really high? > > > > Change: Spell objects > > Details: remove spellist.h and spells.h file - instead have all > > that information > > contained in archetypes. Rely on archetype data for more > > information for spells > > (ie, size of explosion for the variosu fireballs would be by > > value in arch). A > > players known spells would be these spell archetypes in the > > players inventory. > > These archetypes would also be mutable, so someone could easily > > make a 'mega > > fireball' by taking a large fireball spell object, increase sp > > and size, and > > putting it in a spellbooks (spellbooks would basically be a book > > with a spell > > object within it - if player successfully learns it, this object > > goes from book > > to player object) > > Pros: Make spells much more extensible, and may actually reduce > > amount of code > > (as more data would come from archetypes and not values in the > > code itself) > > Cons: Likely to be some performance hit. Mapmakers could put out > > abusive spells > > (but no worse than right now with abusive objects I would guess) > > > > Phew. Longer than I thought it would be. > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From jbontje at suespammers.org Wed May 16 16:35:46 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Crossfire standard text DRAFT Message-ID: <20010516233546.A9497@mids.student.utwente.nl> Hello, I think its important do define a standard text that explains what crossfire is and where to get more information / download it. This could be used to post in newsgroups, put on RPG, AD&D and game sites. Mail it to your friends, spread the word! --- cut --- Crossfire 1.0.0 Crossfire is graphical multi-user 2D tile-based RPG (role playing game) similar to Moria, Angband, Omega, Nethack, Rogue, Gauntlet, and Muds. The bulk of the game is based on predefined maps, however some areas are randomly generated. There are clients for X11 (source, RPM, deb) and Windows (DirectX). This is the first public release/release for wide spread distribution. Offical website: http://crossfire.real-time.com/ Sourcforge page: http://www.sourceforge.net/projects/crossfire/ IRC Channel : #crossfire on irc.openprojects.net --- cut --- This is just a start, please add, change & delete and post the result. Joris Bontje / MiDS From yann.chachkoff at MailAndNews.com Wed May 16 17:07:29 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Future crossfire changes/projects Message-ID: <3B03ADF0@MailAndNews.com> >I am Bjoern, aka Zack42. I am the creator of Yarid's house in >Scorn, which some of you might know. > You asked what we think about your ideas on Crossfire, so here is my answer. >To decide about the future directions of CF, there needs to be a >consensus about the overall goal. > >To my understanding, the overall goal is to significantly enlarge >the player base of CF. In other words, to attract, to pull, many >more new players on the CF platform. > >Second, to attract many new players, one needs to know what most, if >not almost all, players want. > How refreshing it is to see that there are still people interested in players demands ! >Well, new players don't come because technology is nice. They don't >come because the source code is open. They dont come because a new >level 80 spell xyz has been implemented etc...you know what I >mean... > >All players play to have fun and a good and exciting gaming >experience. If you meet this demand, they will come. Otherwise >they will not come. > Definitely agree. You made me notice one strange thing: the discussion about what Crossfire should/should not become takes place on the developer's list, not on the general crossfire list. Many players only subscribe to the general mailing list, and they may have good ideas to share. Why don't we continue the debate on the general list then ? >So, what is needed to meet these demands and expectations ? > >In my opinion, CF needs improvement in 3 top-level areas: > >* Improve Presentation > ** generally : support richer media types > ** better sounds > ** better graphics > ** ambient sounds > ** soundtracks > (** video clips / cut scenes / stills? -> who would be able > to produce them ?) Maybe creating a new mailing list about the 'multimedia' part of Crossfire would be a good idea... It is indeed true that _many_ potential players found the Crossfire graphics 'out-of-date', sounds 'crappy', moves 'ugly' (only square-by-square move ? Even in Zelda I, that was made better !). The potential of the game is huge, but many people don't like it just because it looks so ugly and outdated. Serious multimedia development is now needed if we want to see more players. > >* Improve Content > ** CF background setting / story > ** Consistent World design (world map) > ** high quality Stories, Quests, "Epic Quests" (compare Everquest) > ** New Player experience > >* Improve Game Mechanics / Logic > ** Monster & NPC AI > I tend to bind those two points for now... Making high-quality stories and quests is currently a very difficult task because of lack of advanced 'scenaristic' capabilities in Crossfire (I mean: nearly inexistent NPC AI, poor dynamic map support, etc.). The maps are now often too 'static' and door-monster-treasure-designed. Some attempts do exist (The quest of Lord Eureca for example), but the infrastructure of crossfire is too limited to build really complex quests. I think the scenario is much more important than the source code, but we can't write good stories without some basic tools to support them. Maybe the crossfire map designers should try to make a list of what they want to be possible in the game so the developers would have an idea on what to do. > >That is what I think needs to be adressed to significantly grow the >player base of CF... > >What do you think ? That's what I think too. But it needs lots of work and also a major change of the main crossfire development path (switching from a 'coders->designers->players' model to a 'players->designers->coders' model), and that may be the most difficult part of the run. Chachkoff Y. ------------------------------------------------------------ Get your FREE web-based e-mail and newsgroup access at: http://MailAndNews.com Create a new mailbox, or access your existing IMAP4 or POP3 mailbox from anywhere with just a web browser. ------------------------------------------------------------ From mwedel at scruznet.com Wed May 16 18:17:45 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <6B4DB922.198BC964.79055386@netscape.net> Message-ID: On Wed, 16 May 2001 helfesrieder@netscape.net wrote: > To decide about the future directions of CF, there needs to be a > consensus about the overall goal. > > To my understanding, the overall goal is to significantly enlarge > the player base of CF. In other words, to attract, to pull, many > more new players on the CF platform. > > Second, to attract many new players, one needs to know what most, if > not almost all, players want. I will note that free software may be a bit different in commercial software in this regard. For commerical software, its pretty obvious you want as large ap laying base (and thus a maximum number of sales). Given the developers are getting pained, you can get them to do features/enhancements which meet this goal. Free software is a bit different. I'm not (and I'm guessing most/all the other cf developers) getting any monetary gains from the software (I guess this could potentially change by making crossfire servers fee based for example). Given that fact, the developers work what they want to work on. Many times, these features do match making the game more fun to play/increase its audience (after all, developers also play the game). This is one reason I started the discussion on the cf-dev alias - it is the developers that will end up doing the coding. > All players play to have fun and a good and exciting gaming > experience. If you meet this demand, they will come. Otherwise > they will not come. Others may disagree, but I personally think it is not possible for crossfire to compete with commercial games ala everquest, ultima online, etc. They have a lot more resources to throw at game developement, and can basically tell developers 'do XYZ'. > > So, what is needed to meet these demands and expectations ? > > In my opinion, CF needs improvement in 3 top-level areas: > > * Improve Presentation > ** generally : support richer media types > ** better sounds > ** better graphics > ** ambient sounds > ** soundtracks > (** video clips / cut scenes / stills? -> who would be able > to produce them ?) And at least in the last two, how do you distribute them? Even soundtracks would need to get professionally produced (otherwise, you almost certainly run into copyright issues). I agree sound quality right now is poor. ambient sounds could add a lot. Better graphics is a bit vague. While others have suggested isomorphic style, I personally don't like isomorphic games. The the above view tile may be old fashioned, but I personally like it. One question may be whether isomorphic can be done just in the client, or does the server actually need to know about it in some way (and if it does, how much does it need to know? Just different tiles, or is the handling of it fundementally different) An addition to this, in a little more specific terms, would be enhanced handling of the lighting code. This could become even more relevant if features such as night/day are added. > > * Improve Content > ** CF background setting / story > ** Consistent World design (world map) > ** high quality Stories, Quests, "Epic Quests" (compare Everquest) > ** New Player experience Agree with all of those. Note that most of these are map changes, with the cavaet that for things like epic quests, new/better objects may be needed. > * Improve Game Mechanics / Logic > ** Monster & NPC AI Agree. I would also like to see fewer monsters, but make those out there more interesting/tougher. Ideally, also try to balance monsters and players more equally - right now, monsters have 10 times or more hp monsters that players. The end result of this is that a group of players accidentally casts a spell in the wrong direction, that party may be toast, simply because for the spell to be effective against the monster, it does a lot of hp and kills the players. From sniper at citilink.com Wed May 16 19:06:15 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: Message-ID: > > All players play to have fun and a good and exciting gaming > > experience. If you meet this demand, they will come. Otherwise > > they will not come. > > Others may disagree, but I personally think it is not possible for > crossfire to compete with commercial games ala everquest, ultima online, > etc. They have a lot more resources to throw at game developement, > and can basically tell developers 'do XYZ'. imo, crossfire has a much better engine/framework than ultima online or everquest do. maybe that's just because crossfire has been around so long (so as to give developers a chance to implement features), but I think crossfire, as is, has a lot less work to go in being "awesome" than uo and eq do, which have a number of big problems. so I think that crossfire definately can compete with the bigger games, which tend to be released, then stagnate as no new features get added after release. crossfire, on the other hand, has already shown that it will survive indefinately and continue to evolve. remember that the more popular crossfire becomes, the more developers we'll have, and the faster development will go > And at least in the last two, how do you distribute them? Even soundtracks > would need to get professionally produced (otherwise, you almost certainly > run into copyright issues). I don't really get what you mean about copyright issues did you ever play megazeux? www.modarchive.com has thousands of songs, and I remember that people used to go there (probably still do, I'm not part of the mzx scene much anymore), take songs that had no copyright/license issues, and use them in their megazeux games. so if we built mod support into crossfire, we could do that, or just have somebody write some music specifically for the game -Sniper sniper@citilink.com From dnh at hawthorn.csse.monash.edu.au Wed May 16 19:06:05 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:54 2005 Subject: Transportation objects (Was: Re: [CF-Devel] Future crossfire changes/projects) In-Reply-To: <01051619243102.00457@truth> Message-ID: Hmm actually I would like to see multiple race support. So a monster could be both animal and dragon.. or undead and dragon. Shouldn't be to hard to implement, but it would make for cool classifications, undead dragon.. Were creatures.. the possibilties are endless =) dnh On Wed, 16 May 2001, Philipp Currlin wrote: > > > I don't see *that* much a problem with abuses. For example, if we allowed > > boats to cross water, the player might be able to reach places impossible > > to reach before; however, if we wanted to *prevent* that, we can simply > > add rough waters or deep waters that the player cannot cross safely (or > > cannot cross at all). Ditto with flying objects, such as riding dragons, > > we can have very high mountains with strong winds that prevent the player > > from crossing them. > > I could think of adding either a completely new floor-tile here, or modifying > the existing ones to something like: > allow_horses 1 > allow_dragons 1 > or similar on water: > allow_boat 1 > > Then it would be up to the mapmaker if transports were allowed. And we > wouldn't have to modify the maps. Then players could "carry" their transports > around but wouldn't be able to use them unless that was allowed on the > particular map/tile. > Especially on a new world map with much larger dimensions I think > transports would be really nice. > > > Phil > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From sniper at citilink.com Wed May 16 19:13:35 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Crossfire standard text DRAFT In-Reply-To: <20010516233546.A9497@mids.student.utwente.nl> Message-ID: How about this? I made a couple small modifications: ---------- Crossfire Crossfire is graphical, multi-user, 2D tile-based RPG (role playing game) similar to Ultima Online, Everquest, Moria, Angband, Omega, Nethack, Rogue, Gauntlet, and MUDs. The bulk of the game is based on predefined maps, however some areas are randomly generated. It can be played under Windows 95/98/ME and Linux. Version 1.0.0 is the first public release intended for wide-spread distribution. Offical website: http://crossfire.real-time.com/ Sourcforge page: http://www.sourceforge.net/projects/crossfire/ IRC Channel : #crossfire on irc.openprojects.net ---------- I know saying it can be played under "linux" is vague, but I think saying "X11" will go right over the heads of the majority of gamers (which are, by and large, windows users and have never heard of X), and those are really the people we should really be after if we want Crossfire to ever get popular. -Sniper sniper@citilink.com On Wed, 16 May 2001, Joris Bontje wrote: > Hello, > > I think its important do define a standard text that explains what crossfire > is and where to get more information / download it. This could be used to > post in newsgroups, put on RPG, AD&D and game sites. Mail it to your friends, > spread the word! > > --- cut --- > Crossfire 1.0.0 > > Crossfire is graphical multi-user 2D tile-based RPG (role playing game) similar to Moria, Angband, Omega, Nethack, Rogue, Gauntlet, and Muds. The bulk of the game is based on predefined maps, however some areas are randomly generated. > There are clients for X11 (source, RPM, deb) and Windows (DirectX). > > This is the first public release/release for wide spread distribution. > > Offical website: http://crossfire.real-time.com/ > Sourcforge page: http://www.sourceforge.net/projects/crossfire/ > IRC Channel : #crossfire on irc.openprojects.net > --- cut --- > > This is just a start, please add, change & delete and post the result. > > Joris Bontje / MiDS > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruznet.com Wed May 16 19:16:20 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <200105162328.f4GNS0G26375@tonks.EECS.Berkeley.EDU> Message-ID: On Wed, 16 May 2001, Peter Mardahl wrote: > > Agree. I would also like to see fewer monsters, but make those > > out there more interesting/tougher. Ideally, also try to balance > > monsters and players more equally - right now, monsters have 10 times > > or more hp monsters that players. The end result of this is that a > > group of players accidentally casts a spell in the wrong direction, that > > party may be toast, simply because for the spell to be effective > > against the monster, it does a lot of hp and kills the players. > > Have you seen my earlier comments on this phenonema? I believe it > may be completely unavoidable. Maybe. I realize that currently big monsters (ie, multisquare) have some problem in that more squares = more damage when it comes to area of effect spells. One thought on this was to do it like we have suggested for things like confusion & paralyze - insert a object that says 'this creature has already been hit by fireball XYZ, so other parts won't take damage'. But I just realized that gets somewhat complicated - things like lightning bolt last several ticks, so the monster should take additional damage, but only for once space of the monster. Even if you do things like record the last tick the monster was damaged by that spell, there is still some problems with things like cones, where the center does more damage, so you don't want to negate that extra damage when monster just got hit by the fringe (hard to really predict the ordering of the objects). Another thought I just had would be to give each part of the monster hp independent of the other parts. Thus, for example a hill giant, which lets say currently has 200 hp total, would instead have 100 hp for the head/torso and 100 for the legs. If either of these parts is reduced to less than 0 hp, entire monster dies. If you do this, the result is that area of effects spells would damage both of those about equally. The problem is that for characters like fighters who are doing physical attacks, they will need to keep attacking the same part - switching between the legs and torso would effectively mean the monster has twice as many hp in that case. There would not be any requirement that all parts have equal hp. Thus, for example, you could make monsters whose legs are the weak point (ie, have worse hp than the rest, or worse AC, etc). Unfortuantely, the example above isn't all that realistic, as tall monsters have their legs to the south, and head to the north. So while attack the physical heads could in theory maek sense (fewer hp), and is entirely possible with curretn map layout, realisically, that head might be 30' in the air, and the character would not be physically able to reach it. From mwedel at scruz.net Thu May 17 00:52:14 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Crossfire standard text DRAFT References: Message-ID: <3B03670E.D8F81D40@scruz.net> Mike Ponicki wrote: > I know saying it can be played under "linux" is vague, but I think saying > "X11" will go right over the heads of the majority of gamers (which are, > by and large, windows users and have never heard of X), and those are > really the people we should really be after if we want Crossfire to ever > get popular. Presumably, those windows users will see 'runs under windows', and not care much about after that. I really dislike just saying linux. If anything, it should be .. runs under unix with X windowing system. thats much more accurate. From mwedel at scruz.net Thu May 17 01:27:03 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Future crossfire changes/projects References: <3B022459.8BF15CA1@scruz.net> <990022940.453.2.camel@terra> Message-ID: <3B036F37.8BED190D@scruz.net> Scott Barnes wrote: > Proposed Change: Competition Maps > Details: Add the ability to make NPCs remember things after map resets, > so that maps like a "race to the finish" map or "battle to the death" > map could be feasible. Also, just a novelty idea here, a map could be > done that would be sortof a sumo wrestling tournament, players pay some > coins to enter the tournment, try to push each other out of a circle, > and the winner (the one that never got pushed out) gets all the coins > the players paid. Just a thought :) > Pros: Just think of the possiblities :) > Cons: Might be difficult to do, players that are sore losers might get > bitter and kill the winners ;) There is of course already one map sort of in this category - the arena in the starting town. This could of course be extended for more variations as mentioned above. But I wonder how this might affect playing style. I remember mail recently with a 'problem' of players being too friendly to other players (giving out items to newbies), but it was said this was a preferable problem compared to having a bunch of player killers out there. I wonder if such direct competitions may make players more agressive to other players. > > Proposed Change: "Smart" NPC's > Details: Sortof the same thing. Make NPC's able to "remember" things > about the players. > Pros: It would make it possible for whole new plots to evolve around > the players (ie, a player that steals and attacks townspeople, the > townspeople would "remember" and could tell other players that they're > bad, players could even become "villians" and "heros" of sorts :)) > Cons: Would most likely be EXTREMELY difficult to implement. I think some of this would have to do with the scripting. currently, npcs can't even the last thing a player said to them, let alone from before a map reset. OTOH, I think storing information in the player about reputation might make more sense. Looking at just csua and metalforge, there have been several hundred players started, and these servers typically only have a few players on them. Imagine having thousands of players, and hundreds of town inhabitants. Storing this information in the npc could really get complicated. But a related change: Proposed Change: Have map regions Details: Maps (cities in the current map set) would be set in some region. These regions would have different characteristics. Perhaps some regions don't like certain races as much as others (so for example, the elf in the dwarf city would get shifted by prices, while the dwarf would get really good prices, and everyone else neutral prices). Regions could also contain other information, like alternate treasure lists (food in the dwarf city may be considerably different for example). Related to above comments, players could have different reputations for each region (doing quests may raise ones reputation) Pros: Add more flavor to game. Quests would potentially have additional effects. Some quests could not be available until a certain reputation is reached. Cons: Adds another level of complications. A map with the wrong reputation value could really screw things up. From mwedel at scruz.net Thu May 17 01:34:12 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:54 2005 Subject: Transportation objects (Was: Re: [CF-Devel] Future crossfire changes/projects) References: <3B022459.8BF15CA1@scruz.net> <20010516122237.A5297@crystal> <01051619243102.00457@truth> Message-ID: <3B0370E4.25E031E3@scruz.net> Given a little more thought, I think dealing with transportation objects properly (to prevent abuses) is probably not hard. Without going into too much detail, best way to do it would probably be: ground archs would have a terrain_type value (bitmask). This would replace the current is_wooded, is_hilly, etc. Transportation objects would have a similar bitmask. To be able to travel or some terrain, the transportation object would need to have all the same bits sets as in the current terrain type. Depending on how done, the transportation object could effectively have skills which may counteract some of the speed loss for going over some terrains. Most transportation objects could not be carried around (ie, a boat will never leave the water), but for some, like dragon transports, since they can fly anywhere, the abiltity to use them anywhere is pretty open. From mwedel at scruz.net Thu May 17 01:49:02 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Future crossfire changes/projects References: Message-ID: <3B03745E.4C05E7B0@scruz.net> Mike Ponicki wrote: > imo, crossfire has a much better engine/framework than ultima online or > everquest do. maybe that's just because crossfire has been around so long > (so as to give developers a chance to implement features), but I think > crossfire, as is, has a lot less work to go in being "awesome" than uo and > eq do, which have a number of big problems. so I think that crossfire > definately can compete with the bigger games, which tend to be released, > then stagnate as no new features get added after release. crossfire, on > the other hand, has already shown that it will survive indefinately and > continue to evolve. To be honest, I haven't played either of their commercial games. I would be interested in hearing in more details where crossfire is better. I have no doubt that crossfire is worse in other areas. The one big thing crossfire may have going for it is that since it is open source/maps, players can extend it on their own (make new quests and the like). Stagnation is a tricky aspect. At some level, people don't like things changing one day to the next - to log in and find out that artifact XYZ is not nearly as good as it was would probably upset some players, especially those that have XYZ. So the amount that gets changed in major releases has to be carefully controlled. > > remember that the more popular crossfire becomes, the more developers > we'll have, and the faster development will go There is of course a limit to this (too many cooks in the kitchen syndrome). And even with more developers, major development only moves forward if those new developers want to take it in that direction. If they're more interested in making new spells, things don't really move forward that much - you just get more features in what you currently have (which is not bad in itself). > I don't really get what you mean about copyright issues Basically, everything done has an implied copyright. This mail message right here has an implied copyright. Thats not to say that freely distributible files are not available. Its just that the source for this has to carefully be examined. Personally, background music has never been a big deal for me. when I first get a commercial game, I may leave it turned on for a little bit, but it doesn't take too much playing before I have heard all of them, and quickly tire of it. I think much more important that background music is just a lot more different sounds for crossfire (grates cranking open, fountains making noise, some big monsters may even make some different sounds). From mwedel at scruz.net Thu May 17 02:05:55 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Future crossfire changes/projects References: Message-ID: <3B037853.595D28C5@scruz.net> Mike Ponicki wrote: > The only real purpose to improving performance in crossfire is so that > we'll be able to have more than 4-5 people on a server at once without > getting serious lag. In everquest, there are between 1500 and 2000 people > on a server at once. I think our goal at first should be to get 100 people > on a single crossfire server with lag that doesn't make the game > unplayable There is certainly no douubt that crossfire is far from ideal in performance right now. anyone know how much bandwidth a typical player in crossfire needs? What about for the commercial games (everquests/uol?) At some point, I would guess crossfre may see more of a problem in that most crossfire servers may not have the same amount of raw bandwidth that the commercial servers are also putting out. So at some level, while 100 players may get to be feasible in terms of cpu performance, I wonder how many sites out there will have the bandwidth to support that. Maybe someone wants to write a perl script that goes through the server log file output, grabbing the CSSTAT values and plotting approximate bandwidth usage? May provide some relevant data. At many levels, crossfire is just not really efficient (sends image data, sends what is likely to be a lot of repetitive naming information for objects, etc). Many of these are actually very hard to fix if you still want the game extensible (for example, if you know the data was static, the client could already have all the images, and the server could just send 2 byte identifies for object names, and the client looks it up in its database, since it knows the server hasn't added anything, etc). Thats one advantage the commercial games can offer. While crossfire could do automatic updating of that informatiion, it gets much trickier because the servers may noot be in sync (metalforge may have added new names and csua has added other new ones, etc). once again, with commercial entities, they can be pretty sure all the servers are talking the same thing. > This way it would be much more like everquest, where the world is vast and > can't be traveled in mere seconds. Then, all of the performance gains in > the client/server architecture won't be without purpose. The other advantage of that is that there can be places which are discovered by accident (ie, someone decides to explore the jungle). With the size of the current world continent, a player could basically examine most every square in not a lot of time. Of course, in crossfire, it will always be difficult to hide things, because the maps are available to anyone. OTOH, you could very easily have some set of maps that each server admin has added to some different spots on the continent. From mwedel at scruz.net Thu May 17 02:19:28 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Future crossfire changes/projects References: Message-ID: <3B037B80.5532EAD4@scruz.net> Michael Toennies wrote: > I had think about this isometric changing in the past, so i can tell you > that is will be easy > to change client/server to this. 90% work are the gfx, the whole > gameplay/server will be the same. As I said in another message, I personally don't like isomorphic looking games. There also seems to already be a lot of those out on the market. However, I'm never really against giving the user options. So would it be conceivable that using isomorphic vs tile view just becomes an option you supply to the client? Would using isomorphic view actually require any real change in the server side stuff? OTOH, if support for both iso and tile format, we're back to the same complaint we have now - more than one format to draw for when adding new objects. So then realistically, we probably do need to decide what graphic form we want to use. But thats what this discussion is for. From mwedel at scruz.net Thu May 17 02:33:38 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:54 2005 Subject: [CF-Devel] Future crossfire changes/projects References: <3B022459.8BF15CA1@scruz.net> <01051609570303.01585@Terminus.magellan.fpms.ac.be> Message-ID: <3B037ED2.A4C00DB3@scruz.net> > Change: Improved animations > -Details: Currently, you don't _see_ anything when you hit a monster with > your weapon or with karate/punching/etc. The idea is to create animations > showing your character using his weapon. This system may also be implemented > for some 'critical' monsters. > -Pros: The game will definitely look better. It will be easier for other > players to see if your own character is actually fighting or just waiting > before a monster. Do not involve any changes on the Crossfire protocol/client. > -Cons: May require extra CPU time to handle all those new animations. To me, the biggest con on this is for the new images that show this. We could generalize it some (ie, one image for each class which shows an attck, whether hand to hand or via weapon, one for casting spells, etc). I don't think cpu time will be affected much by this - whenever the appropriate action is done, the function that deals with that action could update the face. > > Change: New Map Features > - Details: It is not always easy to create a map. If you want to add your own > monsters or treasures for example, you may not always find a suitable picture > in standard archetypes. The idea here is to allow new monsters/objects/etc. > to be created and saved completely (including XPM/PNG) inside a map or even > another object. Another map extension: the ability to take current time into > account (for example to cast nightfall when time>22:00 and daylight when > time>7:00). Why not even support for a weather system ? And a music support > (a music tag containing the song to play) ? > - Pros: New monsters/objects submissions would be much more easier since the > only thing you need to get is the map. Standard atmosphere would be improved > a lot with 'real' nightfall. > - Cons: This may also mean a general increase of map sizes if lots of custom > objects are created. May require extra CPU work to handle weather/night. The day/night is one of those things that may be nice to add. Crossfire (IMO) would operate at a faster timescale (not in sync with earth), so that even if you always played at night, the time in crossfire would vary. Shops would close, other things may open depending on time. Depending on level done, this could mean lots of updates for objects/maps, but nothing really hard. I've addressed music in another mail - I'm not really big on it. I also have a feeling that if we are telling people 'download this 300 megs to get some music', not a lot of people are going to bother downloading that 300 megs. I'm not sure I like the idea of embedding images into the map itself, but certainly having something like a /maps/images directory which holds additions could work - when server loads a map that has a referance to an image it does not have, it checks that directory for the image and updates its information accordingly. This may require some changes (I think some of the code presumes the image name -> number is in alphabetical order and uses that for finding the images). But that could be changed to not be terribly inefficient. > > Change: Improved Alchemy System > - Details: The Alchemy is not often used in Crossfire. This may be because it > is seen as somewhat too difficult for too limited effects. Why not extending > its possibilities ? I think of a system allowing you to create objects that > have the added abilities of ingredients used to make them (ex: Sword + Potion > of Dex + Potion of Cha = Sword (Dex+1)(Cha+1)). > - Pros: This may make Alchemy more interesting and fun to play. New fields of > investigation for mages would be opened. > - Cons: May disturb playbalance a lot. I think some of the problem is that if you play honestly, you'll never find useful recipes either. I think just having more information on what to make with alchemy may improve how often it is used. > > Change: Improved Combat System > - Details: The current combat system is very simple: you run into a monster > to hit. It may be interesting to improve this a bit by allowing special > combat techniques and critical hits. Monsters could be > immune/protected/vulnerable against some special combat techniques. In short, > the idea is to create an equivalent of spells but in the field of fighting. > - Pros: Make the warriors much more fun to play with. May allow more tactical > play. > - Cons: May become too complicated for many players to use. I largely agree with this con - especially if it remains as it is now, with most maps packed with lots of monsters - you're probably not going to want to try out these special techniques. I think the biggest problem is the speed of what crossfire is played - you don't have much time to experiment, so I think generally, players will find what attack works best and stick with it and not try to change things in combat. I may be wrong on that. I think for things to be more tactical, things would need to be at a slower pace. When right now you kill the monster by attackign it for 10 seconds, there isn't a lot of time to try different things. If it took 30 seconds, then maybe that would be enough time to try some different things out. From david.delbecq at usa.net Thu May 17 05:04:03 2001 From: david.delbecq at usa.net (DAVID DELBECQ) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] Future of Crossfire Message-ID: <20010517100403.7887.qmail@wwcst269.netaddress.usa.net> There is one great points i agree on the debate we have on the list: We need to attract new players to the game and people who could play the most are windows player (am not speaking about actual crossfire players). To attrack these players to crossfire we need two critical points: 1) An attractive interface which mean beautiful graphics. An iso set becomes urgent. This set should be more complete than the actual 2D set (more monster orientations and animations). It is obvious the crossfire server could not handle bandwidth for loading all these gfx, so we should create a standard pictures naming and force the clients to download, via ftp for example, the set before playing or allow the client to use an alternate ones. So we take of this part of the job from the server. 2) a user friendly client. For the moment, most players have do do thinks like bind cast ice storm bind ...... This NOT attractive. We should have a client which know most of the action which can be done on crossfire and give player a list of these action with in front the associated key (like in most other RPG or Quake likes) or allow binding like in diablo. This client should be done for windows in priority and under GPL for faster developpement. The current directx client is interesting and a lot of work seems to have been done on it but am not sure this client could follow forever the server, especially when importants changes are made (like if we run to iso gfx for example) because his developper is alone for maintenance. Once again am saying what a lots of developper are saying: "Michael Toennies make your client GPL, it could become crazily good". Performances of the server are not so important for the moment. Even if we have a high perfomances server, most rpg players will immediately go away because frightened by the ugly gfx. Most of the time, they will not download the client because of screenshots they have seen. Once again, the iso set is very interresting, if people are ready to help me, i would be glad to work on the client side programming (In fact, am not free before end of june because of exams). In fact, it only needs little change (change the drawer and turn of 45° the direction in client side). To do this, i need a small, working, iso set and we need to define the format we will use for pictures. David Delbecq David.delbecq@usa.net ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From andi.vogl at gmx.net Thu May 17 05:08:11 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] crossfire sound In-Reply-To: Message-ID: <000001c0deb9$4a84b120$f38efea9@kyle> Mike Poincki wrote: > > > ** soundtracks > > > (** video clips / cut scenes / stills? -> who would > > > be able to produce them ?) > > And at least in the last two, how do you distribute them? Even > > soundtracks would need to get professionally produced (otherwise, > > you almost certainly run into copyright issues). > > I don't really get what you mean about copyright issues > > did you ever play megazeux? www.modarchive.com has thousands of songs, and > I remember that people used to go there (probably still do, I'm not part > of the mzx scene much anymore), take songs that had no copyright/license > issues, and use them in their megazeux games. so if we built mod support > into crossfire, we could do that, or just have somebody write some music > specifically for the game Ambient/background sounds is one of the things that I would love to have in crossfire. And Mike is right, there's tons of free music. Available in all kinds of musicfile-formats. While these songs are not exactly what I would play on my next home-party, they are perfectly suited as ambient/background sounds. You can find free music that is a lot better than the stuff you hear in professional games. In my opinion, background music makes for a completely different gaming experience. I still have the music themes from crappy old nintendo console-games in my head. Music is the final piece of an RPG that makes you forget the rest of the world while playing. For the dynamic sound effects (spell sounds etc), the ones included in the dxclient from MichToen are already pretty good. Again, there are huge databases with free sound effects. "Cut scenes" are another thing that would greatly enhance CF, by adding much more flair to quests and stories. I hope this will go hand in hand with scripting abilities of NPCs. Simply allow NPCs to perform scripted movement, talk etc. Then the player can be frozen for a moment to watch the actions. Or maybe the player can even take part in the scene, being controlled by the script for a moment. Andreas V. From andi.vogl at gmx.net Thu May 17 05:35:13 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] isometric graphic In-Reply-To: <3B037B80.5532EAD4@scruz.net> Message-ID: <000101c0debd$10959e80$f38efea9@kyle> Mark W. wrote: > > I had think about this isometric changing in the past, so i can > > tell you that is will be easy to change client/server to this. > > 90% work are the gfx, the whole gameplay/server will be the same. > > As I said in another message, I personally don't like isomorphic looking > games. There also seems to already be a lot of those out on the market. I think isomorphic graphics is the ultimate thing for CF. That would be the only way to end the fuzz about perspective in the current png sets: The standard set has a consistent tilted perspective but some people don't like the hard-to-draw monsters. The alternate set has inconsistend perspective but monsters are displayed straight. Iso is the only way to have both correct perspective and straight monster drawings. It's true that a lot of games use isomorphic look. But why? - Because it is best! Unless you have an awesome 3d-engine and heaps of money to throw at professional artists. > However, I'm never really against giving the user options. So would it > be conceivable that using isomorphic vs tile view just becomes an option > you supply to the client? > > Would using isomorphic view actually require any real change in the > server side stuff? The viewable area is simply rotated by 45?. The real change this brings is that high obstacles overlap with the above square(s). Hence multipart objects will differ. If we want to have a good way to handle multipart objects we might need changes in the server code. (E.g. Allowing to walk *behind* high obstacles is a thing I would consider). > OTOH, if support for both iso and tile format, we're back to the > same complaint we have now - more than one format to draw for when > adding new objects. I think if we go for iso-graphics we must drop all other perspectives or we have chaos. But note that we could take over graphics of monsters and items (Mainly from alternate set and xpm). In other words, there should be a real big majority for iso-graphics before we go that route. > So then realistically, we probably do need to decide what graphic form > we want to use. But thats what this discussion is for. Exactly :) Andreas V. From yann.chachkoff at MailAndNews.com Thu May 17 06:29:55 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] Future of Crossfire Message-ID: <3B0A46FA@MailAndNews.com> >===== Original Message From DAVID DELBECQ ===== > 1) An attractive interface which mean beautiful graphics. An iso set becomes >urgent. This set should be more complete than the actual 2D set (more monster >orientations and animations). It is obvious the crossfire server could not >handle bandwidth for loading all these gfx, so we should create a standard >pictures naming and force the clients to download, via ftp for example, the >set before playing or allow the client to use an alternate ones. So we take of >this part of the job from the server. Agree. Idea: the client connects to the server, _may_ (not _must_) request a list of pictures available with last update dates; if the client pictures are not up-to-date, it may then be able to open a connection to a 'picture server' to download the pictures needed. This is in fact a simple extension of the actual image caching system where the pictures are downloaded only before starting the game and requested from a separate picture server (the picture server may be a specific one or simply an ftp server). > 2) a user friendly client. For the moment, most players have do do thinks >like bind cast ice storm bind ...... This NOT attractive. We should have a >client which know most of the action which can be done on crossfire and give >player a list of these action with in front the associated key (like in most >other RPG or Quake likes) or allow binding like in diablo. Definitely agree. >This client should be done for windows in priority and under GPL for faster >developpement. That I can't agree with. Why do you say 'for Windows in priority' ? To touch a greater number of potential players ? What I think here is that we must use a common cross-platform development environment, resulting in a client that may be compiled on both Windows and Unix systems without changes. Ever thought of libraries like ClanLib or SDL ? >The current directx client is interesting and a lot of work seems to have been >done on it but am not sure this client could follow forever the server, >especially when importants changes are made (like if we run to iso gfx for >example) because his developper is alone for maintenance. Once again am saying >what a lots of developper are saying: "Michael Toennies make your client GPL, >it could become crazily good". > I agree with the idea of making the DirectX client GPL. It is certainly interesting. >Performances of the server are not so important for the moment. Even if we >have a high perfomances server, most rpg players will immediately go away >because frightened by the ugly gfx. Most of the time, they will not download >the client because of screenshots they have seen. > That's true, but you forget some clear facts: the fact that some quests are simply unplayable because the server is unable to run fast enough to sustain them (Didn't you made some comments about it not so long ago ?). The most important thing for new players is certainly how the game looks like, but if they discover that their characters die because of server slowliness, they'll quickly go away. I don't think bringing lots of new players just to see them go away a few time later is really a good idea. Certainly, high performance server alone is not enough, but it is necessary. >Once again, the iso set is very interresting, if people are ready to help me, >i would be glad to work on the client side programming (In fact, am not free >before end of june because of exams). In fact, it only needs little change >(change the drawer and turn of 45? the direction in client side). To do this, >i need a small, working, iso set and we need to define the format we will use >for pictures. > Mmmm... Maybe I'll check if I can do something about this... > > Chachkoff Y. ------------------------------------------------------------ Get your FREE web-based e-mail and newsgroup access at: http://MailAndNews.com Create a new mailbox, or access your existing IMAP4 or POP3 mailbox from anywhere with just a web browser. ------------------------------------------------------------ From jbontje at suespammers.org Thu May 17 07:49:11 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B037853.595D28C5@scruz.net>; from mwedel@scruz.net on Thu, May 17, 2001 at 12:05:55AM -0700 References: <3B037853.595D28C5@scruz.net> Message-ID: <20010517144911.A12202@mids.student.utwente.nl> On Thu, May 17, 2001 at 12:05:55AM -0700, Mark Wedel wrote: > Mike Ponicki wrote: > > > > > There is certainly no douubt that crossfire is far from ideal in performance > right now. > > > > Maybe someone wants to write a perl script that goes through the server log > file output, grabbing the CSSTAT values and plotting approximate bandwidth > usage? May provide some relevant data. I did it, download it at: http://mids.student.utwente.nl/~crossfire/stats/datatraffic/ its an ugly hack, but it works... Joris Bontje / MiDS From Philipp.Currlin at t-online.de Thu May 17 08:14:56 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] poll on isometric graphics Message-ID: <01051715145600.05498@truth> There is now a poll up to decide wether we should use the David Gervais iso set or keep our current view. David Gervais iso set: http://dgrealm.50megs.com/iso-samples.html Vote at: http://mids.student.utwente.nl/~crossfire/polls/vote.php3?pollID=6 From hsteoh at quickfur.yi.org Thu May 17 08:15:21 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B037ED2.A4C00DB3@scruz.net>; from mwedel@scruz.net on Thu, May 17, 2001 at 12:33:38AM -0700 References: <3B022459.8BF15CA1@scruz.net> <01051609570303.01585@Terminus.magellan.fpms.ac.be> <3B037ED2.A4C00DB3@scruz.net> Message-ID: <20010517091521.A8223@crystal> On Thu, May 17, 2001 at 12:33:38AM -0700, Mark Wedel wrote: [snip] > > Change: Improved Alchemy System > > - Details: The Alchemy is not often used in Crossfire. This may be because it > > is seen as somewhat too difficult for too limited effects. Why not extending > > its possibilities ? I think of a system allowing you to create objects that > > have the added abilities of ingredients used to make them (ex: Sword + Potion > > of Dex + Potion of Cha = Sword (Dex+1)(Cha+1)). > > - Pros: This may make Alchemy more interesting and fun to play. New fields of > > investigation for mages would be opened. > > - Cons: May disturb playbalance a lot. > > I think some of the problem is that if you play honestly, you'll never find > useful recipes either. I think just having more information on what to make > with alchemy may improve how often it is used. Agreed. Currently, even low-level formulae are so rare that my level 110 character has yet to collect them all. High-level formulae are practically impossible to find. I think the very least we can do is to increase the chance for formula books. If that turns out to be too unbalancing, perhaps we should think of a way to make the Alchemist class playable.... i.e., Alchemist players get some special way of learning formulae (perhaps a dedicated guild -- we can implement this with race detectors AFAICT -- that hands out useful formulae for players who advance in their level). > > Change: Improved Combat System > > - Details: The current combat system is very simple: you run into a monster > > to hit. It may be interesting to improve this a bit by allowing special > > combat techniques and critical hits. Monsters could be > > immune/protected/vulnerable against some special combat techniques. In short, > > the idea is to create an equivalent of spells but in the field of fighting. > > - Pros: Make the warriors much more fun to play with. May allow more tactical > > play. > > - Cons: May become too complicated for many players to use. [snip] > I think for things to be more tactical, things would need to be at a slower > pace. When right now you kill the monster by attackign it for 10 seconds, there > isn't a lot of time to try different things. If it took 30 seconds, then maybe > that would be enough time to try some different things out. [snip] 10 seconds!! With my ring of the Necromancer, i can clean out an entire room of cyclops/titans in 5 seconds. Less than a split second for each monster. With karate. D'you think I'd be interested to worry about "karate moves"? :-) T -- "How are you doing?" "Doing what?" From helfesrieder at netscape.net Thu May 17 08:44:43 2001 From: helfesrieder at netscape.net (helfesrieder@netscape.net) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] poll on isometric graphics References: <200105170707.f4H771K07093@sprite.real-time.com> Message-ID: <6FCAE625.018318E2.79055386@netscape.net> Hi, I think voting without prior discussion and a thorough exchange of arguments is not very helpful.... That's why it is usually done the other way around. Additionally, IMO the question ISO / not ISO is not the top-level question at the moment. For example, on my list this is only 1 detailed point sitting under 1 of the top 3 issues. However, I understand it is one of the question everybody "jumps at" because it is a visual thing and everybody has an instant opinion on it. Regards, Bjoern aka Zack __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From reeve at ductape.net Thu May 17 09:12:27 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] poll on isometric graphics In-Reply-To: <6FCAE625.018318E2.79055386@netscape.net> References: <200105170707.f4H771K07093@sprite.real-time.com> <6FCAE625.018318E2.79055386@netscape.net> Message-ID: <990108747.4487.0.camel@terra> On 17 May 2001 09:44:43 -0400, helfesrieder@netscape.net wrote: > Hi, > > I think voting without prior discussion and a thorough exchange > of arguments is not very helpful.... > > That's why it is usually done the other way around. > > Additionally, IMO the question ISO / not ISO is not the top-level > question at the moment. For example, on my list this is only > 1 detailed point sitting under 1 of the top 3 issues. > > However, I understand it is one of the question everybody "jumps at" > because it is a visual thing and everybody has an instant opinion > on it. > > Regards, > > Bjoern aka Zack > __________________________________________________________________ > Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel Here's a nice idea, why not make it optional? That's what I'd prefer :) -- -- Reeve the cat ----BEGIN FORTUNE---- "What is wanted is not the will to believe, but the will to find out, which is the exact opposite." -- Bertrand Russell, _Sceptical_Essays_, 1928 ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From dweeves at hotmail.com Thu May 17 14:59:25 2001 From: dweeves at hotmail.com (Sebastien Bracquemont) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] Future crossfire changes/projects Message-ID: Hi, Sorry for the little while i wasn't active on the project. 1 - My Java CF Editor is still in (slow) progress. Not much time at home to do all the stuff i want on my computer :( (if you've got a possessive girlfriend, you know what i mean :) ) 2 - My vision is this one : Iso Graphics: The handling of Tiled or Isometric graphics shouldn't be a server issue but a client-only issue. The only thing that (should) changes are : the tile set and the way it is DRAWN ! As i know , the server doesn't draw anything. The same MAP could be displayable with both views without any change in its definition. About iso , go for it. I think it's a really adapted way to do the graphics for RPG. Graphics Management: A few time ago , i already proposed a "not so heavy" graphic management by the game server and that client should have a local graphics repository.Then it could ask an "image server" for missing or new graphics Generally I think we should let the server do only logical processing (player pos,spell etc...) and the client do the "displayable meaning" of the actions occuring in the server. (See the client as a View/Controller couple and the server as a Model in an MVC point of view) Documentation: A a new developer in the adventure , the big drawback i can notice in CF is the lack of programming documentation. No conceptual doc , a few protocol doc, no file formats doc etc... I think it's really disapointing A little wish : Why not a C++ rewrite/remodeling ? I think object modelization would be more appropriate (and clean) for the purpose of the server.It could permit a much better distribution of the work as well. (And with a good conceptual doc, this should become an obvious choice i think) I think 2.0 can be a new dev branch with OO design . What daya think about it ? Dweeves. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From sniper at citilink.com Thu May 17 11:45:08 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] Crossfire standard text DRAFT In-Reply-To: <3B03670E.D8F81D40@scruz.net> Message-ID: yeah, I guess you're right, as long as we say "windows" the rest should be more specific (unix and X) -Sniper On Wed, 16 May 2001, Mark Wedel wrote: > Mike Ponicki wrote: > > > > I know saying it can be played under "linux" is vague, but I think saying > > "X11" will go right over the heads of the majority of gamers (which are, > > by and large, windows users and have never heard of X), and those are > > really the people we should really be after if we want Crossfire to ever > > get popular. > > Presumably, those windows users will see 'runs under windows', and not care > much about after that. > > I really dislike just saying linux. If anything, it should be > > .. runs under unix with X windowing system. > > thats much more accurate. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From sniper at citilink.com Thu May 17 12:01:39 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B03745E.4C05E7B0@scruz.net> Message-ID: > > imo, crossfire has a much better engine/framework than ultima online or > > everquest do. maybe that's just because crossfire has been around so long > > (so as to give developers a chance to implement features), but I think > > crossfire, as is, has a lot less work to go in being "awesome" than uo and > > eq do, which have a number of big problems. so I think that crossfire > > definately can compete with the bigger games, which tend to be released, > > then stagnate as no new features get added after release. crossfire, on > > the other hand, has already shown that it will survive indefinately and > > continue to evolve. > > To be honest, I haven't played either of their commercial games. I would be > interested in hearing in more details where crossfire is better. > > I have no doubt that crossfire is worse in other areas. > well, crossfire is worse in the area of how many players you can have playing at once. Both the world size and the client/server stuff is a lot slower. In EQ, and maybe in UO also (been YEARS since I've played it, and even then, I wasn't in to it much), there's like 1500 people in the game world. even MUD's similar to crossfire (ex. solace) have at least 10 people playing at once. In areas where crossfire is better, the magic system is much better under crossfire. having spells and prayers is a really neat idea. Also, the whole flow of the game, and the process of leveling up is much better under crossfire. in EQ, you'd sit in a dungeon, kill a few monsters, then get killed, which was both extremely frustrating, it was like a two step forward, one step backwards sort of thing. The camera angles (1st person was the only useful camera angle) made it hard to keep good awareness of surroundings. The dungeons were too crowded, and you ended up arguing over who gets to kill what with all the other players. when you die, you lose all your items, and have to go back and find your corpse to get everythig back. Basically, EQ was extremely frustrating! crossfire has none of these nuances. > The one big thing crossfire may have going for it is that since it is open > source/maps, players can extend it on their own (make new quests and the like). > > Stagnation is a tricky aspect. At some level, people don't like things > changing one day to the next - to log in and find out that artifact XYZ is not > nearly as good as it was would probably upset some players, especially those > that have XYZ. So the amount that gets changed in major releases has to be > carefully controlled. > I understand that part, but if you look at how much UO and EQ have evolved since release, it's been very little. They've released expansion packs, but most players I knew of back when I played didn't buy them since they're $20-$30 a pop, plus the cost it takes to play the game ($10 a month for both games when I played). > > > > remember that the more popular crossfire becomes, the more developers > > we'll have, and the faster development will go > > There is of course a limit to this (too many cooks in the kitchen syndrome). > And even with more developers, major development only moves forward if those new > developers want to take it in that direction. If they're more interested in > making new spells, things don't really move forward that much - you just get > more features in what you currently have (which is not bad in itself). > That's true. but all the same, I think having not just actual coders, but more mappers is a great thing. Having 200 people making maps is a lot better than 5 people. It just means we'll have to be more organized with the development, and have some sort of committee to determine what direction development will go. > > > I don't really get what you mean about copyright issues > > Basically, everything done has an implied copyright. This mail message right > here has an implied copyright. > > Thats not to say that freely distributible files are not available. Its just > that the source for this has to carefully be examined. > > Personally, background music has never been a big deal for me. when I first > get a commercial game, I may leave it turned on for a little bit, but it doesn't > take too much playing before I have heard all of them, and quickly tire of it. > I think much more important that background music is just a lot more different > sounds for crossfire (grates cranking open, fountains making noise, some big > monsters may even make some different sounds). > I think you're definately in the minority there. Background music is a huge issue for most gamers, myself included. I quickly get bored when I don't have music playing during a game. When I play crossfire, I have mp3's going constantly in the background. It's an ok workaround, but I would much rather have music that's part of the game. heavy metal (all I listen to) doesn't go along with an RPG too well, not very conducive to good atmosphere :) Also, I think stripping the music out of a game (ex. by disabling it) takes away from what the author was trying to do with the game in the first place. It'd be like taking the music out of a movie. It'd wreck the atmosphere, it's as a big a part of the movie as the special effects, script etc. is. So I think it would add a ton to the value to crossfire if it had a soundtrack. I guess what I didn't understand about copyright is how someone making music for crossfire is any different than people making maps for it. I mean, maps would have the exact same "implied copyright" as a mod would, assuming the person made it for crossfire, and didn't mind us using it. Are there any good mod trackers out there who could write some fantasy music for use in crossfire? -Sniper sniper@citilink.com From sniper at citilink.com Thu May 17 12:23:27 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B037853.595D28C5@scruz.net> Message-ID: > At many levels, crossfire is just not really efficient (sends image data, sends > what is likely to be a lot of repetitive naming information for objects, etc). > Many of these are actually very hard to fix if you still want the game > extensible (for example, if you know the data was static, the client could > already have all the images, and the server could just send 2 byte identifies > for object names, and the client looks it up in its database, since it knows the > server hasn't added anything, etc). Thats one advantage the commercial games > can offer. While crossfire could do automatic updating of that informatiion, it > gets much trickier because the servers may noot be in sync (metalforge may have > added new names and csua has added other new ones, etc). once again, with > commercial entities, they can be pretty sure all the servers are talking the > same thing. > Regarding the whole performance issue, I think the only good solution is to do exactly what commercial games do, and that's have EVERYTHING possible done on the client side. It's kind of network programming 101, you want as little data as possible going between the server and the client. That means we should have all the maps, sound, music (if/when we add some), everything, on the client side. To get around the problem of server specific stuff, Everquest implemented an automatic update feature. When you log onto one of their servers, it sends over any new/modified maps, spells, any game-related stuff that needs to be updated on the client. Now, it'd be a little more difficult with crossfire, since anyone can change maps, modify sounds etc. But I know that games like Quake 1-3, Unreal Tournament, Half-Life etc. run into the exact same problems, since anyone can change the maps, and anyone can run their own server. Even FPS have some sort of auto-update mechanism (UT and Q3 for ex. download new stuff to the client if the server is running different skins/maps etc.), and with the small file sizes of everything in crossfire, it'd be quick to update the client. Plus, we could have maybe 10 servers or so we could deem "official". They could have a lot of bandwidth and be running on fast PC's. Then we could keep those "official" servers running only the latest official stuff, so they'd all be talking the same. Then if people wanna' try new and experimental stuff, they could log onto Joe Schmo's home server and put up with a bit longer client updates (assuming Joe is running modified game content) Except I don't know how hard this'd (auto-update mechanism) be to implement into the game... :) but I think it should be our eventual goal to have everything moved over to the client side -Sniper sniper@citilink.com From sniper at citilink.com Thu May 17 12:28:15 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B037B80.5532EAD4@scruz.net> Message-ID: > Would using isomorphic view actually require any real change in the server side > stuff? > > OTOH, if support for both iso and tile format, we're back to the same complaint > we have now - more than one format to draw for when adding new objects. On the technical side, if we move all (or as much as possible) game content to the client side, this wouldn't be an issue- the client can choose to render the game any way he/she chooses. But as for the creative side (which I think is what you were referring to), it would be a lot more work to have to keep two or more tilesets updated with new objects. This is a big off subject, but from a technical standpoint, couldn't we even do some sort of opengl renderer, and use polygonal tile sets? This would be in the far future probably, but would it in concept be any different than using, say, isomorphic rendering? -Sniper sniper@citilink.com From sniper at citilink.com Thu May 17 12:33:49 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B037ED2.A4C00DB3@scruz.net> Message-ID: > The day/night is one of those things that may be nice to add. Crossfire (IMO) > would operate at a faster timescale (not in sync with earth), so that even if > you always played at night, the time in crossfire would vary. > ala Everquest, that's exactly how it worked in that game (a day took, I forget, but like an hour real-world time) . And travelling at night was perilous if your race couldn't see well at night, which added a whole new strategic dimension. > I've addressed music in another mail - I'm not really big on it. I also have a > feeling that if we are telling people 'download this 300 megs to get some > music', not a lot of people are going to bother downloading that 300 megs. > Not if we use mods. Mods are relatively small file size (bigger than midi, since the samples are actually in the .mod file), but much smaller than mp3's or some other digital format. > I think for things to be more tactical, things would need to be at a slower > pace. When right now you kill the monster by attackign it for 10 seconds, there > isn't a lot of time to try different things. If it took 30 seconds, then maybe > that would be enough time to try some different things out. > This is totally a taste thing. Personally, I like the speed of crossfire, and how it doesn't take a month to gain a level like it did in Everquest and in a lot of MUD's. But then again, I tried to get one of my friends hooked on Crossfire (he's a big MUD guy) and he hated the combat system in Crossfire, because of the fact it's so fast, and you just plow through monsters to kill them. We should probably have some sort of debate/vote on this, but I think this is a low-priority issue compared to the technical aspects of the game. -Sniper sniper@citilink.com From sniper at citilink.com Thu May 17 12:37:21 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:55 2005 Subject: [CF-Devel] Future of Crossfire In-Reply-To: <20010517100403.7887.qmail@wwcst269.netaddress.usa.net> Message-ID: > There is one great points i agree on the debate we have on the list: > > 1) An attractive interface which mean beautiful graphics. An iso set becomes > urgent. This set should be more complete than the actual 2D set (more monster > orientations and animations). It is obvious the crossfire server could not > handle bandwidth for loading all these gfx, so we should create a standard > pictures naming and force the clients to download, via ftp for example, the > set before playing or allow the client to use an alternate ones. So we take of > this part of the job from the server. > > 2) a user friendly client. For the moment, most players have do do thinks > like bind cast ice storm bind ...... This NOT attractive. We should have a > client which know most of the action which can be done on crossfire and give > player a list of these action with in front the associated key (like in most > other RPG or Quake likes) or allow binding like in diablo. This client should > be done for windows in priority and under GPL for faster developpement. > The current directx client is interesting and a lot of work seems to have been > done on it but am not sure this client could follow forever the server, > especially when importants changes are made (like if we run to iso gfx for > example) because his developper is alone for maintenance. Once again am saying > what a lots of developper are saying: "Michael Toennies make your client GPL, > it could become crazily good". > I agree whole-heartedly. We need new graphics, this is a big priority, if we ever hope to enlarge the crossfire community. However, I still maintain that performance is a big issue too, because as the community grows, we will need improved performance to keep up. -Sniper sniper@citilink.com From tanner at real-time.com Thu May 17 12:41:57 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: ; from sniper@citilink.com on Thu, May 17, 2001 at 12:23:27PM -0500 References: <3B037853.595D28C5@scruz.net> Message-ID: <20010517124157.E6160@real-time.com> Quoting Mike Ponicki (sniper@citilink.com): > Regarding the whole performance issue, I think the only good solution is > to do exactly what commercial games do, and that's have EVERYTHING > possible done on the client side. > > It's kind of network programming 101, you want as little data as possible > going between the server and the client. > > That means we should have all the maps, sound, music (if/when we add > some), everything, on the client side. Talking about this on irc now.... What about security. Both from cheapers and from hackers. Blizzard is have terrible problems with hackers, from a game playing standpoint, ie assinating hard core players, to compromised machines. If everything is held in the client, won't it be possible for someone to tweak equipment? Change stats? A long time ago this was a problem in netrek and the concept of a blessed client was evolved to help prevent cheating. If you aren't familiar with this, http://shell3.ba.best.com/~doosh/netrek/netrekFAQ.html#10 I think cheaters also drive new users away. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From hsteoh at quickfur.yi.org Thu May 17 12:47:12 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <20010517124157.E6160@real-time.com>; from tanner@real-time.com on Thu, May 17, 2001 at 12:41:57PM -0500 References: <3B037853.595D28C5@scruz.net> <20010517124157.E6160@real-time.com> Message-ID: <20010517134712.A8955@crystal> On Thu, May 17, 2001 at 12:41:57PM -0500, Bob Tanner wrote: > Quoting Mike Ponicki (sniper@citilink.com): > > Regarding the whole performance issue, I think the only good solution is > > to do exactly what commercial games do, and that's have EVERYTHING > > possible done on the client side. [snip] > > That means we should have all the maps, sound, music (if/when we add > > some), everything, on the client side. [snip] > What about security. Both from cheapers and from hackers. [snip] > If everything is held in the client, won't it be possible for someone to tweak > equipment? Change stats? [snip] That is why CF currently sends the inventory only once, and then only the changes thereafter. The first part takes care of the cheating, the second part takes care of the performance. Granted, there's still a lot of room for improvement, but I think the basic approach currently used is fine. T -- Roasting my brains over a slow fire. Please do not interrupt this process. From sniper at citilink.com Thu May 17 14:04:53 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] crossfire sound In-Reply-To: <000001c0deb9$4a84b120$f38efea9@kyle> Message-ID: > Ambient/background sounds is one of the things that I would love to have > in crossfire. And Mike is right, there's tons of free music. Available > in all kinds of musicfile-formats. While these songs are not exactly > what I would play on my next home-party, they are perfectly suited > as ambient/background sounds. You can find free music that is a lot > better than the stuff you hear in professional games. > > In my opinion, background music makes for a completely different > gaming experience. I still have the music themes from crappy old > nintendo console-games in my head. Music is the final piece of an > RPG that makes you forget the rest of the world while playing. > > For the dynamic sound effects (spell sounds etc), the ones included in > the dxclient from MichToen are already pretty good. Again, there are > huge databases with free sound effects. > > "Cut scenes" are another thing that would greatly enhance CF, by adding > much more flair to quests and stories. I hope this will go hand in hand > with scripting abilities of NPCs. Simply allow NPCs to perform scripted > movement, talk etc. Then the player can be frozen for a moment to > watch the actions. Or maybe the player can even take part in the scene, > being controlled by the script for a moment. > Has anyone else here played Megazeux, or at the very least, ZZT? Both games had a very simple scripting language (Robotic in MZX, ZZT-OOP in ZZT). Simple yes, but you could do ANYTHING you wanted with it (not so much in ZZT, but definately in MZX). I mean, the base graphics in MZX were overhead. But people made platformers, shooters, racing games etc. out of MZX. You could even make your own characters, palettes, etc, then load them at any time, so you could do elaborate sunsets by changing palettes, awesomely detailed characters etc. People also tried to make RPG's, but MZX was very limited, since it was designed to be flexible, not just to make RPG's with. (doing HUD-style menus was possible, but difficult to maintain, and very slow rendering). Well, if we incorporated some sort of simple scripting language into Crossfire, imagine what we could do with the board design- it'd be awesome. I'm not saying we'd make side-scrolling boards or anything (I guess maybe somehow people could if they were really creative) , but we could easily create very complex quest boards and have the flexibility to do almost anything. I'd really suggest downloading Megazeux (http://sourceforge.net/projects/megazeux/) if you've got time, and just mess around with the board editor for maybe an hour or two, get the hang of the basics of the scripting language. Then you'll see how perfectly this feature would fit into crossfire, it's a perfect fit. -Sniper sniper@citilink.com From sniper at citilink.com Thu May 17 14:09:50 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] Future of Crossfire In-Reply-To: <3B0A46FA@MailAndNews.com> Message-ID: > >This client should be done for windows in priority and under GPL for faster > >developpement. > That I can't agree with. Why do you say 'for Windows in priority' ? To touch a > greater number of potential players ? What I think here is that we must use a > common cross-platform development environment, resulting in a client that may > be compiled on both Windows and Unix systems without changes. Ever thought of > libraries like ClanLib or SDL ? > I agree, I think the client should be cross-platform compatible. SDL would be a great idea. I can't say the same for ClanLib, as unlike SDL, ClanLib has a lot of dependencies on other, external libraries (try compiling a ClanLib-based game; you have to install at least one or two other sets of libraries that the game uses). SDL is great tho' -Sniper sniper@citilink.com From sniper at citilink.com Thu May 17 14:15:01 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: Message-ID: > Iso Graphics: > > The handling of Tiled or Isometric graphics shouldn't be a server issue but > a client-only issue. > > The only thing that (should) changes are : the tile set and the way it is > DRAWN ! > > As i know , the server doesn't draw anything. > > The same MAP could be displayable with both views without any change in its > definition. > > About iso , go for it. I think it's a really adapted way to do the graphics > for RPG. > > Graphics Management: > > A few time ago , i already proposed a "not so heavy" graphic management by > the game server and that client should have a local graphics repository.Then > it could ask an "image server" for missing or new graphics > > Generally I think we should let the server do only logical processing > (player pos,spell etc...) and the client do the "displayable meaning" of > the actions occuring in the server. (See the client as a View/Controller > couple and the server as a Model in an MVC point of view) > EXACTLY! well explained :) I mean, every other online RPG on Earth uses this system, so there must be a reason -Sniper sniper@citilink.com From sniper at citilink.com Thu May 17 14:18:03 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <20010517124157.E6160@real-time.com> Message-ID: > What about security. Both from cheapers and from hackers. > > Blizzard is have terrible problems with hackers, from a game playing standpoint, > ie assinating hard core players, to compromised machines. > > If everything is held in the client, won't it be possible for someone to tweak > equipment? Change stats? > I played Diablo a LOT online, and everyone was level 50 (hacked player files). Verant TOTALLY solved cheating (I mean, cheating was impossible, I never heard of it in EQ) by simply having all the player files themselves on the server. Crossfire is already like this, so there shouldn't be a problem. As for security, I know little, except is there a way we could encrypt player data or something, and use some sort of semi-secure connection, or would that be too slow? -Sniper sniper@citilink.com From peterm at tonks.EECS.Berkeley.EDU Thu May 17 14:19:20 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] Has anyone had time to analyze the scripting patch submitted? In-Reply-To: Your message of "Thu, 17 May 2001 14:09:50 CDT." Message-ID: <200105171919.f4HJJKH29887@tonks.EECS.Berkeley.EDU> Hello, I haven't had time to look at the scripting patch which has already been submitted. I'm not so sure I approve of a scheme-like syntax for a scripting language for crossfire, yet I don't want to dismiss it out of hand out of prejudice. Has anyone tried the patch and evaluated it yet? We must not let it languish or be ignored--I wish I had the time just now to look at it myself. PeterM From mwedel at scruznet.com Thu May 17 14:20:19 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: Message-ID: On Thu, 17 May 2001, Mike Ponicki wrote: > > > I've addressed music in another mail - I'm not really big on it. I also have a > > feeling that if we are telling people 'download this 300 megs to get some > > music', not a lot of people are going to bother downloading that 300 megs. > > > Not if we use mods. Mods are relatively small file size (bigger than midi, > since the samples are actually in the .mod file), but much smaller than > mp3's or some other digital format. Yeah - I guess if we want to do music, those that don't want it can always turn it off (or not download the music file or whatever). So not a big deal there. > This is totally a taste thing. Personally, I like the speed of crossfire, > and how it doesn't take a month to gain a level like it did in Everquest > and in a lot of MUD's. But then again, I tried to get one of my friends > hooked on Crossfire (he's a big MUD guy) and he hated the combat system in > Crossfire, because of the fact it's so fast, and you just plow through > monsters to kill them. We should probably have some sort of debate/vote on > this, but I think this is a low-priority issue compared to the technical > aspects of the game. I think this points to a bigger issue - You can't please everyone. We have to be careful on that - just because one person likes some method of playing certainly doesn't mean everyone else likes it (as your paragraph above states). Now some things may become more 'optional' features - you have the option of using it, but if you don't, its not a big deal. However, that then basically means the feature doesn't do anything useful. If advanced combat techniques allow you to kill the monster quicker, then people would really need to use it (as otherwise what happens is the map designers see that player can use combat technique Z to kill the monster really quickly, so they make the monster tougher, and if you don't use that technique, you may get hosed). So while different ideas are always good to hear, we have to know that not everything is going to get done. Some people would probably be against a change if it changes the gameplay a lot from the old style. For example, if the advanced combat techniques had to be used, and you just couldn't run into monsters to kill them, old time players may get annoyed pretty quickly with that. From mwedel at scruznet.com Thu May 17 14:33:25 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: Message-ID: On Thu, 17 May 2001, Mike Ponicki wrote: > > On the technical side, if we move all (or as much as possible) game > content to the client side, this wouldn't be an issue- the client can > choose to render the game any way he/she chooses. But as for the creative > side (which I think is what you were referring to), it would be a lot more > work to have to keep two or more tilesets updated with new objects. Note that it was an intentional design goal to assume the client is not trustworthy. Therefor, the server does not believe anything the client says. That said, sound area already client side (server just tells client what to play), images can be client side (either through the cache option of -imagefile option in the unix client - perhaps these should be turned on by default instead off of). Dealing with maps gets tricky. The current map set is 10 megabtyes or so, and is not in the most easily parsible format (not really hard, but not completely trivial). I don't really want to see that moving to the client (trust on this is less an issue, since most all maps are available and the player can download them and view them anyways - issue is more complication). Plus, the bandwidth from the maps probably isn't that great - the bigger bandwidth hog is the objects on top of the maps that move around or change time to time - the client having a copy won't help that. The other bandwidth hog is large piles of objects on the ground. This gets costly because for each item, we send the name information (arrow/arrows) as well as lots of other duplicate information (face for example). In some cases, you get unique artifacts and can't help that, but most big piles are a whole bunch of mundane objects that could perhaps be handled in a better fashion. If it was a commercial game with known information between the client and server, it could probably get simplied to '80 of item 1734', and the client would know item 1734 is arrows, its face is this, and its weight is this. From leaf at real-time.com Thu May 17 14:47:27 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] Linux RPG Web Ring Message-ID: I was contacted to sign up Crossfire on the Linux RPG web ring. Anyone have any comments or opinions on doing this? I will take care of the signup process, etc. if we decide to go ahead with this. - Rick Tanner leaf@real-time.com ---------- Forwarded message ---------- Date: Thu, 17 May 2001 04:48:25 -0500 From: "al_beraud@yahoo.fr" I propose you to join a "Linux RPG Web Ring" that I am putting up. At the time being, there is only my own project in it: Deity. You can find it at: http://deity.tuxfamily.org I want that ring to be a gathering of all the RPG projects on Linux. Best regards, Alexandre BERAUD From mwedel at scruznet.com Thu May 17 15:40:34 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: Message-ID: On Thu, 17 May 2001, Mike Ponicki wrote: > That's true. but all the same, I think having not just actual coders, but > more mappers is a great thing. Having 200 people making maps is a lot > better than 5 people. It just means we'll have to be more organized with > the development, and have some sort of committee to determine what > direction development will go. Thats true - crossfire is a ways away from having too many people work on it. And some things are basically independent of others. You can basically have any number of people working on maps with no problems. Even work between clients and server can be seperated to some level (not always - there may be some addition to the server which requires the client to get upgraded so that it understands that new part of the protocol. But assuming the developers agreed on what to work on, I would rather have too many developers than not enough. From mwedel at scruznet.com Thu May 17 16:03:07 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:56 2005 Subject: Alchemy, was Re: [CF-Devel] Future crossfire changes/projects In-Reply-To: <20010517091521.A8223@crystal> Message-ID: On Thu, 17 May 2001, H. S. Teoh wrote: > > I think some of the problem is that if you play honestly, you'll never find > > useful recipes either. I think just having more information on what to make > > with alchemy may improve how often it is used. > > Agreed. Currently, even low-level formulae are so rare that my level 110 > character has yet to collect them all. High-level formulae are practically > impossible to find. I think the very least we can do is to increase the > chance for formula books. > > If that turns out to be too unbalancing, perhaps we should think of a way > to make the Alchemist class playable.... i.e., Alchemist players get some > special way of learning formulae (perhaps a dedicated guild -- we can > implement this with race detectors AFAICT -- that hands out useful > formulae for players who advance in their level). So then would just increasing the frequency and usefulness of these books helps? This would not be hard to do - unfortunately, the current alcehmical formulas do not have any difficulty chance. One thing that may help immediately is changing the title of books to reflect the formula. Ie, instead of just ' a recipe book', have it be a 'recipe book of water of the wise' or the like. I know one problem is that while books currently appear in stores, your not going to buy one only to find it is of a formula you already have. Does anyone ever really buy books out of the shops? The more I think about it, the more it would be nice for the formula to have level/difficulty information. That can be used for: 1) Chance of making item (if level of formula is higher than level of alchemy skill, chance of failure goes up). Right now, I believe the code tries to derive a difficulty based on ingredients and so forth. 2) More difficult formula show up on more difficult maps. So on that higher level map, your more likely to find a recipe for potions, and not how to make water of the wise. 3) Difficulty of the book. More difficult the formula, higher the level in the book, and thus higher literacy skill needed. Unrelated, but still something I think would be nice is somehow record what formula the player has learned. This could be used: 1) Player could dump the alchemistry knowledge the character knows in case they have lost their notes. This can also be more relevant if different servers have different formula (ie, did that note I copied down apply to this server or not) 2) Knowledge of the formula could be required or increase chances of actual creating products. In this way, its still desirable for new characters to learn this information, even if the player has all the formula information (either by looking at file or just starting a new character) I think somewhat related to this is readable objects are just very rare in general. You can go to the shops and maybe 10-15% of the spellbooks are actually readable objects, and of that, some smaller portion actually related to alchemy. But in most dungeons, spellbooks are very rare, and thus readables even rare. So these things just do not turn up that often, even ignoring the fact that you can't be sure what you'll get. From jbontje at suespammers.org Thu May 17 16:17:31 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] Linux RPG Web Ring In-Reply-To: ; from leaf@real-time.com on Thu, May 17, 2001 at 02:47:27PM -0500 References: Message-ID: <20010517231731.A14853@mids.student.utwente.nl> On Thu, May 17, 2001 at 02:47:27PM -0500, Rick Tanner wrote: > > I was contacted to sign up Crossfire on the Linux RPG web ring. > > Anyone have any comments or opinions on doing this? Would be a good thing... (not that I ever use rings to find other sites...) But be carefull that you don't need to ruine the website layout with ugly banners or predefined HTML. Joris Bontje / MiDS From sniper at citilink.com Thu May 17 16:18:08 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:00:56 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: Message-ID: > The other bandwidth hog is large piles of objects on the ground. This gets > costly because for each item, we send the name information (arrow/arrows) > as well as lots of other duplicate information (face for example). In > some cases, you get unique artifacts and can't help that, but most > big piles are a whole bunch of mundane objects that could perhaps be > handled in a better fashion. If it was a commercial game with known > information between the client and server, it could probably get simplied to > '80 of item 1734', and the client would know item 1734 is arrows, its face is > this, and its weight is this. > Is there a way we could simplify the handling of objects, like how you said commercial games would handle it, or would that be really tough to implement? -Sniper sniper@citilink.com From dnh at hawthorn.csse.monash.edu.au Thu May 17 17:40:15 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:57 2005 Subject: [CF-Devel] Future of Crossfire In-Reply-To: <20010517100403.7887.qmail@wwcst269.netaddress.usa.net> Message-ID: Umm I tend to disagree with this. Firstly, I honestly DON'T believe an 'iso' view version of crossfire, or at least a version like the 'standard set'. I personally believe that with a short month, Peterm and I have created a better, more congruent, set that really does look great. The alternate set (which can be found on crossfire.csua.ber....) may look easy to convert to iso but there is a large problem and that is with the multitiled monsters. If we take on an iso view major changes are going to have to be made, and IMHO it simply isn't worth our time.. certainly if some wiz artists comes along AND MAKES the new images I would be happy to see such ventures, but until we have some real live artist walking about, that I can talk to and ask questions about, I don't support this view. Secondly, you say our servers can't support uploading the images to the clients? what do you think they already do? and what do you think is already supported? if you add -usefile or something like that, it will grab its images from a set of pngs, you don't need to get them from the server. This is merely an implementation problem and I am sure Mark would be willing to hear suggestions on a better way to do it ;). 2) We have been looking for someone to work on the linux client for a long long time, Mark has done some excellent work, but the fact remains it is not an interface heavy client. It is simple, it works and I personally find it very useable. Some speed improvements and a few new options in the preferences and I think we have an excellent client already. Most stuff you find in clients today tends to be artists who have plenty of time, if we have one.. then perhaps we could consider this. Not only this, but we are constantly updating the server, I personally have been involved in adding 10 or so spells, and I don't think I want to consider having to fix the client everytime I add a new spell =\. These are just a few thoughts, but they were eating at me, sometimes you must remember that crossfire is not a commercial game, and we don't have spare resources lieing about. While setting a high goal is fine, I think we should set ones that we can achieve ourselves, realistically. dnh On Thu, 17 May 2001, DAVID DELBECQ wrote: > > There is one great points i agree on the debate we have on the list: > > We need to attract new players to the game and people who could play the most > are windows player (am not speaking about actual crossfire players). To > attrack these players to crossfire we need two critical points: > > 1) An attractive interface which mean beautiful graphics. An iso set becomes > urgent. This set should be more complete than the actual 2D set (more monster > orientations and animations). It is obvious the crossfire server could not > handle bandwidth for loading all these gfx, so we should create a standard > pictures naming and force the clients to download, via ftp for example, the > set before playing or allow the client to use an alternate ones. So we take of > this part of the job from the server. > > 2) a user friendly client. For the moment, most players have do do thinks > like bind cast ice storm bind ...... This NOT attractive. We should have a > client which know most of the action which can be done on crossfire and give > player a list of these action with in front the associated key (like in most > other RPG or Quake likes) or allow binding like in diablo. This client should > be done for windows in priority and under GPL for faster developpement. > The current directx client is interesting and a lot of work seems to have been > done on it but am not sure this client could follow forever the server, > especially when importants changes are made (like if we run to iso gfx for > example) because his developper is alone for maintenance. Once again am saying > what a lots of developper are saying: "Michael Toennies make your client GPL, > it could become crazily good". > > Performances of the server are not so important for the moment. Even if we > have a high perfomances server, most rpg players will immediately go away > because frightened by the ugly gfx. Most of the time, they will not download > the client because of screenshots they have seen. > > > Once again, the iso set is very interresting, if people are ready to help me, > i would be glad to work on the client side programming (In fact, am not free > before end of june because of exams). In fact, it only needs little change > (change the drawer and turn of 45° the direction in client side). To do this, > i need a small, working, iso set and we need to define the format we will use > for pictures. > > > > > David Delbecq > David.delbecq@usa.net > > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=1 > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Thu May 17 17:47:10 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:57 2005 Subject: [CF-Devel] isometric graphics In-Reply-To: <000101c0debd$10959e80$f38efea9@kyle> Message-ID: The alternate > set has inconsistend perspective but monsters are displayed straight. > Iso is the only way to have both correct perspective and straight > monster drawings. Umm ask Mich about this, in actual fact the alternate set is absolutely perfect for true isomorphic view, we just have to fix some of the facings. On the other hand the standard set is WAY off, it lakes all perspective (once again ask Mich about this, I don't want to even try explaining). If we wanted to switch to David Gs isomorphic set we would have to take the alternate set images, look at his example if you do'nt believe me. and hard to draw? come on, nobody says they are hard to draw, who doesn't say anything is hard to draw. The only reason I don't draw for it is because I totally dislike it, and can only see myself making poor attempts at it, and not putting 100% in. dnh > The viewable area is simply rotated by 45°. The real change this brings > is that high obstacles overlap with the above square(s). > Hence multipart objects will differ. If we want to have a good > way to handle multipart objects we might need changes in the server > code. (E.g. Allowing to walk *behind* high obstacles is a thing > I would consider). > > > OTOH, if support for both iso and tile format, we're back to the > > same complaint we have now - more than one format to draw for when > > adding new objects. > > I think if we go for iso-graphics we must drop all other perspectives > or we have chaos. But note that we could take over graphics of > monsters and items (Mainly from alternate set and xpm). > > In other words, there should be a real big majority for iso-graphics > before we go that route. > > > So then realistically, we probably do need to decide what graphic form > > we want to use. But thats what this discussion is for. > > Exactly :) > > > Andreas V. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From joel at mamia.prninfo.com Thu May 17 14:51:39 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 18:00:58 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B022459.8BF15CA1@scruz.net> from "Mark Wedel" at May 15, 2001 11:55:21 PM Message-ID: <200105171951.PAA19430@mamia.prninfo.com> I am in favor of the unified outdoor scale,I like the totally unified scale,but i'm just afraid it might take too much work. But,if the developers say then can do it,i'm for it. The main continent is currently too small,and I don't think blowing it up 4 or 5 times bigger will help a great deal. Also,if the main continent is made larger,inns along the main roads would be cool. Also,night and day and weather would be nice. Perhaps certain weather conditions would make it harder for players,besides adding effect. Blizzards would hurt the player,rain would slow them down,sandstorms would hurt also. Perhaps the player could even catch hypothermia from the cold,or pneumonia from the rain. The nice thing about night and day is how it could work with certain quests or map,such as a warehouse in scorn. The one with the vikings versus the pirates. A sign says the arena(the warehouse)opens at 6:00. Moving areas are very nice as well. Cost is imparative traveling with ships,especialy dragons. If the totaly unified scale were to be used,it would be cool to see the ships sailing by as you stood somewhere on the continent. Alchemy could be improved as well. Potions should be improved also,as stated before. Certain things are annoying,such as the sea or rivers being treated as walls. Perhaps to swim through these,you should have to know a skill swimming. Dipping a bottle in a stream or a fountain should create a bottle of water. The problem of bottles being hard to find could be solved by making a glassmaker's shop,or at least a table that creates glass bottles. These bottles could be filled with different liquids:water,poison,swamp lush,etc. Even have indestructable bottles that can contain lava. There should be the option of dumping the bottles,if you have no others on hand. I just really hate searching every city in crossfire to find something as common as water,and this seems like a good improvement. I think soundtrack should be things such as background sounds,like a bustling town,a river running,the splash of waves against the shore. But I guess there could be music,like certain ones in certain caves,or fighting a powerful monster,etc. Its a pretty interesting thought,but should be optional. Short movies would be nice. Such as one when fighting a powerful end boss,like Hanuk. This would be excellent for certain quests. Communicating with NPCs needs much improvement as well. Communicating with other players is good as it is,but here's a suggestion for realism. Perhaps certain characters would have better hearing ability,like they could hear what someone says from 10 speaces,while another player can only hear from 6 spaces. This would even fit in well with hiding,a thief could be caught if a player heard him. This would be useful for a totaly unified scale. Also many of the classes need to be given better benifits,the thief skills should be worth more than they are now. I mean,i never use hiding or stealing. What about singing and oratory,those skills are nearly worthless,i never use them. Btw,is it possible to move around when hiding,without being discovered? As for karate,i have suggested "karate moves". People say this will be too hard to code,but i have made suggestions. Why not make a command like this:perform lunge puch;side kick;open hand block. I think karate moves would add a lot to the fun element. Oh,and i thought of a useful thief skill,one that handles poison. The player could make poison tipped bolts and arrows,weapons with poison attacks,poisoned drinks,etc. But,the thief would have a chance of poisoning himself,stabs finger with bolt,etc. The higher his level in that field,the less chance of getting poisoned. I think players should have reputation. A player could be known for player killing,causing guards to attack him whenever he goes to scorn. Bounty hunters might even be sent after him. Shopkeepers would even refuse trade with him. But i think his reputation would be like that in only certain areas,and would only get that reputation for repeatily player killing. If he commited these crimes only in scorn,he would only be known as a murderer in scorn. Also,attacking townspeople may give him a bad rep as well. Of course,with bad reps,comes good reps. Doing good deeds would earn you a reputation as a hero. But becoming too popular can be bad. Perhaps the local king may see you as a threat(depending on the local king's personality),sending assasins on your trail. Gaining another rival king's favor may result in you becoming a traitor in one city or country. Certain reps would work differently with different people. Thieves might like fellow thieves,troublemakers would fear or hate heroes. Joel Southall From joel at mamia.prninfo.com Thu May 17 15:05:20 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 18:00:58 2005 Subject: [CF-Devel] Future crossfire changes/projects Message-ID: <200105172005.QAA19502@mamia.prninfo.com> >From crossfire-devel-admin@lists.real-time.com Thu May 17 15:52:53 2001 Return-Path: Received: from sprite.real-time.com (IDENT:y3iib8Qx9xeI3fXWxYy2EZafh3MBLwix@lists.real-time.com [208.20.202.12]) by mamia.prninfo.com (8.9.3/8.9.3) with ESMTP id PAA19457; Thu, 17 May 2001 15:52:50 -0400 Received: from sprite.real-time.com (IDENT:xCVU4+w66oXZES1CVqgjQxhI/vXFeXCM@localhost.localdomain [127.0.0.1]) by sprite.real-time.com (8.11.1/8.11.1) with ESMTP id f4I0FAK02815; Thu, 17 May 2001 19:15:10 -0500 Received: from mamia.prninfo.com ([207.113.11.235]) by sprite.real-time.com (8.11.1/8.11.1) with ESMTP id f4I0EPK02794 for ; Thu, 17 May 2001 19:14:25 -0500 Received: (from joel@localhost) by mamia.prninfo.com (8.9.3/8.9.3) id PAA19430; Thu, 17 May 2001 15:51:39 -0400 From: Joel South Message-Id: <200105171951.PAA19430@mamia.prninfo.com> Subject: Re: [CF-Devel] Future crossfire changes/projects To: mwedel@scruz.net (Mark Wedel) Cc: crossfire-devel@lists.real-time.com In-Reply-To: <3B022459.8BF15CA1@scruz.net> from "Mark Wedel" at May 15, 2001 11:55:21 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: crossfire-devel-admin@lists.real-time.com Errors-To: crossfire-devel-admin@lists.real-time.com X-BeenThere: crossfire-devel@lists.real-time.com X-Mailman-Version: 2.0.3 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Crossfire CVS Commit Mailing List List-Unsubscribe: , List-Archive: Date: Thu, 17 May 2001 15:51:39 -0400 (EDT) I am in favor of the unified outdoor scale,I like the totally unified scale,but i'm just afraid it might take too much work. But,if the developers say then can do it,i'm for it. The main continent is currently too small,and I don't think blowing it up 4 or 5 times bigger will help a great deal. Also,if the main continent is made larger,inns along the main roads would be cool. Also,night and day and weather would be nice. Perhaps certain weather conditions would make it harder for players,besides adding effect. Blizzards would hurt the player,rain would slow them down,sandstorms would hurt also. Perhaps the player could even catch hypothermia from the cold,or pneumonia from the rain. The nice thing about night and day is how it could work with certain quests or map,such as a warehouse in scorn. The one with the vikings versus the pirates. A sign says the arena(the warehouse)opens at 6:00. Moving areas are very nice as well. Cost is imparative traveling with ships,especialy dragons. If the totaly unified scale were to be used,it would be cool to see the ships sailing by as you stood somewhere on the continent. Alchemy could be improved as well. Potions should be improved also,as stated before. Certain things are annoying,such as the sea or rivers being treated as walls. Perhaps to swim through these,you should have to know a skill swimming. Dipping a bottle in a stream or a fountain should create a bottle of water. The problem of bottles being hard to find could be solved by making a glassmaker's shop,or at least a table that creates glass bottles. These bottles could be filled with different liquids:water,poison,swamp lush,etc. Even have indestructable bottles that can contain lava. There should be the option of dumping the bottles,if you have no others on hand. I just really hate searching every city in crossfire to find something as common as water,and this seems like a good improvement. I think soundtrack should be things such as background sounds,like a bustling town,a river running,the splash of waves against the shore. But I guess there could be music,like certain ones in certain caves,or fighting a powerful monster,etc. Its a pretty interesting thought,but should be optional. Short movies would be nice. Such as one when fighting a powerful end boss,like Hanuk. This would be excellent for certain quests. Communicating with NPCs needs much improvement as well. Communicating with other players is good as it is,but here's a suggestion for realism. Perhaps certain characters would have better hearing ability,like they could hear what someone says from 10 speaces,while another player can only hear from 6 spaces. This would even fit in well with hiding,a thief could be caught if a player heard him. This would be useful for a totaly unified scale. Also many of the classes need to be given better benifits,the thief skills should be worth more than they are now. I mean,i never use hiding or stealing. What about singing and oratory,those skills are nearly worthless,i never use them. Btw,is it possible to move around when hiding,without being discovered? As for karate,i have suggested "karate moves". People say this will be too hard to code,but i have made suggestions. Why not make a command like this:perform lunge puch;side kick;open hand block. I think karate moves would add a lot to the fun element. Oh,and i thought of a useful thief skill,one that handles poison. The player could make poison tipped bolts and arrows,weapons with poison attacks,poisoned drinks,etc. But,the thief would have a chance of poisoning himself,stabs finger with bolt,etc. The higher his level in that field,the less chance of getting poisoned. I think players should have reputation. A player could be known for player killing,causing guards to attack him whenever he goes to scorn. Bounty hunters might even be sent after him. Shopkeepers would even refuse trade with him. But i think his reputation would be like that in only certain areas,and would only get that reputation for repeatily player killing. If he commited these crimes only in scorn,he would only be known as a murderer in scorn. Also,attacking townspeople may give him a bad rep as well. Of course,with bad reps,comes good reps. Doing good deeds would earn you a reputation as a hero. But becoming too popular can be bad. Perhaps the local king may see you as a threat(depending on the local king's personality),sending assasins on your trail. Gaining another rival king's favor may result in you becoming a traitor in one city or country. Certain reps would work differently with different people. Thieves might like fellow thieves,troublemakers would fear or hate heroes. Joel Southall _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From tanner at real-time.com Thu May 17 19:57:08 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:58 2005 Subject: [CF-Devel] gcc-2.96 ? Message-ID: <20010517195708.E6160@real-time.com> Any bad(?) things with gcc-2.96? I was talking on #mklinux about how gdb on ppc-linux doesn't work with signals very well (it core dumps!) and they said to try upgrading to 2.96 and gdb-5.0. Wanted to get cf developer opinion though. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From mwedel at scruznet.com Thu May 17 21:03:49 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:58 2005 Subject: Performance, was RE: [CF-Devel] Future of Crossfire In-Reply-To: <3B0A46FA@MailAndNews.com> Message-ID: On Thu, 17 May 2001, Yann Chachkoff wrote: > Agree. Idea: the client connects to the server, _may_ (not _must_) request a > list of pictures available with last update dates; if the client pictures are > not up-to-date, it may then be able to open a connection to a 'picture server' > to download the pictures needed. This is in fact a simple extension of the > actual image caching system where the pictures are downloaded only before > starting the game and requested from a separate picture server (the picture > server may be a specific one or simply an ftp server). To some extent, this can already be done - The client can use its own local set of images. Currently, there is no way for the client to get a complete list of images the server is using, but this should not be hard to do. The idea of separating the picture server from the crossfire server has been discussed before. These are the problems: 1) Reliability - if picture server is down and you need an image, your hosed. 2) Simplicity - setting up a new crossfire server now requires the potential that you add new images to the picture server. This now requires authentication of some sort. 3) Client would need a bit of additional code to handle this (not insurtmountable). That said, perhaps forcing users of the client to use local images more may be relevant - the code is all there, and there isn't a big reason not to do this. > That's true, but you forget some clear facts: the fact that some quests are > simply unplayable because the server is unable to run fast enough to sustain > them (Didn't you made some comments about it not so long ago ?). The most > important thing for new players is certainly how the game looks like, but if > they discover that their characters die because of server slowliness, they'll > quickly go away. I don't think bringing lots of new players just to see them > go away a few time later is really a good idea. Certainly, high performance > server alone is not enough, but it is necessary. The big problem right now is lots of spell objects. I plan to look at that problem. Not all quests suffer from that problem. Latency will always be a problem. There would be ways to improve performance in some regards. But some of the problem is the relatively high speed of crossfire - victory over death may be a difference of just a second or two, and most combats are very quick, so if your caught flat footed for even an instant, it can be toast. You don't have much time to move off from that bolt spell being cast on your before your dead. From tanner at real-time.com Thu May 17 21:13:57 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:58 2005 Subject: Performance, was RE: [CF-Devel] Future of Crossfire In-Reply-To: ; from mwedel@scruznet.com on Thu, May 17, 2001 at 07:03:49PM -0700 References: <3B0A46FA@MailAndNews.com> Message-ID: <20010517211357.G6160@real-time.com> Quoting Mark Wedel (mwedel@scruznet.com): > On Thu, 17 May 2001, Yann Chachkoff wrote: > > Agree. Idea: the client connects to the server, _may_ (not _must_) request a > > list of pictures available with last update dates; if the client pictures > The idea of separating the picture server from the crossfire server has been > discussed before. These are the problems: > > 1) Reliability - if picture server is down and you need an image, your hosed. Easily solved. Simpliest solution is have the picture servers in a round-robin DNS setup. Just need to make sure the client, timesout quickly and tries the next IP. A more complex setting, but vastly more reliable, would be using Linux Virtual Server (LVS) (http://www.linuxvirtualserver.org/) with multiple directors using Virtual Servers via IP Tunneling (VS-TUN). > 2) Simplicity - setting up a new crossfire server now requires the potential > that you add new images to the picture server. This now requires > authentication of some sort. Maybe use a DNS analogy here. Couldn't the client look in its local cache for the image. If not, ask the server it's connected to, if not forward the request the picture server? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From joel at mamia.prninfo.com Thu May 17 17:51:54 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 18:00:58 2005 Subject: [CF-Devel] Trouble with the adventurer's guild Message-ID: <200105172251.SAA19912@mamia.prninfo.com> The adventurer's guild has been seen as a problem,it is too easy for low level characters to gain access to its treasure room. On MiDS server,i would find very rare and valuable goods. A player would never have to worry about money again,the guild used to have about 300000 platinum,not to mention the countless gems. Of course,MiDS removed all items having value over 2000 platinum. Unfortunatly,it is nearly worthless to high level players. I propose this. Why don't we make it harder to gain membership to the guild. The dread with the key is clearly not hard enough,why not make the player fight a chinese dragon,a red dragon,and an electric dragon. Then maybe a guild in scorn for newbies could be made. And guilds in other cities could be made.(this would be imparitive if the continent was enlarged to the unified scale and players started in other cities) Joel Southall From highway at cstone.net Thu May 17 22:23:46 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:00:58 2005 Subject: [CF-Devel] Future crossfire changes/projects References: <3B022459.8BF15CA1@scruz.net> <01051609570303.01585@Terminus.magellan.fpms.ac.be> <3B037ED2.A4C00DB3@scruz.net> Message-ID: <3B0495C2.A86B68CF@cstone.net> Mark Wedel wrote: > The day/night is one of those things that may be nice to add. Crossfire (IMO) > would operate at a faster timescale (not in sync with earth), so that even if > you always played at night, the time in crossfire would vary. That's a great idea in my opinion. I've seen that in one RPG on the Dreamcast (Shenmue, I want to say) and I think it was pretty cool. It'd also encourage players to save more, especially if the characters got fatigues if they didn't "sleep". Then again, how would you handle sleep? I like to play all day at work (hey, I work for the state) and would hate it if I had to not play for a while so my character rested. SeanMike From highway at cstone.net Thu May 17 22:28:32 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:00:58 2005 Subject: [CF-Devel] Future crossfire changes/projects References: <3B022459.8BF15CA1@scruz.net> <01051609570303.01585@Terminus.magellan.fpms.ac.be> Message-ID: <3B0496E0.6A4D3E3E@cstone.net> gros wrote: > Change: Isometric graphics ('Diablo-like' point of view). > -Details: The current Crossfire graphics may be nice, there are still many > players that simply find them 'outdated'. Isometric graphics may help > Crossfire to be up-to-date with today's game standards. > -Pros: May improve interest in the game, no longer seen as 'outdated'. No > major changes in the server are needed. > -Cons: The entire tileset would have to be redrawn. New client graphics > handling needed to support isometric view. As others have said, I don't think this is necessarily an improvement. A number of us who play it here at UVA (as you may have gathered, it has quite the cult following in our ITC department) would be turned off by changes like that. Our players bitched enough when we upgraded to .98 from .95.1. They didn't want disease and all that. Upgrades that drastically altered the look/feel of the game would probably keep us from upgrading the server, or even find something different to waste taxpayer's dollars with... SeanMike From mwedel at scruz.net Thu May 17 23:29:48 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:58 2005 Subject: [CF-Devel] gcc-2.96 ? References: <20010517195708.E6160@real-time.com> Message-ID: <3B04A53C.6358B5AA@scruz.net> I've been runninngn gcc-2.96 on my linux/i86 box for a while with no noticable bad effects. From mwedel at scruz.net Thu May 17 23:39:00 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:58 2005 Subject: Performance, was RE: [CF-Devel] Future of Crossfire References: <3B0A46FA@MailAndNews.com> <20010517211357.G6160@real-time.com> Message-ID: <3B04A764.8EED41A6@scruz.net> Bob Tanner wrote: > > Easily solved. Simpliest solution is have the picture servers in a round-robin > DNS setup. Just need to make sure the client, timesout quickly and tries the > next IP. > > A more complex setting, but vastly more reliable, would be using Linux Virtual > Server (LVS) (http://www.linuxvirtualserver.org/) with multiple directors using > Virtual Servers via IP Tunneling (VS-TUN). To me, thats the biggest issue - time. Even with just caching, players saying that seeing the ? for a few ticks is potentially too long - that could be a nasty monster that kills you before you know what it is. I only see the addition of seperate picture servers making this longer (have to dns lookup server, connect to it, then get the image). > > > 2) Simplicity - setting up a new crossfire server now requires the potential > > that you add new images to the picture server. This now requires > > authentication of some sort. > > Maybe use a DNS analogy here. Couldn't the client look in its local cache for > the image. If not, ask the server it's connected to, if not forward the request > the picture server? But given that case, the request would never get beyond the server it is connected to - in some sense, the server connected to must have the images (if it doesn't, whats the likelihood that a picture server would?) The idea of picture servers came up to reduce server load. Sending images doesn't really load the server, it loads the network. The amount of processing it takes to send an image isn't that much. Note that a seperate picture server does not help if the limitation is really the bandwidth at the client end of the connection (ie, playing at the end of an isdn or dialup modem line). A separate picture server really only helps if the crossfire server is otherwise using all of its bandwidth. In this case, a picture server only helps if it is not using the same shared connection as the crossfire server. To give a real example: If there was pictureserver.real-time.com in addition to metalforge.real-time.com, this gains no benefit over metalforge.real-time.com doing everything like it does right now. while metalforge may do 1% less work by not having to serve images, the bandwidth to/from real-time would still be the issue From mwedel at scruz.net Thu May 17 23:46:14 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:58 2005 Subject: [CF-Devel] Has anyone had time to analyze the scripting patch submitted? References: <200105171919.f4HJJKH29887@tonks.EECS.Berkeley.EDU> Message-ID: <3B04A916.A63E5CA@scruz.net> Peter Mardahl wrote: > > Hello, > > I haven't had time to look at the scripting patch which has > already been submitted. > > I'm not so sure I approve of a scheme-like syntax for a > scripting language for crossfire, yet I don't want to dismiss > it out of hand out of prejudice. > > Has anyone tried the patch and evaluated it yet? We must > not let it languish or be ignored--I wish I had the time just > now to look at it myself. I looked at the source/sample files (didn't actually install it.). Given that, these are its shortcomings: 1) scheme like syntax (may or may noot be a shortcoming depending on your like of it) 2) improperly written scripts could crash the entire process. 3) each npc action requires a seperate script file. So one complex npc may have half a dozen different script files. 4) Require guile to be installed on system (ie, more software dependencies) good things: 1) Appears to have support for lots of different actions, so fairly powerful 2) its real life code, vs something on the drawing board. my personal opinion is that as long as points 2 & 3 exist in the shortcomings, its not useful. #2 is a major one, but #3 just in terms of maintainabilty - I would much rather have something line a msgscript .... endscript in the object, and just have a big buffer in the object that contains the script. When something is done, it goes look at this buffer. This way, the script and object using the script stay connected. Note this is just from looking over the code and docs. If I'm wrong on any of this, I apologize to the author. > > PeterM > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Thu May 17 23:50:59 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:58 2005 Subject: [CF-Devel] Future crossfire changes/projects References: <3B022459.8BF15CA1@scruz.net> <01051609570303.01585@Terminus.magellan.fpms.ac.be> <3B037ED2.A4C00DB3@scruz.net> <3B0495C2.A86B68CF@cstone.net> Message-ID: <3B04AA33.6D632149@scruz.net> Sean Michael Whipkey wrote: > It'd also encourage players to save more, especially if the characters > got fatigues if they didn't "sleep". Then again, how would you handle > sleep? I like to play all day at work (hey, I work for the state) and > would hate it if I had to not play for a while so my character rested. I think that is the biggest problem. The fact that the game is real-time means that you just can't spin the clock forward to the next morning when the characters sleep. Now there could be advantages to resting - ie, if your sleeping in a bed, perhaps you don't see your surroundings, but your hp and sp go up faster. OTOH, in many cases, it goes up so quickly that it probably would not be worth finding a place to sleep. Now you could do something a little different but related - certain races get penalties/bonuses depending on time of day. wraiths would not like to be outdoors during the day, so have some negative. This could get related to other factors - dwarves would just not like to be outdoors, but would like to be underground, elves the reverse of that, etc. From mwedel at scruz.net Fri May 18 00:00:29 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:00:58 2005 Subject: [CF-Devel] Future crossfire changes/projects References: Message-ID: <3B04AC6D.AC7172BF@scruz.net> Mike Ponicki wrote: > Is there a way we could simplify the handling of objects, like how you > said commercial games would handle it, or would that be really tough to > implement? It'd be fairly tough. The biggest savings would be to not send naming information every time. In some sense, have a shorthand like '125 = arrow/arrows', 432 = ruby/rubies, etc. This is basically what is done for images (they are referenced by number, not name unless the client is caching, in which case the name is only sent once). This is also safer than sending object information - (ie, object 125 is an arrow object, and 126 is an arrow of death, etc). The problem is there is no record of all the different names with assigned numbers. This could perhaps be created without too much difficulty. The other complication is that object names are much more mutable than face information. You have +1 arrows, helms of gorokh, etc. Realistically, these are probably significantly rarer such that just reducing name for normal objects would be a pretty big savings. the biggest thing would be to try and minimize the number of objects sent - it just starts to get pretty costly. The big problem is typically big piles after you kill some monster - the small individual treasure are usually noot a big deal. From yann.chachkoff at MailAndNews.com Fri May 18 01:26:31 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:00:58 2005 Subject: Why Scheme? (Was RE: [CF-Devel] Has anyone had time to analyze the scripting patch submitted?) Message-ID: <3B154028@MailAndNews.com> >Hello, > > I haven't had time to look at the scripting patch which has >already been submitted. > > I'm not so sure I approve of a scheme-like syntax for a >scripting language for crossfire, yet I don't want to dismiss >it out of hand out of prejudice. I think I must explain here why I have chosen Scheme as scripting language. When I began creating the scripting extensions, I quickly realized that building a new language from scratch would cost me too much time, so I decided to use a generic embeddable scripting tool. That tool would have to follow some basic rules: - Should be able to run under both Unix and Windows systems; - Should be easy to integrate into Crossfire; - Should not cost too much CPU time; - Should be somewhere a 'standard' language; I first tried Python, but I encountered several problems; Python may be easy to use on the Python-side, but it is definitely not on the C side. More, trying to detect/configure the Python interpreter with autoconf was a hard thing to do. Since I found no Python expert, I had to put it aside and try another one. Then I tried ScriptBasic. Easy to learn, but so ugly documented and difficult to compile on various platform that I had to forget it too. And I finally encoutered Guile. I had never seen a Scheme code before, but what attracted me was the portability of the interpreter. After reading some docs, I decided to go on. After some hours of use, I realized that the Scheme syntax was not uglier than Python or Basic, just different. Since some other big OpenSource projects (FreeCraft or Gimp for example) were also using Scheme, I never seen this choice as a problem. What I want now to know is: 1 - Must I continue in that way, or must I change and switch to another language ? 2 - If I have to change, which language should I use ? 3 - In any case, are there some volunteers around here to help ? (there are still many things to do: bugfixing, Windows porting/testing, ...) There has been some discussions about this not so long about, but no clear answer came out. Anyway, until the final decision, I'll continue to support scripting extensions (A new revision will shortly come out). Chachkoff Y. ------------------------------------------------------------ Get your FREE web-based e-mail and newsgroup access at: http://MailAndNews.com Create a new mailbox, or access your existing IMAP4 or POP3 mailbox from anywhere with just a web browser. ------------------------------------------------------------ From dnh at hawthorn.csse.monash.edu.au Fri May 18 01:34:29 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:59 2005 Subject: [CF-Devel] Linux RPG Web Ring In-Reply-To: Message-ID: Please do this Rick, dnh On Thu, 17 May 2001, Rick Tanner wrote: > > I was contacted to sign up Crossfire on the Linux RPG web ring. > > Anyone have any comments or opinions on doing this? > > I will take care of the signup process, etc. if we decide to go ahead with > this. > > - Rick Tanner > leaf@real-time.com > > > ---------- Forwarded message ---------- > Date: Thu, 17 May 2001 04:48:25 -0500 > From: "al_beraud@yahoo.fr" > > I propose you to join a "Linux RPG Web Ring" that I am putting up. > At the time being, there is only my own project in it: Deity. You can find it at: > > http://deity.tuxfamily.org > > I want that ring to be a gathering of all the RPG projects on Linux. > > Best regards, > > Alexandre BERAUD > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From yann.chachkoff at mailandnews.com Fri May 18 07:49:51 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:00:59 2005 Subject: [CF-Devel] Crossfire Scripting Extension patch, version 1.0.0b7 Message-ID: <01051808495100.02261@Terminus.magellan.fpms.ac.be> This is the latest version of the Crossfire Scripting extensions for Crossfire 1.0.0. You need Guile-1.4 installed on your system. It is yet unknown if crossfire does compile under Windows with those extensions. Changes since previous version: - Minor bug fixes; - Removed some crappy things that had nothing to do with scripting in the maps provided; - Added support for day/night in the City of Scorn (See the beholder in the top-right corner of the map). - Added 'cast-ability' function. Consult the README_SCRIPT file for more details. If you have any question, suggestion, bug report, please send it to me so I can improve the code. Note: The patch also contains the latest revision of the 'Town Portal' spell by Tchize (because I used the same server to test it). Chachkoff Y. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-1.0.0b7.bz2 Type: application/x-bzip2 Size: 48229 bytes Desc: Scripting Extension patch Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010518/ce310576/patch-1.0.0b7.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: scriptfire-maps-1.0.0b7.tar.bz2 Type: application/x-bzip2 Size: 15496 bytes Desc: Scripting Extension test maps Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010518/ce310576/scriptfire-maps-1.0.0b7.tar.bin From yann.chachkoff at mailandnews.com Fri May 18 08:51:47 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:00:59 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: References: Message-ID: <01051809514701.02261@Terminus.magellan.fpms.ac.be> > Documentation: > > A a new developer in the adventure , the big drawback i can notice in CF is > the lack of programming documentation. > > No conceptual doc , a few protocol doc, no file formats doc etc... > > I think it's really disapointing > I think the problem is not 'too less docs' but 'badly organized docs'. The source code itself is well commented, but it is sometimes hard to find 'where is ... done'. > A little wish : Why not a C++ rewrite/remodeling ? I think object > modelization would be more appropriate (and clean) for the purpose of the > server.It could permit a much better distribution of the work as well. > (And with a good conceptual doc, this should become an obvious choice i > think) > > I think 2.0 can be a new dev branch with OO design . What daya think about > it ? There was some discussion about it one year ago (The question was to decide if splitting the game engine and the rules was a good idea). Although I think an object-oriented language like C++ or Java should be better for Crossfire, porting the actual code would need massive rewriting, not only because each function needs to be translated to another 'dialect' (not a big problem for C++, a bit harder for Java), but also because some basics would need a complete rethinking. Anyway, if someone gets enough time and will... Chachkoff Y. From yann.chachkoff at mailandnews.com Fri May 18 09:04:12 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:00:59 2005 Subject: [CF-Devel] Has anyone had time to analyze the scripting patch submitted? In-Reply-To: <3B04A916.A63E5CA@scruz.net> References: <200105171919.f4HJJKH29887@tonks.EECS.Berkeley.EDU> <3B04A916.A63E5CA@scruz.net> Message-ID: <01051810041202.02261@Terminus.magellan.fpms.ac.be> > > I looked at the source/sample files (didn't actually install it.). Given > that, these are its shortcomings: > > 1) scheme like syntax (may or may noot be a shortcoming depending on your > like of it) Nothing more to say here. > 2) improperly written scripts could crash the entire process. I am currently writing on that part of code. You may expect correct error handling in a couple of days. It took so long to implement error handling because it is the less documented feature of Guile so it took more time to find a correct solution. > 3) each npc action requires a seperate script file. So one complex npc may > have half a dozen different > script files. Yes. I didn't see this as a problem, but I think you are right. I'll then implement a script...endscript tag to correct this (should not be a big problem because it would be very similar to the msg...endmsg structure). > 4) Require guile to be installed on system (ie, more software dependencies) > That's the price to pay if you don't want to rewrite a scripting language from scratch. > good things: > 1) Appears to have support for lots of different actions, so fairly > powerful 2) its real life code, vs something on the drawing board. > > my personal opinion is that as long as points 2 & 3 exist in the > shortcomings, its not useful. #2 is a major one, but #3 just in terms of > maintainabilty - I would much rather have something line a msgscript .... > endscript in the object, and just have a big buffer in the object that > contains the script. When something is done, it goes look at this buffer. > This way, the script and object using the script stay connected. > > Note this is just from looking over the code and docs. If I'm wrong on > any of this, I apologize to the author. > Do not apologize, you are 100% right. I put the patch on the list to get feedback like this to know what I should do next to improve it, so I thank your very much for giving your opinion. Chachkoff Y. From reeve at ductape.net Fri May 18 08:40:50 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:00:59 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B04AA33.6D632149@scruz.net> References: <3B022459.8BF15CA1@scruz.net> <01051609570303.01585@Terminus.magellan.fpms.ac.be> <3B037ED2.A4C00DB3@scruz.net> <3B0495C2.A86B68CF@cstone.net> <3B04AA33.6D632149@scruz.net> Message-ID: <990193251.8524.0.camel@terra> On 17 May 2001 21:50:59 -0700, Mark Wedel wrote: > Sean Michael Whipkey wrote: > > It'd also encourage players to save more, especially if the characters > > got fatigues if they didn't "sleep". Then again, how would you handle > > sleep? I like to play all day at work (hey, I work for the state) and > > would hate it if I had to not play for a while so my character rested. > > I think that is the biggest problem. > The fact that the game is real-time means that you just can't spin the clock > forward to the next morning when the characters sleep. > > Now there could be advantages to resting - ie, if your sleeping in a bed, > perhaps you don't see your surroundings, but your hp and sp go up faster. OTOH, > in many cases, it goes up so quickly that it probably would not be worth finding > a place to sleep. > > Now you could do something a little different but related - certain races get > penalties/bonuses depending on time of day. wraiths would not like to be > outdoors during the day, so have some negative. This could get related to other > factors - dwarves would just not like to be outdoors, but would like to be > underground, elves the reverse of that, etc. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel That would be great! You could also have area changes (faster food consuption if you're in the desert, etc) I think this would be a wonderful improvement. -- -- Reeve the cat ----BEGIN FORTUNE---- Men use thought only to justify their wrong doings, and speech only to conceal their thoughts. -- Voltaire ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From pc-crossfire at crowcastle.net Fri May 18 12:09:34 2001 From: pc-crossfire at crowcastle.net (pc-crossfire@crowcastle.net) Date: Thu Jan 13 18:00:59 2005 Subject: [CF-Devel] Performance Message-ID: <200105181709.NAA22734@lul1150.lss.emc.com> I haven't looked at the current protocol, so I don't know how much work it would be, but here are some thoughts for how we should do it to maximize efficiency: Messages should be binary, not ASCII. It makes reading the stream more difficult, but saves lots of bandwidth. Each message should start with a 32-bit message type code. We can then define a range of messages that are frequent messages. For example, there could be message types that indicate the presence of a spell effect on the same square as the player. Hence, if 7 fears, 3 icestorms, and 9 slows show up on your square, you only have to receive 19 words. So we can define a standard set of objects that can be sent with just a single code. Special objects will take multi-part messages to send name and weight information, but that's not a problem as long as we get all the spell effects and other really common items. --PC From leaf at real-time.com Fri May 18 12:54:44 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:00:59 2005 Subject: [CF-Devel] Graphic Artist Message-ID: Could some who has a better understanding of the graphics (requirements, limitations, etc.) contact Derek at the address listed below and get him involved in Crossfire? Thanks. - Rick Tanner leaf@real-time.com ---------- Forwarded message ---------- Date: Fri, 18 May 2001 00:08:55 -0500 From: Derek Wilson I was looking at your graphics, and they could definitely be improved upon. I had made a game very similar to this one a few years back, and I would love to help fix up your graphics, as I did mine. From tanner at real-time.com Fri May 18 13:43:02 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:59 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <01051809514701.02261@Terminus.magellan.fpms.ac.be>; from yann.chachkoff@mailandnews.com on Fri, May 18, 2001 at 09:51:47AM -0400 References: <01051809514701.02261@Terminus.magellan.fpms.ac.be> Message-ID: <20010518134302.Q6160@real-time.com> Quoting gros (yann.chachkoff@mailandnews.com): > There was some discussion about it one year ago (The question was to decide > if splitting the game engine and the rules was a good idea). Although I think > an object-oriented language like C++ or Java should be better for Crossfire, > porting the actual code would need massive rewriting, not only because each > function needs to be translated to another 'dialect' (not a big problem for > C++, a bit harder for Java), but also because some basics would need a > complete rethinking. Anyway, if someone gets enough time and will... Let me ask this, do we have developers that "do" OO programming? Do the current developers "do" C++ or Java? I personally, like Java, but I mostly do backend web development. Could Java really be considered a valid solution for the server? Since Linux got a HotSpot capable jvm, things are much better, but before that writing Java code for linux was, "Write once, crawl everywhere". -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From mwedel at scruznet.com Fri May 18 16:13:21 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:00:59 2005 Subject: [CF-Devel] Graphics & Derivative version Message-ID: Tyler Van Gorder brought up to me that the appears to be a somewhat derived version of crossfire out there at http://www.cabochon.com/. Since its in java, and a quick glance makes it appear a bit different, I don't personally think there is much to be done about it under the GPL (I've never been one for much on look and feel, and to me that is probably the biggest aspect that we could complain about). But unrelated to that - take a look at the screenshots. To be, that shows that even with standard tile based drawing and placement based on objects, the graphics can look really good. It appears their tile size is also 32x32 or so. It also appears that the viewport size is 13x13 (crossfire is currently 11x11) I would personally think that it would be easier to get near that form of graphics by taking what we currently have and improving it vs going to a new form (isomorphic). I think some of the screenshots also provide good hints on making things look better - ie, shadowing, 45 degree angles for many of the terrain types to smooth things out, and more variations (bunch of types of trees, flowers and lighter shades in the grass, etc). My other thought on graphics: Good graphics will help a little bit in the first glance 'hey this looks cool' category of gamers. But what will really keep the gamers playing is the gameplay actually being good. The prettiest game in the world won't last long if the gameplay behind it sucks. Personally, I think crossfire has pretty good gameplay, and what that will typically mean is that once you can attract the player, they will stick around (and probably tell their friends about this cool game). Muds typically don't have any cool graphics, yet they have quite a following. I guess my main point being - while increasing graphic quality should continue, I think it would be better to spend the effort making the gameplay better than switching to isomorphic graphics. I've also lived through two big shifts in graphis (xbm -> xpm and now xpm -> png), and I've seen how long it takes and how much effort it takes to make that change. There are like 2500+ images out there - this is not a trivial process. Process takes somewhere between several months to years. From tanner at real-time.com Fri May 18 16:26:32 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:00:59 2005 Subject: [CF-Devel] Graphics & Derivative version In-Reply-To: ; from mwedel@scruznet.com on Fri, May 18, 2001 at 02:13:21PM -0700 References: Message-ID: <20010518162632.A6160@real-time.com> Quoting Mark Wedel (mwedel@scruznet.com): > Tyler Van Gorder brought up to me that the appears to be a somewhat derived > version of crossfire out there at http://www.cabochon.com/. Since its in > java, and a quick glance makes it appear a bit different, I don't personally > think there is much to be done about it under the GPL (I've never been > one for much on look and feel, and to me that is probably the biggest Screenshots LOOK like cfclient! :-) The Map Editor looks great! But my personal xp with swing in java is that is sucks. :-) But I digress. If this guy can make a world editor in java/swing, it at least let me know that a new crossedit could be done in java. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From dnh at hawthorn.csse.monash.edu.au Sat May 19 07:16:34 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:59 2005 Subject: [CF-Devel] Hello there Message-ID: Hi, I am a crossfire developer and I recently recieved a forward of your message to rick tanner. I have done some work on the graphics and am most interested to see you involved in anyway you can. I assume you are the Spider that was involved in realmz/exile3... I have always been a fan of realmz (I bought all the scenarios) and in particular loved the graphics in that game. I have tried to create a set somewhat similar in style to that of realmz. It can be found on crossfire.csua.berkeley.edu.au if you can run a client. Basically, each tile is a 32 x 32 png, but we also support multitiled monsters (similar to realmz). All work is GPL'd and we hope any work done on crossfire will remain on the GPL system. If you are willing in anyway (be it advice or graphics..) please respond to this mail, and I will try to answer any questions you have or connect to you to people who can. If you aren't really interested please just reply so i might know you did recieve this mail, Thanks heaps from the Crossfire development team dnh From dnh at hawthorn.csse.monash.edu.au Sat May 19 07:17:11 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:00:59 2005 Subject: [CF-Devel] Graphic Artist In-Reply-To: Message-ID: Okay, i have sent a reply.. it is cc'd to this list. I do hope I am thinking of the right guy =). /me glances at Cybersoft... dnh On Fri, 18 May 2001, Rick Tanner wrote: > > Could some who has a better understanding of the graphics (requirements, > limitations, etc.) contact Derek at the address listed below and get him > involved in Crossfire? > > Thanks. > > - Rick Tanner > leaf@real-time.com > > > ---------- Forwarded message ---------- > Date: Fri, 18 May 2001 00:08:55 -0500 > From: Derek Wilson > > I was looking at your graphics, and they could definitely be improved upon. > I had made a game very similar to this one a few years back, and I would > love to help fix up your graphics, as I did mine. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From adama at bright.net Sat May 19 11:56:48 2001 From: adama at bright.net (Adam Ashenfelter) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] An Idea for crossfire Message-ID: <3B06A5D0.7C95A9D2@bright.net> I havent developed for crossfire, or posted on this list before. I have a couple ideas, but I thought this one might be the most interesting I was thinking the outdoor epic sized map could be generated procedurally. The map would be broken up into x by x sections that would be tiled together to give the illusion of a seamless outdoor map. When a section first comes into view, a perlin noise function(using global x,y coordinates as seeds) would be used to determine if tiles are land tiles, or water tiles. Then, another function would be run to determine if the land tiles contain any foilage. A third function would be run that determinse if the land tiles contain certain degree's of mountains terrain. Then a normal map file could be read in. If the map file contains a floor tile for a cell, that tile replaces the generated tile, any non floor objects are placed on top. Pros: A huge fairly interesting map can be created very quickly, then tweaked by map designers to add more interesting features. Takes up very little space. Cons: Generating map may take to much server time, and cause game pauses. Designers might want more control overall on the map. More info on Perlin noise is available at the following URL. http://freespace.virgin.net/hugo.elias/models/m_perlin.htm I'll try to write a sample program that just creates map files if anybody is interested. Thanks Adam Ashenfelter Sorry If this is a resend again. From dnh at hawthorn.csse.monash.edu.au Sat May 19 19:58:06 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] An Idea for crossfire In-Reply-To: <3B06A5D0.7C95A9D2@bright.net> Message-ID: On Sat, 19 May 2001, Adam Ashenfelter wrote: > I havent developed for crossfire, or posted on this list before. I > have a couple ideas, but I thought this one might be the most > interesting > > I was thinking the outdoor epic sized map could be generated > procedurally. The map would be broken up into x by x sections that > would be tiled together to give the illusion of a seamless outdoor map. Lol, this is actually what crossfire's world maps already are =) dnh From joel at mamia.prninfo.com Sat May 19 16:11:54 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] An Idea for crossfire In-Reply-To: from "dnh" at May 20, 2001 10:58:06 AM Message-ID: <200105192111.RAA25373@mamia.prninfo.com> > > > > On Sat, 19 May 2001, Adam Ashenfelter wrote: > > > I havent developed for crossfire, or posted on this list before. I > > have a couple ideas, but I thought this one might be the most > > interesting > > > > I was thinking the outdoor epic sized map could be generated > > procedurally. The map would be broken up into x by x sections that > > would be tiled together to give the illusion of a seamless outdoor map. > > Lol, this is actually what crossfire's world maps already are =) > > dnh > Yeah,but his idea may save some time on making a totally unified scale or unified scale. I think his idea is pretty good. Joel Southall From dnh at hawthorn.csse.monash.edu.au Sat May 19 21:35:59 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] SERIOUS problems with anim/mina Message-ID: I have made a massive new monster called the 'Dark Gryphon'. it is a 3 x 3 animal with physical attack that moves very fast. My problem is this, when I run crossfire frames 171 and 111 throught to 174 and 114 + 371 and 311 to 374 and 314 are not animating. All the other tiles are updating properly but these ones seem to remain tile 111. There is no easy way for me to explain this, and I am considering putting what I have done in (all the images are finished as is the .arc). It isn't working but I can't see ANY error in either the images or the .arc file. Anyone got any ideas? I have noticed some problems with the animation code in the past but I think I may have hit something major here. There is an aweful lot of work behind this monster and I would like to see it get in (as I hope do others...). A sample of the monster can be found at: http://mids.student.utwente.nl/~dnh/monsters/gryphons/gryphon_black.111.png dnh ps. If I leave it with only one facing it works perfectly well, its only the two facing version that is screwed.. perhaps I should put all the images, but just have one facing in the .arc so people can test for themselves but the image will work on the servers? From dnh at hawthorn.csse.monash.edu.au Sat May 19 21:49:46 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] SERIOUS problems with anim/mina, follow up In-Reply-To: Message-ID: With some fiddling with the x and y stuff I have fixed a bad redraw problem, but still the 1?? and 3?? frames are broken. I have found that they are out of sync. Basically they seem to be running at half or so the animation speed of the rest of the monster, thus they kind of phase in and out of being right. It is as if gryphon and gryphon3 do not have the same anim_speed as the rest of the objects. I don't understand it! there isn't any reference to anim_speed in any of the objects, I am going to try and add some and see what happens =). dnh From dnh at hawthorn.csse.monash.edu.au Sun May 20 01:39:35 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] Crossedit playing up Message-ID: Crossedit is now segfaulting while trying to load images... This is what I get: Reading bmaps from /usr/games/crossfire/share/crossfire/bmaps...done (got 3667/3668/3668) Reading faces from /usr/games/crossfire/share/crossfire/faces...done Reading animations from /usr/games/crossfire/share/crossfire/animations...done. got (732) Reading archetypes from /usr/games/crossfire/share/crossfire/archetypes... arch-pass 1... Adding friendly object Evil Master, Bonehead. done Setting up archetable...done loading treasure...done arch-pass 2...done done Warning: Cannot convert string "-*-helvetica-bold-r-*-*-12-*-*-*-*-*-*-*" to type FontStruct Warning: Cannot convert string "*-lucidatypewriter-medium-r-normal-*-12-*-*-*-*-*-*-*" to type FontStruct Warning: info: has no acces /usr/games/crossfire/share/crossfire/doc Warning: Cannot convert string "true" to type Bool Building images.........................Segmentation fault I have cvs checkout'd new arch and alternate images, and the compile seems to work, not only that but my server runs. Crossedit has been very flaky of late and now it is just diseased. We really need to find a solution to this. I had to stop making maps because of the constant crashes, now I can't even add monsters =(. dnh From dnh at hawthorn.csse.monash.edu.au Sun May 20 01:42:31 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] Also... Message-ID: crossedit is working perfectly well with -xpm and -xbm. dnh From the_real_tomble at hotmail.com Sun May 20 01:51:14 2001 From: the_real_tomble at hotmail.com (Tom Barnes-Lawrence) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] Scripting and such. Message-ID: (Pretty stupid of me, main reason I joined the list was to try to voice my own POVs on future CF ideas... and then I do something else for a few days, V1 comes out, and I miss most of this discussion :P As my inbox is now bursting with new mail, I'm leaving the list for at least a few days, so please CC any replies to me if poss) Proposed change:NPC communication/scripting,+general scripting, Details: RIGHT. When people have been talking about scripting, they have been talking (1) about scripting map effects (haven't they?) and (2) about improving the way NPC's talk. Many people have said about using Guile or similar. I think Scheme is a neat language for doing scripting, and makes much sense in something like Gimp... but IMHO is waaaay overkill for CF. So, I propose: For NPC's, a variation on what there already is, but with improvements to suit requirements (that I've seen at least), with inspiration from Flex (which I enjoy mucking about with, it's neat..) OLD NPC MESSAGE FORMAT: @trigger-word|alt-trigger-word NPC text @other-trigger-words other NPC text .... NEW FUNKY NPC MESSAGE FORMAT: (requirements line) @NPC-STATES:[CONNECT]|trigger-word|alt-trigger (optional effects line)>NEW-NPC-STATE [EFFECT] (then NPC text, followed by other messages, as above) .... EFFECT is either a number to represent a connection to push, or ANGRY,CALM,SLEEP,CHARM,RETURN, which affect the NPC. Trigger-words are all LOWER case.Anything NPC hears from player is converted to lower case to avoid stupid stuff like @hi|Hi|HI hello @hI Ah, you know the password! and so on. Example of new style NPC message follows: @INIT:hi|hello >MET Hello there! @INIT:* >MET Sorry, I didn't notice you there. What were you saying again? @!INIT:hi|hello Yes, hello, I can hear you, you know. Are you a bit slow or something? @MET:door >OPEN [2] Oh right, you want to go through? OK, sorry-here you go. @OPEN:door It's open already!!! @MET|OPEN:how are you Well, thanks. @*:[3] >ANGRY [ANGRY] Hey, what're you doing with that lever??? @*:You suck >ANGRY [ANGRY] I'll kick your arse!! (NB-INIT is the state the NPC starts off with when player meets them. states like ANGRY should be set by the NPC becoming hostile. !INIT means any-state-but-INIT, if it's not clear.) You get the idea. If player charm's NPC, then (1)any connects that NPC has in message script are removed; (2)NPC enters state PET. (3) effect [RETURN] becomes valid, and causes the NPC to return to player-like the stuff in crossfire.doc said would be done (but AFAIK never was). The entry "NEW-NPC-STATE" can also have a value ".", meaning keep the current state. That is only necessary if there is also an [EFFECT] tag, so you then have >. [EFFECT] rather than >[EFFECT] -Insisting on a new-state entry should make the parser a tiny bit faster and simpler(perhaps). ... The fact that the NPC would now contain code for magic-ear and mood floors *doesn't* make those obsolete, they still have uses. But this opens up various funky possibilities. Full scripting could prolly add more stuff, like NPC following you to a specific different map, then after 10 seconds stopping there... But I expect this format could prolly be expanded to do most of those sort of things, or they could be done as it is, with map-side machinery (more of which later...) Pro's:It's dead good. It's pretty simple, and could be done with a straight-forward lexer,IMO.It can do lots of stuff. Con's:Each NPC needs to maintain state info for each player. (each one it meets, anyway-shouldn't actually be big problem) Allowing NPCs to trigger stuff and be triggered like that could make for nasty code. Issues arise if NPC becomes follower and so moves to different map. ------ As for the other aspects of scripting: Proposed Change:More machinery (related to above) Details: Many of the things that you could want scripts for could IMO be done with better machinery types to put in the maps. (1)Counter tile: Has fields: Input-connection, Reset-at-count, Trigger-at-count, Output-connection, Count (Internal) Count starts at 0. When Input-connection is triggered, if Count equals Reset-at-count, reset Count to 0 again-otherwise, Count increments by 1. If Count now equals Trigger-at-count, push Output-connection (Trigger version should exist, plus button version that releases when count moves on). (There may be a better variation of that. I considered one that could trigger at 2 points, but that could be done with 2 counters). Actually, Something similar to this could be implemented with a creator and an altar-trigger, but I think it could *only* reset when it triggers. (2)AND gate:Fields:Input-1, Input-2, Connected. Self explanatory. I've had difficulty working out how to do a useful AND-you can make various bad ones right now. (3)Persistent connections: Hard to explain.One of my maps, I tried to get it such that if you pulled a lever, it registered on a unique item square before activating what it did, and when the map reset later, the connect would be repushed, as though that lever had just been pushed. It didn't work. I tried this: Tile 1: Tile 2: Creator:connect 1 Button: connect 2 Spikes:Connect 2 Floor: unique Floor: not unique .. So when you push connect 1, an object (in my case, a card), is placed on the button, which pushes connect 2 and raises the spikes. As the floor is unique, the card is still there when the map reloads, but the button does not raise the spikes. I would find this feature useful. (4)Game-wide states variables Think of a type like a cross between magic-mouth and marker, but when you trigger it with a connection, it writes a global variable (I *don't* mean an internal variable), that then can trigger other types, that trigger or switch on/off connections. Each would have fields: Connection, Variable, var-writer and var-trigger would have State field, (for var-writer, this is what it sets Variable to when it is triggered. for var-trigger, this is the state of Variable that triggers it) var-switch would have State-on and State-off field. (IE-var switch stays unset till it sees State-on in variable, then set till it sees State-off.). var-toggle could be a further option. Variable names should be LONG to avoid namespace problems. I could do lots with such a feature, eg-the main city I'm working on is at war with another. At certain times an invasion could occur, and it would effect any number of maps simultaneously. This feature coupled with the proposals I made for simple NPC scripting could do a lot of neat stuff. Actually, this would be able to implement request (3) above. Hurrah! (5) New button type(s) Detects living creature. Also, buttons can't detect players or monsters that fly/levitate/jump over them. Does this include setting fly-on/fly-off on them? I've tried to stick a button *and* a pedestal(to detect players) on the same tile on one of my maps, and it screws up, because it pushes items off the square, then doesn't realise they're gone. (6) Triggerable markers Just like normal marker objects here, but mark a player when they are triggered rather than when the player stands on them for a length of time. Obviously, if no player, no marking. VERY useful, messy to implement other ways. (7) Separate magic-whisper and magic-shout (or a flag on current magic-mouth) If you trigger a magic-mouth that you're not standing on, you can hear it no-matter where you are on the map. I've not found if this is the case if someone *is* standing on the tile when it is triggered. Sometimes, it is necessary/useful/neater to be able to have a magic-mouth that can be triggered, but only heard by a player that is on it or next to it. Maybe just on it, in fact. So lets say a flag on magic-mouth that enables that behaviour as an alternative, if there isn't one already. (I realise that there is already the walk-on behaviour when that flag is on. Is that heard by others too?) ---- Pros: Maps could be soooo much better... I could get some of my stuff done faster, not trying to figure out how to do complicated stuff. Cons: Some may be messy or difficult, or slow stuff down, or maybe just unnecessary/already doable some other way. -------------- Before I go, On stuff said recently: (1)-I came to CF from the roguelike games, which I still like. CF came pretty much from roguelike origins, and I'm not a fan of moving it far from those. I like Iso graphics quite a lot, but I don't much want to see them in CF. If that sounds odd, then: I like ice-cream, I also like pepper. But not together. Having said that, those actual-iso style tiles MichT linked to a few days ago looked pretty good. But I'm still sure there are other issues with rotating the view, like others said. (2) I don't like the idea of pandering to people who won't look twice at a game if it doesn't look amazingly slick. If I'm ever going to play on a server with lots of people on it, I'd rather it wasn't just people like that. I don't much want in game movies or music, I'd rather stick a CD on. But better sound in general would be good.Perhaps using MIDI for handling multiple sounds instead of music, could that work??? (3) In a recent post, Mark said CF was a fast action game, but I still see it more as a multiplayer RPG with roguelike bits. As an actual *action* game, it doesn't compare too well to something like XKobo, which excels at that- raw action and numb fingers (by stage 42). I like doing stupid RPing things in CF, like my ninja character pushing the priestess of gaea and then running off and hiding... where else could you get such deep fulfillment? ;) Anyway, *very* fast action makes little sense on nasty slow internet-you can screw up too easily that way. (4)Unrelated:Death attacks with a slaying field- I'd assumed these were like specialised deathstrikes, ie-they wouldn't hurt anything else, but would be very deadly to whatever they slay. Looking at the code, it is simply a normal death-attack to what they are slaying. Adding a slaying field to such an attack (weapon or spell) actually makes it purely weaker, and not stronger in any way. IMHO, the slaying in deathstrikes should do something like increase the effective level of the attacker, or otherwise allow an attacker some chance to kill the specified creature that is higher level. (5)On subject of deathstrikes (should be new post, but too late), ninjas should have skill "assasinate", a deathstrike that can be used if player is hidden or target is unagressive/asleep. Not implemented as a combat skill (IE, you can't select it then run at someone), but attacks target with AT_DEATH, once. More appropriate for a ninja than stealing. ---- RIGHT, THATS IT FOR NOW-I'm leaving the list for a bit, I'll prolly work on my mapset, may do more on the random-quest-maps proposal and eventually post that, but till then, BYE. Tomble (Sorry it's such big post) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From hsteoh at quickfur.yi.org Sun May 20 07:28:11 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] Map reset bug? Message-ID: <20010520082811.A17709@crystal> I'm making a new mapset, and I've noticed a strange problem with a certain map: The player starts in a map called /lankirk/start-house which has a savebed. The reset time is set to 3600. Now, the odd thing is, whenever i save the play-testing character on the savebed, the map DOES NOT RESET. Even after 12 hours. In fact, it didn't even reset after 24 hours. If I *quit* the play-testing character (i.e. delete instead of save), then the map resets after a reasonable amount of time. Any clues as to what I might be doing wrong, or is this a server bug? T -- Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before. From michael.toennies at nord-com.net Sun May 20 07:45:55 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] FW: Crossfire has released version 1.0 Message-ID: This is the guy of this site: http://www.skoardy.demon.co.uk/rlnews/ As you can see here http://www.skoardy.demon.co.uk/rlnews/links.html The CF link is somewhat outdated and much to small when you look for others. Perhaps we can create here a bigger presence? Seems the guy only needs more information... Btw, great work for the new screenshots, realtime. We neeed more of this and attach it to sites like this. We need a better "public relation". I mean, look at whyvern. CF is so much older (and somewhat bigger, i think), but they had reached fast some better presence. I think we need more visualation. A bigger (also bigger as yet) part for screenshots. What is the difference between CF and some other games? The living dev team... Make a web page which give better information about dev team and what is in work... Mailing list are nice, but they are NOT for quick looks. Animation: CF has tile animation and multi-tile animation. Lets make small animated gifs which the best monsters.. and a gif which shows a player attacking a monster... or a dragon breathing... a flashing lightning... This will kick ass. I saw some of this as banner for an older CF web page. Tanners, will you handle this guy? You know better which links are good or not. > -----Original Message----- > From: Darren Hebden [mailto:dsh@skoardy.demon.co.uk] > Sent: Thursday, May 17, 2001 10:10 PM > To: michael.toennies@nord-com.net > Subject: Re: Crossfire has released version 1.0 > > > ----- Original Message ----- > From: "Michael Toennies" > To: > Sent: Tuesday, May 15, 2001 7:58 PM > Subject: Crossfire has released version 1.0 > > > > The open source rogue like game Crossfire has released version 1.0.0. > > Thanks for the info about the new release. I've often had trouble locating > information about Crossfire and who exactly to contact regards any details > on new versions, etc. If it's not too much trouble, I'd be very happy if > you'd consider dropping me a note from time to time with any new > developments concerning Crossfire. A lot of people are very interested in > multiplayer roguelikes and being able to point them at something > solid would > be a great help. > > Thanks again for your time. > > Regards, > > Darren. > > > From michael.toennies at nord-com.net Sun May 20 07:46:48 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] FW: your free tile set and crossfire Message-ID: This is the guy which the new tile set... > -----Original Message----- > From: Lost Dragon [mailto:lost-dragon@home.com] > Sent: Wednesday, May 16, 2001 8:06 AM > To: michael.toennies@nord-com.net > Subject: Re: your free tile set and crossfire > > > > So, i found your tile set, and you can aspect to see some > > of your tiles in crossfire. > > Sounds cool to me.. Please give me credits in the credits > section of your project (in the software, the manual - whatever > will be seen). > > > CF has a big dev team, aspect all days 5-10 mails in the > > mailing list. All people are very friendy, and when you give > > CF a look and find it nice, > > I will try to take a look at it this Sunday. Right now I > must work :) > > > -- > /| .Oo__. .---.=- -= Lost Dragon, of the Grintooth Clan =- -=.---. U > { \| ,-'' |_|_|==- To the one who tames dragons: -==|_O_| D > `,_/'(_)\_ | | |===- Web Page: http://www.lostdragon.com/ -===| | | I > <...{_)_)_''`G-C' My oath of fealty forevermore. `---' C > > From michael.toennies at nord-com.net Sun May 20 08:35:27 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] Graphics & Derivative version In-Reply-To: Message-ID: The gfx format the guy use is called often the "zelda style", because this console game was one the first action rpgs, using this style. I had shown it to the list sometime ago, look here again, this guy using somewhat same. http://www.lostland.com/altimu/ Well, again: the perspective cames from the background... you got it. One warning: Don't try to make things like "improve our tile set" or something. You can't get this kind of results without a careful designed and styled set. Redraw a new set from the bottom up or don't do it. All others is wasted time. I work in this for money for years, when you think i don't know where i speaking from, than you should not read on. But you should think why other projects and people so often don't hit the road. Its not why they are not so smart as you... Simple: ONE set, ONE style. Every tile depends on the others. Thats why some part of the xbm/xpm sets looks as picture somewhat better then many png set pictures. AND you need to rework some maps. You should never aspect that a new set looks same good with same maps. In fact, to create a game with same maps and 2 gfx set - both looking good with same maps/assemble is real hard. This will not work automatically. But thats not a real hard part. Changing some cosmetic parts of the map set will not be very hard. That why i don't like the way the gfx in CF goes yet. We had 2 main sets yet (when i forget xpm). Both png set looks bad! Sorry for that, they are also for open source project bad. Not single monsters - sone of them looks real good - but one bad tile can destroy the look of a whole screen. Really, you can make when you draw a styled layered background set a much much better looking gfx then CF looking yet. You don't improve map gfx when you put in a new monster. The whyvern set is really not perfect, but its 2 levels better than the CF set... But it has major problems too! The artist also don't really understand all aspects of his work. When you remember my old mails you will see. Look at this: http://www.cabochon.com/screenshots/client3.jpg Here you see 3 (perhaps more?!!) perspectives giving a strange look. The street/background tile are all total flat.. Look at the streets... On a totla flat gfx stand the player on it (very nice objects, isn't it? They also give the monsters more work then the background... ). then the ocean part... here the they fall in the trap with vertical/horizontal structures. a vertical line is a vertical line for the eye, even when its build from not flat objects... and it destroys the iso feeling. The city is funny too... TO iso for the rest of the gfx... Looks like from a other game. The trees are nice, but the flat background destroys the look. Well, if you give david G. iso demo a look, you will see that his gfx is not "nice" as the whyvern one, but the WHOLE picture looks better... more volume, more "3D". Michael > > > Tyler Van Gorder brought up to me that the appears to be a > somewhat derived > version of crossfire out there at http://www.cabochon.com/. Since its in > java, and a quick glance makes it appear a bit different, I don't > personally > think there is much to be done about it under the GPL (I've never been > one for much on look and feel, and to me that is probably the biggest > aspect that we could complain about). > > But unrelated to that - take a look at the screenshots. To be, > that shows that even with standard tile based drawing and placement based > on objects, the graphics can look really good. > > It appears their tile size is also 32x32 or so. It also appears that > the viewport size is 13x13 (crossfire is currently 11x11) > > I would personally think that it would be easier to get near that > form of graphics by taking what we currently have and improving it > vs going to a new form (isomorphic). I think some of the screenshots > also provide good hints on making things look better - ie, shadowing, > 45 degree angles for many of the terrain types to smooth things > out, and more variations (bunch of types of trees, flowers > and lighter shades in the grass, etc). > > My other thought on graphics: > > Good graphics will help a little bit in the first glance 'hey > this looks cool' > category of gamers. But what will really keep the gamers playing is the > gameplay actually being good. The prettiest game in the world > won't last long > if the gameplay behind it sucks. Personally, I think crossfire has pretty > good gameplay, and what that will typically mean is that once you > can attract > the player, they will stick around (and probably tell their > friends about this > cool game). Muds typically don't have any cool graphics, yet > they have quite > a following. > > I guess my main point being - while increasing graphic quality should > continue, I think it would be better to spend the effort making the > gameplay better than switching to isomorphic graphics. > > I've also lived through two big shifts in graphis (xbm -> xpm > and now xpm -> png), and I've seen how long it takes and how much > effort it takes to make that change. There are like 2500+ images out > there - this is not a trivial process. Process takes somewhere > between several months to years. > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From tanner at real-time.com Sun May 20 14:59:30 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:00 2005 Subject: [CF-Devel] FW: Crossfire has released version 1.0 In-Reply-To: ; from michael.toennies@nord-com.net on Sun, May 20, 2001 at 02:45:55PM +0200 References: Message-ID: <20010520145930.K5338@real-time.com> Quoting Michael Toennies (michael.toennies@nord-com.net): > This is the guy of this site: > http://www.skoardy.demon.co.uk/rlnews/ > > As you can see here > http://www.skoardy.demon.co.uk/rlnews/links.html > Tanners, will you handle this guy? > You know better which links are good or not. Sure, I'll volunteer to be crossfire's PR officer(?). Between Leaf and myself we can handle the PR of crossfire. How about a list of sites that CF should be listed on? SourceForge FreshMeat .. .. .. ?? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From yann.chachkoff at mailandnews.com Sun May 20 21:09:15 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Crossfire Scripting Language, version 1.0.0b8 Message-ID: <01052022091500.01588@Terminus.magellan.fpms.ac.be> This is the latest version of the crossfire scripting language. What's new with version b8: - Simple error handling: Now crossfire doesn't crash anymore when you make a syntax error. - Embedded scripts: you can now put the script code inside your objects. Please read the README_SCRIPTS for more details. Chachkoff Y. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-scriptfire-1.0.0b8.bz2 Type: application/x-bzip2 Size: 57710 bytes Desc: Crossfire Scripting patch Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010520/81623f5f/patch-scriptfire-1.0.0b8.bin From joel at mamia.prninfo.com Sun May 20 13:53:29 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] a bug in the world map Message-ID: <200105201853.OAA27600@mamia.prninfo.com> Today I just found a bug. The bug is located in /world/world_c3. There is an exit there that sends the player to world_c2,but to the top of world_c2. Exit coordinants are wrong. From michael.toennies at nord-com.net Sun May 20 18:55:27 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Crossfire Scripting Language, version 1.0.0b8 In-Reply-To: <01052022091500.01588@Terminus.magellan.fpms.ac.be> Message-ID: We test the script stuff and all what i can say its: Include it ASAP. You will not want miss it after 5 minutes playing with it. ** It boost the CF game play on a higher level ** This will add all the stuff we miss in our game. There is some discussion about the syntax and how hard it is to include it. Well, the point is: every powerful script language is more complex. With the GUILE stuff, we will not run in the case we have not enough power. AND this language will grow up. We will see it in MANY other applications - means there will be many people knowing it out and there will be many docs. Also - the work is done. The shit is working. Is really one here which want wrote a own language? I will not... Or one knows a better language which he can include ASAP? i don't know them... We had other things to do as develope the wheel again. Lets put it in ASAP. If one had not a good, a very good reason to include it not, then check this in CVS. We will want/need scripting yet, lets test it hard! The players are still able to crash the server (5 times the damn since friday), so some more potential crashes through scripts will not change anything. Lets play around what can be done. And we need some knowledge about performance - where my opinion is that we will not has a performance hole. The scripts are not used in every action a player invoke. > > This is the latest version of the crossfire scripting language. > What's new with version b8: > > - Simple error handling: Now crossfire doesn't crash anymore when > you make a > syntax error. > - Embedded scripts: you can now put the script code inside your objects. > > Please read the README_SCRIPTS for more details. > > Chachkoff Y. > From michael.toennies at nord-com.net Sun May 20 19:01:01 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] strange crash Message-ID: aving map /esben/puddings.place CSSTAT: Sun May 20 22:20 tot 8422734 109990395 7 165471 inc 31019 558067 3 600 make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/fargot/fargot.pl... make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/fargot/fargot.pl... make_path_tofile /home/unitel/cf/crossfire/var/crossfire/players/Dumberl/_city_apartment_apar tments... Saving map /home/unitel/cf/crossfire/var/crossfire/players/Dumberl/_city_apartment_apar tments remove_friendly_object called with empty friendly list, remove ob=fargot Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/HallOfSelection. load_original_map: /HallOfSelection (0) enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, -1) get_nearest_player: Found free/non friendly object on friendly list Can't open /home/unitel/cf/crossfire/var/crossfire/players/fargot.pl We have not sent item fargot (6587809) We have not sent item fargot (6587809) Resetting map /pup_land/raffle/raffle1. We have not sent item fargot (6587809) We have not sent item fargot (6587809) We have not sent item fargot (6587809) We have not sent item fargot (6587809) We have not sent item fargot (6587809) We have not sent item fargot (6587809) Saving map /city/oldcity/oldcity11 We have not sent item fargot (6587809) We have not sent item fargot (6587809) We have not sent item fargot (6587809) SIGSEGV received. Emergency saves disabled, no save attempted From leaf at real-time.com Sun May 20 19:12:04 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] FW: Crossfire has released version 1.0 In-Reply-To: <20010520145930.K5338@real-time.com> Message-ID: I have started a list of sites that have some sort of reference to Crossfire. http://crossfire.real-time.com/list.html Now, we can track the status (progress?) of making a bigger web presence for Crossfire. Please note, the list is far from complete, and is open to more suggestions. - Rick Tanner leaf@real-time.com On Sun, 20 May 2001, Bob Tanner wrote: > > Sure, I'll volunteer to be crossfire's PR officer(?). Between Leaf and myself we > can handle the PR of crossfire. > > How about a list of sites that CF should be listed on? > > SourceForge > FreshMeat > .. > .. > .. > > ?? > > -- From hsteoh at quickfur.yi.org Sun May 20 20:51:08 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Orc chop of Hideous Poison Message-ID: <20010520215108.A19238@crystal> Somebody on IRC pointed out that although he was playing a beholder, which has 100% poison resistance, eating an orc chop of Hideous Poison still manages to kill him. Apparently the current code simply subtracts the hp from the player? Perhaps it should use AT_POISON with the given amount of damage instead... T -- And life still goes on... From yann.chachkoff at mailandnews.com Mon May 21 06:08:37 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Crossfire Scripting Language, version 1.0.0b8 In-Reply-To: References: Message-ID: <01052107083701.01579@Terminus.magellan.fpms.ac.be> Le Dimanche 20 Mai 2001 19:55, vous avez ?crit : > We test the script stuff and all what i can say its: > Include it ASAP. > We will want/need scripting yet, lets test it hard! > The players are still able to crash the server (5 times the damn since > friday), so some > more potential crashes through scripts will not change anything. Mmmm... I consider potential crashes through scripts to be a problem - that's why I wanted intensive testing/bug tracking. I do not want crossfire to become more unstable than it is now just because of scripts, badly written or not. > > Lets play around what can be done. > > And we need some knowledge about performance - where my opinion is that we > will not has a > performance hole. The scripts are not used in every action a player invoke. True. But there may be a performance loss when many players are running many scripts. If this really become a problem, I'll implement some limit (I thought of something like a maximum number of crossfire instructions that can be executed in a script). MiDS also said you had a problem with the Broadsword of Scripting - can you tell me more about this ? Chachkoff Y. From peterm at tonks.EECS.Berkeley.EDU Mon May 21 00:25:35 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Crossfire Scripting Language, version 1.0.0b8 In-Reply-To: Your message of "Mon, 21 May 2001 01:55:27 +0200." Message-ID: <200105210525.f4L5PZn08789@tonks.EECS.Berkeley.EDU> I have not yet tested it, but I find the writer's arguments in favor of Guile persuasive. I also do not think that using guile is "overkill". I would rather include a powerful scripting language that someone else maintains than reinvent one of our own which we have to add every feature to. If we can resolve the issues Mark raised with this guile implementation, I think we should go ahead with it. I personally would have preferred python, but the author of the guile scripting says python wasn't convenient, and in the absense of my own attempt, I'm inclined to accept his word on it. Regards, PeterM From tanner at real-time.com Mon May 21 00:33:01 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Crossfire Scripting Language, version 1.0.0b8 In-Reply-To: <200105210525.f4L5PZn08789@tonks.EECS.Berkeley.EDU>; from peterm@tonks.EECS.Berkeley.EDU on Sun, May 20, 2001 at 10:25:35PM -0700 References: <200105210525.f4L5PZn08789@tonks.EECS.Berkeley.EDU> Message-ID: <20010521003301.A31356@real-time.com> Quoting Peter Mardahl (peterm@tonks.EECS.Berkeley.EDU): > I have not yet tested it, but I find the writer's arguments in > favor of Guile persuasive. I have not posted my "future of crossfire" document yet. But I am wondering what the time frame is on this decision? I have some ideas, but I need more time to write them out, so is the scripting language going to be something decided in the next couple of days? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From mwedel at scruz.net Mon May 21 01:23:40 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Future crossfire changes/projects References: <01051809514701.02261@Terminus.magellan.fpms.ac.be> Message-ID: <3B08B46C.DD975925@scruz.net> Please remove me from an explicity copy if also sending to the list - I don't need two copies of everthing. gros wrote: > I think the problem is not 'too less docs' but 'badly organized docs'. The > source code itself is well commented, but it is sometimes hard to find 'where > is ... done'. Docs are always hard to keep up to date. Certainly, there are some problems. The client/server protocol is (IMO) decently defined, but that file is actually in the client distribution (Protocol). The other problem is just that documentation does not tend to be a high priority issue for most developers. Its much more fun to write up some new feature than go back and document it. I think the documentation has probably slowly gotten better, but there is just a lot stuff that was done before there was even much a push for documentation. > There was some discussion about it one year ago (The question was to decide > if splitting the game engine and the rules was a good idea). Although I think > an object-oriented language like C++ or Java should be better for Crossfire, > porting the actual code would need massive rewriting, not only because each > function needs to be translated to another 'dialect' (not a big problem for > C++, a bit harder for Java), but also because some basics would need a > complete rethinking. Anyway, if someone gets enough time and will... IMO, if going to C++ was actually going to be done, it would probably be better to do start from scratch. Sure - look at what is currently there, but I have a feeling that trying to take the existing C code and modify it piece by piece into C++ probably is not a useful exercise. As a note, a couple years back, someone was looking to more or less do that (wanted to give it as a class project to write an OOP game), and determined it would be easier to start from scratch than try to redo crossfire. As far as the engine/rules split, that is much more a code re-orginzation than necessarily a rewrite. Some new code would be needed. But a lot of the idea would be to try and clean up a lot of the mess bettween the 'common' and 'server' directory we have right now. A lot of the stuff in common isn't that general. For example, does god code really belong in the common directory? What is currently in the common directory isn't really that common - it is tried pretty precisely to crossfire.. If crossedit goes away/gets redone, such a cleanup may be more useful, as there is also some code in there that only crossedit uses. From mwedel at scruz.net Mon May 21 01:38:07 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Performance References: <200105181709.NAA22734@lul1150.lss.emc.com> Message-ID: <3B08B7CF.A8C41834@scruz.net> pc-crossfire@crowcastle.net wrote: > > I haven't looked at the current protocol, so I don't know how much work it > would be, but here are some thoughts for how we should do it to maximize > efficiency: > > Messages should be binary, not ASCII. It makes reading the stream more > difficult, but saves lots of bandwidth. > > Each message should start with a 32-bit message type code. We can then > define a range of messages that are frequent messages. For example, there > could be message types that indicate the presence of a spell effect on the > same square as the player. Hence, if 7 fears, 3 icestorms, and 9 slows > show up on your square, you only have to receive 19 words. So we can > define a standard set of objects that can be sent with just a single code. > Special objects will take multi-part messages to send name and weight > information, but that's not a problem as long as we get all the spell > effects and other really common items. It really depends on the payload. For the most part, what data that can be sent is sent in binary form. Now the actual protocol commands themselves are in text, but that really isn't that big a deal. Yes - some bandwidth can be saved by going to binary, but most of the protocol commands are <6 characters or so. Presuming 1 byte is enough for unique commands (currently is, but may not be in the future), that saves maybe 5-6 bytes. That is useful, but not especially useful, and is really nothing at all if it is the payload that is 500 bytes. So what really needs to be determined more precisely where the bandwidth is going, and try to improve that. For example, for objects, the biggest hog of the bandwidth is for the names. But there is potential for other savings - animations and animatiion speed may not be relevant for a lot of objects, which means those fields get filled with zeros. Having a 1 byte mask which says what data we're sending along could save some bandwidth there (at the expense if making the object sending code more complicated. The tricky part of your example is definining the value xyz is a fear, foo is a slow, etc. Certainly for some objects, the amount of information sent of objects is excessive (for fear and slow, don't really need to send a nrof, weight, flags, or tag - that right there could save 16 bytes out of the current data stream if only data necessary gets sent along.) PRobably the ideal form is some method of string reduction for commonly used strings, and only sending object information the client actually needs. But the biggest killer can be that for at least objects on the space the player is on, if only one object gets added or removed, the entire space gets resent. And that is just plain not a good idea. From mwedel at scruz.net Mon May 21 02:13:32 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Map reset bug? References: <20010520082811.A17709@crystal> Message-ID: <3B08C01C.B9320ED2@scruz.net> "H. S. Teoh" wrote: > > I'm making a new mapset, and I've noticed a strange problem with a certain > map: > > The player starts in a map called /lankirk/start-house which has a > savebed. The reset time is set to 3600. Now, the odd thing is, whenever i > save the play-testing character on the savebed, the map DOES NOT RESET. > Even after 12 hours. In fact, it didn't even reset after 24 hours. > > If I *quit* the play-testing character (i.e. delete instead of save), then > the map resets after a reasonable amount of time. Any clues as to what I > might be doing wrong, or is this a server bug? Are there other players on the server, or are you the last one? If so, the server basically goes to sleep waiting for new connections. During that time it is asleep, maps do not reset. When someone rejoins, most all the maps will reset if the time has been long enough, but maps the player can visit quickly enough will not reset (this is because the server does not check for potential map resets every tick, but instead every 500 ticks or something). If you keep your client connected waiting for the 'play again prompt', it may also see it as a player being on that map. I'd have to double check this. In reality, these are all server bugs. If its just a problem with youu being the only player, that sort of goes away if youu expect these to be used on public servers. But I'll also see about adding code to reset maps periodically even when sleeping. Now days, when the server is sleeping, it still does in fact do other activitity now and again (at one time, this was not the case - it just waited in select), so while it is doing that other activitity, it can also clear out the old maps. From mwedel at scruz.net Mon May 21 02:32:11 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Crossfire Scripting Language, version 1.0.0b8 References: <200105210525.f4L5PZn08789@tonks.EECS.Berkeley.EDU> <20010521003301.A31356@real-time.com> Message-ID: <3B08C47B.BE47C021@scruz.net> Please remove me from an explicit copy if also sending to the list - I don't need two copies of everthing. Bob Tanner wrote: > > Quoting Peter Mardahl (peterm@tonks.EECS.Berkeley.EDU): > > I have not yet tested it, but I find the writer's arguments in > > favor of Guile persuasive. > > I have not posted my "future of crossfire" document yet. But I am wondering what > the time frame is on this decision? > > I have some ideas, but I need more time to write them out, so is the scripting > language going to be something decided in the next couple of days? Presumably the scripting language will be extensible - what is there now does not necessarily mean that is all the language will ever be able to do. In a sense, just as objects are - much has been added since the original crossfire. Now if the scripting is not extendable, then that is good information to know. As for going into CVS: CVS should not be the main testing place for new features. If that happens, the end result is that the CVS tree will probably become so unstable that virtually no one will use it, and hence no testing will get done. The argument that crossfire is currently not really stable is not a good argument IMO. There may very well be just one bug causing the current set of crashes which can get fixed up, so introducing a new set that may add new crashpoints isn't useful IMO, what Gros has been doing - sending a patch to the list, is the best solution. It makes it widely available and lets people use it and test it out on a smaller basis. And in fact, if we want to put it in as a branch release, I don't have a big problem with that. Now when is something ready to go into CVS? A lot depends on the author - some may feel more confident about their code than others. But in all cases, if the author feels there are still some big bugs, it should not go in. Unrelated - just because something is done first does not always mean that should always be considered the code that should be taken. In this particular case, it seems there is agreement and with the amount of work done, it seems this will be the final solution. But through my experience with crossfire through the years, I have seen many cases where the first 'working solution' which was adopted may have in fact been a bad thing. My main point here is that just because someone wrote the first working version of some desired piece should not mean that is the one that always gets included. that said, I expect at some point between now and 2.0 there will be phase where there will be code in CVS which will not be meant for public servers (there are some pretty big changes listed). But some of that I see more with compatibility issues (for example, going to a 17x17 map will break all existing clients out there right now). From jbontje at suespammers.org Mon May 21 03:26:46 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Metaserver feature request Message-ID: <20010521102646.A6071@mids.student.utwente.nl> Hello, Like you probably know I keep graphical statistics of the metaserver information. (http://mids.student.utwente.nl/~crossfire/stats/) Every 5 minutes graphs are created displaying the amount of servers in total, players in total, and also players for every server listed on the metaserver. I also made an other script that can plot the datatraffic of one server, using the CSSTAT lines in the serverlogs. I can adjust my metaserver graph program very easily to log the datatraffic of ALL the servers. Tho things on the server side should be done: 1) Let the metaserver accept 2 extra fields (bytes in and bytes out). 2) Let the server send on every metaserver update those 2 fields. The trick would be to do it in such a way that the current client don't get broken, probably by putting it in the comments field. Joris Bontje / MiDS From michael.toennies at nord-com.net Mon May 21 05:27:48 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Crossfire Scripting Language, version 1.0.0b8 In-Reply-To: <20010521003301.A31356@real-time.com> Message-ID: Ah, don't fear... because gros has finished the main work... Simply assume it as included. And the real working with it, is part of the next editor/map making/ new quest/content part. > > Quoting Peter Mardahl (peterm@tonks.EECS.Berkeley.EDU): > > I have not yet tested it, but I find the writer's arguments in > > favor of Guile persuasive. > > I have not posted my "future of crossfire" document yet. But I am > wondering what > the time frame is on this decision? > > I have some ideas, but I need more time to write them out, so is > the scripting > language going to be something decided in the next couple of days? > > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org | Fax : (952)943-8500 > Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From hsteoh at quickfur.yi.org Mon May 21 07:23:54 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:01:01 2005 Subject: [CF-Devel] Map reset bug? In-Reply-To: <3B08C01C.B9320ED2@scruz.net>; from mwedel@scruz.net on Mon, May 21, 2001 at 12:13:32AM -0700 References: <20010520082811.A17709@crystal> <3B08C01C.B9320ED2@scruz.net> Message-ID: <20010521082354.A20660@crystal> On Mon, May 21, 2001 at 12:13:32AM -0700, Mark Wedel wrote: > "H. S. Teoh" wrote: [snip] > > The player starts in a map called /lankirk/start-house which has a > > savebed. The reset time is set to 3600. Now, the odd thing is, whenever i > > save the play-testing character on the savebed, the map DOES NOT RESET. > > Even after 12 hours. In fact, it didn't even reset after 24 hours. > > > > If I *quit* the play-testing character (i.e. delete instead of save), then > > the map resets after a reasonable amount of time. Any clues as to what I > > might be doing wrong, or is this a server bug? > > Are there other players on the server, or are you the last one? This is my local server, so it's the last one. > If so, the server basically goes to sleep waiting for new connections. During > that time it is asleep, maps do not reset. When someone rejoins, most all the > maps will reset if the time has been long enough, but maps the player can visit > quickly enough will not reset (this is because the server does not check for > potential map resets every tick, but instead every 500 ticks or something). > > If you keep your client connected waiting for the 'play again prompt', it may > also see it as a player being on that map. I'd have to double check this. Interestingly, the map *does* reset if I leave my client at the play-again prompt. It doesn't if I completely disconnect. > In reality, these are all server bugs. If its just a problem with youu being > the only player, that sort of goes away if youu expect these to be used on > public servers. But I'll also see about adding code to reset maps periodically > even when sleeping. Now days, when the server is sleeping, it still does in > fact do other activitity now and again (at one time, this was not the case - it > just waited in select), so while it is doing that other activitity, it can also > clear out the old maps. It's not *that* hard to do, is it? T -- It is impossible to make anything foolproof because fools are so ingenious. -- Sammy From yann.chachkoff at mailandnews.com Mon May 21 14:47:56 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:02 2005 Subject: [CF-Devel] Crossfire Scripting Extension, version 1.0.0b9 Message-ID: <01052115421905.01579@Terminus.magellan.fpms.ac.be> This is the latest release of the scripting extensions for Crossfire. What's new from 1.0.0b8: - Fixed crashing error that could happen sometimes with the Boomerang Dagger; - Improved (create-object) and (create-object-inside) so they can now recognize item names like 'writing pen' or artifacts such as 'ring of Ice' (previously, only the archname was recognized). - Most of scripting code of the test maps is now embedded inside objects. Chachkoff Y. -------------- next part -------------- A non-text attachment was scrubbed... Name: scriptfire-maps-1.0.0b9.tar.bz2 Type: application/x-bzip2 Size: 15251 bytes Desc: Test maps Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010521/f87b31f3/scriptfire-maps-1.0.0b9.tar.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-scriptfire-1.0.0b9.bz2 Type: application/x-bzip2 Size: 55783 bytes Desc: Scriptfire patch 1.0.0b9 Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010521/f87b31f3/patch-scriptfire-1.0.0b9.bin From dnh at hawthorn.csse.monash.edu.au Mon May 21 09:12:52 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:02 2005 Subject: [CF-Devel] 2 things.. Message-ID: Firstly, has ANYONE looked into this animation bug? secondly, wizards appear to be taking of -3 to con and str instead of -2, did someone change this? Does anyone mind if I change it? dnh From tanner at real-time.com Mon May 21 15:15:26 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:02 2005 Subject: [CF-Devel] rsync vs mirror Message-ID: <20010521151526.L6160@real-time.com> > ! ftp://ftp.scruz.net:/users/mwedel/public (165.227.192.254) > ! ftp://ftp.sourceforge.net:/pub/sourceforge/crossfire (64.28.67.101) > ! ftp://ftp.ifi.uio.no:/pub/crossfire (129.240.64.44) > ftp://ftp.real-time.com/pub/games/crossfire > ! ftp://ftp.cs.city.ac.uk:/pub/games/crossfire/ > ! ftp://ftp.sunet.se:/pub/unix/games/crossfire (130.238.127.3) > ! ftp://ftp.cs.titech.ac.jp:/pub/games/crossfire > ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ > ftp://crossfire.futt.org//pub/crossfire Would it be possible to setup an rsync server instead of using mirror? Just curious. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From david.delbecq at usa.net Mon May 21 15:58:20 2001 From: david.delbecq at usa.net (DAVID DELBECQ) Date: Thu Jan 13 18:01:02 2005 Subject: [Re: [CF-Devel] Future of Crossfire] Message-ID: <20010521205820.27893.qmail@nw174.netaddress.usa.net> dnh wrote: Umm I tend to disagree with this. Firstly, I honestly DON'T believe an 'iso' view version of crossfire, or at least a version like the 'standard set'. I personally believe that with a short month, Peterm and I have created a better, more congruent, set that really does look great. The alternate set (which can be found on crossfire.csua.ber....) may look easy to convert to iso but there is a large problem and that is with the multitiled monsters. If we take on an iso view major changes are going to have to be made, and IMHO it simply isn't worth our time.. certainly if some wiz artists comes along AND MAKES the new images I would be happy to see such ventures, but until we have some real live artist walking about, that I can talk to and ask questions about, I don't support this view. ------------------------------------> You say you don't want iso because you don't have time to create iso monsters, or at least convert. It's your right but don't forget we can parse a lot of flat object (ground and so on) to iso esaily (just some deformation). What concern monster, 1 square monsters can, at least for the moment, be parsed like that (they look good for iso). What concern multiple square monsters, i believe it's a problem but once again, we could for the begin of the developpement, parse them as flat objects which stand up in the front square. The critical point of this are walls, doors, exits, houses, sign and other vertical objects. What i think is you fear your set will go to trap because of iso before being known. Well don't know for the moment how it could be possible when i see the speed at which developpers are speaking before doing something interesting. <------------------------------------ Secondly, you say our servers can't support uploading the images to the clients? what do you think they already do? and what do you think is already supported? if you add -usefile or something like that, it will grab its images from a set of pngs, you don't need to get them from the server. This is merely an implementation problem and I am sure Mark would be willing to hear suggestions on a better way to do it ;). ------------------------------------> I don't think you've understood what i meant. I said server use its processing time to transfer files to other players. Even if the socket do most of the job, i though transferring pictures to the client shouldn't be the work of the server (and why should the server have pictures anyway???). The purpose of this transfer is to keep a coherent set. Ok, but most servers use the same set and i proposed to have a message during the server connection which gives information on where to find an download these picture (could be local or on a public ftp!) <------------------------------------ 2) We have been looking for someone to work on the linux client for a long long time, Mark has done some excellent work, but the fact remains it is not an interface heavy client. It is simple, it works and I personally find it very useable. Some speed improvements and a few new options in the preferences and I think we have an excellent client already. Most stuff you find in clients today tends to be artists who have plenty of time, if we have one.. then perhaps we could consider this. Not only this, but we are constantly updating the server, I personally have been involved in adding 10 or so spells, and I don't think I want to consider having to fix the client everytime I add a new spell =\. These are just a few thoughts, but they were eating at me, sometimes you must remember that crossfire is not a commercial game, and we don't have spare resources lieing about. While setting a high goal is fine, I think we should set ones that we can achieve ourselves, realistically. dnh ------------- I didn't say the client was heavy (except perhaps for the directx one, but it a directx problem). Let's say am a newbie player, i downloaded and lauched the client. I connect to a server, create a player. Then, the server says to type a lot of crappy things in the console. I want to cast spells, i have to type thinks, bind blablabla.. then i can cast. Well am newbie, where on hell can i find a list of commands. Help?? Yes this command work. What?! is this a telnet game with a graphical board? Well i prefer to go away. This could be good, for example to have a small, findable, button where you can click to choose you spell. I would be very happy to have an interface where keyboard is not used to type crazy things among the console (or at least in some rare cases). David Delbecq David.delbecq@usa.net ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From mwedel at scruznet.com Mon May 21 18:13:17 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:02 2005 Subject: [CF-Devel] Metaserver feature request In-Reply-To: <20010521102646.A6071@mids.student.utwente.nl> Message-ID: On Mon, 21 May 2001, Joris Bontje wrote: > Hello, > > I can adjust my metaserver graph program very easily to log the datatraffic of ALL the servers. > Tho things on the server side should be done: > 1) Let the metaserver accept 2 extra fields (bytes in and bytes out). > 2) Let the server send on every metaserver update those 2 fields. > > The trick would be to do it in such a way that the current client don't get broken, probably by putting it in the comments field. This can probably get done pretty easily. As far as the metaserver script itself is concerned, the only thing it cares about from the data the server sends to it is the hostname. It doesn't care about all the other fields (just treats it as string data). When generating HTML, it does split them all apart, so to add a bytes in/bytes out in html would be pretty easy - if that output is not desired in the html output, no changes would be needed. Not positive, but I think the client (unix client at least) only looks for the seperators for data it expects to find - ie, after it gets the separator for the comment section, it does not look for any more separators so it probably should not care. In fact, at least the unix client doesn't even do anything with the comment field, as printing that tended to make the list fairly unreadable. So in summary, this should be easy to do. Since metaserver updates don't necessarily happen in sync with CSSTAT updates, this would probably be cumulative total if inbytes/outbytes. Is that the data you wanted, or did you want elapsed byte counts? From mwedel at scruznet.com Mon May 21 18:24:44 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:02 2005 Subject: [CF-Devel] Map reset bug? In-Reply-To: <20010521082354.A20660@crystal> Message-ID: On Mon, 21 May 2001, H. S. Teoh wrote: > > Interestingly, the map *does* reset if I leave my client at the play-again > prompt. It doesn't if I completely disconnect. Yes - if the client is at the play-again prompt, it is still connected to the server, so the server still watches it for input, sends output, and resets maps. If you completely disconnect, the server goes asleep waiting for new connections, and hence never resets the maps. > It's not *that* hard to do, is it? The fix is in fact quite easy. I just want to test it to make sure it does in fact work - there is no reason checking something in, even if it is simple, if it doesn't in fact fix the problem. From dnh at hawthorn.csse.monash.edu.au Mon May 21 18:25:38 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:02 2005 Subject: [Re: [CF-Devel] Future of Crossfire] In-Reply-To: <20010521205820.27893.qmail@nw174.netaddress.usa.net> Message-ID: On Mon, 21 May 2001, DAVID DELBECQ wrote: > dnh wrote: > Umm I tend to disagree with this. > > Firstly, I honestly DON'T believe an 'iso' view version of crossfire, or > at least a version like the 'standard set'. I personally believe that with > a short month, Peterm and I have created a better, more congruent, set > that really does look great. The alternate set (which can be found on > crossfire.csua.ber....) may look easy to convert to iso but there is a > large problem and that is with the multitiled monsters. If we take on an > iso view major changes are going to have to be made, and IMHO it simply > isn't worth our time.. certainly if some wiz artists comes along AND MAKES > the new images I would be happy to see such ventures, but until we have > some real live artist walking about, that I can talk to and ask questions > about, I don't support this view. > > ------------------------------------> > You say you don't want iso because you don't have time to create iso monsters, > or at least convert. It's your right but don't forget we can parse a lot of > flat object (ground and so on) to iso esaily (just some deformation). What > concern monster, 1 square monsters can, at least for the moment, be parsed > like that (they look good for iso). What concern multiple square monsters, i > believe it's a problem but once again, we could for the begin of the > developpement, parse them as flat objects which stand up in the front square. > The critical point of this are walls, doors, exits, houses, sign and other > vertical objects. > <------------------------------------ I fear that would look really crap dude. Firstly any general scale looks crap (see old standard set pngs.. ), secondly half of the images wont fit the 32 x 32 rectangle. > What i think is you fear your set will go to trap because of iso before being > known. Well don't know for the moment how it could be possible when i see the > speed at which developpers are speaking before doing something interesting. Umm I assume you mean crap. Much of my work has disappeared through time, but it is doing the work that counts in the long run. I hear lots of talk about do this do that, but as of yey onlt gros has made any sounds of even attempting what he is saying. I don't really care if the entire standard set disappears I work on an alternate set, which you may or may not have played. I don't really care if only one other person likes the set that i am help produce, I have done the work and I am glad I did. ps. look on crossfire.csua.berkeley.edu if you want to see what I have been making. > Secondly, you say our servers can't support uploading the images to the > clients? what do you think they already do? and what do you think is > already supported? if you add -usefile or something like that, it will > grab its images from a set of pngs, you don't need to get them from the > server. This is merely an implementation problem and I am sure Mark would > be willing to hear suggestions on a better way to do it ;). > > ------------------------------------> > I don't think you've understood what i meant. I said server use its processing > time to transfer files to other players. Even if the socket do most of the > job, i though transferring pictures to the client shouldn't be the work of the > server (and why should the server have pictures anyway???). The purpose of > this transfer is to keep a coherent set. Ok, but most servers use the same set > and i proposed to have a message during the server connection which gives > information on where to find an download these picture (could be local or on a > public ftp!) > <------------------------------------ Errr, as I said, currently the server ISN'T having trouble uploading graphics. Look at MiDS statistics, the server only needs to output around 1k per player. Why do we need to change it? I see your point, I made exactly the same point awhile ago, but the change is alittle more complicated than the intended benefit for most developers to consider doing it. If you want to do it, I don't think anyone will complain. > 2) We have been looking for someone to work on the linux client for a long > long time, Mark has done some excellent work, but the fact remains it is > not an interface heavy client. It is simple, it works and I personally > find it very useable. Some speed improvements and a few new options in the > preferences and I think we have an excellent client already. Most stuff > you find in clients today tends to be artists who have plenty of time, if > we have one.. then perhaps we could consider this. > > Not only this, but we are constantly updating the server, I personally > have been involved in adding 10 or so spells, and I don't think I want to > consider having to fix the client everytime I add a new spell =\. > > These are just a few thoughts, but they were eating at me, sometimes you > must remember that crossfire is not a commercial game, and we don't have > spare resources lieing about. While setting a high goal is fine, I think > we should set ones that we can achieve ourselves, realistically. > > dnh > > ------------- > > I didn't say the client was heavy (except perhaps for the directx one, but it > a directx problem). Let's say am a newbie player, i downloaded and lauched the > client. I connect to a server, create a player. Then, the server says to type > a lot of crappy things in the console. I want to cast spells, i have to type > thinks, bind blablabla.. then i can cast. Well am newbie, where on hell can i > find a list of commands. Help?? Yes this command work. What?! is this a telnet > game with a graphical board? Well i prefer to go away. > This could be good, for example to have a small, findable, button where you > can click to choose you spell. I would be very happy to have an interface > where keyboard is not used to type crazy things among the console (or at least > in some rare cases). This is a problem with most linux games i find, but then again, most linux users aren't little newbies who don't know where the power switch is. The windows client is appropriate for the intended audience, I propose the linux client is also approriate for its audience. Often you will find anyway, that adding pretty spell buttons and what not actually makes the game more difficult to grasp quickly. Time to fly, dnh > > > > > David Delbecq > David.delbecq@usa.net > > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=1 > From jbontje at suespammers.org Mon May 21 18:54:45 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:02 2005 Subject: [CF-Devel] Metaserver feature request In-Reply-To: ; from mwedel@scruznet.com on Mon, May 21, 2001 at 04:13:17PM -0700 References: <20010521102646.A6071@mids.student.utwente.nl> Message-ID: <20010522015445.A14568@mids.student.utwente.nl> On Mon, May 21, 2001 at 04:13:17PM -0700, Mark Wedel wrote: > On Mon, 21 May 2001, Joris Bontje wrote: > > > I can adjust my metaserver graph program very easily to log the datatraffic of ALL the servers. > > Two things on the server side should be done: > > 1) Let the metaserver accept 2 extra fields (bytes in and bytes out). > > 2) Let the server send on every metaserver update those 2 fields. > > > This can probably get done pretty easily. > > > > Since metaserver updates don't necessarily happen in sync with CSSTAT > updates, this would probably be cumulative total if inbytes/outbytes. > Is that the data you wanted, or did you want elapsed byte counts? Cumulative totals would be best, thats what most traffic analysers eat; if some updates get lost the data can be interpolated. Joris Bontje / MiDS From mwedel at scruznet.com Mon May 21 19:17:03 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:02 2005 Subject: [Re: [CF-Devel] Future of Crossfire] In-Reply-To: <20010521205820.27893.qmail@nw174.netaddress.usa.net> Message-ID: On 21 May 2001, DAVID DELBECQ wrote: > You say you don't want iso because you don't have time to create iso monsters, > or at least convert. It's your right but don't forget we can parse a lot of > flat object (ground and so on) to iso esaily (just some deformation). What > concern monster, 1 square monsters can, at least for the moment, be parsed > like that (they look good for iso). What concern multiple square monsters, i > believe it's a problem but once again, we could for the begin of the > developpement, parse them as flat objects which stand up in the front square. > The critical point of this are walls, doors, exits, houses, sign and other > vertical objects. > What i think is you fear your set will go to trap because of iso before being > known. Well don't know for the moment how it could be possible when i see the > speed at which developpers are speaking before doing something interesting. I've been working on crossfire for around 10 years now, and in that I've gone through the xbm to xpm image conversion and the xpm to png conversion process. Such conversions are not a trivial process. to xpm to png is arguably a more trivial one (only size increasing), and that is still being worked on. Many of the images were converted & resized automatically, and people generally really dislike those images. I have a feeling the same thing will happen with iso for images converted automatically. If the iso version can coexist with the overhead version, this helps out a lot. But in the long run (or even short run), I don't think we want two image sets. But in any case, nothing ever will happen unless people decide to work on it. Even if everyone decides the iso is a good thing (which will not happen judging from the discussion, and I know I won't), it still won't happen if no one actually works on it. Realistically, to get iso done in a reasonable time frame, you probably need 4-5 people working on it pretty seriously. Now in the design of the client was the 'vision' that it could run with whatever graphic format it wants. If someone wanted to run with 64x64 images, they could do so - its just a matter of getting 64x64 images for their client. Same remains true of the iso, as long as extra server support is not needed. However, I have a feeling for iso to look/work right, some changes would be needed (current images may not work good for all forms) > I don't think you've understood what i meant. I said server use its processing > time to transfer files to other players. Even if the socket do most of the > job, i though transferring pictures to the client shouldn't be the work of the > server (and why should the server have pictures anyway???). The purpose of > this transfer is to keep a coherent set. Ok, but most servers use the same set > and i proposed to have a message during the server connection which gives > information on where to find an download these picture (could be local or on a > public ftp!) As said in another message, the processing time the server takes on this is trivial. The big issue might be network bandwidth (also see other message about whether a seperate connection actually helps on that or not). The reason the server has to have images is that you need some source that you know must the images you need. Suppose this example: I run a small server, and add a custom map set which also adds some new archs and images. For whatever reason, I can not update the master image server (I could provide a potential large reasons why this may not happen). The client has to be able to get the new images I'm using. But there is a lot to be send for simplicity. You may very well be behind a firewall which lets high port number connections (ie, crossfire) out, but mandates use of proxies for ftp and http. Do you really now want to not only have the client be able to deal with those protocols, but also able to deal with proxies as intermediaries? Its very nice to know that if you can play the game, you can get all the info you need. Realistically, supplemental image servers may not be bad. Shipping an image set with the client may not be bad. But having that be the only way to get images would be bad - I think at some level the client must be able to get images from the server for a variety of reasons. So the best that can be done is to discourage that behaviour if it really is undesirable. > > I didn't say the client was heavy (except perhaps for the directx one, but it > a directx problem). Let's say am a newbie player, i downloaded and lauched the > client. I connect to a server, create a player. Then, the server says to type > a lot of crappy things in the console. I want to cast spells, i have to type > thinks, bind blablabla.. then i can cast. Well am newbie, where on hell can i > find a list of commands. Help?? Yes this command work. What?! is this a telnet > game with a graphical board? Well i prefer to go away. > This could be good, for example to have a small, findable, button where you > can click to choose you spell. I would be very happy to have an interface > where keyboard is not used to type crazy things among the console (or at least > in some rare cases). If really important, pull down menus to cast spells could be added. Realistically, no advanced player will ever use those windows (or very seldom - just for the spells you cast once in a blue moon that you don't want to bind). Binding spells tends to be much faster in the long run. I know there is desirability to have things mouse navigitable. But even for other games, I usually try to find whatever keyboard shortcuts are available pretty quickly. Also, currently the spells the player knows about are not communicated effectively to the client (the client can invisibly send a cast command to the server and then parse the returning drawinfo data). But some better form such that the client could know the spell lists and some information about them would probably be desirable - it could then generate the menus based on this info. Useful info IMO: spell paths player has repelled, attuned, denied spell info: spell name, type (fire, cold, cure, etc), sp, type (priest/mage), and spellpath (if different from described type), perhaps image Client could then draw nice little icons, put little markers depending on how the players spellpath matches with the spell (so you can more easily see if you are casting an attuned spell for example). With something like 170 spells out there, the lists would need to get broken down into types at some form. Ideally, of course, the spell popup menus would let you set bindings for the spells right there. IMO, doing all the above would be a nice addition of a feature. Its just a bit of work to do (I don't think any of it is actually really hard to do). At least on the unix side, this would be a gtk client issue only. From hsteoh at quickfur.yi.org Mon May 21 20:12:00 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:01:02 2005 Subject: [CF-Devel] Bad random map bug Message-ID: <20010521211200.A23052@crystal> OK, I'm playing on metalforge right now, and there's a serious bug: 1) I'm in a square room -- I'm assuming this is just the roguelike layout giving up because the dimensions are too small: no problem here 2) There is a chest 1 square east, 2 squares north, surrounded by hidden doors (disguised as walls) 3) There are two fake (transparent) walls, one where the up ladder is supposed to be, and the other where i presume the down ladder would have been. 4) These hidden doors/fake walls overlap the circle of signs that surround where you'd expect the up ladder to be. 5) There is no down ladder 6) There is no up ladder. T -- Why is the sea always restless? It's bed is too rocky to sleep on. From pc-crossfire at crowcastle.net Mon May 21 21:29:10 2001 From: pc-crossfire at crowcastle.net (pc-crossfire@crowcastle.net) Date: Thu Jan 13 18:01:02 2005 Subject: [CF-Devel] oratory/singing bug Message-ID: <200105220229.WAA00966@localhost.localdomain> It seems that you can't use oratory or singing with multi-square monsters. Is this intentional? --PC From pc-crossfire at crowcastle.net Mon May 21 21:41:02 2001 From: pc-crossfire at crowcastle.net (pc-crossfire@crowcastle.net) Date: Thu Jan 13 18:01:02 2005 Subject: [CF-Devel] oratory/singing bug Message-ID: <200105220241.WAA32037@lul1150.lss.emc.com> It seems that you can't use oratory or singing with multi-square monsters. Is this intentional? --PC From mwedel at scruz.net Mon May 21 23:47:23 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:02 2005 Subject: [CF-Devel] oratory/singing bug References: <200105220229.WAA00966@localhost.localdomain> Message-ID: <3B09EF5B.A1CA64C9@scruz.net> pc-crossfire@crowcastle.net wrote: > > It seems that you can't use oratory or singing with multi-square monsters. > > Is this intentional? There is definately code in place to prevent this from happening. My guess is that code is there to prevent singing/orating to supposed tough monsters. Unfortunately, some amount of the code presumes that multispace monsters == real tough, so things shouldn't work on them. there are of course some pretty weak multi spaced monsters (giants, wyverns). There is also code for orate/singing to prevent it from working on creatures with messages. This makes some amount of sense (don't want pc to be able to orate to some critical npc or clear out goths tavern), but it does mean that any monster, no matter how weak, is immune to those skills if they have any message. A few archetypes actually have default messages (raas, dwarf priest, dwarf wizard, sages, guildmasters) From crossfire at suckfuell.net Tue May 22 01:07:49 2001 From: crossfire at suckfuell.net (Jochen Suckfuell) Date: Thu Jan 13 18:01:02 2005 Subject: [CF-Devel] oratory/singing bug In-Reply-To: <3B09EF5B.A1CA64C9@scruz.net> Message-ID: Hi! My experience is that you can sing to multi-square monsters, but only to the upper left piece. So I can sing to dragons from the top and from the left, but not from the right, and only in high levels from the bottom (when my singing radius has grown). >> It seems that you can't use oratory or singing with multi-square monsters. >> Is this intentional? Bye Jochen -- E-Mail: Jochen Suckfuell From yann.chachkoff at mailandnews.com Tue May 22 07:25:54 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:02 2005 Subject: [Re: [CF-Devel] Future of Crossfire] In-Reply-To: References: Message-ID: <01052208255400.01570@Terminus.magellan.fpms.ac.be> Le Lundi 21 Mai 2001 19:25, vous avez ?crit : > On Mon, 21 May 2001, DAVID DELBECQ wrote: > > ------------------------------------> > > You say you don't want iso because you don't have time to create iso (...) > I fear that would look really crap dude. Firstly any general scale looks > crap (see old standard set pngs.. ), secondly half of the images wont fit > the 32 x 32 rectangle. > I don't understand what you mean with "half of the images won't fit the 32x32 rectangle". Maybe I was a little na?ve, but I thought the iso pictures should be bigger than 32x32, (at least higher than that), to allow "high" monsters like cyclops. I've put a small example of what I try to say with this e-mail. > Umm I assume you mean crap. Much of my work has disappeared through time, > but it is doing the work that counts in the long run. I hear lots of talk (...) That discussion may be very interesting from a philosophical point of view I'll put the questions no one truly asked for until now: 1 - Are there people interested to create an iso-set on crossfire ? How they want it to be (technical or artistical point of view) does not matter. If there are volunteers ready to get involved in this, please let the others know. 2 - Are there people interested in developing a "better-looking" client (I admit this is somewhat vague, but I consider commercial games like Diablo or Baldur's Gate as references for the interface) ? If yes, then tell it and begin the work. The discussion about those subjects could continue Ad Vitam Aeternam; lots of ideas are certainly a good thing, but I think we nearly emptied the subject here. It does not matter if some people don't see iso or new client as priorities. Not all people working around Crossfire must work on every part being developed. I know that not everyone knows C or is a good drawer, but if we endlessly discuss of the pros/cons without having even tried to do something, we'll never go anywhere. Chachkoff Y. From oxygen at ludd.luth.se Tue May 22 05:17:39 2001 From: oxygen at ludd.luth.se (Isak Styf) Date: Thu Jan 13 18:01:03 2005 Subject: [CF-Devel] Metaserver idle time Message-ID: <021601c0e2a8$6fd929e0$d9c3f082@DS28> Hi! I am currently doing some polishing to incorporate the metaserver functionality into the java client. I just want to know, what exactly is the idle time a measurement of? /// Isak Styf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010522/9a52f5e2/attachment.htm From michael.toennies at nord-com.net Tue May 22 06:11:24 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:03 2005 Subject: [Re: [CF-Devel] Future of Crossfire] In-Reply-To: <01052208255400.01570@Terminus.magellan.fpms.ac.be> Message-ID: You got the point Gros. "Volunteer and begin the work" Thats the point. Again, here is David Gervais iso set http://dgrealm.50megs.com/iso-samples.html - he has startet a basic background set - all flat monsters from our sets will fit or can easily converted Because DG has started the work (for a different game) and is still working on it, he will be with a very high chance agree to add this to our game. Means, he will draw some of the special tile we need, etc. We had the chance to make the CF gfx to "his" gfx... Means he will be a active artist then for us... Remember he is a guy which has drawed for money for game companys. Also, as you can see he has draw a nice skin for a client... We can create one skin for win9x/linux. I will do for the dx client the work when we go this way. We can make a 1024x768 interface, my dev. version of the dx client runs easily in 1024. > -----Original Message----- > From: crossfire-devel-admin@lists.real-time.com > [mailto:crossfire-devel-admin@lists.real-time.com]On Behalf Of gros > Sent: Tuesday, May 22, 2001 2:26 PM > To: crossfire-devel@lists.real-time.com > Subject: Re: [Re: [CF-Devel] Future of Crossfire] > > > Le Lundi 21 Mai 2001 19:25, vous avez ?crit : > > On Mon, 21 May 2001, DAVID DELBECQ wrote: > > > ------------------------------------> > > > You say you don't want iso because you don't have time to create iso > (...) > > I fear that would look really crap dude. Firstly any general scale looks > > crap (see old standard set pngs.. ), secondly half of the > images wont fit > > the 32 x 32 rectangle. > > > I don't understand what you mean with "half of the images won't > fit the 32x32 > rectangle". Maybe I was a little na?ve, but I thought the iso > pictures should > be bigger than 32x32, (at least higher than that), to allow > "high" monsters > like cyclops. I've put a small example of what I try to say with > this e-mail. > > > Umm I assume you mean crap. Much of my work has disappeared > through time, > > but it is doing the work that counts in the long run. I hear > lots of talk > (...) > > That discussion may be very interesting from a philosophical point of view > I'll put the questions no one truly asked for until now: > > 1 - Are there people interested to create an iso-set on crossfire > ? How they > want it to be (technical or artistical point of view) does not matter. If > there are volunteers ready to get involved in this, please let the others > know. > 2 - Are there people interested in developing a "better-looking" > client (I > admit this is somewhat vague, but I consider commercial games > like Diablo or > Baldur's Gate as references for the interface) ? If yes, then tell it and > begin the work. > > The discussion about those subjects could continue Ad Vitam > Aeternam; lots of > ideas are certainly a good thing, but I think we nearly emptied > the subject > here. It does not matter if some people don't see iso or new client as > priorities. Not all people working around Crossfire must work on > every part > being developed. I know that not everyone knows C or is a good > drawer, but if > we endlessly discuss of the pros/cons without having even tried to do > something, we'll never go anywhere. > > Chachkoff Y. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From michael.toennies at nord-com.net Tue May 22 06:32:34 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:03 2005 Subject: [Re: [CF-Devel] Future of Crossfire] In-Reply-To: Message-ID: Hm, sorry to say but you both are wrong ;) The problem are not the monsters... I mean LOOK at the iso example of DG... the monsters are FLAT also some other objects. What is NOT flat is the background - and background in both png sets are really worse and a mix from many sets. I can,t understand that no one believe me that the look of a map NOT DEPENDS ON THE MONSTERS/CREATURE - it depends on the background. Look at the iso example... count the creatures/flat objects and the "other" objects... do this too for a normal CF map... I mean, what you normal see are about 80%-90% background tiles... THEY make the look. Iso BACKGROUND will make the perspective. Iso gfx like DG example makes it easy to include "high" of a object... means there you can stay "behind" a object. * And there is not problem for most of our multi tile monsters for alternate set * * You must make the last "high" png bigger than 32x32 - like 32x40 or 32x50 or whatever * * its a work of some minutes to change clients for this * * the server NEVER handles with the content of a media file, so he don't care about it* * MORE: there is a GOOD point: For a high monster, you only include the foot part of it as object in the map - the HEAD is "in the air" - so, you reduce there some overhead * And because the tiles are arranged in diamond shape style and drawed in iso, the position of objects are "sorted" in a eye friendly way your brain think thats all "natural". diamond shape iso is a grafical AND a physical (the form and position of the tiles) "trick" to fool your eyes... and a technical way to blt the object correct (think about "high" objects). Thats ALL. And for a really last time (i don't want repeat it again and again) - you CAN'T do this physical/ technical view in the way our png sets are working. I mean - SHOW me the game/gfx which use it! Do you think the prof. game artists are all idiots? They know what they do and they had some more thinked about it than you - they got money for it. So, don't try to develope the wheel again - use what people had done. --------------------------------------------------------------------- Michael > > On Mon, 21 May 2001, DAVID DELBECQ wrote: > > > dnh wrote: > > Umm I tend to disagree with this. > > > > Firstly, I honestly DON'T believe an 'iso' view version of crossfire, or > > at least a version like the 'standard set'. I personally > believe that with > > a short month, Peterm and I have created a better, more congruent, set > > that really does look great. The alternate set (which can be found on > > crossfire.csua.ber....) may look easy to convert to iso but there is a > > large problem and that is with the multitiled monsters. If we take on an > > iso view major changes are going to have to be made, and IMHO it simply > > isn't worth our time.. certainly if some wiz artists comes > along AND MAKES > > the new images I would be happy to see such ventures, but until we have > > some real live artist walking about, that I can talk to and ask > questions > > about, I don't support this view. > > > > ------------------------------------> > > You say you don't want iso because you don't have time to > create iso monsters, > > or at least convert. It's your right but don't forget we can > parse a lot of > > flat object (ground and so on) to iso esaily (just some > deformation). What > > concern monster, 1 square monsters can, at least for the > moment, be parsed > > like that (they look good for iso). What concern multiple > square monsters, i > > believe it's a problem but once again, we could for the begin of the > > developpement, parse them as flat objects which stand up in the > front square. > > The critical point of this are walls, doors, exits, houses, > sign and other > > vertical objects. > > <------------------------------------ From michael.toennies at nord-com.net Tue May 22 06:44:53 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:03 2005 Subject: [Re: [CF-Devel] Future of Crossfire] In-Reply-To: Message-ID: Hm, guys... this makes me really really sad. And thats one of the points i decrease my work on CF. Why do you don't give my work a real look? ** I had all this included in the dx client! ** GOD DAMN i had drawed all this fucked 200 spell icons, a ONE BIG menu which list all spells and all pathes, which gives a short description of what the spell do (thx for peterm here too). You see wizard spell left, priest spells right. - You can BROWSE this menu. - You can GRAP icons from it. You can put the spells in a short cut panel (where you can see the icons and select them). - All spells have a ! 2 key combo" which can invoke or cast it! means - "open invoke menu key" + "2" + "b" = "invoke small lightning" "open invoke menu key" + "2" + "B" = "invoke forked lightning" "open cast menu key" + "2" + "b" = "cast forked lightning" and so on... I had asked in the list in the past to submit the descripton/icons/positions of the spell in this kind of menu from server like you got faces. Then you will see only the spells you REALLY know ... And when spells changes with server versions, the server can update the clients. Well... very very sad Michael > Also, currently the spells the player knows about are not communicated > effectively to the client (the client can invisibly send a cast command > to the server and then parse the returning drawinfo data). But > some better > form such that the client could know the spell lists and some information > about them would probably be desirable - it could then generate the menus > based on this info. > > Useful info IMO: spell paths player has repelled, attuned, denied > spell info: spell name, type (fire, cold, cure, etc), sp, type > (priest/mage), > and spellpath (if different from described type), perhaps image > > Client could then draw nice little icons, put little markers > depending on how > the players spellpath matches with the spell (so you can more > easily see if > you are casting an attuned spell for example). > > With something like 170 spells out there, the lists would need > to get broken > down into types at some form. > > Ideally, of course, the spell popup menus would let you set bindings > for the spells right there. > > IMO, doing all the above would be a nice addition of a feature. > Its just a > bit of work to do (I don't think any of it is actually really > hard to do). At > least on the unix side, this would be a gtk client issue only. > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From hsteoh at quickfur.yi.org Tue May 22 07:18:47 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:01:03 2005 Subject: [CF-Devel] Crossfire Scripting Language, version 1.0.0b8 In-Reply-To: ; from michael.toennies@nord-com.net on Mon, May 21, 2001 at 12:27:48PM +0200 References: <20010521003301.A31356@real-time.com> Message-ID: <20010522081847.A24567@crystal> On Mon, May 21, 2001 at 12:27:48PM +0200, Michael Toennies wrote: > Ah, don't fear... because gros has finished the main work... > Simply assume it as included. > > And the real working with it, is part of the next editor/map making/ > new quest/content part. I, for one, will definitely take advantage of the scripting capabilities in my new mapset(s) once it makes it into CVS. (I don't want to rely on it yet, until it's stable/good enough to make it into CVS.) T -- WINDOWS = Will Install Needless Data On Whole System -- CompuMan From e_vestal at hotmail.com Tue May 22 09:43:38 2001 From: e_vestal at hotmail.com (Dany Talbot) Date: Thu Jan 13 18:01:03 2005 Subject: [CF-Devel] Crossfire Scripting Language, version 1.0.0b8 Message-ID: I hope the scripting language can use events/flags. Example- if some guy assign you a quest you would get a certain flag and you could use the said flag later to verify status of the quest. ----Original Message Follows---- From: "H. S. Teoh" To: Crossfire-Devel On Mon, May 21, 2001 at 12:27:48PM +0200, Michael Toennies wrote: > Ah, don't fear... because gros has finished the main work... > Simply assume it as included. > > And the real working with it, is part of the next editor/map making/ > new quest/content part. I, for one, will definitely take advantage of the scripting capabilities in my new mapset(s) once it makes it into CVS. (I don't want to rely on it yet, until it's stable/good enough to make it into CVS.) T -- WINDOWS = Will Install Needless Data On Whole System -- CompuMan _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From leaf at real-time.com Tue May 22 11:35:44 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:01:03 2005 Subject: [CF-Devel] 2-D Tile artist (fwd) Message-ID: Can some one take the lead on this for me? Thanks. - Rick Tanner leaf@real-time.com ---------- Forwarded message ---------- Date: Tue, 22 May 2001 01:36:34 -0400 From: Devin Watson To: "leaf@real-time.com" Subject: 2-D Tile artist Hello! I would like to volunteer some of my time/effort to your project in the area of 2-D tile graphics. If you would be interested, let me know. From peterm at tonks.EECS.Berkeley.EDU Tue May 22 12:54:26 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:03 2005 Subject: [Re: [CF-Devel] Future of Crossfire] In-Reply-To: Your message of "Tue, 22 May 2001 13:44:53 +0200." Message-ID: <200105221754.f4MHsQH10600@tonks.EECS.Berkeley.EDU> > ** I had all this included in the dx client! ** Unfortunately, MT, the crossfire developers are very heavy on the Linux side of things. I, for example, never boot into windows so I cannot appreciate your work. I was glad to help you with the spell descriptions though. PeterM > GOD DAMN i had drawed all this fucked 200 spell icons, > a ONE BIG menu which list all spells and all pathes, > which gives a short description of what the spell do > (thx for peterm here too). > > You see wizard spell left, priest spells right. > > - You can BROWSE this menu. > > - You can GRAP icons from it. You can put the spells > in a short cut panel (where you can see the icons and select them). > > - All spells have a ! 2 key combo" which can invoke or cast it! > means - > "open invoke menu key" + "2" + "b" = "invoke small lightning" > "open invoke menu key" + "2" + "B" = "invoke forked lightning" > "open cast menu key" + "2" + "b" = "cast forked lightning" > and so on... > > I had asked in the list in the past to submit the descripton/icons/positions > of the spell in this kind of menu from server like you got faces. > > Then you will see only the spells you REALLY know ... > And when spells changes with server versions, the server can update the > clients. > > Well... > > very very sad > Michael > > > > Also, currently the spells the player knows about are not communicated > > effectively to the client (the client can invisibly send a cast command > > to the server and then parse the returning drawinfo data). But > > some better > > form such that the client could know the spell lists and some information > > about them would probably be desirable - it could then generate the menus > > based on this info. > > > > Useful info IMO: spell paths player has repelled, attuned, denied > > spell info: spell name, type (fire, cold, cure, etc), sp, type > > (priest/mage), > > and spellpath (if different from described type), perhaps image > > > > Client could then draw nice little icons, put little markers > > depending on how > > the players spellpath matches with the spell (so you can more > > easily see if > > you are casting an attuned spell for example). > > > > With something like 170 spells out there, the lists would need > > to get broken > > down into types at some form. > > > > Ideally, of course, the spell popup menus would let you set bindings > > for the spells right there. > > > > IMO, doing all the above would be a nice addition of a feature. > > Its just a > > bit of work to do (I don't think any of it is actually really > > hard to do). At > > least on the unix side, this would be a gtk client issue only. > > > > > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From jbontje at suespammers.org Tue May 22 13:11:53 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:03 2005 Subject: [CF-Devel] 2-D Tile artist (fwd) In-Reply-To: ; from leaf@real-time.com on Tue, May 22, 2001 at 11:35:44AM -0500 References: Message-ID: <20010522201153.A18845@mids.student.utwente.nl> On Tue, May 22, 2001 at 11:35:44AM -0500, Rick Tanner wrote: > ---------- Forwarded message ---------- > Date: Tue, 22 May 2001 01:36:34 -0400 > From: Devin Watson > To: "leaf@real-time.com" > Subject: 2-D Tile artist > > Hello! I would like to volunteer some of my time/effort to your > project in the area of 2-D tile graphics. If you would be interested, let me > know. Hello Devin, We would be very pleased if you would like to help us with the tile graphics, I don't know how much you already know about crossfire. Here is some general (contact) information for you: Website: http://crossfire.real-time.com/ Mailinglist: https://mailman.real-time.com/mailman/listinfo/crossfire-devel IRC Channel: #crossfire on irc.openprojects.net Download a client (if you haven't already done so). (for windows there is the DirectX client, for unix there is a X11 client) Play on a few servers, there are 2 kind of graphical sets: -standard set (on all servers except for crossfire.csua.berkeley.edu) -alternative set(on crossfire.csua.berkeley.edu) Most discussion about the game is on the mailinglist (subscribe using the web address from above) and on the IRC channel. Please take a look at the graphics, subscribe to the mailinglist, join us in our IRC channel and most important ASK every question you got. Thank you for your interest, Joris Bontje / mids From hsteoh at quickfur.yi.org Tue May 22 13:31:04 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:01:03 2005 Subject: [CF-Devel] Mouse proliferation -- possible solution? Message-ID: <20010522143104.A26472@crystal> I've been making some newbie maps recently, and I noticed how often I had to turn off the "generator" flag in mice so that the maps don't become unplayable very quickly due to the insane proliferation of mice. Which means I cannot use mouse generators either, since the generators would produce only mice with generator=1. But this makes things kinda boring, since you DO want the mice to reproduce, just not as quickly as they do. So here's an idea of how to solve this problem (not just with mice, but with any other monster in the game that reproduce): we already have code to occasionally generate an orc leader from the orc generators, etc.. Why not use this with mice? Every time a mouse reproduces (or a mouse generator makes a mouse), have a random chance of whether the new mouse can reproduce or not. (I.e., mouse generation can produce either fertile mice or sterile mice.) If we keep the chance to some reasonable value, this should make mice reproduce but not forever, so it won't flood the map. (This should be useful not only for mice but also for stuff like caterpillars, which also tend to reproduce endlessly.) What do you think? T -- WINDOWS = Will Install Needless Data On Whole System -- CompuMan From mwedel at scruznet.com Tue May 22 14:02:24 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:03 2005 Subject: [CF-Devel] Metaserver idle time In-Reply-To: <021601c0e2a8$6fd929e0$d9c3f082@DS28> Message-ID: On Tue, 22 May 2001, Isak Styf wrote: > Hi! > > I am currently doing some polishing to incorporate the metaserver > functionality into the java client. > > I just want to know, what exactly is the idle time a measurement of? Idle time is a measure of how many seconds it has been since the metaserver has last received an update notification from the cf server. The server only sends an update once every 5 minutes, so anything less than that on the idle time should be taken to mean the server is up. Anything more than 10-15 minutes means the server is probably down right now, but if still being provided, this indicates it may be a temporary problem. From mwedel at scruznet.com Tue May 22 14:35:22 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:03 2005 Subject: [Re: [CF-Devel] Future of Crossfire] In-Reply-To: Message-ID: On Tue, 22 May 2001, Michael Toennies wrote: > > * And there is not problem for most of our multi tile monsters for alternate > set * > * You must make the last "high" png bigger than 32x32 - like 32x40 or 32x50 > or whatever * > * its a work of some minutes to change clients for this * > * the server NEVER handles with the content of a media file, so he don't > care about it* > > * MORE: there is a GOOD point: For a high monster, you only include the foot > part of it > as object in the map - the HEAD is "in the air" - so, you reduce there > some overhead * This is for the most part true. Server does not care about the media format. So having different sized images won't bother the server at all. Sending only the foot will save some bandwidth (less map update information needed). The hard part of this is that the handling of big monsters would need to change (actually, all multipart objects) Currently all parts of big monsters are drawn/sent to the client as individual segments. That could presumably get changed (although some special information would be needed when big objects are straddling the edges of viewable maps, as the base may be off the map, but you still want the head?) The bigger problem is that right now multipart monsters are referenced with the 'head' being in the upper left. IT sounds like for issue, you really want to say what the base (foot) of the monster is and not the head - especially if the graphics are of differing sizes. There is also other trickery, as the footprint of some monsters will likely remain more than one space, so at least internally, the server needs to know that so other creatures can not enter that creatures footprint. But at the same time, for right iso, you probably only want to send one image for the entire creature. Note that I'm sure all of this is fixable. But it does start getting a bit more code on the server side. On the bright side, such an approach would basically allow you to have tall creatures/objects with the correct sized footprint (tall towers for example would only have that one space footprint, as might things like giants. From hsteoh at quickfur.yi.org Tue May 22 14:38:25 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:01:03 2005 Subject: [Re: [CF-Devel] Future of Crossfire] In-Reply-To: ; from mwedel@scruznet.com on Tue, May 22, 2001 at 12:35:22PM -0700 References: Message-ID: <20010522153825.A26709@crystal> On Tue, May 22, 2001 at 12:35:22PM -0700, Mark Wedel wrote: [snip] > On the bright side, such an approach would basically allow you to have > tall creatures/objects with the correct sized footprint (tall towers > for example would only have that one space footprint, as might things > like giants. Well, IMHO, we might as well fix this now, as it will make a lot of things more sensible (eg. why hill giants can fit on a 1-square wide north/south corridor but not in a 1-square wide east/west corridor). T -- He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter From yann.chachkoff at mailandnews.com Tue May 22 17:35:04 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:03 2005 Subject: [CF-Devel] Crossfire Scripting Language, version 1.0.0b8 In-Reply-To: References: Message-ID: <01052218350400.03974@Terminus.magellan.fpms.ac.be> Le Mardi 22 Mai 2001 10:43, vous avez ?crit : > I hope the scripting language can use events/flags. Example- if some guy > assign you a quest you would get a certain flag and you could use the said > flag later to verify status of the quest. The guard inside the Scripting Tower seems to do just what you mean (it uses a force object to save infos in your character). Chachkoff Y. From yann.chachkoff at mailandnews.com Tue May 22 21:01:03 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:04 2005 Subject: [CF-Devel] Crossfire Scripting Language, version 1.0.0b10 Message-ID: <01052222010302.03974@Terminus.magellan.fpms.ac.be> This is the latest version of the scripting extensions for crossfire. What's new from b9 ? - Death event now implemented; - Calling a script inside a script is now allowed. The 'script stack' can handle up to 127 embedded calls. - Minor bugfix in the attack handling. - Boomerang debugged somewhat. And remember: do not kill old men in the Tower... Chachkoff Y. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-scriptfire-1.0.0b10.bz2 Type: application/x-bzip2 Size: 71941 bytes Desc: Crossfire Scripting Extension Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010522/1b16c615/patch-scriptfire-1.0.0b10.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: scriptfire-maps-1.0.0b10.tar.bz2 Type: application/x-bzip2 Size: 16619 bytes Desc: Latest Maps Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010522/1b16c615/scriptfire-maps-1.0.0b10.tar.bin From tanner at real-time.com Tue May 22 15:32:15 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:04 2005 Subject: [Re: [CF-Devel] Future of Crossfire] In-Reply-To: <200105221754.f4MHsQH10600@tonks.EECS.Berkeley.EDU>; from peterm@tonks.EECS.Berkeley.EDU on Tue, May 22, 2001 at 10:54:26AM -0700 References: <200105221754.f4MHsQH10600@tonks.EECS.Berkeley.EDU> Message-ID: <20010522153215.P3924@real-time.com> Quoting Peter Mardahl (peterm@tonks.EECS.Berkeley.EDU): > > ** I had all this included in the dx client! ** > > Unfortunately, MT, the crossfire developers are very heavy > on the Linux side of things. > > I, for example, never boot into windows so I cannot > appreciate your work. > > I was glad to help you with the spell descriptions > though. I think the dx client is great, but I have only seen it over Leaf's shoulder and 1 time when I ran in in vmware. I, like Peter, don't even have windows on my machine. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From yann.chachkoff at mailandnews.com Tue May 22 21:44:52 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:04 2005 Subject: [CF-Devel] Crossfire Scripting Extensions, version 1.0.0b10 correction Message-ID: <01052222445204.03974@Terminus.magellan.fpms.ac.be> Small correction - I forgot to include it, sorry... Chachkoff Y. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-scriptfire-1.0.0b101.bz2 Type: application/x-bzip2 Size: 71898 bytes Desc: Updated Patch Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010522/de5ccd17/patch-scriptfire-1.0.0b101.bin From yann.chachkoff at mailandnews.com Tue May 22 21:36:37 2001 From: yann.chachkoff at mailandnews.com (gros) Date: Thu Jan 13 18:01:04 2005 Subject: [CF-Devel] Crossfire Scripting Language, version 1.0.0b10 correction Message-ID: <01052222363703.03974@Terminus.magellan.fpms.ac.be> Small correction - sorry for forgetting to do it... Chachkoff Y. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-scriptfire-1.0.0b101.bz2 Type: application/x-bzip2 Size: 71898 bytes Desc: Updated patch Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010522/d26163a6/patch-scriptfire-1.0.0b101.bin From oxygen at ludd.luth.se Tue May 22 16:57:01 2001 From: oxygen at ludd.luth.se (Isak Styf) Date: Thu Jan 13 18:01:04 2005 Subject: [CF-Devel] query command Message-ID: <030d01c0e30a$21463040$d9c3f082@DS28> Hi again. Is it correctly assumed that a query command is handled by sending the actual query in a drawinfo to the text screen, and then just the prompt and query type in the query command? If that really is so (it sure seems like it in the Protocol draft) I sure wonder why. Why not send the the query text in the query packet? This way the client can display a nice dialogue instead of just outputting some text in the window and expect an answer. By doing it this way the risk is high that the user dont notice the query and just wonders whats up when nothing happens. A dialogue that pops up would be much nicer in my opinion, but that would require that the actual query is in the query packet and not already written to the output area. Comments? // Isak Styf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010522/3434e51e/attachment.html From mwedel at scruznet.com Tue May 22 17:49:24 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:04 2005 Subject: [CF-Devel] query command In-Reply-To: <030d01c0e30a$21463040$d9c3f082@DS28> Message-ID: > Hi again. > > Is it correctly assumed that a query command is handled > by sending the actual query in a drawinfo to the text screen, > and then just the prompt and query type in the query command? > > If that really is so (it sure seems like it in the Protocol draft) I sure > wonder why. Why not send the the query text in the query packet? > > This way the client can display a nice dialogue instead of just > outputting some text in the window and expect an answer. > By doing it this way the risk is high that the user dont notice > the query and just wonders whats up when nothing happens. > > A dialogue that pops up would be much nicer in my opinion, but > that would require that the actual query is in the query packet and > not already written to the output area. From peterm at tonks.EECS.Berkeley.EDU Tue May 22 19:54:21 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] It is time to get rid of xpms and xbms Message-ID: <200105230054.f4N0sLP11861@tonks.EECS.Berkeley.EDU> Both the standard png set and the alternate png set are ready now. The xpm set has been merged into the alternate set in large part. There's no longer any reason to keep these older formats around. They increase the overhead to adding new art needlessly. PeterM From dnh at hawthorn.csse.monash.edu.au Tue May 22 19:58:56 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] New armour case Message-ID: Is there any major objections to me making a new case light_armour and moving bracers and girdles into it. Then allowing ruggilli and Q's to wear light armour only. The only real gains are, up to 50% acid resistance or +1 magic, +2 str and con and for ruggilli plus an extra 30 to fire (which it doesn't really need). I feel looking at the body shape of the Q that is is both acceptable and fun. The beholders and fireborn would not be able to wear any of this though. It has also been mentioned that some races, in particular beholders, should be able to wear more than two rings. I put that up to consideration. dnh From mwedel at scruznet.com Tue May 22 20:26:00 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] New armour case In-Reply-To: Message-ID: On Wed, 23 May 2001, dnh wrote: > Is there any major objections to me making a new case light_armour and > moving bracers and girdles into it. Then allowing ruggilli and Q's to > wear light armour only. The only real gains are, up to 50% acid resistance > or +1 magic, +2 str and con and for ruggilli plus an extra 30 to fire > (which it doesn't really need). > > I feel looking at the body shape of the Q that is is both acceptable and > fun. The beholders and fireborn would not be able to wear any of this > though. > > It has also been mentioned that some races, in particular beholders, > should be able to wear more than two rings. I put that up to > consideration. Rather than make another general case, I would much rather there be specific yes/no case for item types, and not just general objects. For example, being able to give the can_use_shield as a specific granularity would be nice (I would think that if Q's can use swords, they should have this). Likewise with can_use_bracers, can_use_boots, ... and so on. I would rather go this specific (1 item type) case than go for a sort of general approach which we'll probably say pretty quickly still isn't good enough. I don't want to get into particular races at this point - I'm more interested in getting an implementation that we will be happy with for a long time. Which, if we take the above a bit further, perhaps a more general approach could be called for (instead of using 20 can_use flags), have item_allowed and item_denied fields, ie, for a Q: item_allowed all item_denied armor, boots, helmet, rings Where as something like the fireborn may have something like: item_allowed ring,scroll,wand,potion,rod item_denied all Fortunately, players don't equip/unequip stuff all that often, so parsing such a form shouldn't be too costly (and if really desired, it could be made so that it is only parse at load up or in major changes, and we just have a bit field for all the object types, with 1/0 values if the player can use the item or not). This method is a bit more work, although I'm not precisely how hard, but has the advantage that it allows as much flexibility as we want - if new item type is added in the future, don't need to worry about the can_use flag - just need to update the parsing routine which will almost certainly be easier (and plus, with the default cases, may not even need to modify monsters/players much). Note having item_denied by the default (since it makes sense for most monsters) works out best, but most players would have item_allowed all. Just my not so random thoughts. From leaf at real-time.com Tue May 22 21:37:29 2001 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] Howto for using alternate graphics Message-ID: I have a rough howto for using the alternate graphics with Crossfire. http://crossfire.real-time.com/alt_images.html Please check the page for accuracy (are the steps the same for all clients, etc.) and I am open to suggestions for making the page more "alive." Perhaps side by side comparisons of graphics from the alternate set vs the main set? Thanks. - Rick Tanner leaf@real-time.com -- From hsteoh at quickfur.yi.org Tue May 22 22:46:13 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:01:05 2005 Subject: Alchemy, was Re: [CF-Devel] Future crossfire changes/projects In-Reply-To: ; from mwedel@scruznet.com on Thu, May 17, 2001 at 02:03:07PM -0700 References: <20010517091521.A8223@crystal> Message-ID: <20010522234613.A27835@crystal> On Thu, May 17, 2001 at 02:03:07PM -0700, Mark Wedel wrote: > On Thu, 17 May 2001, H. S. Teoh wrote: [snip] > One thing that may help immediately is changing the title of books > to reflect the formula. Ie, instead of just ' a recipe book', > have it be a 'recipe book of water of the wise' or the like. Good idea. Although I do somewhat like the current semi-obscure method of assigning titles to recipe books, I think the irritation value is a bit too high. > I know one problem is that while books currently appear in stores, your > not going to buy one only to find it is of a formula you already have. > Does anyone ever really buy books out of the shops? I do. And you know what -- it's almost useless to do so. You only ever get very low level formulae, usually the highest is up to 3 ingredients. 4 or 5 ingredient formulae happen very very rarely, and I've yet to see any higher than that. [snip] > 2) More difficult formula show up on more difficult maps. So on that higher > level map, your more likely to find a recipe for potions, and not how > to make water of the wise. VERY good idea. > 3) Difficulty of the book. More difficult the formula, higher the level > in the book, and thus higher literacy skill needed. I think this is already implemented? Perhaps just needs a bit more tweaking. > Unrelated, but still something I think would be nice is somehow record > what formula the player has learned. This could be used: Yes. This SHOULD be implemented. [snip] > 2) Knowledge of the formula could be required or increase chances of > actual creating products. In this way, its still desirable for > new characters to learn this information, even if the player has > all the formula information (either by looking at file or just starting > a new character) I believe the Fire Temple already has the infrastructure for this in place -- although you learn about the ingredients for making fire resistance potions, it's not until the very end that you get a message telling you that you finally learned the alchemical procedure. Now I'm not sure if you're actually prevented from making fire resistance potions without being marked in that last room first; but I'm sure that's the intention. On that note, there should be a lot more quests for alchemical formulae. If we can implement storing formulae in the player, then I'd volunteer to make a quests for a few of the more interesting formulae. > I think somewhat related to this is readable objects are just very rare in > general. You can go to the shops and maybe 10-15% of the spellbooks are > actually readable objects, and of that, some smaller portion actually related > to alchemy. But in most dungeons, spellbooks are very rare, and thus > readables even rare. So these things just do not turn up that often, even > ignoring the fact that you can't be sure what you'll get. Random treasure should have a higher chance of being readables, IMHO. T -- MS Windows: 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand 1-bit of competition. From peterm at tonks.EECS.Berkeley.EDU Tue May 22 23:16:56 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] Re: Alchemy In-Reply-To: Your message of "Tue, 22 May 2001 23:46:13 EDT." <20010522234613.A27835@crystal> Message-ID: <200105230416.f4N4Gua12325@tonks.EECS.Berkeley.EDU> > > 2) Knowledge of the formula could be required or increase chances of > > actual creating products. In this way, its still desirable for > > new characters to learn this information, even if the player has > > all the formula information (either by looking at file or just starting > > a new character) > > I believe the Fire Temple already has the infrastructure for this in place > -- although you learn about the ingredients for making fire resistance > potions, it's not until the very end that you get a message telling you > that you finally learned the alchemical procedure. Now I'm not sure if > you're actually prevented from making fire resistance potions without > being marked in that last room first; but I'm sure that's the intention. You can't use the formula learned without gaining this mark. You fail every time. Check out how this is done in the map and in the formulae file. PeterM From mwedel at scruz.net Tue May 22 23:59:03 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] Orc chop of Hideous Poison References: <20010520215108.A19238@crystal> Message-ID: <3B0B4397.BDEB2A4F@scruz.net> "H. S. Teoh" wrote: > > Somebody on IRC pointed out that although he was playing a beholder, which > has 100% poison resistance, eating an orc chop of Hideous Poison still > manages to kill him. Apparently the current code simply subtracts the hp > from the player? Perhaps it should use AT_POISON with the given amount of > damage instead... I just tried this change. It makes those items much more dangerous. This is because when you are hit with poison, you get lingering effects. The damage those lingering effects do is based on either the level of the thing that poisoned you, if non zero and its a living creature, or the damage of the poison itself. this later case is used for foods. Foods of Poison hit you with 50 hp, hideous poison would be 100. So it would wipe out a pretty powerful character pretty quickly. so this change can be put in, but the poison artifact foods need to get toned down. Otherwise, characters without poison resistance become toast really quickly. From michael.toennies at nord-com.net Wed May 23 00:23:21 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] window port Message-ID: I had ported the guile patch to windows. The windows server runs fine with it yet. Thats because the guys here has ported guile to windows. http://sourceforge.net/projects/mingwrep/ From michael.toennies at nord-com.net Wed May 23 00:35:26 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] Isometric client and server Message-ID: I had ported the dx client to David Gervais iso view. Yo can see some demo results here. They are VERY basic, i only cut 20 tiles from DGs set. But the results are stunning. I *don't* change anything on the server - only maps and clients get changed. http://mids.student.utwente.nl/~michtoen/isodemo1.png http://mids.student.utwente.nl/~michtoen/isodemo2.png http://mids.student.utwente.nl/~michtoen/isodemo3.png And thats the look if you login to a normal gfx/server. Just to show how it works. http://mids.student.utwente.nl/~michtoen/isodemo4.png some facts: - grafiks look awesome when you move. Same effect like in diablo or other real iso games. - Moving is easy. i changed the client macros, you move quick and easy. - the 3D effect is stunning - The djinn is a player (!) character - because you are now free in high, the djinn are a 1 tile monster... so its possible to include giants and others as player chars. - Tiles are not anymore 32x32 - they can be any size!! - the client puts the tiles in the right position. - the pngs itself are not bigger, because many parts are background color One point are the maps. All TECHNICAL and TRICKY stuff can stay unchanged. All changes are more cosmetical or pratical kind of nature. But it is not possible to simply convert them. This will work, but look bad. But in all cases, we has to change the background style. I will start tomorrow the server again and i will upload the modified client, so you can test for yourself. Michael From mwedel at scruz.net Wed May 23 01:32:17 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] It is time to get rid of xpms and xbms References: <200105230054.f4N0sLP11861@tonks.EECS.Berkeley.EDU> Message-ID: <3B0B5971.E034F2F5@scruz.net> Peter Mardahl wrote: > > Both the standard png set and the alternate png set > are ready now. > > The xpm set has been merged into the alternate set in > large part. > > There's no longer any reason to keep these older formats > around. They increase the overhead to adding new art > needlessly. I have no problem with the xbm and xpm going bye bye. We really need to figure out what to do with the two png sets. If they are going to remain seperate, some better form of support is desired. Ideally the server could serve up both forms. This may become more or less an iso if we go to iso (if we support both forms iso and overhead, then 2 image forms would still be needed, but the overhead png may collapse into one set for simplicity). From mwedel at scruz.net Wed May 23 01:46:09 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:05 2005 Subject: [Re: [CF-Devel] Future of Crossfire] References: <20010522153825.A26709@crystal> Message-ID: <3B0B5CB1.E1E47A19@scruz.net> "H. S. Teoh" wrote: > Well, IMHO, we might as well fix this now, as it will make a lot of things > more sensible (eg. why hill giants can fit on a 1-square wide north/south > corridor but not in a 1-square wide east/west corridor). This can of course get really complicated. For example, wyverns should rightfully be 2 space objects. However, if they arre going north/south, they should be taking 2 spaces in that direction, and if going east/west, taking two spaces in that axis. You are right, this really should be fixed. Unfortunately, its not a trivial fix. But this would save the effort of having to split up images, and in the long run make things easier. OTOH, some re-tweaking of monsters would likely be necessary - I know a lot of monsters have certain number of hp/resistances because being multipart means they are more vulnerable to spells. So for example if the monsters footprint (affectable area) is reduced, the monster may become much tougher. This can also result in some more serious perspective issues for non isomorphic users - thing the demonlord, which should have a much smaller footprint than its real size. in overhead view, it would appear you are standing beneath/on top of his chest, and so you would then need to move to his feet to attack. The same is of course true with iso, but the perspective at least makes it appear a little better). Thats one of the things I don't like about iso - the perspective does not match what the character sees - the character could be standing right next to a gemstone, but because of the isomorphic view, the gem is actually obscured from view with a tree or tower or the like. I know some games fix this by giving a hotkey to 'show all items', which then draws an outline or the like on the top layer of the screen so you can find such things. I don't know if that can be reasonably implemented in crossfire or not. From dnh at hawthorn.csse.monash.edu.au Wed May 23 04:12:29 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] It is time to get rid of xpms and xbms In-Reply-To: <200105230054.f4N0sLP11861@tonks.EECS.Berkeley.EDU> Message-ID: I agree with this idea, the sooner the better in my opinion. dnh On Tue, 22 May 2001, Peter Mardahl wrote: > > Both the standard png set and the alternate png set > are ready now. > > The xpm set has been merged into the alternate set in > large part. > > There's no longer any reason to keep these older formats > around. They increase the overhead to adding new art > needlessly. > > PeterM > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Wed May 23 04:32:25 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] New armour case In-Reply-To: Message-ID: This I to would also like, but looking through the code, your idea would be very hard to do compared to mine. If you want to do that.. I would be most happy, OTOH I will add the new case if you don't. My major concern is if people have a real problem with this. dnh On Tue, 22 May 2001, Mark Wedel wrote: > On Wed, 23 May 2001, dnh wrote: > > > Is there any major objections to me making a new case light_armour and > > moving bracers and girdles into it. Then allowing ruggilli and Q's to > > wear light armour only. The only real gains are, up to 50% acid resistance > > or +1 magic, +2 str and con and for ruggilli plus an extra 30 to fire > > (which it doesn't really need). > > > > I feel looking at the body shape of the Q that is is both acceptable and > > fun. The beholders and fireborn would not be able to wear any of this > > though. > > > > It has also been mentioned that some races, in particular beholders, > > should be able to wear more than two rings. I put that up to > > consideration. > > Rather than make another general case, I would much rather there be > specific yes/no case for item types, and not just general objects. > > For example, being able to give the can_use_shield as a specific > granularity would be nice (I would think that if Q's can use swords, > they should have this). > > Likewise with can_use_bracers, can_use_boots, ... and so on. > > I would rather go this specific (1 item type) case than go for a > sort of general approach which we'll probably say pretty quickly > still isn't good enough. > > I don't want to get into particular races at this point - I'm more interested > in getting an implementation that we will be happy with for a long time. > > Which, if we take the above a bit further, perhaps a more general approach > could be called for (instead of using 20 can_use flags), have item_allowed and > item_denied fields, ie, for a Q: > > item_allowed all > item_denied armor, boots, helmet, rings > > Where as something like the fireborn may have something like: > item_allowed ring,scroll,wand,potion,rod > item_denied all > > Fortunately, players don't equip/unequip stuff all that often, so parsing > such a form shouldn't be too costly (and if really desired, it could be made > so that it is only parse at load up or in major changes, and we just have a > bit field for all the object types, with 1/0 values if the player can use the > item or not). > > This method is a bit more work, although I'm not precisely how hard, but > has the advantage that it allows as much flexibility as we want - if new > item type is added in the future, don't need to worry about the can_use > flag - just need to update the parsing routine which will almost > certainly be easier (and plus, with the default cases, may not even > need to modify monsters/players much). > > Note having item_denied by the default (since it makes sense for most > monsters) works out best, but most players would have item_allowed all. > > Just my not so random thoughts. > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Wed May 23 05:15:45 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] Howto for using alternate graphics In-Reply-To: Message-ID: WOAH! this is GREAT. One small point, you need to run a program called filename_changer, ie sh filename_changer. This is just because make collect doesn't read images with - in them I believe.. ? pete? anyways, yeah be good to show of some alternate graphics in there as there are alot of good ones ;)) dnh On Tue, 22 May 2001, Rick Tanner wrote: > > I have a rough howto for using the alternate graphics with Crossfire. > > http://crossfire.real-time.com/alt_images.html > > Please check the page for accuracy (are the steps the same for all > clients, etc.) and I am open to suggestions for making the page more > "alive." Perhaps side by side comparisons of graphics from > the alternate set vs the main set? > > Thanks. > > - Rick Tanner > leaf@real-time.com > -- > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Wed May 23 05:21:09 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] Isometric client and server In-Reply-To: Message-ID: WOAH I like this =). You need some help with this? be totally cool to have more than just 1 x 1 players, of course I assume it can only be high.. not wide.. =). dnh On Wed, 23 May 2001, Michael Toennies wrote: > I had ported the dx client to David Gervais iso view. > > Yo can see some demo results here. > They are VERY basic, i only cut 20 tiles from DGs set. > But the results are stunning. > > I *don't* change anything on the server - only maps > and clients get changed. > > http://mids.student.utwente.nl/~michtoen/isodemo1.png > http://mids.student.utwente.nl/~michtoen/isodemo2.png > http://mids.student.utwente.nl/~michtoen/isodemo3.png > > And thats the look if you login to a normal gfx/server. > Just to show how it works. > http://mids.student.utwente.nl/~michtoen/isodemo4.png > > some facts: > > - grafiks look awesome when you move. Same effect > like in diablo or other real iso games. > - Moving is easy. i changed the client macros, you move quick and easy. > - the 3D effect is stunning > > - The djinn is a player (!) character > - because you are now free in high, the djinn are a 1 tile monster... > so its possible to include giants and others as player chars. > - Tiles are not anymore 32x32 - they can be any size!! > - the client puts the tiles in the right position. > - the pngs itself are not bigger, because many parts are background color > > One point are the maps. All TECHNICAL and TRICKY stuff can stay unchanged. > All changes are more cosmetical or pratical kind of nature. > > But it is not possible to simply convert them. This will work, but look bad. > > But in all cases, we has to change the background style. > > I will start tomorrow the server again and i will upload the modified > client, > so you can test for yourself. > > Michael > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From andi.vogl at gmx.net Wed May 23 06:12:13 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:05 2005 Subject: [CF-Devel] Isometric client and server Message-ID: <27389.990616333@www41.gmx.net> Miechael T. wrote: > I had ported the dx client to David Gervais iso view. > > Yo can see some demo results here. > They are VERY basic, i only cut 20 tiles from DGs set. > But the results are stunning. > > I *don't* change anything on the server - only maps > and clients get changed. > > http://mids.student.utwente.nl/~michtoen/isodemo1.png > http://mids.student.utwente.nl/~michtoen/isodemo2.png > http://mids.student.utwente.nl/~michtoen/isodemo3.png > > [...] > > One point are the maps. All TECHNICAL and TRICKY stuff can > stay unchanged. All changes are more cosmetical or pratical > kind of nature. > > But it is not possible to simply convert them. This will work, > but look bad. > > But in all cases, we has to change the background style. > > I will start tomorrow the server again and i will upload the > modified client, so you can test for yourself. These iso graphics kick butt! Not only that they look good and add a realistic 3d-effect, they offer much more "creative freedom" in size and shape. I would be interested to know the size of one diamond-shaped background tile. And how are multipart-images handled? I will try to help porting/creating images for this set, as far as my scedule allows. Andreas V. -- Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1! http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From reeve at ductape.net Wed May 23 09:53:03 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:06 2005 Subject: [reeve@ductape.net: Re: [CF-Devel] It is time to get rid of xpms and xbms] In-Reply-To: <20010523105206.A23097@terra>; from reeve@ductape.net on Wed, May 23, 2001 at 10:52:12 -0400 References: <200105230054.f4N0sLP11861@tonks.EECS.Berkeley.EDU> <20010523105206.A23097@terra> Message-ID: <20010523105303.B23097@terra> Oops, forgot to send this to the list :) On Wed, 23 May 2001 10:52:12 Scott Barnes wrote: On Tue, 22 May 2001 20:54:21 Peter Mardahl wrote: > > Both the standard png set and the alternate png set > are ready now. > > The xpm set has been merged into the alternate set in > large part. > > There's no longer any reason to keep these older formats > around. They increase the overhead to adding new art > needlessly. > > PeterM > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > Um, I have to disagree, unless the alternate pngs are smaller than the standard ones. My laptop only has an 800x600 LCD and the crossfire client *barely* fits in that with the xpm set (i had to modify the code to allow resizing just to get it to fit at all) So unless someone creates a png set that the tiles are the size of the xpm tiles, then I think the xpm tiles are still needed. Unless someone wants to write a new client that somehow fits in 800x600 with the png set :) -- -- -- Reeve the cat ----BEGIN FORTUNE---- Whenever people agree with me, I always think I must be wrong. - Oscar Wilde ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ -- -- -- Reeve the cat ----BEGIN FORTUNE---- Whenever people agree with me, I always think I must be wrong. - Oscar Wilde ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From reeve at ductape.net Wed May 23 09:56:57 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:06 2005 Subject: [CF-Devel] New armour case In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Tue, May 22, 2001 at 20:58:56 -0400 References: Message-ID: <20010523105657.C23097@terra> On Tue, 22 May 2001 20:58:56 dnh wrote: > Is there any major objections to me making a new case light_armour and > moving bracers and girdles into it. Then allowing ruggilli and Q's to > wear light armour only. The only real gains are, up to 50% acid > resistance > or +1 magic, +2 str and con and for ruggilli plus an extra 30 to fire > (which it doesn't really need). > > I feel looking at the body shape of the Q that is is both acceptable and > fun. The beholders and fireborn would not be able to wear any of this > though. > > It has also been mentioned that some races, in particular beholders, > should be able to wear more than two rings. I put that up to > consideration. > > dnh First, off topic, I'm running the CVS version and I don't have beholder as a choice of race :( How do I get that? Second, on topic, I think that is an excellent idea. I was actually going to suggest it myself :) Third, odd question, anyone want to explain to me how fireborns wear rings and amulets? They don't have hands, fingers, or necks :) -- -- -- Reeve the cat ----BEGIN FORTUNE---- Whenever people agree with me, I always think I must be wrong. - Oscar Wilde ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From michael.toennies at nord-com.net Wed May 23 10:05:10 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:06 2005 Subject: [CF-Devel] unix iso client Message-ID: Ok here is the deal. I had not coded a iso unix test client yet, but its simple All what you have to do is to load this zip http://mids.student.utwente.nl/~michtoen/isodata.zip This includes data to setup dx client and unix client for iso. For the dx client simply copy all this stuff in a dx client installation of v 1.20 client (make a backup forst, silly). In the map folder is the HallOfSelection and a test1 map. Ifyou had access to a server, copy this in the map folder over the original HallOfSelection (backup, silly!). Now start and create a new char... viola. For the unix client, one must change the map coding. The map has a different space, so you must handle with the map windows. You must include the gfx folder tiles so, that they overrule the server send tiles. In the system folder is a background is use (original from David Gervais), but you don't must use this yet. Change the map printing core of the unix client to this! #define MAX_MAP_XLEN 11 #define MAX_MAP_YLEN 11 #define MAP_TILE_OFFSET_Y 27 #define MAP_XSTART 373 #define MAP_YSTART 283 for(z=y=0;y; // You must get the Y-length of the sprite you blt // this is the easy but tricky part: you use the left bottom edge as blt anchor if(ylen > MAP_TILE_OFFSET_Y) ypos -= ylen-MAP_TILE_OFFSET_Y; } } Thats all. No other changes yet. enjoy Michael From dnh at hawthorn.csse.monash.edu.au Wed May 23 10:22:59 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:06 2005 Subject: [CF-Devel] New armour case In-Reply-To: <20010523105657.C23097@terra> Message-ID: On Wed, 23 May 2001, Scott Barnes wrote: > > On Tue, 22 May 2001 20:58:56 dnh wrote: > > Is there any major objections to me making a new case light_armour and > > moving bracers and girdles into it. Then allowing ruggilli and Q's to > > wear light armour only. The only real gains are, up to 50% acid > > resistance > > or +1 magic, +2 str and con and for ruggilli plus an extra 30 to fire > > (which it doesn't really need). > > > > I feel looking at the body shape of the Q that is is both acceptable and > > fun. The beholders and fireborn would not be able to wear any of this > > though. > > > > It has also been mentioned that some races, in particular beholders, > > should be able to wear more than two rings. I put that up to > > consideration. > > > > dnh > > First, off topic, I'm running the CVS version and I don't have beholder as > a choice of race :( How do I get that? it is only availible on csua as a test. It isn't in cvs, if you want it on your server you will have to add it to the archs. > Second, on topic, I think that is an excellent idea. I was actually going > to suggest it myself :) Good. =) > Third, odd question, anyone want to explain to me how fireborns wear rings > and amulets? They don't have hands, fingers, or necks :) Around the centre core of energy (were computation takes place) in a special region of room temperature air. No one knows how this came about, but fireborn love to put magical trinkits in there (some suggest it gives sexual pleasure). ;) dnh > -- > -- -- > Reeve the cat > ----BEGIN FORTUNE---- > Whenever people agree with me, I always think I must be wrong. > - Oscar Wilde > ----END FORTUNE---- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- > O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ > G e* h-- r+++ y** > ------END GEEK CODE BLOCK------ > From dnh at hawthorn.csse.monash.edu.au Wed May 23 10:24:47 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:06 2005 Subject: [reeve@ductape.net: Re: [CF-Devel] It is time to get rid of xpms and xbms] In-Reply-To: <20010523105303.B23097@terra> Message-ID: Hmm we can't cater for everyone. Firstly, no the alternate set is the same size as the standard to allow cross set swapping, plus 32x32 is the standard size. Secondly, I run 1600x* and I have trouble seeing the monsters even in 32 x 32 =). We are considering allowing the increase of viewing area, perhaps we could also add decrease (use at own peril! ;) dnh On Wed, 23 May 2001, Scott Barnes wrote: > Oops, forgot to send this to the list :) > > On Wed, 23 May 2001 10:52:12 Scott Barnes wrote: > > On Tue, 22 May 2001 20:54:21 Peter Mardahl wrote: > > > > Both the standard png set and the alternate png set > > are ready now. > > > > The xpm set has been merged into the alternate set in > > large part. > > > > There's no longer any reason to keep these older formats > > around. They increase the overhead to adding new art > > needlessly. > > > > PeterM > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > Um, I have to disagree, unless the alternate pngs are smaller than the > standard ones. My laptop only has an 800x600 LCD and the crossfire client > *barely* fits in that with the xpm set (i had to modify the code to allow > resizing just to get it to fit at all) So unless someone creates a png set > that the tiles are the size of the xpm tiles, then I think the xpm tiles > are still needed. Unless someone wants to write a new client that somehow > fits in 800x600 with the png set :) > > -- > -- -- > Reeve the cat > ----BEGIN FORTUNE---- > Whenever people agree with me, I always think I must be wrong. > - Oscar Wilde > ----END FORTUNE---- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- > O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ > G e* h-- r+++ y** > ------END GEEK CODE BLOCK------ > > -- > -- -- > Reeve the cat > ----BEGIN FORTUNE---- > Whenever people agree with me, I always think I must be wrong. > - Oscar Wilde > ----END FORTUNE---- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- > O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ > G e* h-- r+++ y** > ------END GEEK CODE BLOCK------ > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From hsteoh at quickfur.yi.org Wed May 23 10:43:39 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:01:06 2005 Subject: [CF-Devel] Orc chop of Hideous Poison In-Reply-To: <3B0B4397.BDEB2A4F@scruz.net>; from mwedel@scruz.net on Tue, May 22, 2001 at 09:59:03PM -0700 References: <20010520215108.A19238@crystal> <3B0B4397.BDEB2A4F@scruz.net> Message-ID: <20010523114339.A29783@crystal> On Tue, May 22, 2001 at 09:59:03PM -0700, Mark Wedel wrote: [snip] > This is because when you are hit with poison, you get lingering effects. The > damage those lingering effects do is based on either the level of the thing that > poisoned you, if non zero and its a living creature, or the damage of the poison > itself. > > this later case is used for foods. Foods of Poison hit you with 50 hp, hideous > poison would be 100. So it would wipe out a pretty powerful character pretty > quickly. > > so this change can be put in, but the poison artifact foods need to get toned > down. Otherwise, characters without poison resistance become toast really > quickly. How about 5 hp for foods of poison, and 20 hp for foods of hideous poison? (perhaps 30 hp or more for the latter, depending on how nasty we want to make them) Since the effect will be lingering, 5 hp may end up hitting the player for more than 50hp, so this is no weaker than the original version. T -- INTEL = Only half of "intelligence". From peterm at tonks.EECS.Berkeley.EDU Wed May 23 11:53:16 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:06 2005 Subject: [CF-Devel] It is time to get rid of xpms and xbms In-Reply-To: Your message of "Wed, 23 May 2001 10:52:06 EDT." <20010523105206.A23097@terra> Message-ID: <200105231653.f4NGrGW13285@tonks.EECS.Berkeley.EDU> We can't make everyone happy. Having the xpms and xbms triples the burden on artists adding new things. It's one of the reasons crossfire has been relatively static. Can you round up people who play on laptops to do a laptop crossfire graphics project? PeterM > On Tue, 22 May 2001 20:54:21 Peter Mardahl wrote: > > > > Both the standard png set and the alternate png set > > are ready now. > > > > The xpm set has been merged into the alternate set in > > large part. > > > > There's no longer any reason to keep these older formats > > around. They increase the overhead to adding new art > > needlessly. > > > > PeterM > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > Um, I have to disagree, unless the alternate pngs are smaller than the > standard ones. My laptop only has an 800x600 LCD and the crossfire client > *barely* fits in that with the xpm set (i had to modify the code to allow > resizing just to get it to fit at all) So unless someone creates a png set > that the tiles are the size of the xpm tiles, then I think the xpm tiles > are still needed. Unless someone wants to write a new client that somehow > fits in 800x600 with the png set :) > > -- > -- -- > Reeve the cat > ----BEGIN FORTUNE---- > Whenever people agree with me, I always think I must be wrong. > - Oscar Wilde > ----END FORTUNE---- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- > O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ > G e* h-- r+++ y** > ------END GEEK CODE BLOCK------ From peterm at tonks.EECS.Berkeley.EDU Wed May 23 11:59:38 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:06 2005 Subject: Beholder players only at CSUA Re: [CF-Devel] New armour case In-Reply-To: Your message of "Wed, 23 May 2001 10:56:57 EDT." <20010523105657.C23097@terra> Message-ID: <200105231659.f4NGxcR13305@tonks.EECS.Berkeley.EDU> Beholder players exist strictly as a local mod for fun on CSUA. I have no plans on folding it into the main version. In accord with that, I don't see much point in writing special code to cater to beholders having several rings. How fireborns use magic rings and amulets is a mystery. The real reason is that if you deny them those abilities then fireborn play becomes completely untenable. PeterM > First, off topic, I'm running the CVS version and I don't have beholder as > a choice of race :( How do I get that? > > Second, on topic, I think that is an excellent idea. I was actually going > to suggest it myself :) > Third, odd question, anyone want to explain to me how fireborns wear rings > and amulets? They don't have hands, fingers, or necks :) > > -- > -- -- > Reeve the cat > ----BEGIN FORTUNE---- > Whenever people agree with me, I always think I must be wrong. > - Oscar Wilde > ----END FORTUNE---- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- > O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ > G e* h-- r+++ y** > ------END GEEK CODE BLOCK------ > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruznet.com Wed May 23 14:28:42 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:06 2005 Subject: [reeve@ductape.net: Re: [CF-Devel] It is time to get rid of xpms and xbms] In-Reply-To: <20010523105303.B23097@terra> Message-ID: On Wed, 23 May 2001, Scott Barnes wrote: > Um, I have to disagree, unless the alternate pngs are smaller than the > standard ones. My laptop only has an 800x600 LCD and the crossfire client > *barely* fits in that with the xpm set (i had to modify the code to allow > resizing just to get it to fit at all) So unless someone creates a png set > that the tiles are the size of the xpm tiles, then I think the xpm tiles > are still needed. Unless someone wants to write a new client that somehow > fits in 800x600 with the png set :) One reason to get away from the other sets is because they images are different size - this results in much more work for graphics artist. If they were all the same size and just a matter of converting format, that wouldn't be a big deal. But when its a matter of changing size, that becomes more of a problem. As someone else said, if anything, the space requirements are going to increase, as the viewable map size increases. You can try running the client with the -split option (I'm presuming unix client here) - that will give you more control of placement and size of the various windows, so you may be able to fit things in better. Run with a larger virtual desktop? I think if we try to limit things to being able to run on an 800x600 display, we'lll run into more issues than just image size (such limitations may end up limiting client options for example.) If there is a large enough contingent that running on low-res displays is important, the ability to scale down the images could be investigated. Note that most images probably won't look all that great, but this is more likely to hit things like floors and other objects that blend together than things like objects and monsters. From tanner at real-time.com Wed May 23 14:31:51 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:06 2005 Subject: [CF-Devel] It is time to get rid of xpms and xbms In-Reply-To: ; from dnh@hawthorn.csse.monash.edu.au on Wed, May 23, 2001 at 07:12:29PM +1000 References: <200105230054.f4N0sLP11861@tonks.EECS.Berkeley.EDU> Message-ID: <20010523143151.E23363@real-time.com> Quoting dnh (dnh@hawthorn.csse.monash.edu.au): > I agree with this idea, the sooner the better in my opinion. Is there resistence to this move? If so, how about a cvs branch? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From lusena at cs.uky.edu Wed May 23 15:11:22 2001 From: lusena at cs.uky.edu (Chris Lusena) Date: Thu Jan 13 18:01:06 2005 Subject: [CF-Devel] It is time to get rid of xpms and xbms In-Reply-To: <20010523143151.E23363@real-time.com>; from tanner@real-time.com on Wed, May 23, 2001 at 02:31:51PM -0500 References: <200105230054.f4N0sLP11861@tonks.EECS.Berkeley.EDU> <20010523143151.E23363@real-time.com> Message-ID: <20010523161122.G16569@mars.cs.engr.uky.edu> On Wed, May 23, 2001 at 02:31:51PM -0500, Bob Tanner wrote: > Quoting dnh (dnh@hawthorn.csse.monash.edu.au): > > I agree with this idea, the sooner the better in my opinion. > > Is there resistence to this move? I think that the major resistance is to those of us with lower graphics than 1024x728x 24 bit color, or is it 16 bit color? I haven't seen a consensus on what the minimum video requirement should be note that 11X11 of 32x32 tiles is 352x352 pixels which makes even 640x480 a possibility with a clever client and 800x600 I think doable with a slightly better layout then what we have. Just tried 800x600 with split windows and 32x32 tiles it possible but cramped I think a little better designed status subwins and it would be better, a small configuration flag on the unix clients (-lowres) would do the trick I think. What need to be decided is who get left out on the iceflow this time and then we wait at least 2-3 years before we leave anyone else. If I'm out on the iceflow because of only 8 bit colours then so be it. I think that one size and formate of titles an two color modes is the most we can get out of artists. The question is what to color modes, and will the artists do it? The 8bit colour will allow even most VGA people play if some one write the client write. (Though it will have to be a very different client I think) -- Chris Lusena Office: 762 AH Department of Computer Science Phone: 859-257-3678 773 Anderson Hall Fax: 859-323-1971 University of Kentucky Email: lusena@cs.uky.edu Lexington, KY 40506-0046 U.S.A. http://www.cs.uky.edu/~lusena From mwedel at scruznet.com Wed May 23 15:49:50 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:06 2005 Subject: [CF-Devel] It is time to get rid of xpms and xbms In-Reply-To: <20010523143151.E23363@real-time.com> Message-ID: On Wed, 23 May 2001, Bob Tanner wrote: > > Is there resistence to this move? > > If so, how about a cvs branch? There only needs to be a branch if the other formats are continued to be worked on. Note that when something is deleted from cvs, it isn't truly deleted, it just doesn't show up anymore. So for example, if all the xbm and xpm files are deleted, you could still do a cvs checkout -r rel-1-0-0 and get all the files, including xbm and xpm, as well as everything else that is in the 1.0.0 release. One issue here is that even with a branch, presumably the older images will not be included with the server (which does help reduce the distribution size quite a bit), which means the clients need to get the images themselves. And this then poses problems for new images for added archs/maps. Of course, if we go to iso, this probably becomes an even bigger issue, as effectively the viewing area is tilted 45 degrees, making it wider and taller than before, but with the same potential amount of graphic content. From mwedel at scruznet.com Wed May 23 15:56:42 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:06 2005 Subject: [CF-Devel] It is time to get rid of xpms and xbms In-Reply-To: <20010523161122.G16569@mars.cs.engr.uky.edu> Message-ID: On Wed, 23 May 2001, Chris Lusena wrote: > I think that the major resistance is to those of us with lower > graphics than 1024x728x 24 bit color, or is it 16 bit color? Realistically, the number of bits isn't really important. While the graphics will look best with 16+ bit displays, it should still work on 8 bit displays (it does some primitive color matching, which works, but images won't look as good, just as what happens with any reduced color mechanism) > > I haven't seen a consensus on what the minimum video requirement should > be note that 11X11 of 32x32 tiles is 352x352 pixels which makes even > 640x480 a possibility with a clever client and 800x600 I think > doable with a slightly better layout then what we have. > Just tried 800x600 with split windows and 32x32 tiles it possible but > cramped I think a little better designed status subwins > and it would be better, a small configuration flag on the unix clients > (-lowres) would do the trick I think. Things like inventory and look windows could also be done in a more space sensitive fashion. Remove the icon, and just put weight after the name is parens would make it much more compact (a 32 high icon really cuts down on number of objects that can be displayed, where as with just font, you probably could fit 2-3 times more objects in) Realistically, I have big hi-res displays, so am not that interested in optimizing for small displays. But of course, it only takes on person to do so. I already described optimizing the inventory/look windows for more space. I don't think much can be done with the information window other than to make it smaller. Potentially, the stat window (one which has str, dex, etc) isn't needed all that much - putting a toggle between that and the status bar window would save some space there (as the status bar window has all the important information.) From sniper at citilink.com Wed May 23 16:27:40 2001 From: sniper at citilink.com (Mike Ponicki) Date: Thu Jan 13 18:01:06 2005 Subject: [CF-Devel] Isometric client and server In-Reply-To: Message-ID: this looks REALLY cool. that's all I need to say :) -Sniper On Wed, 23 May 2001, Michael Toennies wrote: > I had ported the dx client to David Gervais iso view. > > Yo can see some demo results here. > They are VERY basic, i only cut 20 tiles from DGs set. > But the results are stunning. > > I *don't* change anything on the server - only maps > and clients get changed. > > http://mids.student.utwente.nl/~michtoen/isodemo1.png > http://mids.student.utwente.nl/~michtoen/isodemo2.png > http://mids.student.utwente.nl/~michtoen/isodemo3.png > > And thats the look if you login to a normal gfx/server. > Just to show how it works. > http://mids.student.utwente.nl/~michtoen/isodemo4.png > > some facts: > > - grafiks look awesome when you move. Same effect > like in diablo or other real iso games. > - Moving is easy. i changed the client macros, you move quick and easy. > - the 3D effect is stunning > > - The djinn is a player (!) character > - because you are now free in high, the djinn are a 1 tile monster... > so its possible to include giants and others as player chars. > - Tiles are not anymore 32x32 - they can be any size!! > - the client puts the tiles in the right position. > - the pngs itself are not bigger, because many parts are background color > > One point are the maps. All TECHNICAL and TRICKY stuff can stay unchanged. > All changes are more cosmetical or pratical kind of nature. > > But it is not possible to simply convert them. This will work, but look bad. > > But in all cases, we has to change the background style. > > I will start tomorrow the server again and i will upload the modified > client, > so you can test for yourself. > > Michael > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From lusena at cs.uky.edu Wed May 23 16:50:50 2001 From: lusena at cs.uky.edu (Chris Lusena) Date: Thu Jan 13 18:01:06 2005 Subject: [CF-Devel] It is time to get rid of xpms and xbms In-Reply-To: ; from mwedel@scruznet.com on Wed, May 23, 2001 at 01:56:42PM -0700 References: <20010523161122.G16569@mars.cs.engr.uky.edu> Message-ID: <20010523175050.H16569@mars.cs.engr.uky.edu> On Wed, May 23, 2001 at 01:56:42PM -0700, Mark Wedel wrote: > On Wed, 23 May 2001, Chris Lusena wrote: > > I think that the major resistance is to those of us with lower > > graphics than 1024x728x 24 bit color, or is it 16 bit color? > > Realistically, the number of bits isn't really important. While the > graphics will look best with 16+ bit displays, it should still work on > 8 bit displays (it does some primitive color matching, which works, > but images won't look as good, just as what happens with any reduced > color mechanism) I've used the current color matching 1.0.0 and I can say that the color matching is _very_bad_ IMHO, in fact I find it so bad as to limit playablity. I've switch _back_ to xpm from png because the color matching is so bad, even though since I have sufficient resolution I prefer the bigger tiles. Though I am on a sun which I believe are know for bad X implementations and poor color control, so it could be something odd my system. -- Chris Lusena Office: 762 AH Department of Computer Science Phone: 859-257-3678 773 Anderson Hall Fax: 859-323-1971 University of Kentucky Email: lusena@cs.uky.edu Lexington, KY 40506-0046 U.S.A. http://www.cs.uky.edu/~lusena From mwedel at scruznet.com Wed May 23 17:20:52 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:06 2005 Subject: [CF-Devel] It is time to get rid of xpms and xbms In-Reply-To: <20010523175050.H16569@mars.cs.engr.uky.edu> Message-ID: On Wed, 23 May 2001, Chris Lusena wrote: > I've used the current color matching 1.0.0 and I can say that the color > matching is _very_bad_ IMHO, in fact I find it so bad as to limit > playablity. I've switch _back_ to xpm from png because the color > matching is so bad, even though since I have sufficient resolution > I prefer the bigger tiles. Though I am on a sun which I believe are > know for bad X implementations and poor color control, so it could > be something odd my system. X doesn't really provide any color matching - its all left up to the client (or libraries it uses). Note that quality of color matching will depend a lot on colors available for the application. IF your running netscape and have some pretty color background, that really doesn't leave much in the way of colors for the client to use. The biggest problem is that the client doesn't know what colors will be used in the future. What it probably really needs to do is pre-allocate a representative set of colors and then match against those. Right now, for example, if you re-join the game in say the middle of the wilderness, that will be a lot of greens and some browns, and so it will allocate a bunch of those colors. But now when you wander to the city which uses more greys, it my start running out of unique colors at that point - it may have 40 greens and 3 greys. Much better to have say 10 greens and 10 greys and so forth. But color matching always has some problems. For example, many of the newer graphics have nice tones - say something like a smooth transition from light grey to dark grey. With color matching, that may get reduced to 2 colors, so there is a jarring break in the color, and that break may not be in a place that looks really good. There has been discussion to ditch 8 bit and require 16 bit+ displays. I don't really agree with that - certainly graphics should be designed for higher bit displays, but if the work to do color matching at least presents a playbable game (albeit not the most pretty), I don't see any reason to remove that feature. From michael.toennies at nord-com.net Wed May 23 17:16:04 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] It is time to get rid of xpms and xbms In-Reply-To: <20010523175050.H16569@mars.cs.engr.uky.edu> Message-ID: Well, its as i said long before: the xpm/xbm set is designed. The png set is assembled. There is only one way to avoid it: make a big cut and start from bottom up. I will soon drop some for the iso set, perhaps we can make here the deal and hit 2 flies at once: new set and new style. Again: we don't speak about monsters. The nice of the flat monsters is, that they fit more or less in nearly all true iso gfx. Michael > On Wed, May 23, 2001 at 01:56:42PM -0700, Mark Wedel wrote: > > On Wed, 23 May 2001, Chris Lusena wrote: > > > I think that the major resistance is to those of us with lower > > > graphics than 1024x728x 24 bit color, or is it 16 bit color? > > > > Realistically, the number of bits isn't really important. While the > > graphics will look best with 16+ bit displays, it should still work on > > 8 bit displays (it does some primitive color matching, which works, > > but images won't look as good, just as what happens with any reduced > > color mechanism) > > I've used the current color matching 1.0.0 and I can say that the color > matching is _very_bad_ IMHO, in fact I find it so bad as to limit > playablity. I've switch _back_ to xpm from png because the color > matching is so bad, even though since I have sufficient resolution > I prefer the bigger tiles. Though I am on a sun which I believe are > know for bad X implementations and poor color control, so it could > be something odd my system. > > > -- > Chris Lusena Office: 762 AH > Department of Computer Science Phone: 859-257-3678 > 773 Anderson Hall Fax: 859-323-1971 > University of Kentucky Email: lusena@cs.uky.edu > Lexington, KY 40506-0046 U.S.A. http://www.cs.uky.edu/~lusena > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From reeve at ductape.net Thu May 24 08:44:00 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] It is time to get rid of xpms and xbms In-Reply-To: <200105231653.f4NGrGW13285@tonks.EECS.Berkeley.EDU> References: <200105231653.f4NGrGW13285@tonks.EECS.Berkeley.EDU> Message-ID: <990711841.22995.0.camel@terra> On 23 May 2001 09:53:16 -0700, Peter Mardahl wrote: > > We can't make everyone happy. > > Having the xpms and xbms triples the burden on artists > adding new things. It's one of the reasons crossfire > has been relatively static. > > Can you round up people who play on laptops to do > a laptop crossfire graphics project? > > > PeterM Sounds like a good SourceForge project to me :) Want me to open one up? -- -- Reeve the cat ----BEGIN FORTUNE---- It seems intuitively obvious to me, which means that it might be wrong. -- Chris Torek ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From mavxg at warwick.ac.uk Thu May 24 03:34:40 2001 From: mavxg at warwick.ac.uk (Ben Norrington) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] 25 by 25 instead of 11 by 11 map Message-ID: <990693280.541.0.camel@pc-res-10> Would anyone be interested in a mod to the client and server that uped the visable map size to 25 by 25. I have made a mod for the 0.98 versions of the linux client and server. It is not backwardly compatible with the old clients tho. I would like to know if you think that this would be a good change or whether I sould just take all your code and write crosswater or something (GPL'ed of course). Also would some kind of time system be of interest so that the maps where dark at certain times of the day or so that monsters were not out all the time. If this has all been done before I apoligise - I am new to this and only have version 0.98. Thanks for any input Ben From peterm at tonks.EECS.Berkeley.EDU Thu May 24 11:21:39 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] 25 by 25 instead of 11 by 11 map In-Reply-To: Your message of "24 May 2001 09:34:40 BST." <990693280.541.0.camel@pc-res-10> Message-ID: <200105241621.f4OGLdb17390@tonks.EECS.Berkeley.EDU> Hello, Yes, this is interesting in general. It's nice to have someone hacking on things independently. We did a poll recently, and it seems people would indeed like a larger display... We thought it'd be easier to do it this way though: increase the viewable size to "NxN", but have the server only keep "up to date" 11x11. The client would be responsible for remembering and mapping outside that 11x11, and would add grayness to things it didn't have current data on, a "fog of war" type of effect. That would give more viewable area without increasing the bandwidth overhead at all, and has the further advantage of being mostly backward compatible, and would require very little change to the server. Also, it would allow the client to do 30x30 (or NxN) if he had screen space for it. Would you be interested in doing that? It's significantly more coding than you have already done, but it has its advantages. If not, then we may simply (after some democratic process) adopt your patches regardless. PeterM > Would anyone be interested in a mod to the client and server that uped > the visable map size to 25 by 25. I have made a mod for the 0.98 > versions of the linux client and server. It is not backwardly compatible > with the old clients tho. I would like to know if you think that this > would be a good change or whether I sould just take all your code and > write crosswater or something (GPL'ed of course). Also would some kind > of time system be of interest so that the maps where dark at certain > times of the day or so that monsters were not out all the time. If this > has all been done before I apoligise - I am new to this and only have > version 0.98. > > Thanks for any input > > Ben > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From highway at cstone.net Thu May 24 14:11:34 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] troubles compiling 1.0 (warning long!) Message-ID: <3B0D5CE6.C53A560E@cstone.net> I downloaded the 1.0 source code today from sourceforge so that I could upgrade my .98.0 server. I'm finding, though, that it will not compile the crossedit or crossfire binaries. I'm running a Red Hat 7.1 machine on a 1.3 GHz Pentium with 512 MB of RAM and a 40 GB hard drive. Therefore, space or performance is not an issue. The first file shows running configure. I'm not using any command line flags; I want it to run in /usr/games/crossfire. All of this is exactly the same as when I installed .98.0. The second file shows the results of the make depend. You can see some errors start to show up in there. I then edit the include/config.h file. The only changes I make are: * enable polymorph by commenting out the "define NO_POLYMORPH". * enable permanent experience * enable it so that player saves are in a bed The next file shows the make. When running (I ran it as make >> crossfire.make to save the results) I got these errors: metaserver.c: In function `metaserver_update': metaserver.c:136: warning: passing arg 5 of `sendto' from incompatible pointer type spell_util.c: In function `cast_spell': spell_util.c:575: invalid lvalue in assignment make[1]: *** [spell_util.o] Error 1 Finally, I do the make install and get similar errors: spell_util.c: In function `cast_spell': spell_util.c:575: invalid lvalue in assignment make[1]: *** [spell_util.o] Error 1 When I do an "ls" I don't see crossfire at all in there...this is an ls of /usr/games/crossfire/bin/ in the final file. Once again, sorry about the length of this mail. I'd appreciate some help, as I'm doing this exactly the same as last time (according to my .bash_history) and it's not working, and that means we're out a server until fixed. :) Thanks, seanMike -------------- next part -------------- loading cache ./config.cache checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking how to run the C preprocessor... (cached) gcc -E checking for flex... (cached) lex checking for yywrap in -ll... (cached) no checking for mawk... (cached) mawk checking for a BSD compatible install... (cached) /usr/bin/install -c checking whether ln -s works... (cached) yes checking whether make sets ${MAKE}... (cached) yes checking for ranlib... (cached) ranlib checking for mkdir... (cached) /bin/mkdir checking for tar... (cached) /bin/tar checking for makedepend... no checking for cp... (cached) /bin/cp checking for basename... (cached) /bin/basename checking for sed... (cached) /bin/sed checking for rm... (cached) /bin/rm checking for ar... (cached) /usr/bin/ar checking for latex... no checking for gzip... (cached) /usr/bin/gzip checking for gunzip... (cached) /usr/bin/gunzip checking for perl... (cached) /usr/bin/perl checking for compress... (cached) /usr/bin/compress checking for uncompress... (cached) /usr/bin/uncompress checking for bzip2... (cached) /usr/bin/bzip2 checking for bunzip2... (cached) /usr/bin/bunzip2 checking for sh... (cached) /bin/sh checking for main in -lnsl... (cached) yes checking for main in -lsocket... (cached) no checking for X... (cached) no checking for main in -lX11... (cached) no checking for main in -lICE... (cached) no checking for main in -lSM... (cached) no checking for main in -lXext... (cached) no checking for main in -lXt... (cached) no checking for main in -lXmu... (cached) no checking for main in -lXaw... (cached) no checking for main in -lXpm... (cached) no checking for main in -lm... (cached) yes checking for main in -lpng... (cached) no checking for main in -lcrypt... (cached) yes checking for des_crypt in -ldes... (cached) no checking for main in -ldmalloc... (cached) no checking for dirent.h that defines DIR... (cached) yes checking for opendir in -ldir... (cached) no checking for ANSI C header files... (cached) yes checking for fcntl.h... (cached) yes checking for limits.h... (cached) yes checking for malloc.h... (cached) yes checking for strings.h... (cached) yes checking for sys/file.h... (cached) yes checking for sys/ioctl.h... (cached) yes checking for sys/time.h... (cached) yes checking for time.h... (cached) yes checking for unistd.h... (cached) yes checking for stddef.h... (cached) yes checking for stdlib.h... (cached) yes checking for sys/ttycom.h... (cached) no checking for sys/termios.h... (cached) yes checking for crypt.h... (cached) yes checking for arpa/inet.h... (cached) yes checking for des.h... (cached) no checking for working const... (cached) yes checking for inline... (cached) inline checking for pid_t... (cached) yes checking for size_t... (cached) yes checking whether time.h and sys/time.h may both be included... (cached) yes checking whether struct tm is in sys/time.h or time.h... (cached) time.h checking for uid_t in sys/types.h... (cached) yes checking whether gcc needs -traditional... (cached) no checking for 8-bit clean memcmp... (cached) yes checking whether setpgrp takes no argument... (cached) yes checking return type of signal handlers... (cached) void checking for strftime... (cached) yes checking for vprintf... (cached) yes checking for gettimeofday... (cached) yes checking for mkdir... (cached) yes checking for mktime... (cached) yes checking for rmdir... (cached) yes checking for select... (cached) yes checking for socket... (cached) yes checking for strcspn... (cached) yes checking for strerror... (cached) yes checking for strspn... (cached) yes checking for strstr... (cached) yes checking for strtol... (cached) yes checking for strcasecmp... (cached) yes checking for strncasecmp... (cached) yes checking for snprintf... (cached) yes checking for setsid... (cached) yes checking for srandom... (cached) yes checking for getdtablesize... (cached) yes checking for srand48... (cached) yes checking for srand... (cached) yes checking for sysconf... (cached) yes checking for scandir... (cached) yes checking how many args gettimeofday uses... (cached) two arguments If you are upgrading an 0.95.3 or earlier release, you may want to use --enable-old-layout to use the same install directories creating ./config.status creating Makefile creating crossedit/Makefile creating crossedit/doc/Makefile creating crossedit/include/Makefile creating crossedit/Cnv/Makefile creating crossedit/bitmaps/Makefile creating doc/Makefile creating doc/spell-docs/Makefile creating doc/spoiler/Makefile creating doc/spoiler-html/Makefile creating doc/playbook/Makefile creating doc/playbook-html/Makefile creating lib/Makefile creating random_maps/Makefile creating socket/Makefile creating server/Makefile creating include/Makefile creating utils/Makefile creating lib/xpmtopix.pl creating lib/checkarch.pl creating lib/collect.pl creating utils/add_throw.perl creating utils/crossloop creating utils/crossloop.pl creating utils/metaserver.pl creating common/Makefile creating include/autoconf.h include/autoconf.h is unchanged -------------- next part -------------- making depend in common... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/common' g -O2 -I../include -I./../include -- anim.c arch.c button.c exp.c friend.c glue.c holy.c info.c image.c init.c item.c links.c living.c loader.c logger.c los.c ltostr.c map.c object.c porting.c player.c re-cmp.c readable.c recipe.c shstr.c sqrt.c time.c treasure.c make[1]: g: Command not found make[1]: [depend] Error 127 (ignored) make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/common' making depend in random_maps... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/random_maps' g -O2 -I../include -I. -I../include -- random_map.c room_gen_onion.c room_gen_spiral.c maze_gen.c reader.c floor.c wall.c monster.c door.c decor.c exit.c treasure.c special.c style.c rogue_layout.c snake.c square_spiral.c expand2x.c make[1]: g: Command not found make[1]: [depend] Error 127 (ignored) make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/random_maps' making depend in socket... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/socket' g -O2 -I../include -I./../include -- info.c init.c item.c loop.c lowlevel.c metaserver.c request.c sounds.c make[1]: g: Command not found make[1]: [depend] Error 127 (ignored) make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/socket' making depend in server... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/server' g -O2 -I../include -I./../include -I../include -- alchemy.c apply.c attack.c ban.c c_chat.c c_misc.c c_move.c c_new.c c_object.c c_party.c c_range.c c_wiz.c commands.c daemon.c disease.c egoitem.c encounter.c hiscore.c gods.c init.c login.c main.c monster.c move.c pets.c player.c resurrection.c rune.c shop.c skills.c skill_util.c spell_effect.c spell_util.c swamp.c swap.c time.c make[1]: g: Command not found make[1]: [depend] Error 127 (ignored) make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/server' making depend in include... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/include' make[1]: Nothing to be done for `depend'. make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/include' making depend in lib... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/lib' makedepend -- -I../include -- make[1]: makedepend: Command not found make[1]: *** [depend] Error 127 make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/lib' making depend in utils... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/utils' make[1]: `depend' is up to date. make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/utils' making depend in doc... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/doc' make[1]: Nothing to be done for `depend'. make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/doc' -------------- next part -------------- making all in common... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/common' gcc -g -O2 -I../include -I./../include -c anim.c gcc -g -O2 -I../include -I./../include -c arch.c gcc -g -O2 -I../include -I./../include -c button.c gcc -g -O2 -I../include -I./../include -c exp.c gcc -g -O2 -I../include -I./../include -c friend.c gcc -g -O2 -I../include -I./../include -c glue.c gcc -g -O2 -I../include -I./../include -c holy.c gcc -g -O2 -I../include -I./../include -c info.c gcc -g -O2 -I../include -I./../include -c image.c gcc -g -O2 -I../include -I./../include -c init.c gcc -g -O2 -I../include -I./../include -c item.c gcc -g -O2 -I../include -I./../include -c links.c gcc -g -O2 -I../include -I./../include -c living.c gcc -g -O2 -I../include -I./../include -c loader.c gcc -g -O2 -I../include -I./../include -c logger.c gcc -g -O2 -I../include -I./../include -c los.c gcc -g -O2 -I../include -I./../include -c ltostr.c gcc -g -O2 -I../include -I./../include -c map.c gcc -g -O2 -I../include -I./../include -c object.c gcc -g -O2 -I../include -I./../include -c porting.c gcc -g -O2 -I../include -I./../include -c player.c gcc -g -O2 -I../include -I./../include -c re-cmp.c gcc -g -O2 -I../include -I./../include -c readable.c gcc -g -O2 -I../include -I./../include -c recipe.c gcc -g -O2 -I../include -I./../include -c shstr.c gcc -g -O2 -I../include -I./../include -c sqrt.c gcc -g -O2 -I../include -I./../include -c time.c gcc -g -O2 -I../include -I./../include -c treasure.c /bin/rm -f libcross.a /usr/bin/ar cq libcross.a anim.o arch.o button.o exp.o friend.o glue.o holy.o info.o image.o init.o item.o links.o living.o loader.o logger.o los.o ltostr.o map.o object.o porting.o player.o re-cmp.o readable.o recipe.o shstr.o sqrt.o time.o treasure.o ranlib libcross.a make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/common' making all in random_maps... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/random_maps' gcc -g -O2 -I../include -I. -c random_map.c gcc -g -O2 -I../include -I. -c room_gen_onion.c gcc -g -O2 -I../include -I. -c room_gen_spiral.c gcc -g -O2 -I../include -I. -c maze_gen.c gcc -g -O2 -I../include -I. -c reader.c gcc -g -O2 -I../include -I. -c floor.c gcc -g -O2 -I../include -I. -c wall.c gcc -g -O2 -I../include -I. -c monster.c gcc -g -O2 -I../include -I. -c door.c gcc -g -O2 -I../include -I. -c decor.c gcc -g -O2 -I../include -I. -c exit.c gcc -g -O2 -I../include -I. -c treasure.c gcc -g -O2 -I../include -I. -c special.c gcc -g -O2 -I../include -I. -c style.c gcc -g -O2 -I../include -I. -c rogue_layout.c gcc -g -O2 -I../include -I. -c snake.c gcc -g -O2 -I../include -I. -c square_spiral.c gcc -g -O2 -I../include -I. -c expand2x.c /bin/rm -f random_map gcc -g -O2 -I../include -I. -c standalone.c gcc -o random_map random_map.o room_gen_onion.o room_gen_spiral.o maze_gen.o reader.o floor.o wall.o monster.o door.o decor.o exit.o treasure.o special.o style.o rogue_layout.o snake.o square_spiral.o expand2x.o standalone.o -lcrypt -lm -lnsl -L../common -lcross /bin/rm -f random_map.a /usr/bin/ar clq random_map.a random_map.o room_gen_onion.o room_gen_spiral.o maze_gen.o reader.o floor.o wall.o monster.o door.o decor.o exit.o treasure.o special.o style.o rogue_layout.o snake.o square_spiral.o expand2x.o make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/random_maps' making all in socket... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/socket' gcc -g -O2 -I../include -I./../include -c info.c gcc -g -O2 -I../include -I./../include -c init.c gcc -g -O2 -I../include -I./../include -c item.c gcc -g -O2 -I../include -I./../include -c loop.c gcc -g -O2 -I../include -I./../include -c lowlevel.c gcc -g -O2 -I../include -I./../include -c metaserver.c gcc -g -O2 -I../include -I./../include -c request.c gcc -g -O2 -I../include -I./../include -c sounds.c /bin/rm -f socket.a /usr/bin/ar cq socket.a info.o init.o item.o loop.o lowlevel.o metaserver.o request.o sounds.o ranlib socket.a make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/socket' making all in server... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/server' gcc -g -O2 -I../include -I./../include -c alchemy.c gcc -g -O2 -I../include -I./../include -c apply.c gcc -g -O2 -I../include -I./../include -c attack.c gcc -g -O2 -I../include -I./../include -c ban.c gcc -g -O2 -I../include -I./../include -c c_chat.c gcc -g -O2 -I../include -I./../include -c c_misc.c gcc -g -O2 -I../include -I./../include -c c_move.c gcc -g -O2 -I../include -I./../include -c c_new.c gcc -g -O2 -I../include -I./../include -c c_object.c gcc -g -O2 -I../include -I./../include -c c_party.c gcc -g -O2 -I../include -I./../include -c c_range.c gcc -g -O2 -I../include -I./../include -c c_wiz.c gcc -g -O2 -I../include -I./../include -c commands.c gcc -g -O2 -I../include -I./../include -c daemon.c gcc -g -O2 -I../include -I./../include -c disease.c gcc -g -O2 -I../include -I./../include -c egoitem.c gcc -g -O2 -I../include -I./../include -c encounter.c gcc -g -O2 -I../include -I./../include -c hiscore.c gcc -g -O2 -I../include -I./../include -c gods.c gcc -g -O2 -I../include -I./../include -c init.c gcc -g -O2 -I../include -I./../include -c login.c gcc -g -O2 -I../include -I./../include -c main.c gcc -g -O2 -I../include -I./../include -c monster.c gcc -g -O2 -I../include -I./../include -c move.c gcc -g -O2 -I../include -I./../include -c pets.c gcc -g -O2 -I../include -I./../include -c player.c gcc -g -O2 -I../include -I./../include -c resurrection.c gcc -g -O2 -I../include -I./../include -c rune.c gcc -g -O2 -I../include -I./../include -c shop.c gcc -g -O2 -I../include -I./../include -c skills.c gcc -g -O2 -I../include -I./../include -c skill_util.c gcc -g -O2 -I../include -I./../include -c spell_effect.c gcc -g -O2 -I../include -I./../include -c spell_util.c make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/server' making all in include... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/include' making all in lib... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/lib' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/lib' making all in utils... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/utils' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/utils' making all in doc... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/doc' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/doc' -------------- next part -------------- making install in common... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/common' make[1]: Nothing to be done for `install'. make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/common' making install in random_maps... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/random_maps' /usr/bin/install -c random_map /usr/games/crossfire/bin/random_map make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/random_maps' making install in socket... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/socket' make[1]: Nothing to be done for `install'. make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/socket' making install in server... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/server' gcc -g -O2 -I../include -I./../include -c spell_util.c make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/server' making install in include... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/include' make[1]: Nothing to be done for `install'. make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/include' making install in lib... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/lib' if [ ! -d /usr/games/crossfire/share/crossfire/help ]; then \ echo "Creating directory /usr/games/crossfire/share/crossfire/help"; \ /bin/mkdir -p /usr/games/crossfire/share/crossfire/help; \ fi; Installing ./help/apply Installing ./help/bind Installing ./help/cast Installing ./help/golem Installing ./help/invoke Installing ./help/keys Installing ./help/mark Installing ./help/melee Installing ./help/mouse Installing ./help/move Installing ./help/name Installing ./help/output Installing ./help/output-count Installing ./help/output-sync Installing ./help/party Installing ./help/pickup Installing ./help/quit Installing ./help/range Installing ./help/save Installing ./help/sort_inventory Installing ./help/spells Installing ./help/statistics Installing ./help/take Installing ./help/traps Installing ./help/unbind Installing ./help/usekeys Installing ./artifacts Installing ./ban_file Installing ./def_help Installing ./dm_file Installing ./forbid Installing ./formulae Installing ./messages Installing ./motd Installing ./races Installing ./skill_params Installing ./spell_params Installing ./treasures Installing ./animations Installing ./archetypes Installing ./bmaps Installing ./bmaps.paths Installing ./crossfire.xpm Installing ./faces Installing ./crossfire.xbm Installing ./crossfire.png Installing ./xpmtopix.pl Installing ./collect.pl Installing ./util.pl touch /usr/games/crossfire/var/crossfire/highscore touch /usr/games/crossfire/var/crossfire/bookarch touch /usr/games/crossfire/var/crossfire/temp.maps make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/lib' making install in utils... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/utils' rm -f /usr/games/crossfire/bin/flushlocks sed s%xxxx%%g /usr/games/crossfire/bin/flushlocks chmod 755 /usr/games/crossfire/bin/flushlocks rm -f /usr/games/crossfire/bin/crossloop.pl sed s%BINDIR%/usr/games/crossfire/bin%g /usr/games/crossfire/bin/crossloop.pl chmod 755 /usr/games/crossfire/bin/crossloop.pl rm -f /crossloop sed s%BINDIR%/usr/games/crossfire/bin%g /usr/games/crossfire/bin/crossloop chmod 755 /usr/games/crossfire/bin/crossloop /usr/bin/install -c mktable.script /usr/games/crossfire/bin/mktable /usr/bin/install -c add_throw.perl /usr/games/crossfire/bin/add_throw make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/utils' making install in doc... make[1]: Entering directory `/home/smw4s/crossfire-1.0.0/doc' /usr/bin/install -c ./crossedit.man /usr/games/crossfire/man/man6/crossedit.6 /usr/bin/install -c ./crossfire.man /usr/games/crossfire/man/man6/crossfire.6 make[1]: Leaving directory `/home/smw4s/crossfire-1.0.0/doc' -------------- next part -------------- total 752 -rwxr-xr-x 1 root root 683 May 24 15:07 add_throw -rwxr-xr-x 1 root root 8684 May 24 15:07 collect.pl -rwxr-xr-x 1 root root 567 May 24 15:07 crossloop -rwxr-xr-x 1 root root 1468 May 24 15:07 crossloop.pl -rwxr-xr-x 1 root root 419 May 24 15:07 flushlocks -rwxr-xr-x 1 root root 2025 May 24 15:07 mktable -rwxr-xr-x 1 root root 1519 May 24 15:07 util.pl -rwxr-xr-x 1 root root 4110 May 24 15:07 xpmtopix.pl -rwxr-xr-x 1 root root 718222 May 24 15:07 random_map From mwedel at scruznet.com Thu May 24 15:41:02 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] troubles compiling 1.0 (warning long!) In-Reply-To: <3B0D5CE6.C53A560E@cstone.net> Message-ID: There is a typo for the polymorph code. For now, turn of polymorph. I will fix this in CVS shortly. From highway at cstone.net Thu May 24 15:57:29 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] troubles compiling 1.0 (warning long!) References: Message-ID: <3B0D75B9.228F72A3@cstone.net> Thanks to those who helped; I turned off polymorph and it worked. SeanMike From pc-crossfire at crowcastle.net Thu May 24 16:03:00 2001 From: pc-crossfire at crowcastle.net (pc-crossfire@crowcastle.net) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] 25 by 25 instead of 11 by 11 map Message-ID: <200105242103.RAA00813@localhost.localdomain> I for one would love a larger viewable area, buy why hard-code a specific number? How about having the server send a message to the client upon connection that tells it what size to use? On the server side, it can be a configuration option. Having the client remember what was seen outside the immediate region is a separate issue. That would require the client knowing the difference between moving one square and teleporting. (Or in the case of tiled maps, not noticing the change in maps, though that would probably be a much later step.) I'm not sure how much info is there now. Both are great ideas. --PC From mwedel at scruznet.com Thu May 24 16:53:32 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] 25 by 25 instead of 11 by 11 map In-Reply-To: <990693280.541.0.camel@pc-res-10> Message-ID: On 24 May 2001, Ben Norrington wrote: > Would anyone be interested in a mod to the client and server that uped > the visable map size to 25 by 25. I have made a mod for the 0.98 > versions of the linux client and server. It is not backwardly compatible > with the old clients tho. I would like to know if you think that this > would be a good change or whether I sould just take all your code and > write crosswater or something (GPL'ed of course). Also would some kind > of time system be of interest so that the maps where dark at certain > times of the day or so that monsters were not out all the time. If this > has all been done before I apoligise - I am new to this and only have > version 0.98. I would definately be interested in seeing the code. This has been mentioned more recently. Ideally, the maximum size will be a compile time setting on the server. This is mostly to determine what the optimum size may be (25x25 may be considered too large). The client should then be able to negotiate with the server what size display it wants. Maybe it only wants 11x11, or 15x15 or whatever. Typically, negotiation of smaller size would be for bandwidth reasons, but running on low res displays, it may be desirable to run at the lower resolution. I'm sure your code will provide a better starting point for them than from starting from scratch. From mwedel at scruznet.com Thu May 24 17:13:19 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] 25 by 25 instead of 11 by 11 map In-Reply-To: <200105241621.f4OGLdb17390@tonks.EECS.Berkeley.EDU> Message-ID: On Thu, 24 May 2001, Peter Mardahl wrote: > > Hello, > > Yes, this is interesting in general. It's nice to have someone > hacking on things independently. > > We did a poll recently, and it seems people would indeed like > a larger display... > > We thought it'd be easier to do it this way though: > increase the viewable size to "NxN", but have the server only > keep "up to date" 11x11. The client would be responsible for > remembering and mapping outside that 11x11, and would add > grayness to things it didn't have current data on, a "fog of war" > type of effect. This gets pretty tricky to do properly. Things like teleporters taht just move you a few spaces will make such a system unusable. I'd have to double check, but I don't think it is easy to know when the player has moved a space - there is the scrollmap protocol commands, but I don't think they are used in all cases (ie, if player gets pushed, is on top of a gate that moves them, or is on a player mover, I'm not sure if those cases use that). In either case, I was thinking of optimizing that for bandwidth - compare the price of doing a scroll and update vs just sending a new frame. If in combat, probably cheaper to skip the scroll as the monsters and spells will make most of the old frame useless anyways. > That would give more viewable area without increasing the > bandwidth overhead at all, and has the further advantage of > being mostly backward compatible, and would require very little > change to the server. As said in another message, ideally, the client can negotiate on size of map it gets sent. There should also be some other optimizations it can negotiate, like how many objects to send per space (on low bandwdith, you maybe only want the top one) > Also, it would allow the client to do 30x30 (or NxN) if he had > screen space for it. That is true. Of course, even if the server sends say a 25x25 map, there is still nothing preventing the client from trying to cache more than that. One of the worries I have about client caching is if it becomes a 'advertised feature', new players will try it out and pretty quickly complain that the stored data is completely bogus. > > Would you be interested in doing that? It's significantly more > coding than you have already done, but it has its advantages. As said above, doing one does not preclude the other. But obviously, if the server supports a 25x25 viewable map, the need for caching is much less. > > If not, then we may simply (after some democratic process) > adopt your patches regardless. I'm going to take a look at the code regardless. As said, ideally this will become a config issue, so server admins and players can do what they want. If a server admin wants a 'classic map size', then they just set those defines to 11x11. Bandwidth is increasing at a fairly rapid rate. While support low bandwidth/cpu things is still desirable, I don't think we should be limited by that. But at the same time, I think 25x25 is probably on the large size - bandwidth needed for updates would be roughly proportional to the amount of data - 25x25 is 625 spaces, 11x11 is 121, so you talking roughly 5 times the bandwidth to send that larger map (this ignoring the fact the additional overhead for a new map update command, since the current one only supports 15x15 max map sizes). And in terms of resolution, you are talking 800x800. If your running the server on the local machine/ subnet, the bandwidth may not be an issue. The problem of course is that the bandwidth needs become much higher when in combat, which is more important to get quick updates. Some form of dynamic updating may then be desired - ie, if in heavy combat, maybe only a 9x9 map gets sent just so the player can see what is immediately around them (and presents danger), while when strolling accross the countryside, you get the 25x25 map. And in the case, caching of the older data certainly becomes much more desirable - still nice to know that the red dragon may still be up the corrider in the way of your exit path. From peterm at tonks.EECS.Berkeley.EDU Thu May 24 17:39:21 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] Re: 25 x 25 In-Reply-To: Your message of "24 May 2001 22:39:14 BST." <990740354.4385.0.camel@pc-res-10> Message-ID: <200105242239.f4OMdLm18921@tonks.EECS.Berkeley.EDU> > I think that the spliting of the project into two branches might be the > best option - mabey you can have votes on a name. I only got the game 3 We don't really have the development resources to support two branches. I do not consider forking a good option. > mass opposition to even things like true colour graphics - something to > do with a lot of people on old computers playing this. My goal was to two people is not "mass opposition", and I think a NxN option will do much to address their concerns. > >From a bandwidth point of view I would be interested to know what > percent of the trafic is the pixel maps and what is the maping info (I > only had a quick play with the code but it seems to send the updating of Take this up on the list, I do not know it. > I haven't done any coding for the DirectX or gtk versions but the x one You'd not be involved except for advice, int he DirectX version, I imagine. Mich Toen maintains that. > I would be happy to write your fog of war model but it will have to wait > a couple of weeks I am just coming up to second year exams and I need to > get a good grade for the year. Yes, of course. This is free software development here. We are not pros. Things happen when people have time for them. People work on what they want to work on. PeterM From peterm at tonks.EECS.Berkeley.EDU Thu May 24 17:51:01 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] 25 by 25 instead of 11 by 11 map In-Reply-To: Your message of "Thu, 24 May 2001 15:13:19 PDT." Message-ID: <200105242251.f4OMp1b18994@tonks.EECS.Berkeley.EDU> > > This gets pretty tricky to do properly. Things like teleporters taht just > move you a few spaces will make such a system unusable. I'd have to The only way I see to do the 'fog of war' type of thing is to extend the protocol to send a 'change map' message every time the map is changed, and to send a 'player coordinates' every time the player is moved. The only drawback is that the client would have the extra information of where exactly the player was on the map. The client could then construct a map based on what data it is sent. PeterM From mwedel at scruznet.com Thu May 24 20:01:05 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] 25 by 25 instead of 11 by 11 map In-Reply-To: <200105242251.f4OMp1b18994@tonks.EECS.Berkeley.EDU> Message-ID: On Thu, 24 May 2001, Peter Mardahl wrote: > > The only way I see to do the 'fog of war' type of thing is to > extend the protocol to send a 'change map' message every > time the map is changed, and to send a 'player coordinates' every > time the player is moved. > > The only drawback is that the client would have the extra information > of where exactly the player was on the map. > > The client could then construct a map based on what data it is sent. Note that sending the player coordinates would not be a big deal. You could piggyback that on the stats command, so it would only be 3 more bytes (I'll presume a map will never be more than 255x255). You do have to make sure the stats command is always set before the map update, so the coordinates the map use have the proper relation (because the coordinate sent in the map update are relative - the upper left of the viewing area is always 0,0). Sending coordinates could give away information. For example, if the furtherest west/north you can get and you still find yourself and 10,10, you can probably conclude there is something hidden behind that area (of course, this may not always be true - some maps may just have solid rock there). The one interesting thing with sending map coordinates is magic map could be more useful (ie, the information it gathers could track the movement of the player). That code could even be updated as the player moves around. Of course, that magic map doesn't always represent the full map - it only represents the reachable areas, so you could wander off it it. But determining how much a leak sending the player the coordinates they are at is a matter of debate. Its certainly a leak - I'm less sure how big a leak it is (as I think about it, there are probably other equally as big leaks - you could figure the exact resistances of various items by equipping them, since the resistances get updated. This of course is no worse than getting the stat bonuses). IMO, this is a pretty minor leak. And it is of course potentially useless information if automatic map tiling is addede (as being at 0,0 may not mean anything at all). And you only need some small portion of maps to actually put solid rock 5 tiles thick along the top or left and players will learn that trying to find secret doors/hidden things beyond it is a waste of time, so won't trust being at 0,0 or 5,5 as that much different. ITs really hard to say how much a deal information leak is when all the maps are basically available for anyone to download. The client could presumably hide the coordinates the player is at from the player (with of course a modified client showing this). there are of course other potential ways to deal with this - you could add a random 'fudge factor' to maps when first loaded - this fudge value is added to all direct coordinate values as sent to the client, so character can never really be sure what the top of the map really is. From mwedel at scruznet.com Thu May 24 20:19:07 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] Re: 25 x 25 In-Reply-To: <200105242239.f4OMdLm18921@tonks.EECS.Berkeley.EDU> Message-ID: On Thu, 24 May 2001, Peter Mardahl wrote: > > I think that the spliting of the project into two branches might be the > > best option - mabey you can have votes on a name. I only got the game 3 > > We don't really have the development resources to support two branches. > I do not consider forking a good option. As a note, there are already 2 branches for the server - the main cvs branch and a patch-1-0(-0? - can't remember). The patch one is just for that - minor patches/things to improve stability. As of this instant, it is the same as CVS tree, but that is not likely to be the case soon (I do plan to rip out all the code in CVS to deal with older client revisions for example). I agree with Peter on that we don't really have the resource to be doing several things at once. Also, I think we will get a better product if we focus on one thing vs trying to do 10 things. > > >From a bandwidth point of view I would be interested to know what > > percent of the trafic is the pixel maps and what is the maping info (I > > only had a quick play with the code but it seems to send the updating of > > Take this up on the list, I do not know it. This is not a simple question. First, by pixel maps, I'm taking you mean images. Given that, if the client is caching the images, very little bandwidth is used for that - the only bandwidth is to fill in missing images that the client does not have. Even if the client is not caching (which really means caching between different servers/runs), the client still caches the images for a connection to the server. So worst case, for any session, each image is only sent once. Given that case, bandwith portions depend on how long the person plays. If they just hop on, play for 10 minutes, and then leave, the portion for images will be much higher than that for map information. But if they hop on, and play for 5 hours, probably the bulk of the images will have been sent in the first 10-15 minutes, with occasional batches as the player runs into new monters or goes to a new map set with different style. But in that case, it will be the map (and item, and other protocol actions) which have the bulk of the bandwith. The image file in total is a little under 2 megabytes. So worst case, 2 megabytes of image information will get sent. From what I have seen, it isn't amount of data sent, but when that data is sent. If I'm in town selling/identifying items, having some lag as I do that isn't that big a deal. A little annoying, but this is the best time for the server to be sending bunches of data to the client. A little lag in the middle of combat is a big deal - it can literally be deadly. Now you hit some image information if that is the first you have seen the monster. But after that, it is just a matter of the spells flying and other bandwidth consuming tasks. From mwedel at scruz.net Thu May 24 23:10:40 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:07 2005 Subject: [CF-Devel] Metaserver feature request References: <20010521102646.A6071@mids.student.utwente.nl> <20010522015445.A14568@mids.student.utwente.nl> Message-ID: <3B0DDB40.F8879BFE@scruz.net> I've put in reporting of inbytes, output bytes, and server uptime into the metaserver reporting. Turns out that no changes are really needed. The metaserver output to html splits on the |, so it just ignores those fields. As does the client. I'm not sure how important it would be for the metaserver to actually do something with that data when it writes out to html. From mwedel at scruz.net Thu May 24 23:17:31 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] Mouse proliferation -- possible solution? References: <20010522143104.A26472@crystal> Message-ID: <3B0DDCDB.EF513595@scruz.net> "H. S. Teoh" wrote: > > I've been making some newbie maps recently, and I noticed how often I had > to turn off the "generator" flag in mice so that the maps don't become > unplayable very quickly due to the insane proliferation of mice. Which > means I cannot use mouse generators either, since the generators would > produce only mice with generator=1. But this makes things kinda boring, > since you DO want the mice to reproduce, just not as quickly as they do. > > So here's an idea of how to solve this problem (not just with mice, but > with any other monster in the game that reproduce): we already have code > to occasionally generate an orc leader from the orc generators, etc.. Why > not use this with mice? Every time a mouse reproduces (or a mouse > generator makes a mouse), have a random chance of whether the new mouse > can reproduce or not. (I.e., mouse generation can produce either fertile > mice or sterile mice.) If we keep the chance to some reasonable value, > this should make mice reproduce but not forever, so it won't flood the > map. I find this is a great use for the disease spells - quickly wipes out large numbers of these pesky creatures. The question of self generating monsters may be more reasonable. I don't have a problem with black puddings and green slime, but things like the mice, normal slime, etc, reproduce to the extent its just a nuisance - the creatures by themselves are harmless. You are right in that the artifact monster code can be used to fix this. Just turn off the generating ability in the mice archetype and then creating an 'artifact mouse' with that flag turned on will do the trick. Its hard to generalize this for all monsters that should reproduce, but the artifact file does support multiple matching. Problem is the base arch really has to get changed, which could affect some maps that require rapid breeding of the creatures. But I can't see too many maps relying on that fact. From mwedel at scruz.net Thu May 24 23:26:01 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] New armour case References: Message-ID: <3B0DDED9.B28AAD19@scruz.net> dnh wrote: > > This I to would also like, but looking through the code, your idea would > be very hard to do compared to mine. If you want to do that.. I would be > most happy, OTOH I will add the new case if you don't. My major concern is > if people have a real problem with this. I can understand that sentiment. But you have to look at the longer run also - for most things, there is the long term maintenance in addition to the short term work to do it. For a short term fix, I don't have a big problem, but would still much prefer a can_use_girdle and can_use_bracers instead of a can_use_light_armor. Doing splitting that in two pieces shouldn't be that much harder, provides more flexibility, and also avoids the confusion of exactly what light armor could be (I can see someone saying 'robes are pretty light - shouldn't that qualify as ligth armor?') From mwedel at scruz.net Thu May 24 23:29:57 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] Orc chop of Hideous Poison References: <20010520215108.A19238@crystal> <3B0B4397.BDEB2A4F@scruz.net> <20010523114339.A29783@crystal> Message-ID: <3B0DDFC5.7C600287@scruz.net> I've put this into CVS: lib/artifacts: Reduce potency of Poison artifact foods. server/apply.c: When eating poison artifact foods, hit player with poison attacktype instead of just subtracting hp. This way people with poison resistance get proper benefit. MSW 2001-05-24 future tuning may be needed - I haven't played around much with verifying the potency of this. From jbontje at suespammers.org Fri May 25 01:34:37 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] Metaserver feature request In-Reply-To: <3B0DDB40.F8879BFE@scruz.net>; from mwedel@scruz.net on Thu, May 24, 2001 at 09:10:40PM -0700 References: <20010521102646.A6071@mids.student.utwente.nl> <20010522015445.A14568@mids.student.utwente.nl> <3B0DDB40.F8879BFE@scruz.net> Message-ID: <20010525083437.A19173@mids.student.utwente.nl> On Thu, May 24, 2001 at 09:10:40PM -0700, Mark Wedel wrote: > > I've put in reporting of inbytes, output bytes, and server uptime into the > metaserver reporting. Thanks! Will change my stats saturday. Joris Bontje / mids From dnh at hawthorn.csse.monash.edu.au Fri May 25 02:10:08 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] 25 by 25 instead of 11 by 11 map In-Reply-To: <990693280.541.0.camel@pc-res-10> Message-ID: We have just been discussing this.. WOO HOO =) dnh On Thu, 24 May 2001, Ben Norrington wrote: > Would anyone be interested in a mod to the client and server that uped > the visable map size to 25 by 25. I have made a mod for the 0.98 > versions of the linux client and server. It is not backwardly compatible > with the old clients tho. I would like to know if you think that this > would be a good change or whether I sould just take all your code and > write crosswater or something (GPL'ed of course). Also would some kind > of time system be of interest so that the maps where dark at certain > times of the day or so that monsters were not out all the time. If this > has all been done before I apoligise - I am new to this and only have > version 0.98. > > Thanks for any input > > Ben > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From pc-crossfire at crowcastle.net Fri May 25 11:26:20 2001 From: pc-crossfire at crowcastle.net (pc-crossfire@crowcastle.net) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] 25 by 25 instead of 11 by 11 map Message-ID: <200105251626.MAA03728@lul1150.lss.emc.com> > Note that sending the player coordinates would not be a big deal. >You could piggyback that on the stats command, so it would only be >3 more bytes (I'll presume a map will never be more than 255x255). This may not be the right way of doing it. If, instead, whenever the player moves, you sent a direction code to the client with a special value for teleport, you would solve the problem with only needing 4 bits, and you wouldn't have to worry about a maximum map size or weird behaviour with tiling maps. So normal movement would result in sending the client one of eight directions. Going to a new map, teleporting, jumping, or falling through a pit would result in sending the client the special teleport code. If you wanted to, you could use one byte with the lower nibble being the direction and the upper nibble being the distance. This would allow for jumping and short-range dimension door. My main reason for arguing this is to support transparent map tiling. With server-supported tiling, you will be changing maps, but the client doesn't need to know this. Hence, if we can just tell the client we moved one square, then it works just like moving within one map. Personally, I think the automatic map tiling is really critical right now. It really needs to be done before expanding the main world map. --PC From tanner at real-time.com Fri May 25 13:40:17 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] sprintf bad, snprintf good Message-ID: <20010525134017.T29366@real-time.com> I was looking through the socket code for the metaserver routines and I see a significant use of sprintf and strcpy. I hate these functions. Being an ISP I fight a war with hackers almost daily. The 2 most used attacks are buffer overflows and format string vulnerabilities. sprintf and strcpy are 2 of the most exploited function calls. Can I replace these with snprintf and strncpy? Can I recommend that we use the 'n' string functions for this day forth? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From mwedel at scruznet.com Fri May 25 19:25:35 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] sprintf bad, snprintf good In-Reply-To: <20010525134017.T29366@real-time.com> Message-ID: On Fri, 25 May 2001, Bob Tanner wrote: > I was looking through the socket code for the metaserver routines and I see a > significant use of sprintf and strcpy. I hate these functions. > > Being an ISP I fight a war with hackers almost daily. The 2 most used attacks > are buffer overflows and format string vulnerabilities. > > sprintf and strcpy are 2 of the most exploited function calls. > > Can I replace these with snprintf and strncpy? > > Can I recommend that we use the 'n' string functions for this day forth? certainly strncpy is probably always a good idea. But of course, there are times you know it is safe (when copying static data into the string buffer). Using snprintf is probably not a bad idea. But how common is snprintf? I remember that at least as of a few years ago, there was a non trivial number of systems that lacked that. This may be fixable by including a proper version of snprintf in porting.c (a trivial version of course it to just call sprintf without the length for systems that don't have it.) But probably the biggest issue of string overflows will still be strcat and appending to strings - unless you know how long the string is that is being appended, those get harder to fix. And I worry a little about putting strlen in all over the place to really make sure we don't do anything bad - performance on that may be a bit of an issue. From mwedel at scruznet.com Fri May 25 19:38:23 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] 25 by 25 instead of 11 by 11 map In-Reply-To: <200105251626.MAA03728@lul1150.lss.emc.com> Message-ID: On Fri, 25 May 2001 pc-crossfire@crowcastle.net wrote: > > This may not be the right way of doing it. > > If, instead, whenever the player moves, you sent a direction code to the > client with a special value for teleport, you would solve the problem with > only needing 4 bits, and you wouldn't have to worry about a maximum map > size or weird behaviour with tiling maps. True. What I'm worried about in the teleport cases is what happens when the teleport is within the same map, and maybe in the same vicinity? You may not to lose that extra caching. Of course, this may not be an issue at all of extra caching of edge tiles is not done. I'm not too concerned about saving a byte in updating the players coordinates when they move - the actual bytes needed for updating the map and other information will be so much more, that trying to optimize that to save 10% will be a much bigger gain than trying to save a byte here. > My main reason for arguing this is to support transparent map tiling. With > server-supported tiling, you will be changing maps, but the client doesn't > need to know this. Hence, if we can just tell the client we moved one > square, then it works just like moving within one map. Reasonable concern. To me, here are the potential cases to worry about: 1) Normal movement - the trivial case - easy to do. 2) Player changes maps - old cache is toast - clear it out. 3) Player transitions across tiled maps - old cache is still usable. 4) Player moves many spaces within the same map (ie, dimension door, teleportor). Depending on amount of movement, keeping the old information could still be desirable (think of cases where there may be a gate along a wall and you just want to get to the other side so you ddoor two spaces - much of your old cache is still usuable). Simple method is to do as you suggest (just say player moved east for example). That covers cases 1 and 3. If player uses exit/telporter (2,4), just throw everything out. Not ideal, but keeps things simple (one other disadvantage I realized with the sending coordinates is the teleporter issue - it may allow players a much easier time to figure their way back/home.) > Personally, I think the automatic map tiling is really critical right now. > It really needs to be done before expanding the main world map. There are lots of really important things to do. I would say a new editor may be pretty important also - doing a major map rehaul may require better tools than we have now (or at least enhancements to what we have now, like say a expander built into the editor so you can say 'expand this map 5x' to make the resize easier). From tanner at real-time.com Fri May 25 19:48:31 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] troubles compiling 1.0 (warning long!) In-Reply-To: <3B0D5CE6.C53A560E@cstone.net>; from highway@cstone.net on Thu, May 24, 2001 at 03:11:34PM -0400 References: <3B0D5CE6.C53A560E@cstone.net> Message-ID: <20010525194831.F29366@real-time.com> Quoting Sean Michael Whipkey (highway@cstone.net): > I'm running a Red Hat 7.1 machine on a 1.3 GHz Pentium with 512 MB of > RAM and a 40 GB hard drive. Therefore, space or performance is not an > issue. I just installed RedHat 7.1 from commerical cd. Both rel-1-0-0 and rel-1-0-0-patches compiled with only warnings. I then updated the 7.1 with all the relevant updates. Again, both rel-1-0-0 and rel-1-0-0-patches compiled with only warnings. Did you install from commerical cd or from iso image from a ftp server? Did you double check the check sum on the iso? Have you applied all the updates? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From mwedel at scruz.net Fri May 25 22:02:38 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] sprintf bad, snprintf good References: <20010525134017.T29366@real-time.com> <20010525195704.I29366@real-time.com> Message-ID: <3B0F1CCE.E13AF18B@scruz.net> Bob Tanner wrote: > We can change autoconf to check the system for it and set the appropriate > #define's on what it finds. Yeah - that part is pretty easy. And even if we use the trivial sprintf suggestion if snprintf does not exist, it still does provide us additional benefits for the systems that does have it. > Has anyone run purecoverage over crossfire? > > What routines are "hot spots"? > > We can keep the strncat out of the hot spots. Probably not. I've run purify on it a few times. I believe there are other coverage tools. compiling with -prof and using gprof works pretty good for finding where cpu time is being spent. I'm most worried about things that form the packets we send to the client - they tend to add the pieces in. But anything that can iterate a lot in one tick could be a problem. I beleive peter runs electric fence, which should catch these things, but only when they occur. Things like: strcpy(buf,query_name(op)) may work fine for 99.9% of the cases, until you get something with a really long object name, at which point it breaks. > IMHO, things like this: > > strcpy(obuf,"Range: nothing"); > > There is no problem doing a strncpy (also there is really no overflow potential > either). for strncpy to be useful, you then have to put stuff like: obuf[LEN-1] =0; after all the strncpy functions. Otherwise, you have an unterminated string sitting around which will almost certainly cause other problems. From elsbernd at dfki.uni-kl.de Sat May 26 03:01:17 2001 From: elsbernd at dfki.uni-kl.de (Klaus Elsbernd) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] (no subject) Message-ID: <200105260806.f4Q86pa07997@gate-2000.kl.dfki.de> Hallo > Quoting dnh (dnh@hawthorn.csse.monash.edu.au): > > I agree with this idea, the sooner the better in my opinion. > > Is there resistence to this move? There is more resistence, (from me) but I see, that severall major developpers have good reasons for doing so. :-( And those, who wan't to remove png should see (on the count of mailing) that are a lot people which are against it. Even the I think there is a majority of useres, which aren't on the list or are quiet. crossfire-devel-request@lists.real-time.com said: > The 8bit colour will allow even most VGA people play if some one write > the client write. And some workstation-graphics adapters too. The arguments went towards pc-Problems. (For I am an old-fashionend unix-guy, you know.) >The question is what to color modes, and will the artists do it? The future of crossfire should make use of new features, graphics and artists. If this results in a move to new graphics, modes, file-formats, crossfire should use those. But it should not (imho) get rid of the old ones, if there is no real need for it. The old formats can be supported by automatically converting those graphics/formats... If the result would be not accurate or not very nice, it would be so. If someone makes it better, he should be able to do it. But this needs, that the code isn't dropped. On 23 May 2001 09:53:16 -0700, Peter Mardahl wrote: > > We can't make everyone happy. But we should try it at last. > Having the xpms and xbms triples the burden on artists > adding new things. It's one of the reasons crossfire > has been relatively static. I have not this opinion. Let the code of xpms/xbms be included, as the pictures too. New deveopements should go on png which can be converted (more or less good) Bis dann Klaus -- "Sure, vi is user friendly. It's just particular about who it makes friends with." ;-) _________________________ Klaus Elsbernd; System Administrator, BOFH | elsbernd@dfki.uni-kl.de Deutsches Forschungsz. f?r K?nstliche Intelligenz | DFKI GmbH, Geb. 57/285 67657 Kaiserslautern; Germany | Tel: (+49) 0631/205-3486 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 2628 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010526/cb390518/attachment.pgp From dnh at hawthorn.csse.monash.edu.au Sat May 26 03:43:03 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] (no subject) In-Reply-To: <200105260806.f4Q86pa07997@gate-2000.kl.dfki.de> Message-ID: Err I have to disagree with this. On Sat, 26 May 2001, Klaus Elsbernd wrote: > Hallo > > Quoting dnh (dnh@hawthorn.csse.monash.edu.au): > > > I agree with this idea, the sooner the better in my opinion. > > > > Is there resistence to this move? > There is more resistence, (from me) but I see, that severall major developpers > have good reasons for doing so. :-( > And those, who wan't to remove png should see (on the count of mailing) > that are a lot people which are against it. Even the I think there is a > majority of useres, which aren't on the list or are quiet. ? > crossfire-devel-request@lists.real-time.com said: > > The 8bit colour will allow even most VGA people play if some one write > > the client write. > And some workstation-graphics adapters too. > The arguments went towards pc-Problems. > (For I am an old-fashionend unix-guy, you know.) > >The question is what to color modes, and will the artists do it? ? > The future of crossfire should make use of new features, graphics and artists. > If this results in a move to new graphics, modes, file-formats, > crossfire should use those. But it should not (imho) get rid of the old > ones, if there is no real need for it. > The old formats can be supported by automatically converting those > graphics/formats... If the result would be not accurate or not very nice, > it would be so. If someone makes it better, he should be able to do it. > But this needs, that the code isn't dropped. > On 23 May 2001 09:53:16 -0700, Peter Mardahl wrote: This is where I disagree. While we should try to keep backwards compatability as much as POSSIBLE. It is no longer possible to expect artists to continue working on 4 sets at once. Not only that but the old images aren't the standard size + they aren't the standard colour limits. I have made a few images myself, and I can say that while I like the old xpm set, it is time to move on. Infact you could say i was resposible in part for its continuation this long. There is now a png set that similuts the old xpm/xbm sets, so the only real arguement I can see is that some platforms don't support PNG. Well, I must say we have to draw the line somewhere.. we cold implement a telnet client, but how many people would use it? and who would write it? I say we don't remove the xbm sets completely, but we de link them and stop directly supporting it. If anyone wants to continue a second branch I suppose that is acceptable, but it if no one wants to support it (ie everyone is just complaining.. ) then the line is drawn. dnh > > We can't make everyone happy. > But we should try it at last. > > > Having the xpms and xbms triples the burden on artists > > adding new things. It's one of the reasons crossfire > > has been relatively static. > I have not this opinion. Let the code of xpms/xbms be included, as the > pictures too. New deveopements should go on png which can be converted > (more or less good) > > Bis dann > Klaus > > -- > "Sure, vi is user friendly. > It's just particular about who it makes friends with." ;-) > _________________________ > Klaus Elsbernd; System Administrator, BOFH | elsbernd@dfki.uni-kl.de > Deutsches Forschungsz. für Künstliche Intelligenz | DFKI GmbH, Geb. 57/285 > 67657 Kaiserslautern; Germany | Tel: (+49) 0631/205-3486 > > > From e_vestal at hotmail.com Sat May 26 17:35:12 2001 From: e_vestal at hotmail.com (Dany Talbot) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] (no subject) Message-ID: I also disagree. BUT, I see no problems leaving the old xpms in and stopping working on them. Homewer, I'm so sick of needing to do an .xpm./xbm each time I want to add an item/monster.... ----Original Message Follows---- From: dnh To: Klaus Elsbernd CC: crossfire-devel@lists.real-time.com, elsbernd@gate-2000.kl.dfki.de Err I have to disagree with this. On Sat, 26 May 2001, Klaus Elsbernd wrote: > Hallo > > Quoting dnh (dnh@hawthorn.csse.monash.edu.au): > > > I agree with this idea, the sooner the better in my opinion. > > > > Is there resistence to this move? > There is more resistence, (from me) but I see, that severall major developpers > have good reasons for doing so. :-( > And those, who wan't to remove png should see (on the count of mailing) > that are a lot people which are against it. Even the I think there is a > majority of useres, which aren't on the list or are quiet. ? > crossfire-devel-request@lists.real-time.com said: > > The 8bit colour will allow even most VGA people play if some one write > > the client write. > And some workstation-graphics adapters too. > The arguments went towards pc-Problems. > (For I am an old-fashionend unix-guy, you know.) > >The question is what to color modes, and will the artists do it? ? > The future of crossfire should make use of new features, graphics and artists. > If this results in a move to new graphics, modes, file-formats, > crossfire should use those. But it should not (imho) get rid of the old > ones, if there is no real need for it. > The old formats can be supported by automatically converting those > graphics/formats... If the result would be not accurate or not very nice, > it would be so. If someone makes it better, he should be able to do it. > But this needs, that the code isn't dropped. > On 23 May 2001 09:53:16 -0700, Peter Mardahl wrote: This is where I disagree. While we should try to keep backwards compatability as much as POSSIBLE. It is no longer possible to expect artists to continue working on 4 sets at once. Not only that but the old images aren't the standard size + they aren't the standard colour limits. I have made a few images myself, and I can say that while I like the old xpm set, it is time to move on. Infact you could say i was resposible in part for its continuation this long. There is now a png set that similuts the old xpm/xbm sets, so the only real arguement I can see is that some platforms don't support PNG. Well, I must say we have to draw the line somewhere.. we cold implement a telnet client, but how many people would use it? and who would write it? I say we don't remove the xbm sets completely, but we de link them and stop directly supporting it. If anyone wants to continue a second branch I suppose that is acceptable, but it if no one wants to support it (ie everyone is just complaining.. ) then the line is drawn. dnh > > We can't make everyone happy. > But we should try it at last. > > > Having the xpms and xbms triples the burden on artists > > adding new things. It's one of the reasons crossfire > > has been relatively static. > I have not this opinion. Let the code of xpms/xbms be included, as the > pictures too. New deveopements should go on png which can be converted > (more or less good) > > Bis dann > Klaus > > -- > "Sure, vi is user friendly. > It's just particular about who it makes friends with." ;-) > _________________________ > Klaus Elsbernd; System Administrator, BOFH | elsbernd@dfki.uni-kl.de > Deutsches Forschungsz. für Künstliche Intelligenz | DFKI GmbH, Geb. 57/285 > 67657 Kaiserslautern; Germany | Tel: (+49) 0631/205-3486 > > > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From hsteoh at quickfur.yi.org Sun May 27 14:04:13 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:01:08 2005 Subject: [CF-Devel] Magic power shop Message-ID: <20010527150413.A30470@crystal> The person at the front desk appears to be the priest from the house of healing working a second job... and appears to think he's in the house of healing. May I fix this and check it in CVS? Also, I want to change the look/feel of that shop a bit. I hope nobody minds if I change the wall/floor styles? T -- "A mathematician is a device for turning coffee into theorems." -- P. Erdos From tanner at real-time.com Sun May 27 22:34:28 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B022459.8BF15CA1@scruz.net>; from mwedel@scruz.net on Tue, May 15, 2001 at 11:55:21PM -0700 References: <3B022459.8BF15CA1@scruz.net> Message-ID: <20010527223428.G27707@real-time.com> Quoting Mark Wedel (mwedel@scruz.net): > Now that 1.0 is out, I'd like to get a little discussion/input on future > changes for crossfire (say 2.0). Change: Convert archfiles to xml Details: The archfile parser is built into crossfire, this tight coupling between the game-engine and the parser makes it inconvenient for external programs from using the archfile without re-implementing the parser. Pros: Using xml as the archfile format would allow the parser to be external to the game engine, using a tool like Xerces we would have a c, perl and java parser immediately. An up to date handbook would be as simple as using cocoon, some stylesheets and the archfiles for html/web presentation. Consumption of the archfiles by other programs would be simplified. Conversion to other formats (like PDF via FOP) would also be simplified. Potential for new cool things, like syndication (ala my.netscape.com). Because XML is self-describing, additions to the format would be easier. Allows for localization/internationalization of the archfiles. Using Xerces-J as a validating XML parser integration into a project was just a couple of hours of work (I'll include the code in another post). Conversion from the current style to XML is trivial. Conversion from XML to the current style is also trivial. Cons: New crossedit would be needed. Lots of work to re-write the archfiles. Zone builders would have to learn another archfile format. Developers would have to learn another tool and set of APIs. Xerces: http://xml.apache.org Cocoon: http://xml.apache.org FOP: http://xml.apache.org ================================================================== Change: Re-write crossedit in java Details: Crossedit needs to be updated. Crossfire will only be as good as the zones available to play. Right now crossedit is a chore to use. It does the basic things as a level editor. If the archfile are migrated to XML, a new level editor will be needed, and we want to have a level editor that will work on as many platforms as possible. Using Java gives us that cross-platform potential. Pros: Crossedit needs a face-lift and better UI. Java is cross-platform, so we have a bigger audience of potential zone builders. OO-design should make the editor easier to extend. Cons: Java is slow. Swing can be a pain to work with. More or less we throw out the old crossedit. Zone builders will have to learn a new level editor. Probably will have to support the current archfiles to help in migration to the new level editor. Developers may not have Java skill-set. ================================================================== Change: Re-write client to use SDL Details: There is the gcfclient, cfclient which run only under unix-like operating systems. We have the java client, but it does not have a large user base and only 1(?) developer. We have the dxclient which only runs under windows. Cfclient, gcfclient and the java client are open source. The dxclient source code is currently not available. The gcflient and cfclient share a common code base. The java client is a total re-write and since we do not have access to the dxclient source code I cannot comment. We have multiple client for several platforms and poor code re-use amongst them. What we need is a client that can be easily ported to other platforms, has a large set of common code, and is open source. Writing a client using SDL will give the potential for a client that is easily ported to Linux, MacOS and Win32, with access to Sound API, OpenGL, DMA, DGA, and Full Screen X11. Pros: A client that is portable. A client that has support for a full range of multi-media capabilities. Code re-use, code re-use, code re-use. A client that has lots of eye candy to attrack new players. Cons: Will probably re-implement most of MT's work. Developers will have to learn a new set of APIs. Developers may not have the skill-set to work with SDL. Another level of indirection before you get to the hardware. Should maybe look at a level editor written in SDL. SDL: http://www.libsdl.org/ ================================================================== Change: Support WorldForge Atlas protocol Details: Seperation of the game-end from the client/server protocol. The re-write of the archfiles into XML pulls out the parser from the game engine, let's do the same for the client/server protocol. No need to re-invent the wheel, we can use the WorldForge project as a template. Pros: Protocol support en extension mechanism Seperates the client/server protocol from the actual game engine. Any Atlas protocol clients would become Crossfire clients. The SDL crossfire client could be used to play on other Atlas protocol servers, thus drawing more developers to the SDL crossfire client (and to the crossfire servers). Could have many different types of clients. Text, 3D, iso, etc.. Crossfire would be support an open source protocol for gaming, thus getting some good PR on the WorldForge site. Cons: Evolving protocol. As stated in the battleplan. "... it is unlikely that perfection can be achieved right off of the bat - either in the protocol itself or in the various implementations of it. ..." Total re-work of client and server protocol. Breaks old clients (unless server supports old protocol). Main site for protocol http://www.worldforge.org/website/protocols/ RFC for Atlas specification http://bilbo.escapesystems.com/~aloril/atlas/spec/devel/index.html Battleplan http://www.worldforge.org/website/protocols/atlas/battleplan -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From peterm at tonks.EECS.Berkeley.EDU Mon May 28 00:21:03 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] Magic power shop In-Reply-To: Your message of "Sun, 27 May 2001 15:04:13 EDT." <20010527150413.A30470@crystal> Message-ID: <200105280521.f4S5L3W30050@tonks.EECS.Berkeley.EDU> I did that map and you should feel free to redo it as you see fit. I actually started with the House of Healing as a template and modified it,hence the priest, an oversight on my part. PeterM > The person at the front desk appears to be the priest from the house of > healing working a second job... and appears to think he's in the house of > healing. May I fix this and check it in CVS? > > Also, I want to change the look/feel of that shop a bit. I hope nobody > minds if I change the wall/floor styles? > > > T > > -- > "A mathematician is a device for turning coffee into theorems." -- P. Erdos > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Mon May 28 01:59:26 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] Future crossfire changes/projects References: <3B022459.8BF15CA1@scruz.net> <20010527223428.G27707@real-time.com> Message-ID: <3B11F74E.D0CA2226@scruz.net> My general impression with your suggestions it that these would probably be good things to do if we were still early in development (ie, if we decided to make crossfire now, much of this should be done). But with the current status, I would rather look forward with new featuresw than go sideways - keeping the same feature, but how those features are used end up being different. But some notes below, as there arre some good ideas: Bob Tanner wrote: > Change: Convert archfiles to xml First, I note that currently more than just the archfile uses a commom format - the map file is basically the same as the archetypes file, as is player save files. So at minimum, either legacy support for the older format is needed, or conversion tools would also need to be written. My biggest question on xerces is what is the performance like, and how is the data represented to the program using it. > An up to date handbook would be as simple as using cocoon, some stylesheets and > the archfiles for html/web presentation. That seems a bit dubious to me - the majority of the handbook is information not derived from archetypes. Now that information can also be put into the archetype file, but that would seem a bit odd. > Conversion to other formats (like PDF via FOP) would also be simplified. I'd really like to get some real world examples on what would be done with this archetype information. I know the concept of xml - self describing. So if you have a phonebook (lets say) in xml, then your can trivial convert it to presentable format, even if you organize it different/have different information (maybe you do have e-mail addresses in addition to real addresses, while someone else doesn't store that information). Being able to convert a phonebook into something presentable makes sense. It strikes me the arch data doesn't fall into that category nearly as easily. This could be useful for the spoiler, but of course you still need filtering support. > Because XML is self-describing, additions to the format would be easier. I personally don't think adding stuff to the current arch structure is hard - there just seems to be some amount of apprehension from developers to do this. The real hard part isn't the parser, but typically doing something with that data and everything related with it. Adding the Pow stat a while back wasn't hard from a parser/save issue, but updating all the code and archetypes to use it is the hard part. To me, the biggest reason not to do this is the fact that we already have a working parser. If we were starting out and lacked a parser, it would be very compelling to take something that already that worked. The biggest reason to do this would be that it provides more standard parsing abilities for many languages, as you mention. However, localizing the current parser could probably done with less overall work (and really, the parser needs to go with the map to be useful in most cases (ie editors), and I think that would still be true with xml) > ================================================================== > Change: Re-write crossedit in java I don't think you will get much disagreement that a new editor is needed. In all cases, probably abandoning pretty much all the current crossedit code would be prudent, simply because a lot of the code currently used with the editor is pretty intermixed with the Xt code there. OTOH, a C (or c++) editor can at least recycle the current parsing and loading code. If it remains in C/C++, then perhaps it at least possible to do something like the client - keep all the non graphics code for the editor localized and not mix it with the graphics code. But this is probably much harder for the editor, as pretty much everything it does is interact with the player, so there really isn't that much common backend. My one really big worry about java is performance. If the performance is just too slow, people aren't going to use the client anyways, and so someone ends up writing a new one in probably a platform specific mode (ie, unix, windows, or mac only). Perhaps make the editor in SDL? To me, ideally, the moioier common ground that can be kept between all components, the better. That means the core developers can in theory at least do minor updates to all pieces. I think you are more likely to get people to learn to modify the editor if its in C and a common toolkit than something like java. > ================================================================== > Change: Re-write client to use SDL A SDL implementation of the unix client may not be a bad thing. I only recently learned GTK - I'm not likely to learn SDL anytime soon. The client was written to try and keep the graphic vs non graphic support separated, and it works for the gtk/X11 client. SDL could certainly be added on top of that. But there is still nothing preventing yet some other person do decide they would rather do say a Mac client and not use the code or modify it such that its now divergent. I don't know of any way to prevent that - an SDL client may still not, simply because someone may want a more native look, or wants the style different, or whatever else. A client written in anything but C will obviously need to diverge from common code. I may be wrong, but a very quick look suggests that SDL is really a low level toolkit. So to be useful, implementation of things like scrollbards, buttons, pull down menus, etc would need to be done. Perhaps there are already toolkits that build on top of SDL. But my other worry in general is number of required applications needed to support the application. I know that I have personally given up on installing some programs after finding out there are a dozen dependencies I need to solve. This isn't that big a deal with linux which has prepackaged rpm's for even obscure stuff, but when on solaris, this can be a real pain. I will note that there is a gtk+ for win32. I have no idea how good it is - its at http://user.sgic.fi/~tml/gimp/win32/. If its at all decent, that means that in theory at least, there already is at least a cross platform/open source client for windows - someone just needs to compile it up. > ================================================================== > Change: Support WorldForge Atlas protocol Once again, if we were just starting out and didn't have a protocol, this would be more compelling. We already have a protocol - not ideal, but from what I see on their webpages, probably more mature than atlas (albeit specific for just crossfire). My biggest worry look at the referance is the comment which was basically 'this protocol is preliminary and text based, but will change to binary (incompatible) in the future'. This protocol seems just way to early in development to be considered for use. And I really don't want to rely on something like an external program that is that early in development for such a key piece. Maybe in a year, relooking at this might be reasonable. But right now, I don't see this really gaining anything, so seems like an awful lot of work for nothing. I would also presume by the very extensible nature and the fact that a proper client can run on any server that writing a conforming client would also just be a lot harder (as you can not presume anything about form or data, so you need to support in theory any number of attributes for the player, items, maps, etc, requiring then a very general purpose client, which obvioiusly gets much more complicated). My guess is that for most part, people writing the client would not do that, and instead write for the data they are expecting. I would also think that gives better results for a specific game engine - ie, the data important to crossfire may be different than the data for another game system, even though the data is the same (ie, you want that data displayed more prominantly (say in form of a scrollbar) when playing crossfire, but not that other game. > Could have many different types of clients. Text, 3D, iso, etc.. Just as a note, the current protocol does not preclude that in any way, or at least not in any way that an atlas client would allow - no matter what the underlying protocol, there is still some set of underlying data that is being sent, and the client can do what it wants with that. In theory a 3d client could be written with the current protocol - it would get image names from the server, and could then have an idea what to draw based on that information. Realistically, a text implementation, while possible, would probably be difficult (just from play point of view - there are so many monsters, that just having a letter represent them may not be all that useful - fitting that in the standard 96 viewable characters would be difficult. And if you are presuming you can have your own font or other special viewable characters, whats the point? To me, a text client could be useful for things like the smaller devices out there). From tanner at real-time.com Mon May 28 02:16:44 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] Future crossfire changes/projects In-Reply-To: <3B11F74E.D0CA2226@scruz.net>; from mwedel@scruz.net on Sun, May 27, 2001 at 11:59:26PM -0700 References: <3B022459.8BF15CA1@scruz.net> <20010527223428.G27707@real-time.com> <3B11F74E.D0CA2226@scruz.net> Message-ID: <20010528021644.M27707@real-time.com> Quoting Mark Wedel (mwedel@scruz.net): > Bob Tanner wrote: > > Change: Convert archfiles to xml > > First, I note that currently more than just the archfile uses a commom format > - the map file is basically the same as the archetypes file, as is player > save files. So at minimum, either legacy support for the older format is > needed, or conversion tools would also need to be written. > > My biggest question on xerces is what is the performance like, and how is the > data represented to the program using it. How often is the parser called? Xerces hands the parsed data off just like flex/bison. To can use callbacks to plug in handler routines. So, it be be presented any way you want. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From mwedel at scruz.net Mon May 28 02:40:48 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] Future crossfire changes/projects References: <3B022459.8BF15CA1@scruz.net> <20010527223428.G27707@real-time.com> <3B11F74E.D0CA2226@scruz.net> <20010528021644.M27707@real-time.com> Message-ID: <3B120100.EDCAA11D@scruz.net> Bob Tanner wrote: > How often is the parser called? Anytime anything is loaded from disk (ie, maps, players). The maps is the big one. If the loader takes a long time, the game freezes for everyone, which would not be a good thing. As more people play, the more often maps will get loaded, and thus the bigger the problem. This can be fixed in ways other than a fast parser, and in fact should be at some point. There used to be a problem on some servers with the shared apartments - so many people piled so much loot into them, that loading that map took a noticable amount of time so the game froze. This bug was 'fixed' by each player getting a private apartment building. But one player could still in theory cause problems by piling a lot of stuff onto their private map. But I believe you really would be talking a lot of data. > > Xerces hands the parsed data off just like flex/bison. To can use callbacks to > plug in handler routines. So, it be be presented any way you want. Ok. Unclear if that will really make it save much space code then, but I'd have to look at xerces further to see how well it integrates in. Can you provide an example of an arch you've converted to xml? That may provide input as to whether pepole really want to use it or not when they see what advantages or disadvantages it may have. From dnh at hawthorn.csse.monash.edu.au Mon May 28 03:54:06 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] Gorokh Message-ID: Not satisfied with it yet, I think it needs another attack type, fear is crap... I suggest, paralyze, acid, fire or best of all poison (which does overlap gnarg) Fear is completely useless really and in most cases puts the wielder in more risk than the defender. OTOH vitriol is very powerful, we could turn it down but I am not sure adding paralyze etc to attack type will help much in later levels.. anyway if there are no complaints I will change it myself (as per norm) dnh From dnh at hawthorn.csse.monash.edu.au Mon May 28 05:21:52 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] gcfclient troubles Message-ID: I am getting this when I load the cvs client.. Got line we did not understand: scrolllines: 36 Got line we did not understand: scrollinfo: False also, when I enter a save bed a say quit the client seg faults. dnh From dnh at hawthorn.csse.monash.edu.au Mon May 28 05:50:14 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] Problem.. Message-ID: I just cast an aura 20 times.. that is a great way to kill a server.. csua is still chugging! pete got any ideas? dnh From hsteoh at quickfur.yi.org Mon May 28 08:51:19 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] Magic power shop In-Reply-To: <200105280521.f4S5L3W30050@tonks.EECS.Berkeley.EDU> Message-ID: <20010528095119.A1552@crystal> On Sun, May 27, 2001 at 10:21:03PM -0700, Peter Mardahl wrote: > > I did that map and you should feel free to > redo it as you see fit. [snip] OK, I checked in the improved House of Power. Check it out and let me know if you have any comments/suggestions. T -- Why is the sea always restless? It's bed is too rocky to sleep on. From dweeves at hotmail.com Mon May 28 20:12:02 2001 From: dweeves at hotmail.com (Sebastien Bracquemont) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] Future crossfire changes/projects Message-ID: Hi folks , it seemed that i missed a little (good) thing. Is there a move to port file formats to XML ?? I think it's a great idea.We can this move to reorganize some things as well if necessary. It could make the file format clear and safe (if a DTD is provided), and easy to read as well. I'm using Xerces professionally. This library is great But .... not very easy to use and is C++ intensive ! so , if you wanna use it , the best is to create a wrapper classes for (R)ead and/or (W)rite operations For Write operations, it's far from trivial to do it if you wanna use DTD's as well.The Xerces API isn't very documented for these kind of 'controlled' writing. I think we should use DTD in order to describe the file formats. I think i can provide easy to use C++ classes for XML R/W operations based on Xerces. Xerces can either use A DOM or SAX way to handle files. But their DOM implementation is based on SAX mechanisms, so to use DOM efficiently, you have also to register some SAX handlers. Can i have some XML samples too ? Thanks Dweeves. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From mwedel at scruz.net Mon May 28 16:08:43 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] gcfclient troubles References: Message-ID: <3B12BE5B.CC6F816D@scruz.net> dnh wrote: > > I am getting this when I load the cvs client.. > > Got line we did not understand: scrolllines: 36 > Got line we did not understand: scrollinfo: False That is a normal condition due to a change I made. Just hit the Save Config and those will then go away. Those are left over - when the person did the original gtk port, he took much of the x11.c code, and left in a lot of stuff no longer needed. In my recent cleanup, I got rid of some of that, which included those options (they didn't do anything anyways.) > > also, when I enter a save bed a say quit the client seg faults. I haven't seen that, so difficult to fix (not that it doesn't happen - just something I can't reproduce is very hard to fix). From peterm at tonks.EECS.Berkeley.EDU Tue May 29 00:16:15 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] Problem.. In-Reply-To: Your message of "Mon, 28 May 2001 20:50:14 +1000." Message-ID: <200105290516.f4T5GFs31264@tonks.EECS.Berkeley.EDU> That's strange, I've done the same thing without killing the server. It operates much like any other spell, except it hits less spaces, so it should be no worse than 20 cone spells, and in fact, considerably better. PeterM > I just cast an aura 20 times.. that is a great way to kill a server.. csua > is still chugging! > > pete got any ideas? > > dnh > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Tue May 29 01:41:13 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] RFC: new map protocol command Message-ID: <3B134489.EFD90910@scruz.net> To support maps larger than 15x15 in the client display, a new map command is needed (old command packed the coordinates into a single byte). This is what I came up with, sprinkled liberally with my comments of why I did it that way. S->C: map1 [darkness1][face1a][face1b][face1c][darkness2][face2a ]... This is an update of the map command to support large map sizes. The old map command supported a maximum map size of 15x15 - anything larger than that required a new command. Given that this larger map now needs 2 bytes for the coordinates - the same as for the images, trying to optimize one vs the other does not makes much sense. All data is in standard binary form. the coord values are flags + x + y values. The value itself, but the data represented looks like this: first 6 bits: The x coordinate next 6 bits: the y coordinate last 4 bits: MSB - true if we send darkness MSB-1 - will send floor face MSB-2 - will send intermediate face MSB-3 (aka LSB) - will send top face 6 bits is enough for 63x63 maps. For the time being, it should be a safe assumption that we won't be sending anything larger than that. Through the use of this bitmasks, any and all of the following values may be optional. This allows the update of one face on the space without needing to send the others (in the old map command, this is not possible, so as an arrow flies over a space, the floor + arrow needs to get resent - this allows just the arrow to get sent). This should conserve bandwidth when spells are cast (we have an extra byte for the coordinate, but save 2 bytes for the image itself, plus another 2 potential bytes if there is something on the space.) If all the flag values are 0, this then means the space is considered blocked from view, and should be drawn as black. This conserves bandwidth for sending blocked spaces, which occur pretty frequently. Once a space is marked as block, if it re-appears within view, the 3 layers should be marked is blank. For spaces that are empty, one or more of the faces will be sent as blank faces (exactly how many will depend on what was on the floor before - for example, if a floor disappears, then only the floor needs to get updated, but if there was stuff on the floor, then that face will also need to get cleared). There may be cases where transitioning from the blocked to empty space occurs, in which case the client will send the floor as an empty space. The darkness value is a single byte - 0 is pitch black, while 255 is fully illuminated. It is up to the client to figure out what it wants to do with this (use masking to reduce visibility, or actually do a real light reduction on the image). the face values are 16 bit values, as before. They will be sent in MSB order of the flag (ie, floor, then intermediate, then top, presuming the bit in the flag is set that says that layer is being sent) Blank faces may get sent if an object disappears - in the example of the flying arrow, for the space the arrow leaves, a blank face will be sent in place of the arrow. Note that this implementation is much simpler than the prior one because it now works on spaces rather than layers, and most all the code also works on spaces. The downside of this is that this will need to get redone if we want to put more than 3 faces on a space (as we are then out of bits). It would be trivial to do something different, like send as many faces as desired and just have a marking tag at the end - the problem with this is that if something changes, then once again, you need to send the entire space as there is no way to say 'face xyz has disappeared'. And in any case, to support more faces will require more work on the server. From hsteoh at quickfur.yi.org Tue May 29 10:19:18 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] Alt png set: broken exit images Message-ID: <20010529111918.A5813@crystal> It seems that only exit.111.png ever made it into CVS, whereas the exit animation needs 3 frames. And so, right now, it is a very ugly mixture of the old swirl and the new swirl. I suppose somebody unintentionally forgot to commit exit.112.png and exit.113.png ? T -- INTEL = Only half of "intelligence". From reeve at ductape.net Tue May 29 11:53:40 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] New project Message-ID: <20010529125340.C26276@terra.localnet> I have started writing a GNOME client for Crossfire, and I was wondering if you might host it. I was just going to start a SourceForge project for it but I thought I'd check with you guys first. It's based off the GTK client's code, though mostly only the protocol code still remains from it. I'm nowhere near finished with what I intend to do with it, but it already works (except the new docking code) and can do everything the other GTK and X11 clients can. Also, if you don't want to make it an official client, can I at least get a show of hands of people that are interested in it? -- -- -- Reeve the cat ----BEGIN FORTUNE---- GREAT MOMENTS IN AMERICAN HISTORY (#17): On November 13, Felix Unger was asked to remove himself from his place of residence. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From jbontje at suespammers.org Tue May 29 12:51:56 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] New project In-Reply-To: <20010529125340.C26276@terra.localnet> References: <20010529125340.C26276@terra.localnet> Message-ID: <20010529195156.A10856@mids.student.utwente.nl> On Tue, May 29, 2001 at 12:53:40PM -0400, Scott Barnes wrote: > I have started writing a GNOME client for Crossfire, and I was wondering if > you might host it. You can get an account on my box. Probably you can get better offers. > I was just going to start a SourceForge project for it > but I thought I'd check with you guys first. It's based off the GTK > client's code, though mostly only the protocol code still remains from it. > I'm nowhere near finished with what I intend to do with it, but it already > works (except the new docking code) and can do everything the other GTK and > X11 clients can. Also, if you don't want to make it an official client, > can I at least get a show of hands of people that are interested in it? I am interested. I volunteer as betatester :) Joris Bontje / mids From tanner at real-time.com Tue May 29 14:25:31 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] New project In-Reply-To: <20010529195156.A10856@mids.student.utwente.nl>; from jbontje@suespammers.org on Tue, May 29, 2001 at 07:51:56PM +0200 References: <20010529125340.C26276@terra.localnet> <20010529195156.A10856@mids.student.utwente.nl> Message-ID: <20010529142531.P25724@real-time.com> Quoting Joris Bontje (jbontje@suespammers.org): > On Tue, May 29, 2001 at 12:53:40PM -0400, Scott Barnes wrote: > > I have started writing a GNOME client for Crossfire, and I was wondering if > > you might host it. I think hosting it on sourceforge is the best. 1 location, it has all the tools. Why make users bounce around the web looking for stuff? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From Philipp.Currlin at t-online.de Tue May 29 15:44:14 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:01:09 2005 Subject: [CF-Devel] quetzalcoatl monk Message-ID: <01052922441401.00661@truth> Just for fun I started a quetzalcoatl monk. I noticed two interesting things: 1.) You can wield weapons once you learned the skill 'melee weapons' and have been praying on an altar. (You get the message 'you can now use weapons again). 2.) You do not get any spells when starting with this combination. (Except burning hands of course) Phil From mwedel at scruznet.com Tue May 29 15:46:12 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] New project In-Reply-To: <20010529125340.C26276@terra.localnet> Message-ID: On Tue, 29 May 2001, Scott Barnes wrote: > I have started writing a GNOME client for Crossfire, and I was wondering if > you might host it. I was just going to start a SourceForge project for it > but I thought I'd check with you guys first. It's based off the GTK > client's code, though mostly only the protocol code still remains from it. > I'm nowhere near finished with what I intend to do with it, but it already > works (except the new docking code) and can do everything the other GTK and > X11 clients can. Also, if you don't want to make it an official client, > can I at least get a show of hands of people that are interested in it? If it works, the ideal solution would be to just put the needed source files into the current client directory and modify the makefile to build that client of appropriate libraries are available. The big advantage of this is that you keep more of the common code, so as no protocol commands are added, your client would not to get modified in addition to the other clients (now if that new protocol command means new data to be displayed, that will of course require modificiation). Just for curiousity, can you give some examples of what your client does beyond the gtk client that we already have? My impression is that gnome apps generally use gtk as their toolkit. From nazgarn at hotmail.com Tue May 29 20:09:07 2001 From: nazgarn at hotmail.com (Aaron Shinn) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] Error Message in DirectX Client Message-ID: Upon loading a character from the MIDS server in the DirectX Client for windows, an error message appeared, reading: ERROR MESSAGE (window title) modul: commands.c func: FIO_close() 0.msg: "Unknown stat number" 1.err: 0(0h) I tried the linux and old win32 clients and they worked fine. Also, it worked upon creating a new character but not loading old ones. I got to level 18 before this happened, maybe an update on the server caused it? Thanks, - Sizor _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From dnh at hawthorn.csse.monash.edu.au Tue May 29 20:52:22 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] New project In-Reply-To: <20010529125340.C26276@terra.localnet> Message-ID: Woah! We have been waiting ages for this, the current gcfclient, while having a nice interface is SLOW to buggery. I personally would love to see someone take on this project, but can I hand you some free advice. Ask Mark Wedel about various issues, he has done the most work on the client of late and will most probably be able to give some of the best advice.. on the other hand he is quite busy =). Anyway, I am sure you can put your project in the crossfire sourceforge project, again ask Mark, Peter or Joris to add you in. Best advice I can give right now is come into #crossfire on openprojects and have a chat to us =). dnh On Tue, 29 May 2001, Scott Barnes wrote: > I have started writing a GNOME client for Crossfire, and I was wondering if > you might host it. I was just going to start a SourceForge project for it > but I thought I'd check with you guys first. It's based off the GTK > client's code, though mostly only the protocol code still remains from it. > I'm nowhere near finished with what I intend to do with it, but it already > works (except the new docking code) and can do everything the other GTK and > X11 clients can. Also, if you don't want to make it an official client, > can I at least get a show of hands of people that are interested in it? > > -- > -- -- > Reeve the cat > ----BEGIN FORTUNE---- > GREAT MOMENTS IN AMERICAN HISTORY (#17): > > On November 13, Felix Unger was asked to remove himself from his place > of residence. > ----END FORTUNE---- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- > O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ > G e* h-- r+++ y** > ------END GEEK CODE BLOCK------ > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From dnh at hawthorn.csse.monash.edu.au Tue May 29 20:54:34 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] gcfclient crash - a csua problem only Message-ID: I just noticed something VERY interesting. I only get the seg fault when leaving the game on Peter's server. Wierd.. dnh From pc-crossfire at crowcastle.net Tue May 29 21:02:35 2001 From: pc-crossfire at crowcastle.net (pc-crossfire@crowcastle.net) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] Another random map bug Message-ID: <200105300202.WAA00945@localhost.localdomain> I've been going through the 50-levels of random undead maps recently, and I've noticed another bug. I had just gone down some stairs, and found myself on top of something like a "dun_1_2" instead of a stairs up. There was no way back. Just now, I was going down, and on about the sixth level, there was no stairs down. I looked at the map file, and didn't see anything unusual. For reference, the map file is at: http://www.crowcastle.net/preston/maps/ --PC From mwedel at scruz.net Tue May 29 21:57:13 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] Error Message in DirectX Client References: Message-ID: <3B146189.FCC0682E@scruz.net> I'm guessing the MIDS updated his server. This in itself is not a bad thing. What has changed is that a while ago, MT made some patches to the server to send skill experience. They were not put in at that time since we were on the way to 1.0. I recently put them in, but changed how they worked some (to be more consistent with the rest of the code). The end result: Current unix clients work fine, because I modified them to understand this. Old unix clients work fine, because they don't request this data. Old dx clients work fine for the same reason. current dx client does not work because the data is not in the form expected. The change is pretty trivial, so I expect MT will be making a new client sometime soon that will fix that problem. I'm not sure if there is any option to turn off the skill experience feature from getting sent to the DX client. Now, the reason it works at low level is that even though it does not understand the data format, the data it does got can be interperted as other data which it can understand. I would guess this would still result in other stats getting garbled. Aaron Shinn wrote: > > Upon loading a character from the MIDS server in the DirectX Client for > windows, an error > message appeared, reading: > > ERROR MESSAGE (window title) > modul: commands.c > func: FIO_close() > 0.msg: "Unknown stat number" > 1.err: 0(0h) > > I tried the linux and old win32 clients and they worked fine. Also, it > worked upon creating a new character but not loading old ones. I got to > level 18 before this happened, maybe an update on the server caused it? > > Thanks, > - Sizor > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From michael.toennies at nord-com.net Tue May 29 22:42:48 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] Error Message in DirectX Client In-Reply-To: <3B146189.FCC0682E@scruz.net> Message-ID: Uh, yes its the skill exp. I had included the interface in the dx client as i do the patch. Because there is some changed now, the client knows that this is not a unknown command, but he knows too that this is not the right format, so he excit for secure. I'll update the client today. I notice also a small bug in the metaserver text print, some text is not wrapped there. Michael > > I'm guessing the MIDS updated his server. This in itself is not > a bad thing. > > What has changed is that a while ago, MT made some patches to > the server to > send skill experience. They were not put in at that time since > we were on the > way to 1.0. > > I recently put them in, but changed how they worked some (to be > more consistent > with the rest of the code). > > The end result: > Current unix clients work fine, because I modified them to > understand this. > Old unix clients work fine, because they don't request this data. > Old dx clients work fine for the same reason. > current dx client does not work because the data is not in the > form expected. > > The change is pretty trivial, so I expect MT will be making a new client > sometime soon that will fix that problem. I'm not sure if there > is any option > to turn off the skill experience feature from getting sent to the > DX client. > > Now, the reason it works at low level is that even though it does not > understand the data format, the data it does got can be > interperted as other > data which it can understand. I would guess this would still > result in other > stats getting garbled. > > > > Aaron Shinn wrote: > > > > Upon loading a character from the MIDS server in the DirectX Client for > > windows, an error > > message appeared, reading: > > > > ERROR MESSAGE (window title) > > modul: commands.c > > func: FIO_close() > > 0.msg: "Unknown stat number" > > 1.err: 0(0h) > > > > I tried the linux and old win32 clients and they worked fine. Also, it > > worked upon creating a new character but not loading old ones. I got to > > level 18 before this happened, maybe an update on the server caused it? > > > > Thanks, > > - Sizor > > > _________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at scruz.net Wed May 30 02:03:26 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] Any Line of Sight wizards out there? Message-ID: <3B149B3E.D6EDE4B6@scruz.net> I'm doing work to make the viewable map a larger size (max size settable by config.h setting). The little difficulty I'm running into is the line of sight code. If you look at the common/los.c file, near the top you will notice a whole bunch of set_block calls - I'll copy a few below: set_block(5,4,4,3); set_block(5,4,5,3); set_block(5,4,6,3); set_block(4,3,4,2); This is all 'hard coded' for an 11x11 map. Presume the player is at 5,5 (as would be the case for an 11x11 map). The first line basically says that if there is something at 5,4 that blocks the view, you can't see 4,3 (first line), 5,3 (second line), and 6,3. The next line then says that if something blocks view at 4,3 that you can't see 4,2. And so on. This creates a whole set of relations - so if 5,4 is blocked, you can pretty quickly figure out all the other spaces that get blocked by traversing the structures set up. As evidenced in the current code, this works just fine for the 11x11 map. Ideally, I would like a more general solution. I certainly don't want to have a hard code in place for a 25x25 map (which would be hundreds of lines). I did a quick web search for a better LOS method, but didn't find one. Most of them are presuming the simpler cases (have point A and point B - does anything prevent them from seeing each other). I'm thinking of using something like that to initialize the tables in a brute force fashion - this table is only initialized at startup, so something all that efficient to initialize the table is not all that important. On a 25x25 map, there are 625 spaces. Worst case here is also that there could still be a few hard coded entries to fix up gaps or the like. But before I do that approach, just wanted to see if anyone had some more clever solution. From tanner at real-time.com Wed May 30 02:15:12 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] Any Line of Sight wizards out there? In-Reply-To: <3B149B3E.D6EDE4B6@scruz.net>; from mwedel@scruz.net on Wed, May 30, 2001 at 12:03:26AM -0700 References: <3B149B3E.D6EDE4B6@scruz.net> Message-ID: <20010530021512.A25757@real-time.com> Quoting Mark Wedel (mwedel@scruz.net): > > I'm doing work to make the viewable map a larger size (max size settable by > config.h setting). http://www.gamedev.net/reference/articles/article729.asp http://www.cs.pdx.edu/~idr/graphics/imp-los.html -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From michael.toennies at nord-com.net Wed May 30 06:54:57 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] Any Line of Sight wizards out there? In-Reply-To: <3B149B3E.D6EDE4B6@scruz.net> Message-ID: These are 2 of the best resources you can find... http://www-cs-students.stanford.edu/~amitp/gameprog.html and http://www.gameai.com/ai.html > > I'm doing work to make the viewable map a larger size (max size > settable by > config.h setting). > > The little difficulty I'm running into is the line of sight code. > > If you look at the common/los.c file, near the top you will > notice a whole > bunch of set_block calls - I'll copy a few below: > > set_block(5,4,4,3); > set_block(5,4,5,3); > set_block(5,4,6,3); > set_block(4,3,4,2); > > This is all 'hard coded' for an 11x11 map. Presume the player > is at 5,5 (as > would be the case for an 11x11 map). > > The first line basically says that if there is something at 5,4 > that blocks the > view, you can't see 4,3 (first line), 5,3 (second line), and 6,3. > > The next line then says that if something blocks view at 4,3 > that you can't see > 4,2. > > And so on. This creates a whole set of relations - so if 5,4 is > blocked, you > can pretty quickly figure out all the other spaces that get blocked by > traversing the structures set up. > > As evidenced in the current code, this works just fine for the 11x11 map. > > Ideally, I would like a more general solution. I certainly > don't want to have > a hard code in place for a 25x25 map (which would be hundreds of lines). > > I did a quick web search for a better LOS method, but didn't > find one. Most of > them are presuming the simpler cases (have point A and point B - > does anything > prevent them from seeing each other). > > I'm thinking of using something like that to initialize the > tables in a brute > force fashion - this table is only initialized at startup, so > something all that > efficient to initialize the table is not all that important. On > a 25x25 map, > there are 625 spaces. Worst case here is also that there could > still be a few > hard coded entries to fix up gaps or the like. > > But before I do that approach, just wanted to see if anyone had some more > clever solution. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From reeve at ductape.net Wed May 30 09:52:47 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] New project In-Reply-To: ; from mwedel@scruznet.com on Tue, May 29, 2001 at 16:46:12 -0400 References: <20010529125340.C26276@terra.localnet> Message-ID: <20010530105247.A11352@terra.localnet> On Tue, 29 May 2001 16:46:12 Mark Wedel wrote: > If it works, the ideal solution would be to just put the needed source > files into the current client directory and modify the makefile to > build that client of appropriate libraries are available. > > The big advantage of this is that you keep more of the common code, so > as no protocol commands are added, your client would not to get modified > in addition to the other clients (now if that new protocol command means > new data to be displayed, that will of course require modificiation). > > Just for curiousity, can you give some examples of what your client does > beyond the gtk client that we already have? My impression is that gnome > apps generally use gtk as their toolkit. Yes, GTK is the toolkit used by Gnome, but that's not why I did it, sure, the GTK client looks good in Gnome but it doesn't take advantage of Gnome's features. As for examples, here goes: * Uses gnome_sound functions for sound effects, resulting in the ability to use sound under Gnome much better than before * Uses GnomeCanvas for the map, thus allowing scaling of the map to fit small displays or be more visible on large displays * Uses GnomeApp for the main window, allowing the menus to be more easily modified, have pixmaps, and follow the users global Gnome UI settings * Use of GnomeApp also allows the seperate parts of the window to be made into GnomeDockItems, thus allowing the user to change their positions, tear them off the window, etc. (thus also obsoleting the "split windows" option) * Use of gdk_imlib for image proccessing, thus allowing the images to be reused and resized more efficiently (for instance, the Inv and Look lists now use smaller images than the actual map so that they don't eat up so much screen space) * Uses GnomeEntry instead of GtkEntry for the "command line" so that history is saved between sessions and conforms to the UI design of other Gnome apps better * Uses gnome_config functions to store the configuration thus making the config load/save code cleaner * Uses Gnome's soundlist system for defining the sound effects so the user can change the sfx to their liking in the Gnome Control Center * Many more things coming but that's all I've finished for now (but hey, that's a LOT considering I started this three days ago :)) There is one downside though, the map drawing is slightly slower than the GTK client's because of the fact that the GTK client just used a quick blit to a GtkDrawable while the Gnome one uses separate drawables for each tile to better allow scaling. However, the difference isn't all that noticable unless you're on a slower machine (like about a 75Mhz) Basically, it's just better for Gnome users than the plain GTK client, but it does have some other advantages over the GTK client just because of some of the things Gnome libs offers than GTK doesn't. Also, about the "put it in the current client" idea, that may not work, since the sound code and a few lines in client.c, player.c, and commands.c had to be modified/rewritten in order to allow for some of the enhancements. However, the protocol code is essentially the same so maybe with some work it could be integrated into the current client. However, for now I'm going to submit it to SourceForge and just keep all the duplicate code up to date with the CVS version of the regular client. But I would like to see it added to the current client one day. Anyway, this mail is getting a bit lengthy so I'll just stop now :) -- -- -- Reeve the cat ----BEGIN FORTUNE---- It's later than you think. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From bugs at real-time.com Wed May 30 04:53:43 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] [Bug 368] New - 'lock'-commands doesn't work Message-ID: <200105300953.f4U9rh007558@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=368 *** shadow/368 Wed May 30 04:53:43 2001 --- shadow/368.tmp.7555 Wed May 30 04:53:43 2001 *************** *** 0 **** --- 1,24 ---- + +============================================================================+ + | 'lock'-commands doesn't work | + +----------------------------------------------------------------------------+ + | Bug #: 368 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: PC | + | Severity: normal OS/Version: Linux | + | Priority: P2 Component: server | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: gour@mail.ru | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + It seems that 'lock'-command does not work because there is not exist in Commands[] array (server/commands.c) + inv-lock and inv-unlock doesn't work too. They appears only in gnome-client's help and in handbook (chapter A) + + I think 'lock' and 'lock'-related commands must be re-written like 'mark'-command + (in file server/c_object.c, function command_mark(..) ) + + WBR + Gour \ No newline at end of file From meeg at mamia.prninfo.com Wed May 30 19:49:55 2001 From: meeg at mamia.prninfo.com (Meegwun South) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] random map problem Message-ID: <200105310049.UAA20622@mamia.prninfo.com> A player that I know has gone into many random maps and then it comes to a dead end.He used xray and saw thru the wall and he saw the exit on the other side.This player even tried dimension door but that did not work.If you could get rid of this problem he would be happy. From mwedel at scruz.net Wed May 30 21:55:30 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] New project References: <20010529125340.C26276@terra.localnet> <20010530105247.A11352@terra.localnet> Message-ID: <3B15B2A2.D85FADBA@scruz.net> Scott Barnes wrote: > > Yes, GTK is the toolkit used by Gnome, but that's not why I did it, sure, > the GTK client looks good in Gnome but it doesn't take advantage of Gnome's > features. As for examples, here goes: Ok. Some of it was just curiousity of what specifically had to be done to make it work under gnome properly > * Use of gdk_imlib for image proccessing, thus allowing the images to be > reused and resized more efficiently (for instance, the Inv and Look lists > now use smaller images than the actual map so that they don't eat up so > much screen space) As a note - imlib was originally used for the client for png support. But it was so buggy/slow I gave it up. Basically, it would not render some PNG files correctly (some of them important, like the cobblestones). Maybe they've finally fixed that up. > > There is one downside though, the map drawing is slightly slower than the > GTK client's because of the fact that the GTK client just used a quick blit > to a GtkDrawable while the Gnome one uses separate drawables for each tile > to better allow scaling. However, the difference isn't all that noticable > unless you're on a slower machine (like about a 75Mhz) some people are already complaining that the performance of the gtk client is poor. But I guess if you have the hardware to run it, up to each user to choose client that works best for them. > Also, about the "put it in the current client" idea, that may not work, > since the sound code and a few lines in client.c, player.c, and commands.c > had to be modified/rewritten in order to allow for some of the > enhancements. However, the protocol code is essentially the same so maybe > with some work it could be integrated into the current client. However, > for now I'm going to submit it to SourceForge and just keep all the > duplicate code up to date with the CVS version of the regular client. But > I would like to see it added to the current client one day. Ok. I guess its your call to do the extra work to keep it in sync. From reeve at ductape.net Thu May 31 08:17:31 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] New project In-Reply-To: <3B15B2A2.D85FADBA@scruz.net>; from mwedel@scruz.net on Wed, May 30, 2001 at 22:55:30 -0400 References: <20010529125340.C26276@terra.localnet> <20010530105247.A11352@terra.localnet> <3B15B2A2.D85FADBA@scruz.net> Message-ID: <20010531091731.A10375@terra.localnet> On Wed, 30 May 2001 22:55:30 Mark Wedel wrote: > some people are already complaining that the performance of the gtk > client is > poor. But I guess if you have the hardware to run it, up to each user to > choose > client that works best for them. I know, I'm one of them :) I'm still working my butt off trying to speed it up though :) > > Ok. I guess its your call to do the extra work to keep it in sync. I have resolved the issues somewhat, so I could put it in to the current client in CVS, if you would like. I'll need an account though :) -- -- -- Reeve the cat ----BEGIN FORTUNE---- Can you buy friendship? You not only can, you must. It's the only way to obtain friends. Everything worthwhile has a price. -- Robert J. Ringer ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From smurf at CSUA.Berkeley.EDU Thu May 31 12:48:59 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] New project Message-ID: <20010531104859.A9419@soda.csua.berkeley.edu> >> Scott Barnes wrote: > Mark Wedel wrote: >> >> Yes, GTK is the toolkit used by Gnome, but that's not why I did it, sure, >> the GTK client looks good in Gnome but it doesn't take advantage of Gnome's >> features. As for examples, here goes: > > Ok. Some of it was just curiousity of what specifically had to be done > to make it work under gnome properly GTK is only used as a base for gnome. Gnome actually has its own set of widgets all built on top of gtk with lots of nifty features, like tear away menu bars and stuff. GTK native code works fine on Gnome, just doesn't take advantage of gnome. Gnome also has an opengl canvas which could be used for some interesting effects maybe. > As a note - imlib was originally used for the client for png support. But it >was so buggy/slow I gave it up. Basically, it would not render some PNG files >correctly (some of them important, like the cobblestones). Maybe they've >finally fixed that up. I believe gnome is dropping imlib too.. Or maybe that was just enlightenment. I've heard nothing good about imlib in general though. -Scott From Adam.Moore at nottingham.ac.uk Thu May 31 18:51:57 2001 From: Adam.Moore at nottingham.ac.uk (adam moore) Date: Thu Jan 13 18:01:10 2005 Subject: [CF-Devel] (no subject) Message-ID: Greets! Saw Crossfire on Freshmeat, downloaded it, compiled it, love it. Then, I started thinking....I've got 4-6 Egyptian students coming to do a 8-week intensive IT project, starting in July - usually I get them to do some simple coding or XML stuff (2 example projects from last year - A 3DML represntation of the department, An XML network visualisation application) but this year I thought some crossfire stuff might be fun - developing an XML file format, SVG front end, GIS -> CrossFire maps, Some Java tools. This group will be widely varying in abilities and time is short, but if anyone has suggestions or tasks that would be great to be done, now is the time to speak! *8-) Please add my email: adam.moore@nottingham.ac.uk to any follow-ups Sorry if I'm stepping on anyone's toes, please send all flames to /dev/null *8-), otherwise advice on better places to ask, people to talk to gladly received! Dr Adam Moore adam.moore@nottingham.ac.uk From tanner at real-time.com Sat May 12 00:22:32 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:55 2005 Subject: [CF List] MetalForge moving to a dedicated machine Message-ID: <20010512002232.I32683@real-time.com> I'll be moving MetalForge to a dedicated Crossfire Server tonight (May 12) at 12:30am CST. The new machine will be dedicated to running MetalForge. It's a G3 Mac running YellowDog PPC linux, it's got 128Mb of RAM (we will upgrade the RAM to 384Mb later this month). The machine will be accessible via metalforge.real-time.com as soon as DNS updates. Mark will make change the Metaserver stuff in a couple of minutes. This should keep both the Netrek players and the Crossfire players happy, since they both have their own machines now. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From mwedel at scruz.net Sun May 13 17:42:19 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:03:55 2005 Subject: [CF List] Crossfire 1.0.0 released Message-ID: <3AFF0DCB.E93FB8CC@scruz.net> Crossfire 1.0.0 has been released. This is the first public release/release for wide spread distribution. Extenstive testing has gone out, and the server appears quite stable. NOTE TO MIRROR SITES: The primary site (ftp.scruz.net) has limited download bandwidth per day. You can also get this release off of sourceforge.net. Files released for this version: sums (bsd) filename 64947 1567 crossfire-1.0.0-arch.tar.bz2 29912 1858 crossfire-1.0.0-arch.tar.gz 44121 2995 crossfire-1.0.0-maps.tar.bz2 11006 4327 crossfire-1.0.0-maps.tar.gz 21265 2703 crossfire-1.0.0.tar.bz2 24930 239 crossfire-client-1.0.0.tar.gz Sums (md5) 18c3cff268c55a7561c785f6202ba715 crossfire-1.0.0-arch.tar.bz2 25990ae2ecdabcb4a2195dce92cc335a crossfire-1.0.0-arch.tar.gz 00b045172663768997a7b4f7e5dcf64c crossfire-1.0.0-maps.tar.bz2 d30eb96538627a899edd22b5cf2f2323 crossfire-1.0.0-maps.tar.gz bece4993c7ce9e3b15347c723f2a0d93 crossfire-1.0.0.tar.bz2 0bb73a6ea4268ecd4a5720128ecdf9c5 crossfire-1.0.0.tar.gz c79bf87ddc71bbee4ab46f64f3c908c7 crossfire-client-1.0.0.tar.gz crossfire-client-1.0.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. crossfire-1.0.0.tar.{gz/bz2} contains the server code with prebuilt archetype and image files. crossfire-1.0.0.arch.tar.{gz/bz2} contains the unpacked archetype changes. This is not needed if you only want to compile the server and play the game. crossfire-1.0.0-maps.tar.{gz/bz2} contains the maps. This is needed with the server distribution. FOR FIRST TIME USERS: You will only need the appropriate server, map and client file. You do not need the arch file. If you are a first time user, you may want the doc file unless you are using a web based player referance. If you just want to play the game at some remote server, you need the client and perhaps some version of the doc file. Crossfire is avaible on the following ftp sites Primary: ftp://ftp.scruz.net:/users/mwedel/public (165.227.192.254) ftp://ftp.sourceforge.net:/pub/sourceforge/crossfire (64.28.67.101) ftp://ftp.ifi.uio.no:/pub/crossfire (129.240.64.44) Secondary: ftp://ftp.real-time.com/pub/games/crossfire (206.10.252.12) ftp://ftp.cs.city.ac.uk:/pub/games/crossfire/ ftp://ftp.sunet.se:/pub/unix/games/crossfire (130.238.127.3) ftp://ftp.cs.titech.ac.jp:/pub/games/crossfire ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ ftp://crossfire.futt.org//pub/crossfire I uploaded this version to just ftp.scruz.net and sourceforge- it should be on the other ftp sites in a short time Mark Wedel mwedel@scruz.net ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Changes: Client: Changes for 1.0.0: player.c: Fix for client crashes if player enters really long commands (like say .....). MSW 2001-05-08 gx11.c,command.c: Remove some debug statements which really should not be there for 1.0, and which are not really useful anyways. items_types, item_types.h: Varioius minor updates. MSW 2001-05-04 gx11.c: Fix bug that causes gtk client not to update weapon speed. metaserver.c: Have the listing get sorted by hostname to make it easier to find the host the user may want. MSW 2001-05-02 ------------------------------------------------------------------------------ Server: Changes for 1.0.0: common/living.c: Fix AC wrapping problem - now limit ac to +/- 120. MSW 2001-05-12 include/config.h: Add NO_POLYMORPH feature selection include/spellist.h: If NO_POLYMORPH is set, make it so that polymorph will not show up in wands/rods server/spell_util.c: Handling for NO_POLYMORPH selection MSW 2001-05-11 server/rune.c: Make sure rune message is newline terminated. Fix map corruption problem. MSW 2001-05-10 Various improvements to make finding memory leaks easier. common/anim.c: Add free_all_anim function common/arch.c: Modify free_all_arch to free more data common/init.c: If running under MEMORY_DEBUG, don't pre-allocate objects. common/map.c: Add free_all_maps functiion. common/object.c: Modify object allocations if using MEMORY_DEBUG to only malloc one object at a time, and not pre-allocate objects. common/readable.c: Fix memory leak. common/shstr.c: Include autoconf.h so it can pull in dmalloc.h file. include/config.h: Remove notes of what was removed a long time ago. Add MEMORY_DEBUG option. include/libproto.h, include/sockproto.h, include/sproto.h: automatic rebuild server/c_misc.c: Fix 'malloc info command so it reports right memory total for maps. Add command_style_map_info which sums up memory used by style maps. server/commands.c: Add style_info wiz command which dumps memory usage for style maps. server/init.c: Have sighup handler call cleanup function. server/main.c: Fix clean_tmp_files which could result in crash if one of the maps in memory has 0 reset time. Modify cleanup function to free more data. server/player.c: op_on_battleground: Fix compile warning about unuused variable. socket/init.c: Change name of free_all_ericserver to free_all_newserver, have it free all face data. MSW 2001-05-08 socket/item.c: Modify look_at to not stop when it finds the first invisible object. server/monster.c: Modify monster_check_pickup to check to see if the next object got destroyed. I'm not sure the exact way this happens, but I've seen one crash where this did happen - I'm guess some function further down in the monster_check_apply look may call this or destroy the item. MSW 2001-05-01 common/object.c: Add clear_owner function. include/libproto.h: rebuild. server/player.c: Modify op_on_battleground to look for battleground anyplace on space. Temp for for wall of thorns on space - as long as maps don't try to abuse the use of battlegrounds, should be OK. server/time.c: Add clear_owner call to stop_arrow. Fixes problem of thrown objects not getting saved. MSW 2001-04-28 common/object.c: Have update_object map the look window for redraw if the object is not something the client normally animates (like a lever). MSW 2001-04-27 server/apply.c: Modify apply_id_altar check for player - had a && instead of a ||. socket/item.c: Modify ApplyCmd so a removed player can not apply objects. Fix crashes caused by players applying savebeds after they have used the bed. MSW 2001-04-26 server/spell_util.c: have put_a_monster generate random monster abilities. TODO, doc/mapguide: Various minor updates. MSW 2001-04-25 server/c_object.c: Pass right object to query_cost_string so that if you pick up an unpaid object into a container, it generates the correct price. MSW 2001-04-22 server/c_wiz.c: fix shutdown and reset_map wizard commands/function so they no longer crash the server. MSW 2001-04-22 server/monster.c: add check to was_destroyed when monster fires an arrow. Call was certainly missing, and appears to be responsible for crash. MSW 2001-04-20 server/player.c: Clear op->chosen_skill when we get to the play_again prompt. Otherwise, the server may try to use this later on, and it no longer points to a valid object, so it results in a crash. MSW 2001-04-19 server/skill_util.c: Add missing call to out_of_map in skill_attack which could result in crashes if player is at edge of maps and decides to attack in direction off map. MSW 2001-04-18 server/attack.c: Remove error message about golem without owners, also add better checking before clering the op->contr->golem field. common/map.c: set status flag on maps to MAP_SAVING so remove_ob does not do extra work when we are deleting a map (ie, immediate reset) from emory. server/skills.c: If someone is stolen from a player, send an esrv_delete_item to the client so the clients inventory remains correct. MSW 2001-04-16 common/re-cmp.c: Modify re_cmp functiion so that it properly matches strings not at the start 'ie, dude chain will now match against the chain value'. server/monster.c: Properly alter direction monster moves if they are feared or confused. It was properly altering direction when monsters were using range attacks, but not if they were just wanting to move. MSW 2001-04-12 common/living.c: Don't use the last_heal object in experience objects as sp regen penalty. This should fix the problem of inconsistent sp regen rates - last_heal is used in experience objects if the permanent experience option is turned on. MSW 2001-04-11 PeterM: server/spell_util.c: fix peace so it gives experience common/button.c: change the "error" to a "debug" message to reduce server crashing. From peterm at tonks.EECS.Berkeley.EDU Sun May 13 18:20:47 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:55 2005 Subject: [CF List] Crossfire 1.0.0 released In-Reply-To: Your message of "Sun, 13 May 2001 15:42:19 PDT." <3AFF0DCB.E93FB8CC@scruz.net> Message-ID: <200105132320.f4DNKlT16305@tonks.EECS.Berkeley.EDU> Hooray! Congratulations to all, and thanks especially to Mark, who has done much of the hard work to make this possible. Before we go back to hacking the game with this and that how about spending a week or two evangelizing the game? Trying to get it in Linux distributions, FreeBSD ports, gaming sites, etc? PeterM > Crossfire 1.0.0 has been released. > This is the first public release/release for wide spread distribution. > Extenstive testing has gone out, and the server appears quite stable. > > NOTE TO MIRROR SITES: The primary site (ftp.scruz.net) has limited download > bandwidth per day. You can also get this release off of sourceforge.net. > > Files released for this version: > > sums (bsd) filename > 64947 1567 crossfire-1.0.0-arch.tar.bz2 > 29912 1858 crossfire-1.0.0-arch.tar.gz > 44121 2995 crossfire-1.0.0-maps.tar.bz2 > 11006 4327 crossfire-1.0.0-maps.tar.gz > 21265 2703 crossfire-1.0.0.tar.bz2 > 24930 239 crossfire-client-1.0.0.tar.gz > > Sums (md5) > 18c3cff268c55a7561c785f6202ba715 crossfire-1.0.0-arch.tar.bz2 > 25990ae2ecdabcb4a2195dce92cc335a crossfire-1.0.0-arch.tar.gz > 00b045172663768997a7b4f7e5dcf64c crossfire-1.0.0-maps.tar.bz2 > d30eb96538627a899edd22b5cf2f2323 crossfire-1.0.0-maps.tar.gz > bece4993c7ce9e3b15347c723f2a0d93 crossfire-1.0.0.tar.bz2 > 0bb73a6ea4268ecd4a5720128ecdf9c5 crossfire-1.0.0.tar.gz > c79bf87ddc71bbee4ab46f64f3c908c7 crossfire-client-1.0.0.tar.gz > > crossfire-client-1.0.0 is the client (X11) distribution - standard > X11 and gtk interfaces are provided. > > crossfire-1.0.0.tar.{gz/bz2} contains the server code with prebuilt > archetype and image files. > > crossfire-1.0.0.arch.tar.{gz/bz2} contains the unpacked archetype changes. > This is not needed if you only want to compile the server and play the > game. > > crossfire-1.0.0-maps.tar.{gz/bz2} contains the maps. This is needed > with the server distribution. > > FOR FIRST TIME USERS: You will only need the appropriate server, map > and client file. You do not need the arch file. If you are a first time > user, you may want the doc file unless you are using a web based player > referance. > > If you just want to play the game at some remote server, you need the client > and perhaps some version of the doc file. > > Crossfire is avaible on the following ftp sites > > Primary: > ftp://ftp.scruz.net:/users/mwedel/public (165.227.192.254) > ftp://ftp.sourceforge.net:/pub/sourceforge/crossfire (64.28.67.101) > ftp://ftp.ifi.uio.no:/pub/crossfire (129.240.64.44) > > Secondary: > ftp://ftp.real-time.com/pub/games/crossfire (206.10.252.12) > ftp://ftp.cs.city.ac.uk:/pub/games/crossfire/ > ftp://ftp.sunet.se:/pub/unix/games/crossfire (130.238.127.3) > ftp://ftp.cs.titech.ac.jp:/pub/games/crossfire > ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ > ftp://crossfire.futt.org//pub/crossfire > > I uploaded this version to just ftp.scruz.net and sourceforge- it should be o >n > the other ftp sites in a short time > > Mark Wedel > mwedel@scruz.net > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >+ > Changes: > > Client: > Changes for 1.0.0: > > player.c: Fix for client crashes if player enters really long commands > (like say .....). MSW 2001-05-08 > > gx11.c,command.c: Remove some debug statements which really should not be > there for 1.0, and which are not really useful anyways. > items_types, item_types.h: Varioius minor updates. > MSW 2001-05-04 > > gx11.c: Fix bug that causes gtk client not to update weapon speed. > metaserver.c: Have the listing get sorted by hostname to make it easier to > find the host the user may want. > MSW 2001-05-02 > > ----------------------------------------------------------------------------- >- > Server: > Changes for 1.0.0: > > common/living.c: Fix AC wrapping problem - now limit ac to +/- 120. > MSW 2001-05-12 > > include/config.h: Add NO_POLYMORPH feature selection > include/spellist.h: If NO_POLYMORPH is set, make it so that polymorph will > not show up in wands/rods > server/spell_util.c: Handling for NO_POLYMORPH selection > MSW 2001-05-11 > > server/rune.c: Make sure rune message is newline terminated. Fix map > corruption problem. MSW 2001-05-10 > > Various improvements to make finding memory leaks easier. > common/anim.c: Add free_all_anim function > common/arch.c: Modify free_all_arch to free more data > common/init.c: If running under MEMORY_DEBUG, don't pre-allocate objects. > common/map.c: Add free_all_maps functiion. > common/object.c: Modify object allocations if using MEMORY_DEBUG to only > malloc one object at a time, and not pre-allocate objects. > common/readable.c: Fix memory leak. > common/shstr.c: Include autoconf.h so it can pull in dmalloc.h file. > include/config.h: Remove notes of what was removed a long time ago. > Add MEMORY_DEBUG option. > include/libproto.h, include/sockproto.h, include/sproto.h: automatic rebuild > server/c_misc.c: Fix 'malloc info command so it reports right memory total > for maps. Add command_style_map_info which sums up memory used by > style maps. > server/commands.c: Add style_info wiz command which dumps memory usage > for style maps. > server/init.c: Have sighup handler call cleanup function. > server/main.c: Fix clean_tmp_files which could result in crash if one > of the maps in memory has 0 reset time. Modify cleanup function > to free more data. > server/player.c: op_on_battleground: Fix compile warning about unuused variab >le. > socket/init.c: Change name of free_all_ericserver to free_all_newserver, > have it free all face data. > MSW 2001-05-08 > > socket/item.c: Modify look_at to not stop when it finds the first invisible > object. > server/monster.c: Modify monster_check_pickup to check to see if the > next object got destroyed. I'm not sure the exact way this happens, > but I've seen one crash where this did happen - I'm guess some > function further down in the monster_check_apply look may call > this or destroy the item. > MSW 2001-05-01 > > common/object.c: Add clear_owner function. > include/libproto.h: rebuild. > server/player.c: Modify op_on_battleground to look for battleground > anyplace on space. Temp for for wall of thorns on space - as long > as maps don't try to abuse the use of battlegrounds, should be OK. > server/time.c: Add clear_owner call to stop_arrow. Fixes problem of > thrown objects not getting saved. > MSW 2001-04-28 > > common/object.c: Have update_object map the look window for redraw if > the object is not something the client normally animates (like a lever). > MSW 2001-04-27 > > server/apply.c: Modify apply_id_altar check for player - had a && instead of > a ||. > socket/item.c: Modify ApplyCmd so a removed player can not apply objects. > Fix crashes caused by players applying savebeds after they have > used the bed. MSW 2001-04-26 > > server/spell_util.c: have put_a_monster generate random monster > abilities. > TODO, doc/mapguide: Various minor updates. > MSW 2001-04-25 > > server/c_object.c: Pass right object to query_cost_string so that > if you pick up an unpaid object into a container, it generates > the correct price. MSW 2001-04-22 > server/c_wiz.c: fix shutdown and reset_map wizard commands/function > so they no longer crash the server. MSW 2001-04-22 > > server/monster.c: add check to was_destroyed when monster fires an > arrow. Call was certainly missing, and appears to be responsible for > crash. MSW 2001-04-20 > > server/player.c: Clear op->chosen_skill when we get to the play_again > prompt. Otherwise, the server may try to use this later on, and it > no longer points to a valid object, so it results in a crash. > MSW 2001-04-19 > > server/skill_util.c: Add missing call to out_of_map in skill_attack which > could result in crashes if player is at edge of maps and decides to attack > in direction off map. MSW 2001-04-18 > > server/attack.c: Remove error message about golem without owners, > also add better checking before clering the op->contr->golem field. > common/map.c: set status flag on maps to MAP_SAVING so remove_ob does > not do extra work when we are deleting a map (ie, immediate reset) > from emory. > server/skills.c: If someone is stolen from a player, send an esrv_delete_item > to the client so the clients inventory remains correct. > MSW 2001-04-16 > > common/re-cmp.c: Modify re_cmp functiion so that it properly matches > strings not at the start 'ie, dude chain will now match against > the chain value'. > server/monster.c: Properly alter direction monster moves if they are > feared or confused. It was properly altering direction when monsters > were using range attacks, but not if they were just wanting to move. > MSW 2001-04-12 > > common/living.c: Don't use the last_heal object in experience objects as > sp regen penalty. This should fix the problem of inconsistent sp regen > rates - last_heal is used in experience objects if the permanent experienc >e > option is turned on. MSW 2001-04-11 > > PeterM: > server/spell_util.c: fix peace so it gives experience > common/button.c: change the "error" to a "debug" message > to reduce server crashing. > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From scott at campy.tymnet.com Sun May 13 19:42:41 2001 From: scott at campy.tymnet.com (Scott Wedel) Date: Thu Jan 13 18:03:55 2005 Subject: [CF List] Crossfire 1.0.0 released Message-ID: <200105140042.SAA02509@moots.tymnet.com> A good idea. I think it would be really good to mention the active servers and the the distinctions (settings and possibly the types of players) of those servers. >To: crossfire-list@lists.real-time.com >Subject: Re: [CF List] Crossfire 1.0.0 released >From: Peter Mardahl >X-Beenthere: crossfire-list@lists.real-time.com >X-Mailman-Version: 2.0.3 >List-Help: >List-Post: >List-Subscribe: , >List-Id: Crossfire Discussion Mailing List >List-Unsubscribe: , >List-Archive: >Date: Sun, 13 May 2001 16:20:47 -0700 > > >Hooray! > >Congratulations to all, and thanks especially to Mark, who has >done much of the hard work to make this possible. > >Before we go back to hacking the game with this and that >how about spending a week or two evangelizing the game? >Trying to get it in Linux distributions, >FreeBSD ports, >gaming sites, etc? > >PeterM > > > > >> Crossfire 1.0.0 has been released. >> This is the first public release/release for wide spread distribution. >> Extenstive testing has gone out, and the server appears quite stable. >> >> NOTE TO MIRROR SITES: The primary site (ftp.scruz.net) has limited download >> bandwidth per day. You can also get this release off of sourceforge.net. >> >> Files released for this version: >> >> sums (bsd) filename >> 64947 1567 crossfire-1.0.0-arch.tar.bz2 >> 29912 1858 crossfire-1.0.0-arch.tar.gz >> 44121 2995 crossfire-1.0.0-maps.tar.bz2 >> 11006 4327 crossfire-1.0.0-maps.tar.gz >> 21265 2703 crossfire-1.0.0.tar.bz2 >> 24930 239 crossfire-client-1.0.0.tar.gz >> >> Sums (md5) >> 18c3cff268c55a7561c785f6202ba715 crossfire-1.0.0-arch.tar.bz2 >> 25990ae2ecdabcb4a2195dce92cc335a crossfire-1.0.0-arch.tar.gz >> 00b045172663768997a7b4f7e5dcf64c crossfire-1.0.0-maps.tar.bz2 >> d30eb96538627a899edd22b5cf2f2323 crossfire-1.0.0-maps.tar.gz >> bece4993c7ce9e3b15347c723f2a0d93 crossfire-1.0.0.tar.bz2 >> 0bb73a6ea4268ecd4a5720128ecdf9c5 crossfire-1.0.0.tar.gz >> c79bf87ddc71bbee4ab46f64f3c908c7 crossfire-client-1.0.0.tar.gz >> >> crossfire-client-1.0.0 is the client (X11) distribution - standard >> X11 and gtk interfaces are provided. >> >> crossfire-1.0.0.tar.{gz/bz2} contains the server code with prebuilt >> archetype and image files. >> >> crossfire-1.0.0.arch.tar.{gz/bz2} contains the unpacked archetype changes. >> This is not needed if you only want to compile the server and play the >> game. >> >> crossfire-1.0.0-maps.tar.{gz/bz2} contains the maps. This is needed >> with the server distribution. >> >> FOR FIRST TIME USERS: You will only need the appropriate server, map >> and client file. You do not need the arch file. If you are a first time >> user, you may want the doc file unless you are using a web based player >> referance. >> >> If you just want to play the game at some remote server, you need the client >> and perhaps some version of the doc file. >> >> Crossfire is avaible on the following ftp sites >> >> Primary: >> ftp://ftp.scruz.net:/users/mwedel/public (165.227.192.254) >> ftp://ftp.sourceforge.net:/pub/sourceforge/crossfire (64.28.67.101) >> ftp://ftp.ifi.uio.no:/pub/crossfire (129.240.64.44) >> >> Secondary: >> ftp://ftp.real-time.com/pub/games/crossfire (206.10.252.12) >> ftp://ftp.cs.city.ac.uk:/pub/games/crossfire/ >> ftp://ftp.sunet.se:/pub/unix/games/crossfire (130.238.127.3) >> ftp://ftp.cs.titech.ac.jp:/pub/games/crossfire >> ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ >> ftp://crossfire.futt.org//pub/crossfire >> >> I uploaded this version to just ftp.scruz.net and sourceforge- it should be o >>n >> the other ftp sites in a short time >> >> Mark Wedel >> mwedel@scruz.net >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++ >>+ >> Changes: >> >> Client: >> Changes for 1.0.0: >> >> player.c: Fix for client crashes if player enters really long commands >> (like say .....). MSW 2001-05-08 >> >> gx11.c,command.c: Remove some debug statements which really should not be >> there for 1.0, and which are not really useful anyways. >> items_types, item_types.h: Varioius minor updates. >> MSW 2001-05-04 >> >> gx11.c: Fix bug that causes gtk client not to update weapon speed. >> metaserver.c: Have the listing get sorted by hostname to make it easier to >> find the host the user may want. >> MSW 2001-05-02 >> >> ------------------------------------------------------------------------ ----- >>- >> Server: >> Changes for 1.0.0: >> >> common/living.c: Fix AC wrapping problem - now limit ac to +/- 120. >> MSW 2001-05-12 >> >> include/config.h: Add NO_POLYMORPH feature selection >> include/spellist.h: If NO_POLYMORPH is set, make it so that polymorph will >> not show up in wands/rods >> server/spell_util.c: Handling for NO_POLYMORPH selection >> MSW 2001-05-11 >> >> server/rune.c: Make sure rune message is newline terminated. Fix map >> corruption problem. MSW 2001-05-10 >> >> Various improvements to make finding memory leaks easier. >> common/anim.c: Add free_all_anim function >> common/arch.c: Modify free_all_arch to free more data >> common/init.c: If running under MEMORY_DEBUG, don't pre-allocate objects. >> common/map.c: Add free_all_maps functiion. >> common/object.c: Modify object allocations if using MEMORY_DEBUG to only >> malloc one object at a time, and not pre-allocate objects. >> common/readable.c: Fix memory leak. >> common/shstr.c: Include autoconf.h so it can pull in dmalloc.h file. >> include/config.h: Remove notes of what was removed a long time ago. >> Add MEMORY_DEBUG option. >> include/libproto.h, include/sockproto.h, include/sproto.h: automatic rebuild >> server/c_misc.c: Fix 'malloc info command so it reports right memory total >> for maps. Add command_style_map_info which sums up memory used by >> style maps. >> server/commands.c: Add style_info wiz command which dumps memory usage >> for style maps. >> server/init.c: Have sighup handler call cleanup function. >> server/main.c: Fix clean_tmp_files which could result in crash if one >> of the maps in memory has 0 reset time. Modify cleanup function >> to free more data. >> server/player.c: op_on_battleground: Fix compile warning about unuused variab >>le. >> socket/init.c: Change name of free_all_ericserver to free_all_newserver, >> have it free all face data. >> MSW 2001-05-08 >> >> socket/item.c: Modify look_at to not stop when it finds the first invisible >> object. >> server/monster.c: Modify monster_check_pickup to check to see if the >> next object got destroyed. I'm not sure the exact way this happens, >> but I've seen one crash where this did happen - I'm guess some >> function further down in the monster_check_apply look may call >> this or destroy the item. >> MSW 2001-05-01 >> >> common/object.c: Add clear_owner function. >> include/libproto.h: rebuild. >> server/player.c: Modify op_on_battleground to look for battleground >> anyplace on space. Temp for for wall of thorns on space - as long >> as maps don't try to abuse the use of battlegrounds, should be OK. >> server/time.c: Add clear_owner call to stop_arrow. Fixes problem of >> thrown objects not getting saved. >> MSW 2001-04-28 >> >> common/object.c: Have update_object map the look window for redraw if >> the object is not something the client normally animates (like a lever). >> MSW 2001-04-27 >> >> server/apply.c: Modify apply_id_altar check for player - had a && instead of >> a ||. >> socket/item.c: Modify ApplyCmd so a removed player can not apply objects. >> Fix crashes caused by players applying savebeds after they have >> used the bed. MSW 2001-04-26 >> >> server/spell_util.c: have put_a_monster generate random monster >> abilities. >> TODO, doc/mapguide: Various minor updates. >> MSW 2001-04-25 >> >> server/c_object.c: Pass right object to query_cost_string so that >> if you pick up an unpaid object into a container, it generates >> the correct price. MSW 2001-04-22 >> server/c_wiz.c: fix shutdown and reset_map wizard commands/function >> so they no longer crash the server. MSW 2001-04-22 >> >> server/monster.c: add check to was_destroyed when monster fires an >> arrow. Call was certainly missing, and appears to be responsible for >> crash. MSW 2001-04-20 >> >> server/player.c: Clear op->chosen_skill when we get to the play_again >> prompt. Otherwise, the server may try to use this later on, and it >> no longer points to a valid object, so it results in a crash. >> MSW 2001-04-19 >> >> server/skill_util.c: Add missing call to out_of_map in skill_attack which >> could result in crashes if player is at edge of maps and decides to attack >> in direction off map. MSW 2001-04-18 >> >> server/attack.c: Remove error message about golem without owners, >> also add better checking before clering the op->contr->golem field. >> common/map.c: set status flag on maps to MAP_SAVING so remove_ob does >> not do extra work when we are deleting a map (ie, immediate reset) >> from emory. >> server/skills.c: If someone is stolen from a player, send an esrv_delete_item >> to the client so the clients inventory remains correct. >> MSW 2001-04-16 >> >> common/re-cmp.c: Modify re_cmp functiion so that it properly matches >> strings not at the start 'ie, dude chain will now match against >> the chain value'. >> server/monster.c: Properly alter direction monster moves if they are >> feared or confused. It was properly altering direction when monsters >> were using range attacks, but not if they were just wanting to move. >> MSW 2001-04-12 >> >> common/living.c: Don't use the last_heal object in experience objects as >> sp regen penalty. This should fix the problem of inconsistent sp regen >> rates - last_heal is used in experience objects if the permanent experienc >>e >> option is turned on. MSW 2001-04-11 >> >> PeterM: >> server/spell_util.c: fix peace so it gives experience >> common/button.c: change the "error" to a "debug" message >> to reduce server crashing. >> _______________________________________________ >> crossfire-list mailing list >> crossfire-list@lists.real-time.com >> https://mailman.real-time.com/mailman/listinfo/crossfire-list >_______________________________________________ >crossfire-list mailing list >crossfire-list@lists.real-time.com >https://mailman.real-time.com/mailman/listinfo/crossfire-list From mwedel at scruz.net Mon May 14 01:14:09 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:03:55 2005 Subject: [CF List] Crossfire 1.0.0 released References: <200105132320.f4DNKlT16305@tonks.EECS.Berkeley.EDU> Message-ID: <3AFF77B1.3FD94F2D@scruz.net> Peter Mardahl wrote: > > Hooray! > > Congratulations to all, and thanks especially to Mark, who has > done much of the hard work to make this possible. I would like to give my thanks to Peter and the Tanner's, who by having up to date servers and keeping them up with the latest CVS helped find bugs and determine when it really was stable > > Before we go back to hacking the game with this and that > how about spending a week or two evangelizing the game? > Trying to get it in Linux distributions, > FreeBSD ports, > gaming sites, etc? I've updated the README (unfortunately, after the release of 1.0, so you'll need to get it from CVS.) IT may be usable as something to send out. Note that I still think discussing future features now is relevant - I figure it will probably take a week or two just to figure out what the future features may be. i'll be sending out another message about that. From jajcus at bnet.pl Mon May 14 12:02:35 2001 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:03:55 2005 Subject: [CF List] Reliable saving of players/unique-items Message-ID: <20010514190235.A17057@nic.nigdzie> Hi, I have just lost my apartments again, because of full filesystem (BTW it was filled by crashed crossfire). I have never lost the player the same way, but if player files are created the same way as unique-items file it can always happen. Maybe those files should be created more reliably. Eg. by writting file.new first, and only if it succeeds the file would be renamed to proper name. It can "save some lives". Greets, Jacek From peterm at tonks.EECS.Berkeley.EDU Mon May 14 13:14:58 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:55 2005 Subject: [CF List] Reliable saving of players/unique-items In-Reply-To: Your message of "Mon, 14 May 2001 19:02:35 +0200." <20010514190235.A17057@nic.nigdzie> Message-ID: <200105141815.f4EIEwt17781@tonks.EECS.Berkeley.EDU> This is an excellent suggesstion. I have referred it to the crossfire development list. PeterM > Hi, > > I have just lost my apartments again, because of full filesystem (BTW it > was filled by crashed crossfire). I have never lost the player the same > way, but if player files are created the same way as unique-items file > it can always happen. > > Maybe those files should be created more reliably. Eg. by writting > file.new first, and only if it succeeds the file would be renamed to > proper name. It can "save some lives". > > Greets, > Jacek > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From mwedel at scruz.net Mon May 14 23:53:29 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:03:56 2005 Subject: [CF List] Crossfire 1.0.0 released. Message-ID: <3B00B649.51CB47E5@scruz.net> Crossfire 1.0.0 has been released. This is the first public release/release for wide spread distribution. Extenstive testing has gone out, and the server appears quite stable. NOTE TO MIRROR SITES: The primary site (ftp.scruz.net) has limited download bandwidth per day. You can also get this release off of sourceforge.net. Files released for this version: sums (bsd) filename 64947 1567 crossfire-1.0.0-arch.tar.bz2 29912 1858 crossfire-1.0.0-arch.tar.gz 44121 2995 crossfire-1.0.0-maps.tar.bz2 11006 4327 crossfire-1.0.0-maps.tar.gz 21265 2703 crossfire-1.0.0.tar.bz2 24930 239 crossfire-client-1.0.0.tar.gz Sums (md5) 18c3cff268c55a7561c785f6202ba715 crossfire-1.0.0-arch.tar.bz2 25990ae2ecdabcb4a2195dce92cc335a crossfire-1.0.0-arch.tar.gz 00b045172663768997a7b4f7e5dcf64c crossfire-1.0.0-maps.tar.bz2 d30eb96538627a899edd22b5cf2f2323 crossfire-1.0.0-maps.tar.gz bece4993c7ce9e3b15347c723f2a0d93 crossfire-1.0.0.tar.bz2 0bb73a6ea4268ecd4a5720128ecdf9c5 crossfire-1.0.0.tar.gz c79bf87ddc71bbee4ab46f64f3c908c7 crossfire-client-1.0.0.tar.gz crossfire-client-1.0.0 is the client (X11) distribution - standard X11 and gtk interfaces are provided. crossfire-1.0.0.tar.{gz/bz2} contains the server code with prebuilt archetype and image files. crossfire-1.0.0.arch.tar.{gz/bz2} contains the unpacked archetype changes. This is not needed if you only want to compile the server and play the game. crossfire-1.0.0-maps.tar.{gz/bz2} contains the maps. This is needed with the server distribution. FOR FIRST TIME USERS: You will only need the appropriate server, map and client file. You do not need the arch file. If you are a first time user, you may want the doc file unless you are using a web based player referance. If you just want to play the game at some remote server, you need the client and perhaps some version of the doc file. Crossfire is avaible on the following ftp sites Primary: ftp://ftp.scruz.net:/users/mwedel/public (165.227.192.254) ftp://ftp.sourceforge.net:/pub/sourceforge/crossfire (64.28.67.101) ftp://ftp.ifi.uio.no:/pub/crossfire (129.240.64.44) Secondary: ftp://ftp.real-time.com/pub/games/crossfire ftp://ftp.cs.city.ac.uk:/pub/games/crossfire/ ftp://ftp.sunet.se:/pub/unix/games/crossfire (130.238.127.3) ftp://ftp.cs.titech.ac.jp:/pub/games/crossfire ftp://mirror.aarnet.edu.au/games/roguelike/crossfire/ ftp://crossfire.futt.org//pub/crossfire I uploaded this version to just ftp.scruz.net and sourceforge- it should be on the other ftp sites in a short time Mark Wedel mwedel@scruz.net ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Changes: Client: Changes for 1.0.0: player.c: Fix for client crashes if player enters really long commands (like say .....). MSW 2001-05-08 gx11.c,command.c: Remove some debug statements which really should not be there for 1.0, and which are not really useful anyways. items_types, item_types.h: Varioius minor updates. MSW 2001-05-04 gx11.c: Fix bug that causes gtk client not to update weapon speed. metaserver.c: Have the listing get sorted by hostname to make it easier to find the host the user may want. MSW 2001-05-02 ------------------------------------------------------------------------------ Server: Changes for 1.0.0: common/living.c: Fix AC wrapping problem - now limit ac to +/- 120. MSW 2001-05-12 include/config.h: Add NO_POLYMORPH feature selection include/spellist.h: If NO_POLYMORPH is set, make it so that polymorph will not show up in wands/rods server/spell_util.c: Handling for NO_POLYMORPH selection MSW 2001-05-11 server/rune.c: Make sure rune message is newline terminated. Fix map corruption problem. MSW 2001-05-10 Various improvements to make finding memory leaks easier. common/anim.c: Add free_all_anim function common/arch.c: Modify free_all_arch to free more data common/init.c: If running under MEMORY_DEBUG, don't pre-allocate objects. common/map.c: Add free_all_maps functiion. common/object.c: Modify object allocations if using MEMORY_DEBUG to only malloc one object at a time, and not pre-allocate objects. common/readable.c: Fix memory leak. common/shstr.c: Include autoconf.h so it can pull in dmalloc.h file. include/config.h: Remove notes of what was removed a long time ago. Add MEMORY_DEBUG option. include/libproto.h, include/sockproto.h, include/sproto.h: automatic rebuild server/c_misc.c: Fix 'malloc info command so it reports right memory total for maps. Add command_style_map_info which sums up memory used by style maps. server/commands.c: Add style_info wiz command which dumps memory usage for style maps. server/init.c: Have sighup handler call cleanup function. server/main.c: Fix clean_tmp_files which could result in crash if one of the maps in memory has 0 reset time. Modify cleanup function to free more data. server/player.c: op_on_battleground: Fix compile warning about unuused variable. socket/init.c: Change name of free_all_ericserver to free_all_newserver, have it free all face data. MSW 2001-05-08 socket/item.c: Modify look_at to not stop when it finds the first invisible object. server/monster.c: Modify monster_check_pickup to check to see if the next object got destroyed. I'm not sure the exact way this happens, but I've seen one crash where this did happen - I'm guess some function further down in the monster_check_apply look may call this or destroy the item. MSW 2001-05-01 common/object.c: Add clear_owner function. include/libproto.h: rebuild. server/player.c: Modify op_on_battleground to look for battleground anyplace on space. Temp for for wall of thorns on space - as long as maps don't try to abuse the use of battlegrounds, should be OK. server/time.c: Add clear_owner call to stop_arrow. Fixes problem of thrown objects not getting saved. MSW 2001-04-28 common/object.c: Have update_object map the look window for redraw if the object is not something the client normally animates (like a lever). MSW 2001-04-27 server/apply.c: Modify apply_id_altar check for player - had a && instead of a ||. socket/item.c: Modify ApplyCmd so a removed player can not apply objects. Fix crashes caused by players applying savebeds after they have used the bed. MSW 2001-04-26 server/spell_util.c: have put_a_monster generate random monster abilities. TODO, doc/mapguide: Various minor updates. MSW 2001-04-25 server/c_object.c: Pass right object to query_cost_string so that if you pick up an unpaid object into a container, it generates the correct price. MSW 2001-04-22 server/c_wiz.c: fix shutdown and reset_map wizard commands/function so they no longer crash the server. MSW 2001-04-22 server/monster.c: add check to was_destroyed when monster fires an arrow. Call was certainly missing, and appears to be responsible for crash. MSW 2001-04-20 server/player.c: Clear op->chosen_skill when we get to the play_again prompt. Otherwise, the server may try to use this later on, and it no longer points to a valid object, so it results in a crash. MSW 2001-04-19 server/skill_util.c: Add missing call to out_of_map in skill_attack which could result in crashes if player is at edge of maps and decides to attack in direction off map. MSW 2001-04-18 server/attack.c: Remove error message about golem without owners, also add better checking before clering the op->contr->golem field. common/map.c: set status flag on maps to MAP_SAVING so remove_ob does not do extra work when we are deleting a map (ie, immediate reset) from emory. server/skills.c: If someone is stolen from a player, send an esrv_delete_item to the client so the clients inventory remains correct. MSW 2001-04-16 common/re-cmp.c: Modify re_cmp functiion so that it properly matches strings not at the start 'ie, dude chain will now match against the chain value'. server/monster.c: Properly alter direction monster moves if they are feared or confused. It was properly altering direction when monsters were using range attacks, but not if they were just wanting to move. MSW 2001-04-12 common/living.c: Don't use the last_heal object in experience objects as sp regen penalty. This should fix the problem of inconsistent sp regen rates - last_heal is used in experience objects if the permanent experience option is turned on. MSW 2001-04-11 PeterM: server/spell_util.c: fix peace so it gives experience common/button.c: change the "error" to a "debug" message to reduce server crashing. From tanner at real-time.com Wed May 16 13:07:25 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:56 2005 Subject: [CF List] New Mailing List Message-ID: <20010516130725.H4770@real-time.com> With the release of 1.0, I expect public CF servers to start to pop-up "all" over the place. Talking on irc philc said a list where all the admins of the public CF servers would be subscribed would be helpful in disseminating info amongst the admins and the user base. I agree and the below mailing list is the result. https://mailman.real-time.com/mailman/listinfo/crossfire-admin If you are an admin (wannabe admin :-) please subscribe to the above list. I see this list as being a place where admins can discuss issues on RUNNING a crossfire server. I still think crossfire-list would be where general discussion happens, where user comments/dicussion happens, etc.. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From highway at cstone.net Thu May 17 16:57:34 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:03:56 2005 Subject: [CF List] cursed potions Message-ID: <3B04494E.B96F143B@cstone.net> Okay, quick question... What happens if you drink a cursed potion? SeanMike From j.jongmans at aprogas.cx Thu May 17 17:19:12 2001 From: j.jongmans at aprogas.cx (Jasper Jongmans) Date: Thu Jan 13 18:03:56 2005 Subject: [CF List] cursed potions In-Reply-To: <3B04494E.B96F143B@cstone.net>; from highway@cstone.net on Thu, May 17, 2001 at 23:57:34 +0200 References: <3B04494E.B96F143B@cstone.net> Message-ID: <20010518001912.Q371@muisje.aprogas.cx> On 2001/05/17 23:57 Sean Michael Whipkey wrote: > What happens if you drink a cursed potion? I think it will have the reversed effect of what it normally has (i.e. dexterity -1 instead of +1) but I am not sure (never drank a cursed potion). Anyway, I recommend you just try it :). -- Jasper Jongmans j.jongmans@aprogas.cx Website http://130.89.222.57/~aprogas/ PGP key ftp://130.89.222.57/keys/pgp_dss.asc From joel at mamia.prninfo.com Thu May 17 12:57:37 2001 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 18:03:56 2005 Subject: [CF List] cursed potions In-Reply-To: <3B04494E.B96F143B@cstone.net> from "Sean Michael Whipkey" at May 17, 2001 05:57:34 PM Message-ID: <200105171757.NAA19046@mamia.prninfo.com> > > Okay, quick question... > > What happens if you drink a cursed potion? > > SeanMike The potion will do the opposite of its normal benifit. Example: You drink a cursed potion of Str,the potion will remove one point of Strength. I'm not sure about some of the other potions though,such as a potion of life. I only tried a stat potion. Btw,if you pray long enough,the potion will uncurse and will give stats instead of removing them. Joel Southall From Philipp.Currlin at t-online.de Thu May 17 17:20:24 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:03:56 2005 Subject: [CF List] cursed potions In-Reply-To: <3B04494E.B96F143B@cstone.net> References: <3B04494E.B96F143B@cstone.net> Message-ID: <01051800202402.05498@truth> If it's a stat potion, that stat will go down by one. If you had Strength 15, after drinking it you will have 14 If it's a resistance potion you will get minus that resistance e.g. you drink a potion of cold resistance (cursed) you will have cold resistance -90 afterwards instead of +90 You can uncurse potions by praying on an altar of your god PhilC On Thursday 17 May 2001 23:57, you wrote: > Okay, quick question... > > What happens if you drink a cursed potion? > > SeanMike > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From lembark at wrkhors.com Thu May 17 17:46:26 2001 From: lembark at wrkhors.com (Steven Lembark) Date: Thu Jan 13 18:03:56 2005 Subject: [CF List] cursed potions References: <200105171757.NAA19046@mamia.prninfo.com> Message-ID: <3B0454C2.BC015045@wrkhors.com> Joel South wrote: > > > > > Okay, quick question... > > > > What happens if you drink a cursed potion? > > > > SeanMike > > The potion will do the opposite of its normal benifit. Example: You > drink a cursed potion of Str,the potion will remove one point of Strength. > I'm not sure about some of the other potions though,such as a potion of > life. I only tried a stat potion. Btw,if you pray long enough,the potion > will uncurse and will give stats instead of removing them. that or cast remove curse? -- Steven Lembark 2930 W. Palmer St. Chicago, IL 60647 lembark@wrkhors.com 800-762-1582 From Philipp.Currlin at t-online.de Thu May 17 18:07:49 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:03:56 2005 Subject: [CF List] cursed potions In-Reply-To: <3B0454C2.BC015045@wrkhors.com> References: <200105171757.NAA19046@mamia.prninfo.com> <3B0454C2.BC015045@wrkhors.com> Message-ID: <01051801074903.05498@truth> On Friday 18 May 2001 00:46, you wrote: > Joel South wrote: > > > Okay, quick question... > > > > > > What happens if you drink a cursed potion? > > > > > > SeanMike > > > > The potion will do the opposite of its normal benifit. Example: You > > drink a cursed potion of Str,the potion will remove one point of > > Strength. I'm not sure about some of the other potions though,such as a > > potion of life. I only tried a stat potion. Btw,if you pray long > > enough,the potion will uncurse and will give stats instead of removing > > them. > > that or cast remove curse? Remove curse only works when you wear or wield a cursed item. It does not work on items that are just in your inventory. Only praying on an altar can remove curses from other equipment. PhilC From highway at cstone.net Thu May 17 22:17:49 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] cursed potions References: <3B04494E.B96F143B@cstone.net> <01051800202402.05498@truth> Message-ID: <3B04945D.D6055B22@cstone.net> Philipp Currlin wrote: > > If it's a stat potion, that stat will go down by one. > If you had Strength 15, after drinking it you will have 14 > > If it's a resistance potion you will get minus that resistance > e.g. you drink a potion of cold resistance (cursed) you will have cold > resistance -90 afterwards instead of +90 > > You can uncurse potions by praying on an altar of your god Thanks! This is exactly what I needed to know... SeanMike From tanner at real-time.com Fri May 18 00:59:40 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] Freshmeat entry Message-ID: <20010518005930.A5228@real-time.com> The freshmeat crew finally got the crossfire entry right. http://freshmeat.net/projects/crossfire/ -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From quinet at gamers.org Fri May 18 07:51:22 2001 From: quinet at gamers.org (Raphael Quinet) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] Advogato entry Message-ID: <200105181251.OAA22795@chapelle.eed.ericsson.se> If you have an account on Advogato (http://www.advogato.org/), you may want to register yourself as a crossfire developer or contributor. I created the crossfire entry on Advogato in 1999, when I still thought that I would have the time to make many useful contributions to the game... The CrossFire project page on Advogato can be found here: http://www.advogato.org/proj/CrossFire/ -Raphael From tanner at real-time.com Sun May 20 15:06:59 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] [news-admins@freshmeat.net: [fm #7714] (news-admins) Submission report - Crossfire, Windows DirectX Client branch] Message-ID: <20010520150659.A8264@real-time.com> Hmph. ----- Forwarded message from daniel pearson via RT ----- > Subject: [fm #7714] (news-admins) Submission report - Crossfire, Windows DirectX Client branch > From: daniel pearson via RT > To: Bob Tanner > Cc: > Date: Sun, 20 May 2001 09:15:24 -0400 (EDT) > > The following notes are in response to your recent freshmeat.net submission: > > - freshmeat doesn't list Windows software. We're happy to provide information > about this software's Unix/Linux version, but if you want to advertise the > Windows version, then you should use a site that targets Windows users. > http://windows.davecentral.com/ is such a site. > > Your contribution of a new branch has been respectfully rejected. > > Sincerely, > daniel pearson > > > > Note: Make sure you include the prefix '[fm #7714]' > in the subject when replying to this email. > ----- End forwarded message ----- -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From highway at cstone.net Tue May 22 15:41:01 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] player stuck Message-ID: <3B0ACEDD.8A9E7D27@cstone.net> I have a player stuck in the Burial Ground in Lake Country who can't get out. I can't get crossedit compiled on my machine. What can we do? He's a wraith, so he takes forever to starve... SeanMike From j.jongmans at aprogas.cx Tue May 22 15:56:30 2001 From: j.jongmans at aprogas.cx (Jasper Jongmans) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] player stuck In-Reply-To: <3B0ACEDD.8A9E7D27@cstone.net>; from highway@cstone.net on Tue, May 22, 2001 at 22:41:01 +0200 References: <3B0ACEDD.8A9E7D27@cstone.net> Message-ID: <20010522225630.G20557@muisje.aprogas.cx> On 2001/05/22 22:41 Sean Michael Whipkey wrote: > I have a player stuck in the Burial Ground in Lake Country who can't get > out. > > I can't get crossedit compiled on my machine. > > What can we do? He's a wraith, so he takes forever to starve... Have a Dungeon Master summon him to a different place: Let the DM stand on that place and use the command ``summon playername''. The playername is case sensitive. -- Jasper Jongmans j.jongmans@aprogas.cx Website http://130.89.222.57/~aprogas/ PGP key ftp://130.89.222.57/keys/pgp_dss.asc From highway at cstone.net Tue May 22 16:24:38 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] player stuck References: <3B0ACEDD.8A9E7D27@cstone.net> <20010522225630.G20557@muisje.aprogas.cx> Message-ID: <3B0AD916.132FBAD0@cstone.net> Jasper Jongmans wrote: > > On 2001/05/22 22:41 Sean Michael Whipkey wrote: > > I have a player stuck in the Burial Ground in Lake Country who can't get > > out. > > > > I can't get crossedit compiled on my machine. > > > > What can we do? He's a wraith, so he takes forever to starve... > > Have a Dungeon Master summon him to a different place: Let the DM stand on > that place and use the command ``summon playername''. The playername is case > sensitive. As the admin of a server, how do I become the DM? SeanMike From Philipp.Currlin at t-online.de Tue May 22 16:41:19 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] player stuck In-Reply-To: <3B0AD916.132FBAD0@cstone.net> References: <3B0ACEDD.8A9E7D27@cstone.net> <20010522225630.G20557@muisje.aprogas.cx> <3B0AD916.132FBAD0@cstone.net> Message-ID: <01052223411901.00436@truth> On Tuesday 22 May 2001 23:24, you wrote: > Jasper Jongmans wrote: > > On 2001/05/22 22:41 Sean Michael Whipkey wrote: > > > I have a player stuck in the Burial Ground in Lake Country who can't > > > get out. > > > > > > I can't get crossedit compiled on my machine. > > > > > > What can we do? He's a wraith, so he takes forever to starve... > > > > Have a Dungeon Master summon him to a different place: Let the DM stand > > on that place and use the command ``summon playername''. The playername > > is case sensitive. > > As the admin of a server, how do I become the DM? > > SeanMike > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list There is a file in /usr/games/crossfire/share/crossfire called "dm_file". Enter your name and password there and after restart of the server you can become the DM with "dm yoursecretpassword". To end DM type: nowiz PhilC From mwedel at scruznet.com Tue May 22 16:58:39 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] player stuck In-Reply-To: <01052223411901.00436@truth> Message-ID: On Tue, 22 May 2001, Philipp Currlin wrote: > > There is a file in /usr/games/crossfire/share/crossfire called "dm_file". > Enter your name and password there and after restart of the server you can > become the DM with "dm yoursecretpassword". > To end DM type: nowiz You don't need to restart the file. the dm_file is read everytime someone enters the dm command. So you can change it basically at any time and get the desired effect. Note that if the player actually saves/leaves the game, several things may happen: 1) If its a random map, player should end up home after some amount of time. 2) If not a random map, and server has backup_save_at_home set in config.h, player will return to home. 3) You can manually edit the player file, changing the map to something like /city/city and player will end up there. From peterm at tonks.EECS.Berkeley.EDU Tue May 22 18:39:53 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] player stuck In-Reply-To: Your message of "Tue, 22 May 2001 16:41:01 EDT." <3B0ACEDD.8A9E7D27@cstone.net> Message-ID: <200105222339.f4MNdrx11696@tonks.EECS.Berkeley.EDU> > I have a player stuck in the Burial Ground in Lake Country who can't get > out. > > I can't get crossedit compiled on my machine. > > What can we do? He's a wraith, so he takes forever to starve... > > SeanMike > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From peterm at tonks.EECS.Berkeley.EDU Tue May 22 18:41:01 2001 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] player stuck In-Reply-To: Your message of "Tue, 22 May 2001 16:41:01 EDT." <3B0ACEDD.8A9E7D27@cstone.net> Message-ID: <200105222341.f4MNf1F11711@tonks.EECS.Berkeley.EDU> Oops, sorry for previous contentless message. It's possible for a player to get HIMSELF out of that area. I forget exactly how, but a minute or two with the map editor will show you the way. Alternately, there are hints contained in the map itself. PeterM > I have a player stuck in the Burial Ground in Lake Country who can't get > out. > > I can't get crossedit compiled on my machine. > > What can we do? He's a wraith, so he takes forever to starve... > > SeanMike > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From Kimmo.Hoikka at Digia.com Wed May 23 01:03:28 2001 From: Kimmo.Hoikka at Digia.com (Kimmo Hoikka) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] player stuck References: <200105222341.f4MNf1F11711@tonks.EECS.Berkeley.EDU> Message-ID: <3B0B52B0.7DC200BA@Digia.com> If it's the burial ground in the mountains, you're supposed to say something. I recall it read in some of the tombstones there, you can check the mapfile (type mapinfo and look the match in the mapfile) > Oops, sorry for previous contentless message. > > It's possible for a player to get HIMSELF out of that area. > > I forget exactly how, but a minute or two with the map editor > will show you the way. > > Alternately, there are hints contained in the map itself. > > PeterM > > I have a player stuck in the Burial Ground in Lake Country who can't get > > out. > > > > I can't get crossedit compiled on my machine. > > > > What can we do? He's a wraith, so he takes forever to starve... > > > > SeanMike > > _______________________________________________ > > crossfire-list mailing list > > crossfire-list@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-list > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list -- Digital Information Architects Inc. Digia Oy Kimmo Hoikka Software Architect Kimmo.Hoikka@Digia.com tel: (direct) +358 (0)424 5050 505 fax: +358 (0)424 5050 700 Laserkatu 6 FIN-53850 Lappeenranta Finland www.digia.com mmm.digia.com From mwedel at scruz.net Wed May 23 01:25:45 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:03:57 2005 Subject: [CF List] player stuck References: <200105222341.f4MNf1F11711@tonks.EECS.Berkeley.EDU> <3B0B52B0.7DC200BA@Digia.com> Message-ID: <3B0B57E9.88CE13E0@scruz.net> Kimmo Hoikka wrote: > > If it's the burial ground in the mountains, you're supposed to say something. > I recall it read in some of the tombstones there, you can check the mapfile > (type mapinfo and look the match in the mapfile) Of course, that is not the proper solution for the player itself. Is the problem perhaps that to players, it appears that they are improperly trapped (ie, bug) when there is in fact an exit? Perhaps have a more obvioius clue (dead body or the like) that mentions there is a way out, but not what it is, so it at least provides some confidence to players that they can get out? From Kimmo.Hoikka at Digia.com Wed May 23 01:36:32 2001 From: Kimmo.Hoikka at Digia.com (Kimmo Hoikka) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] player stuck References: <200105222341.f4MNf1F11711@tonks.EECS.Berkeley.EDU> <3B0B52B0.7DC200BA@Digia.com> <3B0B57E9.88CE13E0@scruz.net> Message-ID: <3B0B5A70.5ECD7FA@Digia.com> Unfortunately it often happens that the mapmaker has left no obvious clues, so the player will have to ask someone or look at the mapfile. That problem should always be considered thoroughly when making and accepting new maps, however most of the old maps are not all so good in that sense... > Kimmo Hoikka wrote: > > > > If it's the burial ground in the mountains, you're supposed to say something. > > I recall it read in some of the tombstones there, you can check the mapfile > > (type mapinfo and look the match in the mapfile) > > Of course, that is not the proper solution for the player itself. > > Is the problem perhaps that to players, it appears that they are improperly > trapped (ie, bug) when there is in fact an exit? Perhaps have a more obvioius > clue (dead body or the like) that mentions there is a way out, but not what it > is, so it at least provides some confidence to players that they can get out? > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list -- Digital Information Architects Inc. Digia Oy Kimmo Hoikka Software Architect Kimmo.Hoikka@Digia.com tel: (direct) +358 (0)424 5050 505 fax: +358 (0)424 5050 700 Laserkatu 6 FIN-53850 Lappeenranta Finland www.digia.com mmm.digia.com From lembark at wrkhors.com Wed May 23 02:11:12 2001 From: lembark at wrkhors.com (Steven Lembark) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] player stuck References: <200105222341.f4MNf1F11711@tonks.EECS.Berkeley.EDU> <3B0B52B0.7DC200BA@Digia.com> <3B0B57E9.88CE13E0@scruz.net> <3B0B5A70.5ECD7FA@Digia.com> Message-ID: <3B0B6290.A1E65D75@wrkhors.com> > Unfortunately it often happens that the mapmaker has left no obvious clues, so the > player will have to ask someone or look at the mapfile. That problem should always > be considered thoroughly when making and accepting new maps, however most of the > old maps are not all so good in that sense... in this case the map does say "What is my name?" when you are atop a tombstone. viewing the tombstone gives an excellent clue as to what should be said. along the edge of the room are any number of spots where the live/die remarks show up. since the entire room has disabled magic it also gives a clue that there must be some way out (else word of recall wouldn't have been disabled). question of artistic taste: would this seem sufficient? aside: if the map maker code won't compile just find the map file and grep -i 'match' to get the magic words. or isn't this doable in the original situation? -- Steven Lembark 2930 W. Palmer St. Chicago, IL 60647 lembark@wrkhors.com 800-762-1582 From highway at cstone.net Wed May 23 09:02:49 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] player stuck References: <200105222341.f4MNf1F11711@tonks.EECS.Berkeley.EDU> <3B0B52B0.7DC200BA@Digia.com> <3B0B57E9.88CE13E0@scruz.net> Message-ID: <3B0BC309.CECE936D@cstone.net> Mark Wedel wrote: > Is the problem perhaps that to players, it appears that they are improperly > trapped (ie, bug) when there is in fact an exit? Perhaps have a more obvioius > clue (dead body or the like) that mentions there is a way out, but not what it > is, so it at least provides some confidence to players that they can get out? That's what it looked like to him. The problems he had in getting out were two-fold: 1. It wasn't clear where he needed to stand. To be honest, had he not been standing on the ghost when I came in and said the magic word, he'd still be stuck there. 2. The one time he did say the word, it didn't recognize it for some reason (not having seen what he typed, I don't know if he failed to capitalize it or what the problem was). I think in this case having it be more obvious at least where to stand would be the single biggest help, and the second one might be more of a scripting issue (as discussed on the -devel list) then anything... SeanMike From scott at campy.tymnet.com Wed May 23 03:25:06 2001 From: scott at campy.tymnet.com (Scott Wedel) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] player stuck Message-ID: <200105230825.CAA01749@moots.tymnet.com> I think the difficulty of knowing whether a map is a trap needing to solve a puzzle to escape must be judged in the context of adjacent maps. If this map is one of a series of puzzle maps then it sounds like a reasonable puzzle. If it is more of a standalone map and the player has no reason to expect a puzzle then the map should have a very clear statement that it is a puzzler. Something like a note saying "For all that also end up trapped here: This puzzle is not that hard, but I, Tekwla the Generous, will provide the secret for you. Go to the exit and say " - bottom of the note torn off. I know that isn't very clever, but since players can get accidently trapped in a room with no escape other than word of recall then it needs to be exceptionally clear when the room is a puzzle needing to be solved. > >> Unfortunately it often happens that the mapmaker has left no obvious clues, so the >> player will have to ask someone or look at the mapfile. That problem should always >> be considered thoroughly when making and accepting new maps, however most of the >> old maps are not all so good in that sense... > >in this case the map does say "What is my name?" when you are atop >a tombstone. viewing the tombstone gives an excellent clue as to >what should be said. along the edge of the room are any number of >spots where the live/die remarks show up. since the entire room >has disabled magic it also gives a clue that there must be some >way out (else word of recall wouldn't have been disabled). > >question of artistic taste: would this seem sufficient? > > >aside: if the map maker code won't compile just find the map >file and grep -i 'match' to get the magic words. or isn't this >doable in the original situation? > >-- > Steven Lembark 2930 W. Palmer St. > Chicago, IL 60647 > lembark@wrkhors.com 800-762-1582 >_______________________________________________ >crossfire-list mailing list >crossfire-list@lists.real-time.com >https://mailman.real-time.com/mailman/listinfo/crossfire-list From dubious at 2xtreme.net Thu May 24 18:47:27 2001 From: dubious at 2xtreme.net (cf) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] Not getting sounds (gtk+ client) Message-ID: <200105242342.f4ONgBr14942@www.interlinkbiotech.com> Congratulations, incidentally, on the 1.0 release! I got a server set up on my home network and have finally made time to sit down and "seriously" play with Crossfire for the first time since I heard of it two years ago, and I'm quite impressed. I'm having trouble, though, getting sound. The cfsndserv process seems to be running, but I never hear any sound from it. No error messages show up on the console, so I can't tell what the problem might be. If it helps, I'm running it under KDE 2.x, and I've tried invoking it with a plain "gcfclient -png -cache" and with "artsdsp gcfclient -png -cache". Two machines I've tried it on are using the alsa drivers, and another is just using the OSS driver from the kernel (2.4.4). Any suggestions? As far as I can tell from perusing the older mailing lists, either I'm the only one with this problem, or nobody else has noticed the lack of sound (which is possible - I find the game quite fun without the sound anyway, I'm just wondering why I'm not able to get it working...) Thanks! -- "Given the pace of technology, I propose we leave math to the machines and go play outside." - Calvin From mwedel at scruznet.com Thu May 24 20:04:16 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] Not getting sounds (gtk+ client) In-Reply-To: <200105242342.f4ONgBr14942@www.interlinkbiotech.com> Message-ID: On Thu, 24 May 2001, cf wrote: First - did you download the sound files? Second - check audio volume. I find that I need the crank up the volume a bit higher for crossfire sounds to be as audible as some other games. If you compiled the game yourself, make sure the sound definition files match where you have actually installed the sound files (this is the sounds* file in the client directory). I know sound works with OSS/kernel 2.4 as that is what I use. Don't know about ALSA. From olle at viksten.com Thu May 24 23:05:04 2001 From: olle at viksten.com (Olle Viksten) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] Not getting sounds (gtk+ client) In-Reply-To: References: Message-ID: <01052506050500.04088@pingu> fredagen den 25 maj 2001 03:04 you wrote: > On Thu, 24 May 2001, cf wrote: > > First - did you download the sound files? > > Second - check audio volume. I find that I need the crank up the > volume a bit higher for crossfire sounds to be as audible as some other > games. > > If you compiled the game yourself, make sure the sound definition > files match where you have actually installed the sound files > (this is the sounds* file in the client directory). > > I know sound works with OSS/kernel 2.4 as that is what I use. Don't > know about ALSA. I'm having the same problem, no sound. I'm also using KDE, 2.1 and suspect the problem is with KDE's sound configuration. But crossfire is very good even without sound. Olle Viksten From dubious at 2xtreme.net Thu May 24 23:16:23 2001 From: dubious at 2xtreme.net (dubious (cf)) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] Not getting sounds (gtk+ client) In-Reply-To: <01052506050500.04088@pingu> References: <01052506050500.04088@pingu> Message-ID: <01052421162400.00212@mRNA> Yup, in fact I downloaded both versions (the .au and the .raw) just in case. I put them in /usr/local/lib/sounds which the client compile lists as the default. I'll recheck the sound volume when I get a chance, but I SUSPECT that's not the problem. It could be KDE, as I occasionally run into problems getting to the sound channel from other programs (e.g. Xine), but normally running the programs through artsdsp correctly passes the sounds through. I do remember that last time I tried crossfire at all (compiled server and played for about 1/2 hour...about 2 years ago...) I was getting some sound, but it was very intermittent during the game, and at the time amounted to the occasional "blip" of sound that was apparently associated with combat...I don't remember what WM I was using at the time, it may have been KDE 1.x or it could have been fvwm2. As you say, Crossfire's a lot of fun even without the sounds, so it's not an urgent issue for me, I'm just intensely curious to find out what I'm screwing up... On Thursday 24 May 2001 21:05, you wrote: > fredagen den 25 maj 2001 03:04 you wrote: > > On Thu, 24 May 2001, cf wrote: > > > > First - did you download the sound files? > > > > Second - check audio volume. I find that I need the crank up the > > volume a bit higher for crossfire sounds to be as audible as some other > > games. > > > > If you compiled the game yourself, make sure the sound definition > > files match where you have actually installed the sound files > > (this is the sounds* file in the client directory). > > > > I know sound works with OSS/kernel 2.4 as that is what I use. Don't > > know about ALSA. > > I'm having the same problem, no sound. I'm also using KDE, 2.1 and suspect > the problem is with KDE's sound configuration. But crossfire is very good > even without sound. > > Olle Viksten -- "Given the pace of technology, I propose we leave math to the machines and go play outside." - Calvin From tanner at real-time.com Fri May 25 22:12:20 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] Mirrors vs Sourceforge Message-ID: <20010525221220.L29366@real-time.com> Do we still need the mirrors for the crossfire source? With sourceforge, we have all(?) that we need, expect maybe redundancy. I ask this because I was talking to Mark about switching mirrors from ftp to rsync over ssh. Mostly for security and also for efficiency. But, he does not have the privs to put up an rsync daemon at his isp, so we talked about moving the primary ftp to Real Time. Then I got to thinking that do we need the mirrors? Comments? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From highway at cstone.net Wed May 30 15:16:23 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] wraith/devourers question Message-ID: <3B155517.A1D7CEA1@cstone.net> One of my players on our 1.0 server is a wraith worshipping the devourers. He got the spell "Nightfall" from his own altar but it's denied to him. Why is that? SeanMike From trevj at mail.mainetoday.com Thu May 31 11:20:50 2001 From: trevj at mail.mainetoday.com (Trevor Jennings) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] How do you pray on an alter? Message-ID: <200105311610.MAA15887@mail.mainetoday.com> Hello, I know this is a very newbie question so I apologise for that. I was wondering how the heck do you pray at an altar? I've read the survival guide and manual and it mentions about what can be done with the different 'cults' and you pray to a god for special powers etc....but I'll be darned if I can figure out just HOW do you actually go about joining. Is it the 'use_skill praying' command? Cheers, - Trevor |Trevor Jennings |Programmer/System Administrator |MaineToday.com - Division of Blethen Maine Newspapers |Email: trevj@portland.com |ICQ: 656540 Phone: (207) 822 4070 From Philipp.Currlin at t-online.de Thu May 31 11:36:41 2001 From: Philipp.Currlin at t-online.de (Philipp Currlin) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] How do you pray on an alter? In-Reply-To: <200105311610.MAA15887@mail.mainetoday.com> References: <200105311610.MAA15887@mail.mainetoday.com> Message-ID: <01053118364100.00620@truth> Hi Yes, the easiest way to pray is to bind 'use_skill praying' to a key. Then you just have to press the key to pray. This can also be done for other skills, like literacy, so you can identify books and scrolls by just pressing the key. PhilC On Thursday 31 May 2001 18:20, Trevor Jennings wrote: > Hello, > > I know this is a very newbie question so I apologise for that. I was > wondering how the heck do you pray at an altar? I've read the survival > guide and manual and it mentions about what can be done with the different > 'cults' and you pray to a god for special powers etc....but I'll be darned > if I can figure out just HOW do you actually go about joining. Is it the > 'use_skill praying' command? > > Cheers, > > - Trevor > > |Trevor Jennings > |Programmer/System Administrator > |MaineToday.com - Division of Blethen Maine Newspapers > |Email: trevj@portland.com > |ICQ: 656540 Phone: (207) 822 4070 > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From j.jongmans at aprogas.cx Thu May 31 11:37:58 2001 From: j.jongmans at aprogas.cx (Jasper Jongmans) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] How do you pray on an alter? In-Reply-To: <200105311610.MAA15887@mail.mainetoday.com>; from trevj@mail.mainetoday.com on Thu, May 31, 2001 at 18:20:50 +0200 References: <200105311610.MAA15887@mail.mainetoday.com> Message-ID: <20010531183758.W20557@muisje.aprogas.cx> On 2001/05/31 18:20 Trevor Jennings wrote: > I know this is a very newbie question so I apologise for that. I was > wondering > how the heck do you pray at an altar? I've read the survival guide and > manual > and it mentions about what can be done with the different 'cults' and you > pray > to a god for special powers etc....but I'll be darned if I can figure out > just > HOW do you actually go about joining. Is it the 'use_skill praying' > command? ``use_skill praying'' will only pray once, it would be more useful to ``ready_skill praying'' and then use the keybinding that is associated with the fire command (usually . (dot)). Keep it pressed for a while (you will see the text ``You pray'' or ``You pray over the altar of X'' alot of times). Watch your grace and stop praying when it doesnt increase anymore (at low levels this is at maxgrace, at higher levels this is at maxgrace*2 when praying over an altar). You can find a list of Gods and their properties at . -- Jasper Jongmans j.jongmans@aprogas.cx Website http://130.89.222.57/~aprogas/ PGP key ftp://130.89.222.57/keys/pgp_dss.asc From philb at CSUA.Berkeley.EDU Thu May 31 10:31:21 2001 From: philb at CSUA.Berkeley.EDU (Philip Brown) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] java client update Message-ID: <20010531083121.A91865@soda.csua.berkeley.edu> Hi crossfire folks, long time no write :-) I'm happy to announce that the java client has been updated, so that it is now semi-usable with a v1.0 server. It's also a little friendlier when it comes to keyboard input, now. http://www.bolthole.com/jcrossclient/ Okay, it still has some "issues" to be worked out :-/ But I fixed the really big issue, in that I fixed my Xpm class to read xpms that have colors indexed by #xxxxxx, instead of only by english names like "gray33". So now all the images should actually display!! I think its neat that you can play a game like crossfire through java, so I wanted to "keep the dream alive" :-) If anyone wants to make an applet to go with a public crossfire server they are running, gimme a holler (to the email listed on the web page, if you want fast response) As the web page says, there are still a few features lacking. But if people give me an occasional nudge, I'll get around to em. I just wanted to release this initial update before I lapsed into a coding coma again :-) From highway at cstone.net Thu May 31 11:47:29 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] How do you pray on an alter? References: <200105311610.MAA15887@mail.mainetoday.com> <20010531183758.W20557@muisje.aprogas.cx> Message-ID: <3B1675A1.165BE56E@cstone.net> Jasper Jongmans wrote: > times). Watch your grace and stop praying when it doesnt increase anymore Actually, if you keep praying, you won't gain grace, but you will at times gain weapon blessings, holy possession, uncursing of potions, etc. Of course, it's boring, but hey, if you really need an item uncursed or your weapon blessed you've just got to slog through it. SeanMike From olle at viksten.com Thu May 31 12:22:46 2001 From: olle at viksten.com (Olle Viksten) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] How do you pray on an alter? In-Reply-To: <20010531183758.W20557@muisje.aprogas.cx> References: <200105311610.MAA15887@mail.mainetoday.com> <20010531183758.W20557@muisje.aprogas.cx> Message-ID: <01053119224600.01320@pingu> torsdagen den 31 maj 2001 18:37 wrote Jasper Jongmans: > ``use_skill praying'' will only pray once, it would be more useful to > ``ready_skill praying'' and then use the keybinding that is associated with > the fire command (usually . (dot)). Keep it pressed for a while (you will > see the text ``You pray'' or ``You pray over the altar of X'' alot of > times). Watch your grace and stop praying when it doesnt increase anymore > (at low levels this is at maxgrace, at higher levels this is at maxgrace*2 > when praying over an altar). You can find a list of Gods and their > properties at > ml>. Or to save yourself even more typing bind use_skill pray;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire;stay fire; to a key,I'm using 1. My mailer wraps the lines the above should of course be on one line. Olle Viksten From dubious at 2xtreme.net Thu May 31 12:41:49 2001 From: dubious at 2xtreme.net (cf) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] How do you pray on an alter? In-Reply-To: <200105311610.MAA15887@mail.mainetoday.com> References: <200105311610.MAA15887@mail.mainetoday.com> Message-ID: <200105311736.f4VHaUr23034@www.interlinkbiotech.com> On Thursday 31 May 2001 09:20, you wrote: > Hello, > > I know this is a very newbie question so I apologise for that. I was > wondering how the heck do you pray at an altar? I've read the survival > guide and manual and it mentions about what can be done with the different > 'cults' and you pray to a god for special powers etc....but I'll be darned > if I can figure out just HOW do you actually go about joining. Is it the > 'use_skill praying' command? In addition to the advice given elsewhere, it also wasn't immediately obvious to me but you have to be standing "on" the altar, not next to it, when you do the praying bit... -- "Given the pace of technology, I propose we leave math to the machines and go play outside." - Calvin From highway at cstone.net Thu May 31 13:18:41 2001 From: highway at cstone.net (Sean Michael Whipkey) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] goblin king Message-ID: <3B168B01.15E50FEE@cstone.net> So, I'm trying to get rank in Scorn so I can my a coworker call me Sir.:) First, when I walk in to the castle, it says "the knights salute the baronet of Scorn" when I haven't achieved that rank (I think) yet. Second, I cannot find the Goblin King, to get the rank of knight! Does anyone know where he is? I've cleared out the fortress northeast of Navar, Castle Aaaargh, and several other places... Thanks, SeanMike From hsteoh at quickfur.yi.org Thu May 31 13:19:57 2001 From: hsteoh at quickfur.yi.org (H. S. Teoh) Date: Thu Jan 13 18:03:58 2005 Subject: [CF List] goblin king In-Reply-To: <3B168B01.15E50FEE@cstone.net> Message-ID: <20010531141957.A15576@crystal> On Thu, May 31, 2001 at 02:18:41PM -0400, Sean Michael Whipkey wrote: > So, I'm trying to get rank in Scorn so I can my a coworker call me > Sir.:) > > First, when I walk in to the castle, it says "the knights salute the > baronet of Scorn" when I haven't achieved that rank (I think) yet. > > Second, I cannot find the Goblin King, to get the rank of knight! Does > anyone know where he is? I've cleared out the fortress northeast of > Navar, Castle Aaaargh, and several other places... [snip] You've gone *way* too far :-) The goblin king lives in the random dungeon in the hole just outside Scorn, on the mountains to the northeast (between Euthville and Scorn), just next to Barad-Dur. T -- The design document is what the program should do. The source code is what the program actually does. If you're lucky, the two may resemble each other... From lembark at wrkhors.com Thu May 31 16:57:50 2001 From: lembark at wrkhors.com (Steven Lembark) Date: Thu Jan 13 18:03:59 2005 Subject: [CF List] How do you pray on an alter? References: <200105311610.MAA15887@mail.mainetoday.com> <20010531183758.W20557@muisje.aprogas.cx> Message-ID: <3B16BE5E.BBE7DF7D@wrkhors.com> http://mids.student.utwente.nl/~dnh/gods_pantheon/gods_pantheon_new.html looking over the page, it seems they gave Devourers a bum rap. the increased sustinence is rather nice, you get to summon useful monsters and being denied fire isn't at all painful for a wraith :-) -- Steven Lembark 2930 W. Palmer St. Chicago, IL 60647 lembark@wrkhors.com 800-762-1582